Setiap beberapa bulan, ada saja pemilik bisnis yang mengirim saya screenshot tagihan AWS dengan pesan yang sama: "Ini terus naik dan tidak ada yang tahu kenapa." Aplikasinya tidak sedang tumbuh secepat itu. Traffic-nya relatif flat. Tapi angkanya terus naik setiap bulan seolah punya pikiran sendiri.

Panduan optimasi biaya cloud ini ditujukan untuk pemilik bisnis seperti itu. Bukan untuk perusahaan yang menjalankan ribuan server dengan tim finance-and-ops khusus, tapi untuk bisnis Indonesia pada umumnya yang tagihan cloud bulanannya diam-diam naik dari Rp 8 juta menjadi Rp 25 juta sementara semua orang sibuk mengejar fitur baru.

Kabar baiknya: dari hampir semua tagihan yang saya audit, setidaknya 30 persen dari pengeluarannya adalah pemborosan murni. Bukan peluang optimasi yang rumit, tapi sekadar uang yang terbakar untuk hal-hal yang sudah tidak dipakai siapa pun. Menemukannya tidak butuh spesialis. Yang dibutuhkan hanya 30 menit fokus setiap bulan dan kesediaan untuk bertanya hal-hal yang tidak nyaman.

Zombie Resources: Hal Pertama yang Harus Dibunuh

Sumber pemborosan terbesar bukanlah inefisiensi. Melainkan resource yang ditinggalkan begitu saja. Sesuatu dinyalakan, lalu tidak pernah dimatikan.

Cari yang berikut ini dulu, karena inilah kemenangan tercepat:

  • Environment testing dan staging yang terlupakan. Seorang developer membuat salinan penuh dari production untuk menguji sesuatu di bulan November, dan sejak itu ia berjalan 24 jam sehari tanpa henti. Item tunggal ini sering menjadi baris terbesar di tagihan sebuah UKM.
  • Storage volume yang tidak lagi terpasang. Anda menghapus sebuah server, tapi disk yang dulu terpasang padanya tetap hidup, terus menagih Anda setiap bulan untuk data yang tidak akan pernah Anda baca lagi.
  • Snapshot dan backup lama. Ratusan backup otomatis dari 2021 yang tidak pernah dibersihkan oleh kebijakan apa pun.
  • Load balancer menganggur dan static IP yang tidak terpakai. Masing-masing kecil, tapi semuanya bertambah, dan tidak satu pun sedang melakukan sesuatu yang berguna.

Tidak satu pun dari ini muncul sebagai alert yang mengkhawatirkan. Semuanya hanya duduk diam di tagihan, tidak terlihat, karena tidak ada yang bertanggung jawab untuk memeriksanya. Membunuh zombie resources saja seringkali langsung menghemat 15 hingga 20 persen.

Right-Sizing: Berhenti Membayar Ruang Kosong yang Tidak Pernah Dipakai

Lapisan kedua adalah over-provisioning. Ketika tim menyiapkan infrastruktur, mereka menebak-nebak ukuran yang dibutuhkan, menebak lebih besar demi "aman," dan tidak pernah meninjau ulang tebakan itu.

Contoh klasiknya adalah database. Seseorang memilih instance besar "biar aman," dan instance itu berjalan sepanjang hari hanya di 8 persen CPU. Anda membayar mesin yang empat kali lebih besar dari kebutuhan workload Anda. Hal yang sama terjadi pada application server yang di-set untuk lonjakan traffic yang datang setahun sekali, atau bahkan tidak pernah datang sama sekali.

Right-sizing memang tidak terdengar keren, tapi ini uang yang bisa diandalkan:

  • Lihat pemakaian CPU dan memory aktual selama sebulan terakhir, bukan puncaknya, tapi rata-ratanya.
  • Jika sebuah server konsisten berada di bawah 20 persen utilisasi, itu kandidat untuk diturunkan satu ukuran.
  • Untuk workload yang predictable dan always-on, committed pricing (reserved atau savings plan) memangkas tarif secara signifikan untuk komitmen satu hingga tiga tahun.

