Tagihan cloud jarang membesar karena satu file besar. Lebih sering, penyebabnya adalah ribuan atau jutaan objek kecil yang terus disimpan: hasil ekspor laporan, gambar lama, log aplikasi, artefak deployment, dan versi file yang sebenarnya sudah tidak pernah dibuka.
Object storage seperti Amazon S3, Google Cloud Storage, dan Azure Blob Storage menyediakan lifecycle policy, yaitu aturan otomatis untuk memindahkan objek ke kelas penyimpanan yang lebih murah atau menghapusnya setelah usia tertentu. Fitur ini bisa menjadi penghemat biaya yang efektif, tetapi juga bisa menghapus data penting jika dirancang hanya berdasarkan tebakan.
Lifecycle policy bukan sekadar aturan “hapus setelah 30 hari”
Dalam bentuk paling sederhana, lifecycle policy menjawab tiga pertanyaan: data apa yang dikenai aturan, kapan aturan dijalankan, dan tindakan apa yang dilakukan.
- Data apa: misalnya file di awalan
logs/, gambar sementara, atau objek dengan tag tertentu. - Kapan: setelah 7 hari, 30 hari, 90 hari, atau berdasarkan waktu terakhir diubah maupun diakses.
- Tindakan: dipindahkan ke storage class yang lebih murah, dihapus, atau versi lama dibersihkan.
Amazon S3, Google Cloud Storage, dan Azure Blob Storage sama-sama mendukung pola ini, meskipun nama storage class, syarat transisi, dan perilaku penghapusannya berbeda. Google Cloud, misalnya, menerapkan lifecycle pada objek yang memenuhi semua kondisi dalam sebuah aturan, sementara Azure dapat menerapkan aturan pada versi saat ini, versi sebelumnya, dan snapshot. ([docs.cloud.google.com](https://docs.cloud.google.com/storage/docs/lifecycle?utm_source=openai))
Masalah tersembunyi: versioning membuat “file yang dihapus” belum tentu hilang
Versioning berguna ketika kita perlu memulihkan file yang tertimpa atau terhapus. Namun, fitur ini juga dapat membuat kapasitas terus bertambah. Saat sebuah objek diperbarui berkali-kali, versi lama tetap tersimpan sebagai versi nonaktif sampai ada aturan khusus yang mengelolanya.
Di Amazon S3, aturan expiration untuk objek aktif tidak otomatis menghapus semua versi noncurrent. Versi lama memerlukan pengaturan lifecycle tersendiri, seperti transisi atau penghapusan setelah beberapa hari. Karena itu, bucket yang terlihat rapi dari sisi nama file masih bisa menyimpan banyak versi tersembunyi. ([docs.aws.amazon.com](https://docs.aws.amazon.com/AmazonS3/latest/userguide/intro-lifecycle-rules.html?utm_source=openai))
Prinsip yang sama berlaku di layanan lain: sebelum mengaktifkan versioning, tentukan berapa banyak versi yang memang perlu dipertahankan dan berapa lama versi tersebut harus tersedia.
Bedakan data aktif, data arsip, dan data sementara
Kesalahan umum adalah menerapkan satu aturan untuk seluruh bucket. Padahal, pola akses data berbeda-beda.
- Data aktif: gambar produk, dokumen pelanggan, atau aset yang sering dibaca. Data ini sebaiknya tetap berada di kelas yang cepat diakses.
- Data jarang diakses: laporan bulanan, hasil ekspor, atau dokumen lama. Data ini dapat dipindahkan ke kelas penyimpanan yang lebih murah setelah periode tertentu.
- Data sementara: file hasil proses, cache, log debug, dan artefak build. Data ini biasanya memiliki batas umur yang jelas dan dapat dihapus lebih cepat.
- Data wajib simpan: dokumen legal, catatan audit, atau data yang terikat kebijakan retensi. Data ini memerlukan perlindungan dan aturan berbeda, bukan sekadar penghapusan otomatis.
Gunakan struktur prefix atau tag untuk membedakan kelompok tersebut. Contohnya, uploads/, reports/, temp/, dan logs/ lebih mudah diatur daripada menaruh seluruh objek dalam satu ruang tanpa pola.
Storage lebih murah belum tentu lebih murah secara keseluruhan
Memindahkan data ke kelas dingin memang dapat menurunkan biaya penyimpanan bulanan. Namun, beberapa kelas memiliki biaya pengambilan kembali, durasi penyimpanan minimum, atau waktu pemulihan yang perlu diperhitungkan.
Data yang ternyata masih sering dibaca justru bisa membuat biaya meningkat setelah dipindahkan ke kelas arsip. Karena itu, keputusan transisi sebaiknya memakai data akses nyata, bukan asumsi seperti “file yang berusia 30 hari pasti tidak penting”.
Untuk aplikasi yang sesekali membutuhkan file lama, kelas penyimpanan dingin mungkin masuk akal. Untuk file yang sering dipakai oleh pengguna, penghematan kapasitas bisa kalah oleh biaya akses dan latensi tambahan.
Jangan mengharapkan aturan berjalan seketika
Lifecycle policy biasanya dijalankan sebagai proses latar belakang. Ada jeda antara saat objek memenuhi syarat dan saat tindakan benar-benar dilakukan. Google Cloud menjelaskan bahwa tindakan lifecycle berlangsung secara asynchronous, sedangkan Azure menyebutkan bahwa kebijakan baru dapat memerlukan waktu hingga 24 jam untuk mulai berlaku. ([docs.cloud.google.com](https://docs.cloud.google.com/storage/docs/lifecycle?utm_source=openai))
Artinya, lifecycle policy tidak cocok dijadikan mekanisme yang harus menghapus file tepat pada menit tertentu. Jika aplikasi memerlukan penghapusan instan karena alasan keamanan atau bisnis, lakukan penghapusan melalui aplikasi atau pekerjaan terjadwal, lalu gunakan lifecycle policy sebagai lapisan pengaman tambahan.
Checklist sebelum membuat aturan
- Inventarisasi isi bucket. Kelompokkan data berdasarkan fungsi, bukan hanya berdasarkan tanggal.
- Periksa versioning, snapshot, dan soft delete. Ketiganya dapat memengaruhi kapan data benar-benar hilang dan berapa banyak ruang yang dipakai.
- Ukur pola akses. Lihat apakah objek lama masih sering dibaca atau hanya disimpan tanpa pernah disentuh.
- Mulai dari data berisiko rendah. Terapkan aturan lebih dulu pada log, file sementara, dan artefak build.
- Gunakan prefix atau tag yang spesifik. Hindari aturan umum pada bucket yang mencampur data penting dan data sementara.
- Uji pada lingkungan terpisah. Periksa objek yang akan terkena aturan sebelum menerapkannya ke data produksi.
- Pantau hasilnya. Bandingkan kapasitas, jumlah objek, biaya akses, dan error setelah kebijakan berjalan.
Apa artinya bagi kita?
Lifecycle policy bukan tombol hemat biaya yang bisa ditekan tanpa konsekuensi. Ia lebih mirip sistem penyortiran otomatis: sangat membantu jika kategori dan batas waktunya jelas, tetapi berbahaya jika semua barang dianggap sama.
Langkah paling aman adalah memulai dari satu kelompok data yang mudah dipahami. Misalnya, hapus file sementara setelah 14 hari, pindahkan laporan lama setelah 90 hari, dan bersihkan versi noncurrent setelah periode pemulihan yang disepakati tim. Setelah hasilnya dipantau, barulah aturan diperluas ke kelompok data lain.
Dokumentasi resmi tentang lifecycle tersedia di Amazon S3, Google Cloud Storage, dan Azure Blob Storage. Detail implementasinya berbeda, tetapi prinsipnya sama: simpan data sesuai nilai dan pola aksesnya, bukan selamanya hanya karena biaya awalnya terlihat kecil.
Sumber & bacaan lebih lanjut
- Amazon S3 Lifecycle configuration elements
- Google Cloud Storage Object Lifecycle Management
- Azure Blob Storage lifecycle management overview
- Azure Blob Storage lifecycle management policy FAQ
– Rio Yotto @rioyotto