Tagihan Cloud Membengkak Pelan-Pelan? Cari Reso…

Tagihan cloud sering terasa seperti keran yang bocor: tidak langsung membanjiri ruangan, tetapi terus menetes setiap jam. Sebuah server pengujian yang lupa dimatikan, disk yang sudah tidak terhubung, atau snapshot lama yang menumpuk bisa menjadi biaya rutin tanpa pernah terlihat di dashboard aplikasi.

Masalahnya bukan selalu karena perusahaan memakai terlalu banyak komputasi. Sering kali, masalahnya adalah tidak ada yang benar-benar tahu resource mana yang masih dibutuhkan, siapa pemiliknya, dan kapan resource tersebut boleh dihapus. Karena itu, penghematan cloud sebaiknya dimulai dari visibilitas, bukan dari menurunkan spesifikasi server secara membabi buta.

Mulai dari memisahkan biaya berdasarkan layanan

Langkah pertama adalah melihat tagihan berdasarkan jenis layanan, bukan hanya total bulanannya. Kelompokkan biaya menjadi komputasi, storage, database, transfer data, alamat IP, dan layanan pendukung lainnya.

Di AWS, Cost Explorer dapat digunakan untuk menganalisis biaya dan pemakaian berdasarkan periode, layanan, wilayah, maupun filter tertentu. Azure memiliki Cost Analysis untuk melihat biaya saat ini, tren, dan perkiraan tagihan. Google Cloud menyediakan laporan biaya serta anggaran yang dapat dibatasi berdasarkan akun, proyek, layanan, atau label.

Tujuannya bukan sekadar menemukan angka terbesar. Biaya komputasi yang besar mungkin memang berasal dari aplikasi utama dan sulit dikurangi tanpa pengujian. Sebaliknya, biaya storage yang lebih kecil tetapi terus naik bisa menandakan data lama yang tidak pernah memiliki kebijakan retensi.

Empat sumber biaya yang sering luput

1. Disk yang tidak lagi terhubung

Ketika sebuah VM dihapus, disk tambahan tidak selalu ikut terhapus. Bergantung pada konfigurasi, disk dapat tetap tersedia agar datanya tidak hilang. Ini berguna jika penghapusan VM hanya bersifat sementara, tetapi menjadi pemborosan jika resource tersebut berasal dari eksperimen berbulan-bulan lalu.

Pada AWS, volume EBS dengan status available berarti tidak sedang terhubung ke instance. Status ini bukan bukti bahwa volume boleh dihapus, tetapi merupakan daftar awal yang perlu diperiksa. Sebelum menghapusnya, pastikan data sudah tidak diperlukan atau sudah memiliki salinan yang dapat dipulihkan.

2. Snapshot dan backup tanpa masa kedaluwarsa

Backup memang penting, tetapi backup tanpa aturan retensi akan berubah menjadi arsip permanen. Snapshot harian yang awalnya dibuat untuk kebutuhan pemulihan bisa terus bertambah selama berbulan-bulan.

Snapshot EBS bersifat incremental: setelah snapshot awal, hanya blok data yang berubah yang disimpan. Namun, penghapusan satu snapshot belum tentu langsung menghilangkan seluruh data yang terkait karena blok tersebut mungkin masih digunakan oleh snapshot lain. Artinya, pengelolaan snapshot perlu mengikuti kebijakan, bukan dilakukan dengan menghapus secara acak.

Tentukan aturan sederhana, misalnya menyimpan backup harian selama tujuh hari, backup mingguan selama empat minggu, dan backup bulanan selama enam bulan. Angka ini bukan aturan universal. Aplikasi keuangan, sistem internal, dan website kecil bisa memiliki kebutuhan retensi yang berbeda.

3. Lingkungan development dan staging yang selalu aktif

Server produksi biasanya memiliki pemilik dan jadwal operasional yang jelas. Lingkungan development atau staging lebih sering dibuat cepat untuk menguji fitur, lalu dilupakan. Jika server tersebut memiliki database, disk, alamat IP, dan layanan tambahan, biayanya dapat muncul dari beberapa pos sekaligus.

