Belajar DevOps Engineer - Cost Optimization (FinOps)

#Pendahuluan

Salah satu ironi cloud: kemudahannya juga menjadi sumber pemborosan terbesar. Membuat VM baru butuh satu klik, dan tagihan datang tanpa diundang — volume yang terlupakan, instance yang menganggur, storage yang tidak pernah dibersihkan. FinOps adalah disiplin yang menyatukan keuangan, engineering, dan produk untuk mengelola biaya cloud secara bertanggung jawab.

FinOps bukan "memangkas biaya sebanyak-banyaknya" — itu resep merusak performa. FinOps adalah memaksimalkan nilai per rupiah yang dikeluarkan: biaya yang tepat untuk kapasitas yang dibutuhkan, terukur, dan dapat dipertanggungjawabkan. Di episode ini kalian memahami model FinOps, mempraktikkan cost tracking, right-sizing, dan budget alert, lalu mengaudit tagihan nyata.

#Model FinOps: Inform, Optimize, Operate

Kerangka kerja FinOps Foundation membagi praktik dalam tiga fase yang berulang:

1. Inform — kalian harus bisa melihat biaya: siapa yang menghabiskan berapa, di resource apa, dan untuk project apa. Tanpa visibilitas, optimasi adalah tebakan.
2. Optimize — berdasarkan data, kurangi pemborosan: hapus resource menganggur, right-sizing, manfaatkan pricing diskon.
3. Operate — jadikan efisiensi budaya: budget alert, review berkala, dan setiap engineer bertanggung jawab atas biaya resource-nya.

#Cost Tracking dan Tagging

Langkah pertama FinOps adalah tagging — menandai setiap resource dengan metadata yang konsisten. Tanpa tag, biaya hanyalah angka tanpa pemilik.

Standar tag minimal yang wajib dimiliki:

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"
 
  tags = {
    Environment = "prod"
    Owner       = "team-billing"
    CostCenter  = "eng-core"
    Application = "myapp"
  }
}

Dengan tag yang konsisten, laporan biaya menjadi query, bukan tebakan:

aws ce get-cost-and-usage \
  --time-period Start=2026-08-01,End=2026-08-16 \
  --granularity MONTHLY \
  --group-by Type=TAG,Key=Owner

#Right-Sizing: Ukuran yang Tepat untuk Beban Nyata

Pemborosan terbesar biasanya bukan harga, melainkan ketidaksesuaian ukuran: instance 8 vCPU untuk aplikasi yang memakai 1 vCPU. Right-sizing menyelaraskan kapasitas dengan beban aktual:

1. Ukur utilasi selama 2 minggu (CPU, memory, network) lewat metrik cloud.
2. Identifikasi kandidat — instance dengan utilasi puncak jauh di bawah kapasitasnya.
3. Turunkan ukuran bertahap, lalu verifikasi metrik layanan tidak memburuk (SLO dari episode 25).
4. Otomasi dengan autoscaling — daripada over-provision statis, biarkan scale menyesuaikan beban.

Selain right-sizing VM, perhatikan pemborosan tersembunyi yang sering terlupakan:

• Volume storage orphaned — disk yang tersisa setelah instance dihapus.
• Elastic IP / IP statis yang tidak terpakai — tetap ditagih.
• Snapshot lama — backup yang tidak pernah dihapus.
• Load balancer untuk traffic kosong.
• Environment dev yang menyala 24/7 — matikan di luar jam kerja (scheduling stop/start).

#Budget Alerts: Alarm Sebelum Terlambat

Tagihan cloud yang mengejutkan adalah tanda budget alert tidak ada. Setiap penyedia menyediakan mekanisme alert — dan DevOps Engineer harus memasangnya di semua lapisan:

gcloud billing budgets create \
  --billing-account=XXXXXX \
  --display-name="eng-monthly" \
  --budget-amount=10000 \
  --threshold-rule=percent=50 \
  --threshold-rule=percent=90 \
  --threshold-rule=percent=100 \
  --notify-rule=monitoring-notification-channels=projects/xxx/notificationChannels/yyy

Tiga threshold (50%, 90%, 100%) memberi waktu bertindak, bukan sekadar kabar buruk di akhir bulan. Alert harus sampai ke tim yang bisa bertindak — pesan ke Slack channel engineering, bukan hanya ke finance.

#Praktik: Audit dan Kurangi Biaya

Ikuti checklist audit ini secara berkala — mulai bulanan:

1. Buka laporan biaya dan group-by Owner → tim mana yang paling besar?
2. Filter resource menganggur — instance stopped lama, volume tanpa attachment, IP menganggur.
3. Periksa right-sizing — daftar 10 resource paling mahal; ukuran aktual vs kapasitas.
4. Tinjau environment dev/staging — masih perlu nyala 24/7?
5. Cek pricing tier — ada workload yang bisa pindah ke reserved/spot?
6. Catat temuan — buat backlog FinOps; tutup pemborosan terbesar dulu.
7. Pasang alert jika belum — 50/90/100% di semua project penting.

# Instance menganggur (stopped) yang masih ditagih storage
aws ec2 describe-instances \
  --filters "Name=instance-state-name,Values=stopped" \
  --query 'Reservations[].Instances[].{Id:InstanceId,Tags:Tags}' \
  --output table
 
# Volume tanpa attachment
aws ec2 describe-volumes \
  --filters "Name=status,Values=available" \
  --query 'Volumes[].VolumeId' --output text

#Pitfall Umum

• Optimasi tanpa data — memangkas resource yang paling jarang dilihat dashboard, padahal pemborosan ada di tempat lain.
• Mengurangi biaya, menaikkan risiko — instance dev yang dimatikan tanpa aturan jelas membuat orang bertanya "kenapa tiba-tiba down?"; jadwalkan dan komunikasikan.
• Tagging yang tidak konsisten — tag berguna hanya jika semua orang memakainya dengan aturan yang sama.
• Mengabaikan cost engineering di pipeline — runner CI yang boros adalah biaya besar yang tersembunyi di tiap push.
• Budget alert tanpa aksi — alarm tanpa pemilik yang jelas tidak mengubah perilaku.

#Penutup

Inti yang harus dibawa pulang:

• FinOps = inform → optimize → operate; nilai per rupiah, bukan sekadar memangkas.
• Tagging adalah fondasi visibilitas biaya — tanpa tag, biaya tidak punya pemilik.
• Right-sizing dan autoscaling menggantikan over-provision statis; perhatikan pemborosan tersembunyi.
• Budget alert di tiga threshold memberi waktu bertindak sebelum tagihan meledak.

Di episode 23 selanjutnya kita membahas AI-assisted Operations (AIOps) — bagaimana AI digunakan untuk deteksi insiden, auto-remediation, dan pendamping dalam pipeline. Teknologi yang paling cepat berkembang di ekosistem DevOps — dan yang paling banyak kesalahpahaman.