Saya belum pernah membuka tagihan cloud perusahaan menengah dan mendapatinya bersih. Selalu ada server staging yang tidak ada yang ingat kapan dinyalakan, load balancer yang mengarah ke tempat kosong, dan instance yang di-size untuk lonjakan traffic delapan belas bulan lalu yang tidak pernah terulang. Optimasi biaya cloud bukan disiplin khusus yang hanya milik perusahaan dengan tim FinOps. Ini audit setengah hari yang bisa dijalankan technical lead mana pun, dan biasanya menemukan tiga puluh persen dari tagihan yang sebenarnya menganggur.
Alasan pemborosan ini menumpuk sifatnya struktural, bukan karena kecerobohan. Cloud membuat provisioning jadi sangat mudah dan melupakannya jadi sama mudahnya. Tidak ada yang di-page saat server terlalu besar ukurannya. Tidak ada yang di-page saat disk volume tidak terpakai tapi tetap ditagih. Tagihannya terus merayap naik, dan karena dihitung dalam mata uang yang tidak pernah dicek baris per baris, ia terus merayap sampai akhirnya seseorang membuka invoice dan bertanya kenapa jumlahnya dua kali lipat dalam setahun.
Kabar baiknya, memangkas pemborosan ini jarang menyentuh risiko produksi. Sebagian besar penghematan ada di resource yang sudah tidak terpakai atau kelewat besar ukurannya, bukan di sistem yang benar-benar melayani pelanggan.
Di Mana Pemborosan Sebenarnya Bersembunyi
Di setiap audit yang pernah saya jalankan, pemborosan selalu mengelompok di lima tempat yang sama:
- Environment non-production yang jalan 24/7. Server dev dan staging untuk tim yang kerja jam 9-to-6 tidak perlu menyala malam dan akhir pekan. Itu sekitar 65 persen dari seminggu yang dibayar untuk sesuatu yang tidak dipakai.
- Instance yang kelewat besar dari tebakan hari peluncuran. Tim melakukan provisioning untuk skenario terburuk yang tidak pernah terjadi, lalu tidak pernah meninjaunya lagi setelah keadaan stabil.
- Storage dan snapshot yatim piatu. Disk volume yang tidak terpasang, snapshot database lama, dan bucket log yang tidak pernah dilihat siapa pun selama setahun.
- Load balancer dan static IP yang menganggur. Tertinggal setelah sebuah service dinonaktifkan atau dimigrasikan.
- Harga on-demand untuk beban kerja yang stabil. Membayar tarif tertinggi untuk kapasitas yang sudah Anda tahu akan Anda pakai selama dua belas bulan ke depan.
Tidak satu pun dari ini membutuhkan penulisan ulang arsitektur. Yang dibutuhkan hanya seseorang yang mau melihat.
Ritual Audit Setengah Hari
Berikut versi yang benar-benar saya jalankan bersama klien, dipadatkan ke bagian yang penting saja:
| Langkah | Yang diperiksa | Penghematan tipikal |
|---|---|---|
| 1. Inventaris | Daftar semua instance yang berjalan, diurutkan berdasarkan biaya bulanan | Langsung memunculkan outlier |
| 2. Utilisasi | Tarik grafik CPU/memori 30 hari per instance | Menandai apa pun dengan rata-rata pemakaian di bawah 20 persen |
| 3. Sapuan yatim piatu | Temukan volume tidak terpasang, IP tidak terpakai, load balancer menganggur | Sering 5-10 persen dari tagihan, murni penghapusan |
| 4. Jadwalkan non-prod | Auto-stop dev/staging di luar jam kerja | 40-60 persen lebih hemat di environment tersebut |
| 5. Rightsizing | Turunkan ukuran instance yang jalan jauh di bawah kapasitas selama 30+ hari | 15-30 persen di instance yang terdampak |
| 6. Tinjauan komitmen | Pindahkan beban kerja stabil ke harga reserved atau committed-use | 20-40 persen lebih hemat di porsi tersebut |
Sebuah perusahaan multifinance yang pernah saya tangani menjalankan urutan persis ini dan memangkas belanja infrastruktur bulanannya hampir sepertiga, tanpa perubahan apa pun yang terlihat pelanggan. Storage yatim piatu saja, yang menumpuk selama tiga tahun migrasi, nilainya lebih besar dari gaji bulanan seorang junior engineer.
Langkah Reserved Pricing yang Sering Dilewatkan Tim
Langkah dengan leverage tertinggi justru yang paling sering dihindari tim karena terasa seperti komitmen. Harga on-demand ada untuk menutup lonjakan yang tidak terduga. Jika Anda punya beban kerja baseline yang berjalan stabil, setiap bulan Anda membayar tarif on-demand untuk itu adalah uang yang tertinggal di atas meja.
Langkahnya: lihat pemakaian 90 hari terakhir, temukan titik terendahnya (kapasitas minimum yang tidak pernah Anda turuni), lalu komit ke titik terendah itu dengan harga reserved atau committed-use. Anda tidak sedang berjudi soal pertumbuhan masa depan. Anda hanya mengunci bagian dari belanja yang sudah Anda tahu bersifat permanen. Penghematan di titik terendah itu biasanya berkisar 20 sampai 40 persen, dan balik modal sejak bulan pertama.
Ini disiplin yang sama dengan subscription creep di anggaran software Anda: biaya berulang bersembunyi di depan mata sampai seseorang mau menghitungnya secara sengaja.
Rightsizing Tanpa Mengorbankan Produksi
Kekhawatiran yang menghentikan sebagian besar tim untuk menyentuh instance produksi itu wajar. Cara melakukan rightsizing dengan aman:
- Hanya sentuh instance dengan data utilisasi 30+ hari, bukan snapshot dari seminggu yang sedang sepi.
- Turunkan satu tingkat saja dalam satu waktu, bukan dua, dan pantau selama satu siklus bisnis penuh sebelum langkah berikutnya.
- Pertahankan headroom autoscaling untuk lonjakan yang genuine; rightsizing baseline itu berbeda dengan menghilangkan kapasitas burst.
- Lakukan ini di luar musim puncak Anda. Jika Anda melayani retail dan sekarang bulan November, tunggu sampai Januari.
Menjadikan Audit Sebagai Ritme Tetap
Satu kali pembersihan memberi Anda penghematan setahun, tapi pemborosan akan kembali karena provisioning tetap mudah dan penghapusan tetap opsional. Solusinya bukan tool, melainkan kebiasaan berulang: masukkan tinjauan biaya kuartalan ke kalender, dimiliki oleh satu orang yang disebut namanya, dengan checklist lima langkah yang sama seperti di atas. Lima belas menit per kuartal sudah cukup untuk menangkap penyimpangan sebelum ia berubah menjadi item biaya yang mendarah daging lagi.
Kesimpulan
Optimasi biaya cloud bukan soal berpindah provider atau merombak arsitektur apa pun. Ini kedisiplinan setengah hari untuk melihat apa yang sudah Anda miliki, menghapus apa yang tidak dipakai siapa pun, mengecilkan apa yang tidak dibutuhkan siapa pun, dan berkomitmen pada titik terendah yang sudah Anda tahu akan Anda bayar bagaimanapun juga. Jalankan audit ini bulan ini sebelum invoice berikutnya datang, dan jika tinjauan ini memunculkan pertanyaan arsitektur yang lebih besar dari sekadar pembersihan biaya, itu momen yang tepat untuk melibatkan partner daripada menebak-nebak sendiri.