Storage Cloud Murah Tidak Selalu Hemat: Cara Me…

Memilih storage cloud sering dimulai dari angka yang paling mudah dibandingkan: harga per gigabita per bulan. Masalahnya, biaya nyata tidak hanya muncul saat data disimpan. Ketika file sering dibaca, dipindahkan, diambil kembali dari arsip, atau disimpan terlalu lama karena aturan retensi yang keliru, tagihan bisa naik tanpa terasa.

Karena itu, storage cloud sebaiknya diperlakukan seperti gudang dengan beberapa zona. Barang yang dipakai setiap hari diletakkan dekat pintu. Barang yang jarang disentuh bisa dipindahkan ke area yang lebih murah, tetapi aksesnya tidak selalu secepat dan semurah area utama.

Storage class bukan sekadar pilihan harga

Penyedia cloud biasanya menawarkan beberapa storage class, yaitu kategori penyimpanan dengan karakteristik harga dan akses yang berbeda. Kelas standar cocok untuk data yang sering dibaca, sedangkan kelas dingin atau arsip ditujukan untuk data yang jarang disentuh.

Google Cloud, misalnya, membedakan Standard, Nearline, Coldline, dan Archive. Nearline memiliki masa penyimpanan minimum 30 hari, Coldline 90 hari, dan Archive 365 hari. Kelas yang lebih dingin biasanya menurunkan biaya penyimpanan, tetapi dapat menambahkan biaya pengambilan data atau aturan retensi minimum. ([docs.cloud.google.com](https://docs.cloud.google.com/storage/docs/storage-classes?utm_source=openai))

Azure menggunakan istilah Hot, Cool, Cold, dan Archive. Dokumentasinya menjelaskan bahwa Cool dan Cold memiliki masa penyimpanan minimum masing-masing 30 dan 90 hari, sedangkan Archive ditujukan untuk data yang jarang diakses dan dapat membutuhkan waktu pemulihan hingga hitungan jam. ([learn.microsoft.com](https://learn.microsoft.com/en-us/azure/storage/blobs/access-tiers-overview?utm_source=openai))

Di Amazon S3, data dapat dipindahkan melalui aturan Lifecycle ke kelas seperti Standard-IA, Intelligent-Tiering, Glacier Flexible Retrieval, atau Glacier Deep Archive. Pemindahan tersebut dapat diatur berdasarkan umur objek, tag, maupun status versinya. ([docs.aws.amazon.com](https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-transition-general-considerations.html?utm_source=openai))

Empat biaya yang sering terlupakan

1. Biaya penyimpanan

Ini adalah biaya yang paling mudah dilihat: berapa banyak data yang disimpan dan berapa lama data tersebut berada di suatu kelas. Untuk data besar yang jarang berubah, kelas dingin memang dapat menghemat biaya bulanan.

Namun, penghematan tersebut baru masuk akal jika pola aksesnya sesuai. Memindahkan database aktif, file yang sering diproses, atau aset website ke kelas arsip hanya karena tarif simpannya murah bisa menciptakan masalah performa dan biaya tambahan.

2. Biaya pengambilan dan transfer data

Beberapa kelas penyimpanan mengenakan biaya ketika data dibaca kembali. Jika sebuah tim menyimpan log di kelas arsip tetapi setiap hari membuat laporan dari seluruh log tersebut, biaya pengambilan data bisa menghapus penghematan yang diharapkan.

Hal serupa berlaku untuk transfer keluar atau egress, yaitu biaya ketika data dikirim dari cloud ke internet, pusat data lain, atau layanan berbeda. Besarnya biaya bergantung pada penyedia, wilayah, volume, dan jenis operasi. Karena itu, jangan hanya menghitung kapasitas penyimpanan; hitung juga berapa kali data akan dibaca dan ke mana data akan dikirim.

3. Biaya operasi

Object storage biasanya menghitung operasi seperti upload, download, listing, copy, dan perpindahan kelas. File berukuran kecil dalam jumlah sangat banyak dapat menghasilkan banyak operasi meskipun total kapasitasnya tidak besar.

Amazon S3, misalnya, secara default tidak memindahkan objek yang berukuran di bawah 128 KB melalui aturan Lifecycle karena biaya permintaan transisi dapat lebih besar daripada penghematan penyimpanan. ([docs.aws.amazon.com](https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-transition-general-considerations.html?utm_source=openai))

4. Biaya kesalahan desain

Biaya paling mahal kadang bukan angka di invoice, melainkan data yang sulit dipulihkan ketika dibutuhkan. Contohnya, rekaman transaksi disimpan di kelas yang memerlukan waktu rehidrasi, padahal tim keuangan membutuhkannya dalam beberapa menit.

Ini bukan berarti kelas arsip buruk. Kelas tersebut cocok untuk data yang memang jarang diakses, seperti rekaman lama, hasil ekspor historis, atau dokumen yang harus disimpan untuk kebutuhan kepatuhan. Yang penting, ekspektasi pemulihannya jelas sejak awal.

Cara menentukan kelas penyimpanan

Mulailah dari perilaku data, bukan dari nama produk. Tanyakan empat hal berikut:

Seberapa sering data dibaca? Data aktif dan sering diakses sebaiknya berada di kelas standar atau kelas otomatis yang dapat menyesuaikan pola akses.
Seberapa cepat data harus tersedia? Jika aplikasi membutuhkan respons langsung, hindari kelas dengan proses pemulihan yang memerlukan waktu lama.
Berapa lama data akan disimpan? Cocokkan masa retensi dengan aturan minimum penyimpanan. Data yang mungkin dihapus dalam beberapa hari tidak cocok ditempatkan di kelas dengan komitmen retensi berbulan-bulan.
Apakah data berubah atau hanya bertambah? File yang sering ditimpa dapat menghasilkan versi lama, biaya operasi, dan kebutuhan aturan pembersihan yang berbeda dari file arsip yang hanya ditulis sekali.

Lifecycle: biarkan aturan yang bekerja

Lifecycle adalah aturan otomatis untuk memindahkan atau menghapus objek berdasarkan usia, awalan nama, tag, atau versinya. Contoh sederhana untuk log aplikasi dapat berbentuk seperti ini:

Hari 0-30   : Standard
Hari 31-90  : Nearline atau kelas akses jarang
Hari 91+    : Archive atau hapus sesuai kebijakan

Angka tersebut bukan resep universal. Gunakan data penggunaan aktual untuk menentukan batasnya. Jika log masih sering dipakai untuk investigasi selama 60 hari, memindahkannya pada hari ke-30 mungkin terlalu agresif.

Aturan lifecycle juga perlu mencakup versi lama, file multipart yang gagal, dan objek sementara. Pada bucket yang mengaktifkan versioning, menghapus file terbaru belum tentu menghapus seluruh versi sebelumnya. Tanpa kebijakan pembersihan, kapasitas dapat terus bertambah meski folder terlihat rapi.

Google Cloud menyediakan Object Lifecycle Management untuk mengatur perpindahan kelas, masa hidup objek, dan versi nonaktif. Dokumentasinya juga mengingatkan bahwa sistem tidak memvalidasi apakah perpindahan kelas yang dibuat pengguna sudah sesuai dengan kebutuhan akses. ([docs.cloud.google.com](https://docs.cloud.google.com/storage/docs/lifecycle?utm_source=openai))

Apa artinya bagi kita?

Storage cloud murah bukan berarti semua data harus dipindahkan ke kelas paling dingin. Pilihan yang baik adalah pilihan yang cocok dengan pola akses dan target pemulihan.

Untuk aplikasi kecil, pendekatan praktisnya adalah memisahkan bucket atau awalan objek berdasarkan fungsi: active/ untuk data yang sering dipakai, logs/ untuk log sementara, dan archive/ untuk data historis. Dengan pemisahan ini, aturan lifecycle lebih mudah dibaca dan risiko salah menerapkan kebijakan menjadi lebih kecil.

Yang bisa dilakukan sekarang

Ambil data penggunaan storage dan transfer selama 30 hari terakhir.
Kelompokkan file berdasarkan frekuensi akses, bukan hanya berdasarkan ukuran.
Catat kebutuhan waktu pemulihan untuk setiap jenis data.
Buat lifecycle rule pada lingkungan uji sebelum menerapkannya ke data produksi.
Pasang alarm biaya dan tinjau laporan setelah aturan berjalan.
Uji pengambilan kembali sebagian data arsip agar prosedurnya tidak hanya terlihat benar di atas kertas.

Kesimpulannya, optimasi storage bukan perlombaan mencari tarif per gigabita paling rendah. Tujuannya adalah menempatkan setiap data di tempat yang sesuai: cukup cepat ketika dibutuhkan, cukup murah ketika hanya perlu disimpan, dan tetap bisa dipulihkan ketika keadaan tidak berjalan sesuai rencana.

Sumber & bacaan lebih lanjut

– Rio Yotto @rioyotto