Lakukan ini dengan hati-hati dan ukur hasilnya setelah setiap perubahan, tapi polanya hampir selalu sama: Anda membayar ruang kosong yang tidak pernah Anda sentuh.

Pertanyaan yang Hampir Tidak Pernah Ditanyakan

Ini yang tidak nyaman. Untuk sejumlah UKM yang mengejutkan, masalah sebenarnya bukan setup cloud yang tidak efisien. Masalahnya adalah mereka memakai arsitektur cloud yang kompleks sama sekali.

Di suatu titik, seorang developer membangun sistem persis seperti yang digambarkan blog post perusahaan besar: managed Kubernetes, banyak service, autoscaling group, managed database cluster. Mengesankan, dan sepenuhnya berlebihan untuk aplikasi yang melayani beberapa ribu pengguna per hari.

Jadi pertanyaan yang perlu diajukan secara jujur: apakah satu virtual private server seharga USD 40 per bulan sebenarnya sudah cukup untuk kebutuhan ini?

Untuk banyak internal tool, website perusahaan, dan aplikasi skala sedang, jawaban jujurnya adalah ya. Satu VPS yang dikonfigurasi dengan baik, atau platform managed kecil, bisa melayani beban tersebut dengan sebagian kecil dari biaya dan sebagian kecil dari kompleksitas operasionalnya. Arsitektur yang rumit itu sedang menyelesaikan masalah skala yang tidak dimiliki bisnis tersebut. Ini adalah versi infrastruktur dari jebakan yang saya bahas di Vendor Lock-In: Pertanyaan yang Harus Ditanyakan Sebelum Tanda Tangan, di mana opsi yang terlihat canggih diam-diam menelan biaya lebih besar daripada opsi sederhana yang justru pas.

Saya tidak sedang menyarankan Anda membongkar cloud Anda besok. Yang saya maksud, arsitekturnya harus sesuai dengan bisnisnya, bukan mengikuti diagram dari perusahaan yang seribu kali lebih besar dari Anda.

Jadikan Ritual Bulanan 30 Menit

Pemborosan akan kembali begitu Anda berhenti mengawasinya, jadi bangun kebiasaan ringan alih-alih pembersihan satu kali. Sebulan sekali, sisihkan 30 menit dan jalankan checklist ini:

  1. Buka rincian biaya per service. Apa yang naik sejak bulan lalu, dan kenapa?
  2. Buru zombie. Ada environment yang berjalan tapi tidak dipakai siapa pun bulan ini? Ada storage yang tidak terpasang atau snapshot basi? Matikan atau jadwalkan penghapusannya.
  3. Periksa tiga resource paling mahal. Apakah ukurannya sudah sesuai dengan pemakaian rata-rata sebenarnya?
  4. Pasang billing alert. Ambang batas sederhana yang mengirim email saat tagihan melewati angka yang diharapkan, sehingga kejutan menjadi masalah minggu itu juga, bukan kejutan di akhir bulan.
  5. Ajukan pertanyaan besar sekali per kuartal. Apakah arsitekturnya masih sesuai dengan beban aktual, atau sudah berkembang ke arah yang salah dibanding kebutuhan bisnis?

Tiga puluh menit sebulan jauh lebih murah dari konsultan mana pun dan menangkap sebagian besar kerusakan sebelum berlipat ganda.

Kesimpulan

Tagihan cloud yang membengkak jarang benar-benar menjadi misteri begitu Anda menelusurinya. Panduan optimasi biaya cloud ini bermuara pada tiga langkah: bunuh zombie resources yang sudah tidak diingat siapa pun, right-size server yang di-over-provisioning karena kehati-hatian berlebih, dan tanyakan dengan jujur apakah arsitektur Anda jauh lebih besar dari kebutuhan bisnis Anda. Sebagian besar UKM membawa pemborosan setidaknya 30 persen, dan review bulanan 30 menit yang disiplin akan mengembalikannya tanpa perlu spesialis. Cloud tidak menagih Anda berlebihan. Ia hanya terus menagih setiap keputusan yang lupa Anda tinjau ulang, jadi jadikan meninjau ulang itu sebagai kebiasaan.