Bayu Permadi Tagihan Cloud Naik, Padahal Beban Kerja Tidak Banyak Berubah
Mengapa Satu Model Harga Jarang Cukup
Banyak perusahaan menjalankan seluruh server mereka dengan satu model harga saja, biasanya on-demand, karena itu pilihan paling mudah saat pertama kali masuk ke cloud. Masalahnya muncul beberapa bulan kemudian. Beban kerja mulai stabil, jumlah server bertambah, dan tagihan bulanan ikut naik tanpa ada fitur baru yang sebanding. Bagi pengambil keputusan, kondisi ini sering terasa janggal: sistem berjalan normal, tetapi biaya terus membesar.
Penyebabnya umumnya bukan kesalahan teknis, melainkan ketidakcocokan antara model harga dan karakter beban kerja. Server yang menyala 24 jam setiap hari dibayar dengan tarif yang dirancang untuk kebutuhan sementara. Di sisi lain, pekerjaan yang sebenarnya bisa ditunda atau diulang justru berjalan di kapasitas yang mahal.
Biaya yang Sebenarnya Bisa Dikendalikan
Sebelum berbicara soal diskon, ada satu pertanyaan yang layak diajukan: berapa bagian dari infrastruktur Anda yang benar-benar dibutuhkan terus-menerus, dan berapa yang hanya muncul pada jam atau musim tertentu? Jawaban atas pertanyaan itu menentukan model harga mana yang paling masuk akal. Jika Anda belum punya gambaran ini, mulailah dari pembahasan kami tentang tagihan cloud yang mahal akibat salah desain awal, karena akar masalahnya sering berada di sana.
Memahami Tiga Model Harga Sebelum Menggabungkannya
On-Demand: Fleksibel dengan Harga Penuh
On-demand berarti Anda membayar sesuai pemakaian tanpa komitmen jangka panjang. Kapasitas bisa ditambah atau dihentikan kapan saja. Model ini paling cocok untuk beban kerja baru yang polanya belum jelas, lonjakan trafik yang tidak terduga, atau lingkungan pengujian jangka pendek. Kelemahannya sederhana: ini adalah tarif paling mahal per jam pemakaian, sehingga kurang efisien jika dipakai untuk beban yang berjalan terus-menerus.
Reserved Instance: Komitmen untuk Beban yang Stabil
Reserved instance menukar komitmen pemakaian, biasanya satu atau tiga tahun, dengan tarif yang jauh lebih rendah. Menurut dokumentasi AWS, skema komitmen seperti ini dapat memberi penghematan hingga sekitar 72 persen dibanding on-demand, tergantung jenis instance, durasi, dan opsi pembayaran. Model ini cocok untuk database produksi, aplikasi inti, dan layanan yang hampir pasti tetap berjalan sepanjang tahun. Risikonya ada di sisi perencanaan: jika kebutuhan Anda menyusut atau arsitektur berubah, komitmen yang sudah dibeli tetap harus dibayar. Anda dapat membaca detail skemanya di halaman resmi AWS Savings Plans.
Spot Instance: Murah, tetapi Bisa Dihentikan
Spot instance memanfaatkan kapasitas cadangan penyedia cloud dengan harga yang jauh lebih murah. AWS menyebutkan potongan hingga sekitar 90 persen dibanding on-demand. Imbalannya, instance dapat diambil kembali oleh penyedia dengan pemberitahuan singkat. Karena itu, spot paling aman dipakai untuk pekerjaan yang toleran terhadap gangguan, seperti proses batch, pemrosesan data, build pipeline CI/CD, atau rendering. Untuk gambaran teknisnya, lihat halaman Amazon EC2 Spot Instances.
Strategi Kombinasi yang Realistis untuk Perusahaan
Pembagian Porsi Berdasarkan Karakter Beban Kerja
Pendekatan yang paling sering berhasil adalah membagi infrastruktur menjadi tiga lapisan. Lapisan dasar, yaitu kapasitas minimum yang selalu menyala, ditutup dengan reserved instance. Lapisan tengah, yaitu kapasitas yang naik turun mengikuti jam sibuk, dibiarkan di on-demand agar tetap fleksibel. Lapisan atas, yaitu pekerjaan yang bisa ditunda atau diulang, dijalankan di spot. Sebagai titik awal diskusi, banyak tim memulai dari kisaran separuh atau lebih kapasitas dasar di reserved, lalu menyesuaikan setelah melihat data pemakaian nyata. Angka ini hanya ilustrasi, bukan standar baku, dan setiap perusahaan perlu menghitung ulang dari datanya sendiri.
Risiko yang Perlu Diantisipasi
Kombinasi yang baik tetap punya titik lemah. Komitmen reserved yang terlalu besar bisa menjadi beban jika kebutuhan turun. Spot yang dipasang pada layanan yang tidak siap kehilangan server akan menimbulkan gangguan bagi pelanggan. Karena itu, tetapkan batas yang jelas: layanan yang berhubungan langsung dengan transaksi pelanggan sebaiknya tidak bergantung pada spot. Pantau juga pengeluaran secara berkala, misalnya dengan deteksi anomali biaya cloud, agar lonjakan tidak baru terlihat di akhir bulan.
Disiplin Tagging sebagai Fondasi
Strategi apa pun sulit dijalankan jika Anda tidak tahu biaya mana milik tim atau layanan mana. Praktik tagging dan alokasi biaya membuat keputusan membeli komitmen jadi berbasis data, bukan tebakan. Pembahasannya ada di artikel kami tentang tagging dan cost allocation sebagai fondasi FinOps. Untuk kerangka kerja yang lebih luas, FinOps Foundation menyediakan panduan yang bisa dijadikan acuan.
Langkah Pertama yang Bisa Dimulai Minggu Ini
Mulai dari Audit Pola Pemakaian
Anda tidak perlu langsung membeli komitmen besar. Mulailah dengan melihat pemakaian server selama tiga sampai enam bulan terakhir, lalu pisahkan mana yang konstan, mana yang musiman, dan mana yang bisa diulang jika terhenti. Dari pemetaan sederhana ini, biasanya terlihat bagian mana yang paling layak dipindahkan ke model harga lain. Lakukan perubahan bertahap dan ukur dampaknya pada tagihan sebelum menambah komitmen berikutnya.
Diskusikan Skenarionya dengan Tim yang Memahami Konteks Anda
Menentukan porsi yang tepat memerlukan pemahaman tentang beban kerja, toleransi risiko, dan rencana pertumbuhan bisnis. Jika tim internal Anda belum punya waktu untuk menganalisisnya, Pandawa Cloud .Net dapat membantu meninjau data pemakaian dan menyusun skenario kombinasi yang sesuai, tanpa kewajiban untuk melanjutkan. Dengan begitu, keputusan komitmen dibuat berdasarkan angka yang jelas, bukan perkiraan.
