Tagihan cloud yang tiba-tiba naik sering dianggap sebagai konsekuensi pertumbuhan bisnis. Padahal, banyak kenaikan biaya justru datang dari hal yang lebih sederhana: server terlalu besar, lingkungan pengujian lupa dimatikan, storage menyimpan terlalu banyak salinan, atau layanan tambahan terus berjalan meski sudah tidak dipakai.
Cloud memang memberi fleksibilitas karena kapasitas bisa ditambah kapan saja. Namun, fleksibilitas itu bekerja seperti keran air: mudah dibuka, tetapi tetap harus diawasi agar tidak mengalir tanpa batas. Kabar baiknya, Anda tidak perlu langsung memindahkan seluruh sistem atau mengganti provider. Langkah pertama adalah memahami dari mana biaya muncul dan apakah kapasitas yang dibayar benar-benar digunakan.
Kenapa biaya cloud bisa naik tanpa trafik meningkat?
Biaya cloud biasanya tidak hanya berasal dari satu server. Tagihan dapat terdiri dari komputasi, storage, transfer data, database, snapshot, alamat IP, load balancer, layanan monitoring, hingga lingkungan staging.
Masalahnya, sebagian biaya bersifat tetap atau terus berjalan selama resource masih aktif. Sebuah server virtual yang hanya dipakai beberapa jam sehari tetap bisa menimbulkan biaya selama berstatus menyala. Begitu juga disk dan snapshot: menghapus server belum tentu menghapus storage yang terhubung dengannya.
Ada juga biaya yang muncul karena pola penggunaan. Misalnya, aplikasi mengirim banyak data dari satu region ke region lain, backup dibuat terlalu sering, atau log disimpan berbulan-bulan tanpa aturan retensi. Tidak ada satu kesalahan besar, tetapi banyak biaya kecil yang akhirnya menumpuk.
Mulai dari membaca tagihan, bukan menebak
Langkah pertama yang paling praktis adalah membuka rincian biaya berdasarkan layanan, region, akun, proyek, atau label resource. Jangan hanya melihat total tagihan bulanan. Total hanya memberi tahu bahwa ada masalah, bukan di mana masalahnya.
Buat daftar sederhana seperti berikut:
- Komputasi: instance, container, fungsi serverless, atau cluster.
- Storage: disk, object storage, snapshot, dan backup.
- Database: kapasitas instance, penyimpanan, replica, serta biaya I/O.
- Jaringan: transfer data keluar, NAT gateway, load balancer, dan alamat IP.
- Operasional: monitoring, log, audit trail, dan layanan keamanan.
Bandingkan angka tersebut dengan bulan sebelumnya. Cari perubahan paling besar, lalu hubungkan dengan aktivitas teknis atau bisnis yang terjadi. Jika tidak ada peluncuran fitur, kenaikan trafik, atau migrasi sistem, lonjakan pada satu layanan patut diperiksa lebih lanjut.
Periksa resource yang terlalu besar
Salah satu pemborosan paling umum adalah memilih kapasitas berdasarkan perkiraan terburuk, lalu tidak pernah menyesuaikannya. Server dengan delapan vCPU mungkin masuk akal saat kampanye besar, tetapi belum tentu diperlukan untuk aplikasi yang sepanjang hari hanya memakai sebagian kecil CPU.
Periksa metrik penggunaan selama beberapa minggu, bukan hanya kondisi pada satu jam tertentu. Beberapa hal yang perlu dilihat antara lain:
- Rata-rata dan puncak penggunaan CPU.
- Penggunaan memori serta kejadian kehabisan memori.
- Beban disk dan sisa kapasitas storage.
- Jumlah koneksi atau request per detik.
- Waktu ketika beban paling tinggi dan paling rendah.
Jika penggunaan konsisten rendah, pertimbangkan rightsizing, yaitu menyesuaikan ukuran resource dengan kebutuhan nyata. Namun, jangan mengecilkan server hanya berdasarkan CPU. Aplikasi bisa terlihat santai di CPU tetapi terbebani memori, disk, atau koneksi database.
Jangan lupa lingkungan staging dan pengujian
Lingkungan staging, development, dan pengujian sering menjadi sumber biaya yang luput dari perhatian. Tim membuat server untuk mencoba fitur, menjalankan simulasi, atau menguji migrasi, kemudian resource tersebut tetap menyala setelah pekerjaan selesai.
Pisahkan resource berdasarkan lingkungan dan beri nama yang jelas. Terapkan jadwal otomatis untuk mematikan server nonproduksi pada malam hari, akhir pekan, atau di luar jam kerja. Untuk lingkungan yang hanya dibutuhkan sesekali, lebih baik membuatnya dari template ketika diperlukan daripada membiarkannya aktif sepanjang bulan.
Aturan ini tidak selalu cocok untuk semua sistem. Beberapa pipeline pengujian membutuhkan resource yang tersedia kapan saja. Karena itu, keputusan sebaiknya didasarkan pada waktu pemakaian dan dampak terhadap produktivitas, bukan sekadar mengejar penghematan.
Storage dan backup perlu memiliki masa kedaluwarsa
Storage terasa murah ketika dilihat satu per satu. Masalah muncul ketika file, log, artefak build, snapshot, dan backup bertambah setiap hari tanpa pernah dibersihkan.
Buat kebijakan retensi yang mudah dipahami. Contohnya, backup harian disimpan selama 14 hari, backup mingguan selama tiga bulan, dan backup bulanan selama satu tahun. Angka tersebut bukan aturan universal; pilih berdasarkan kebutuhan pemulihan dan kewajiban bisnis.
Periksa juga apakah backup menyimpan data yang sebenarnya tidak perlu. Cache, file sementara, hasil build lama, dan salinan lokal yang dapat dibuat ulang mungkin tidak harus masuk ke backup utama.
Yang penting, penghematan storage tidak boleh mengorbankan kemampuan pemulihan. Backup yang murah tetapi tidak pernah diuji tetap berisiko. Pastikan sebagian backup dapat dipulihkan dan dokumentasikan berapa lama prosesnya.
Waspadai biaya transfer data
Biaya jaringan sering lebih sulit terlihat karena tidak selalu berkaitan langsung dengan jumlah pengguna. Aplikasi dapat menimbulkan transfer besar ketika server, database, object storage, dan CDN berada di lokasi atau region berbeda.
Periksa pola komunikasi antarlayanan. Apakah database berada di region yang sama dengan aplikasi? Apakah file besar dikirim melalui server aplikasi padahal bisa disajikan langsung dari object storage atau CDN? Apakah sistem monitoring mengirim log dalam jumlah besar ke layanan eksternal?
Optimasi jaringan tidak berarti semua layanan harus dipindahkan ke satu tempat. Pemisahan region bisa diperlukan untuk redundansi, latensi, atau kepatuhan. Namun, alasan tersebut perlu jelas dan dibandingkan dengan biaya tambahannya.
Gunakan batas anggaran dan notifikasi
Audit manual penting, tetapi tidak cukup jika dilakukan setelah tagihan membengkak. Pasang anggaran bulanan dan notifikasi ketika pemakaian melewati ambang tertentu. Buat beberapa ambang, misalnya 50 persen, 80 persen, dan 100 persen dari anggaran.
Notifikasi bukan pengganti monitoring teknis. Ia hanya memberi sinyal bahwa biaya perlu diperiksa. Tim tetap perlu mengetahui resource mana yang berubah dan siapa yang bertanggung jawab atasnya.
Gunakan tag atau label seperti project, environment, owner, dan cost-center. Tanpa penandaan, sulit menentukan apakah resource tertentu milik aplikasi produksi, eksperimen pribadi, atau proyek yang sudah dihentikan.
Apa artinya bagi kita?
Penghematan cloud bukan sekadar mencari server termurah. Tujuannya adalah memastikan setiap resource punya alasan keberadaan, kapasitas yang masuk akal, dan batas penggunaan yang jelas.
Mulailah dari audit kecil: pilih lima layanan dengan biaya terbesar, periksa pemakaiannya, lalu cari resource yang tidak digunakan atau terlalu besar. Setelah itu, buat kebiasaan bulanan untuk meninjau biaya dan kebiasaan mingguan untuk membersihkan resource sementara.
Jika sistem sudah tumbuh besar, pertimbangkan pendekatan FinOps, yaitu praktik menghubungkan keputusan teknis dengan dampak finansial. Dalam praktiknya, developer, tim infrastruktur, dan bagian keuangan tidak hanya melihat tagihan setelah bulan berakhir, tetapi ikut memahami bagaimana setiap perubahan arsitektur memengaruhi biaya.
Cloud tetap menjadi pilihan yang kuat karena dapat mengikuti kebutuhan bisnis. Namun, skalabilitas yang sehat bukan hanya kemampuan menambah kapasitas. Ia juga mencakup kemampuan mengurangi kapasitas ketika beban turun, menghentikan resource yang tidak diperlukan, dan mengetahui dengan jelas untuk apa setiap rupiah dibelanjakan.
– Rio Yotto @rioyotto