Belajar Cloud Engineer - Cost Optimization & FinOps

#Pendahuluan

Di episode 15 kita mengamankan infrastruktur. Sekarang pertanyaan yang sama pentingnya untuk kelangsungan hidup di dunia kerja: berapa biayanya? Cloud itu paradoks — sangat mudah untuk membuat resource baru (klik, jadi), tapi sangat sulit untuk mengingat menghapusnya. Tagihan bulanan yang membengkak bukan karena satu keputusan besar, melainkan ratusan keputusan kecil yang tidak terkendali.

Episode 16 membahas cost optimization & FinOps — disiplin yang menggabungkan keuangan, engineering, dan data untuk mengelola biaya cloud. Kalian akan belajar right-sizing, reserved/savings plans, tagging, dan cost monitoring, lalu melakukan audit nyata untuk menemukan dan memangkas pemborosan di infrastruktur yang sudah kalian bangun.

#Mengapa Cost Bukan Urusan "Nanti"

Analogi yang tepat: cloud seperti dapur restoran dengan kulkas tanpa kunci. Kapan pun lapar, ambil saja — tapi lupa mencatat, stok habis tanpa disadari. Di perusahaan, tagihan cloud tanpa FinOps adalah kebocoran senyap yang muncul di rapat keuangan tiga bulan kemudian sebagai "kejutan".

Tiga pemborosan paling umum:

1. Resource idle — VM menyala 24 jam tapi dipakai 2 jam sehari.
2. Over-provisioning — beli c5.2xlarge padahal beban muat di t3.medium (right-sizing).
3. Tanpa tagging — biaya tidak bisa dialokasikan ke tim/proyek, jadi tidak ada yang merasa bertanggung jawab.

#FinOps: Tiga Fase Siklus

FinOps bukan tool, melainkan siklus yang berulang:

• Inform — lihat tagihan, alokasikan per tim/proyek (membutuhkan tagging yang disiplin).
• Optimize — right-sizing, menghapus idle, memakai savings plans.
• Operate — proses yang berjalan terus: review berkala, budget alert, laporan otomatis.

Peran penting: semua orang bertanggung jawab, bukan hanya Finance. Engineer yang membuat resource harus paham biayanya; tim yang memakai resource harus menanggungnya lewat tagging.

#Right-Sizing

Right-sizing adalah mencocokkan ukuran resource dengan beban aktual — tidak terlalu besar (boros), tidak terlalu kecil (melambat). Caranya berbasis data, bukan perasaan:

Contoh nyata: VM t3.xlarge (4 vCPU, 16 GB) yang CPU-nya nyaris tidak pernah lewat 15% — biaya per bulan tiga kali lebih besar daripada t3.medium (2 vCPU, 4 GB) yang cukup. Di episode 21 kita akan melihat bagaimana auto-scaling menyelesaikan masalah ini secara otomatis; untuk sekarang, right-sizing adalah langkah manual yang wajib.

aws ec2 describe-instances \
  --query 'Reservations[].Instances[].[InstanceId,InstanceType,State.Name,Tags[?Key==`Name`].Value|[0]]' \
  --output table

Metrik utilisasi bisa diambil dari CloudWatch (episode 9): CPU average 14 hari adalah data utama untuk memutuskan ukuran baru.

#Reserved & Savings Plans

Harga cloud itu seperti tarif transportasi: bayar per-perjalanan (on-demand) itu paling mahal, bayar langganan lebih murah. Provider memberi potongan besar jika kalian berkomitmen:

• AWS Reserved Instances / Savings Plans — potongan hingga 60-70% untuk komitmen 1-3 tahun.
• GCP Committed Use Discounts — potongan untuk komitmen resource compute 1-3 tahun.
• Azure Reserved VM Instances / Savings Plan — pola yang sama.

Kapan memakainya? Aturan praktis:

1. Base load (beban yang selalu ada) → commit. Beban variabel → on-demand.
2. Beban predictable seperti workload produksi dengan trafik stabil adalah kandidat utama.
3. Mulai dari komitmen kecil, naikkan perlahan — jangan langsung komitmen 3 tahun tanpa data.

Kombinasi yang sehat: on-demand menyerap lonjakan, savings plan menyerap beban dasar — dua-duanya penting, porsi disesuaikan data.

#Tagging: Fondasi Semua Analisis Biaya

Tanpa tagging, cost monitoring hanya bisa menjawab "berapa totalnya", bukan "siapa yang menghabiskan berapa". Tag adalah pasangan key:value yang ditempel ke resource:

Kunci suksesnya: tagging harus dipaksakan. Di Terraform, jadikan tag wajib di setiap resource; di pipeline CI/CD, tambahkan validasi yang menolak deploy jika tag hilang.

variable "default_tags" {
  type = map(string)
  default = {
    environment = "dev"
    team        = "learning"
    project     = "lab-ecommerce"
  }
}
 
resource "aws_instance" "web" {
  ami           = var.ami_id
  instance_type = var.instance_type
  tags          = var.default_tags
}

Jika semua resource memakai var.default_tags, satu aturan berlaku di mana-mana — inilah IaC membantu FinOps (episode 7).

#Cost Monitoring & Laporan

Setiap provider punya pusat biaya sendiri: AWS Cost Explorer, GCP Cost Management, Azure Cost Management. Fungsinya: melihat breakdown per layanan, per region, per tag, dan tren bulanan.

Pola analisis yang wajib:

1. Lihat tren — bulan lalu vs bulan ini; berapa pertumbuhan biaya.
2. Breakdown per service — mana yang dominan? (Sering: EC2/Compute + transfer data).
3. Breakdown per tag — environment mana yang membengkak? dev yang dibiarkan menyala.
4. Cari anomali — lonjakan tak wajar di luar pola; langsung selidiki.

Untuk multi-account, tool seperti AWS Organizations + Cost Explorer, GCP Billing Export ke BigQuery, atau Azure Cost Management + Power BI memberi visibilitas terpusat. Data biaya yang bisa di-query adalah jantung FinOps di skala besar.

#Praktik: Audit & Kurangi Biaya

Mari audit infrastruktur lab kalian dan cari pemborosan:

1. Cek resource yang menyala — describe-instances (AWS) / gcloud compute instances list / az vm list; tandai yang idle.
2. Ukur utilization — ambil metrik CPU rata-rata 14 hari (episode 9) untuk setiap VM.
3. Turunkan yang over-provisioned — instance dengan CPU di bawah 30% turunkan ukurannya.
4. Hapus yang tidak dipakai — VM "sementara" yang terlupakan, snapshot lama, load balancer orphan, IP elastis yang tidak ter-attach.
5. Terapkan tagging — pasang environment, team, project ke semua resource.
6. Pasang budget alert — di 50% dan 85%.
7. Commit beban dasar — jika ada workload 24/7 yang stabil, pertimbangkan savings plan.

aws ec2 describe-addresses \
  --query 'Addresses[?AssociationId==`null`].[PublicIp,AllocationId]' \
  --output table

Aturan praktis: resource yang tidak bisa dijelaskan fungsinya dalam 5 menit = kandidat hapus. Setelah audit selesai, bandingkan proyeksi tagihan bulan depan dengan bulan ini — penurunan nyata adalah bukti bahwa FinOps bekerja.

#Kesalahan Umum (Common Pitfalls)

1. Mengoptimalkan tanpa data — menurunkan ukuran VM berdasarkan perasaan, lalu aplikasi melambat; selalu ukur dulu.
2. Mengabaikan data transfer — transfer antar-region dan internet sering jadi biaya tersembunyi terbesar.
3. Tagging serampangan — tag dipasang tapi tidak dipakai untuk analisis; kekacauan baru.
4. Commit sebelum memahami beban — savings plan 3 tahun untuk workload yang belum stabil = terikat biaya mati.
5. Resource sisa percobaan dibiarkan — "nanti saya hapus" yang tidak pernah terjadi; jadwalkan penghapusan otomatis (episode 8).
6. Tidak ada alert — tagihan baru disadari saat sudah terlanjur besar; budget alert sejak awal.

#Penutup

Inti yang harus dibawa pulang:

• FinOps adalah siklus inform → optimize → operate — bukan proyek sekali jalan.
• Right-sizing berbasis data utilization 14 hari; jangan menebak.
• Savings plans untuk beban dasar yang stabil; on-demand untuk lonjakan.
• Tagging adalah prasyarat semua analisis biaya — wajib dan dipaksakan.
• Budget alert dipasang sebelum masalah, bukan sesudah tagihan besar.

Di episode 17 selanjutnya kita akan memakai pemahaman ini dalam skenario paling menantang seorang cloud engineer: migration to cloud — assessment, strategi 6R, lift-and-shift vs re-platform, dan data migration, lalu menyusun rencana migrasi aplikasi nyata. Sampai jumpa di episode 17!