Gunakan jadwal otomatis untuk mematikan lingkungan nonproduksi di luar jam kerja. Untuk tim yang bekerja dari pukul 09.00 sampai 18.00, mematikan resource pada malam dan akhir pekan bisa mengurangi jam aktif secara signifikan. Tetap uji dampaknya, terutama jika ada proses backup, job terjadwal, atau akses dari anggota tim di zona waktu berbeda.

4. Data keluar dan resource lintas wilayah

Banyak orang memperhatikan harga server dan storage, tetapi melupakan biaya transfer data. CDN, backup lintas region, replikasi database, dan API yang mengirim file besar dapat meningkatkan penggunaan data keluar.

Jangan langsung menyimpulkan bahwa semua transfer data harus dikurangi. Replikasi lintas wilayah mungkin memang dibutuhkan untuk ketahanan layanan. Yang perlu dilakukan adalah mengetahui jalur datanya: data apa yang keluar, dari layanan mana, menuju wilayah atau provider mana, dan apakah ukuran transfernya masuk akal.

Tag bukan dekorasi: gunakan untuk menemukan pemilik biaya

Tag atau label adalah metadata sederhana seperti environment=production, team=marketing, atau owner=andi. Dengan penamaan yang konsisten, biaya dapat dikelompokkan berdasarkan aplikasi, tim, proyek, dan lingkungan.

Skema tag yang baik tidak perlu panjang. Mulailah dengan empat kolom:

application: nama aplikasi atau layanan;
environment: production, staging, atau development;
owner: tim atau orang yang bertanggung jawab;
expiry: tanggal evaluasi atau penghapusan resource sementara.

Tag tidak otomatis menyelesaikan pemborosan. Tag hanya membantu menjawab pertanyaan penting: siapa yang perlu memeriksa resource ini? Pada AWS, tag tertentu dapat diaktifkan sebagai cost allocation tag untuk membantu mengelompokkan biaya. Di Google Cloud, label dapat digunakan sebagai bagian dari cakupan anggaran dan laporan biaya.

Jangan hanya memasang alert, buat tindakan setelah alert

Anggaran dan notifikasi penting, tetapi email peringatan tidak otomatis menghentikan pemakaian. Google Cloud secara eksplisit membedakan budget alert dari mekanisme pembatasan pengeluaran: alert memberi tahu bahwa biaya mendekati ambang, tetapi tidak selalu mencegah layanan terus berjalan.

Karena itu, setiap alert sebaiknya memiliki prosedur tindak lanjut. Contohnya:

Periksa layanan yang mengalami kenaikan biaya.
Bandingkan dengan perubahan deployment atau kampanye yang sedang berjalan.
Periksa resource sementara, disk tidak terhubung, snapshot, dan transfer data.
Tentukan apakah kenaikan tersebut memang direncanakan.
Jika tidak, hentikan atau ubah resource setelah pemiliknya menyetujui.

Yang bisa dilakukan sekarang

Sisihkan 30–60 menit setiap minggu untuk membuat inventaris resource. Mulai dari daftar VM, disk, snapshot, database, bucket storage, IP publik, dan lingkungan nonproduksi. Tambahkan kolom pemilik, tujuan, tanggal dibuat, serta keputusan terakhir: dipertahankan, diubah, atau dihapus.

Untuk resource yang belum jelas pemiliknya, jangan langsung menghapus. Beri tag sementara seperti review-needed=true, lalu tetapkan batas waktu pemeriksaan. Jika setelah periode tersebut tidak ada pemilik yang mengonfirmasi kebutuhan, barulah buat rencana penghapusan atau pemindahan ke storage yang lebih murah.

Penghematan cloud yang sehat bukan berarti memangkas semua resource hingga aplikasi rapuh. Fokusnya adalah memastikan setiap biaya punya alasan: melayani pengguna, menjaga pemulihan, memenuhi kebutuhan keamanan, atau mendukung pekerjaan yang memang sedang berlangsung. Jika sebuah resource tidak bisa dijelaskan manfaatnya, itulah kandidat pertama untuk diperiksa.

Sumber & bacaan lebih lanjut

– Rio Yotto @rioyotto