Belajar Infrastructure Engineer - Cost Optimization Infra

#Pendahuluan

Setelah di episode 23 kita membangun infrastruktur AI yang mahal, kini kita membahas seni menjaga biaya tetap terkendali: cost optimization. Cloud memberi skala elastis — sekaligus tagihan elastis. Tanpa disiplin, infrastruktur bisa menghabiskan anggaran tanpa menghasilkan nilai sepadan.

Mengapa topik ini penting? Karena biaya infrastruktur adalah tanggung jawab teknis, bukan sekadar urusan keuangan. Tim yang bisa memangkas biaya 30-50% tanpa mengorbankan performa adalah aset besar. Episode ini membangun pendekatan FinOps: visibilitas, rightsizing, lifecycle, dan akuntabilitas tim.

#FinOps: Mengelola Biaya seperti DevOps Mengelola Kode

FinOps adalah budaya dan praktik mengelola biaya cloud dengan prinsip yang mirip DevOps: iterasi, otomasi, dan kolaborasi lintas tim.

#Cost Visibility: Kalian Tidak Bisa Mengelola yang Tidak Terlihat

#Tagging: Fondasi Visibilitas

Tanpa tag, tagihan cloud adalah angka tanpa wajah. Setiap resource wajib punya tag sejak dibuat:

Env        : prod | staging | dev
Team       : platform | data | checkout
CostCenter : CC-4012
Project    : billing-api
Owner      : budi@lab.local
Shutdown   : 18-07 (auto stop jam 18, start 07)

resource "aws_instance" "app" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t3.medium"
 
  tags = {
    Env        = "prod"
    Team       = "platform"
    CostCenter = "CC-4012"
    Shutdown   = "18-07"
  }
}

Tag yang konsisten mengubah tagihan cloud menjadi laporan per tim, per project, per environment — data keputusan, bukan tebak-tebakan.

#Cost Report dan Budget Alert

Biasakan melihat angka setiap minggu — bukan saat tagihan datang:

Mingguan : review biaya per team/service, cari anomali
Bulanan  : bandingkan dengan bulan lalu, proyeksikan
Alert    : budget threshold 50% / 80% / 100% → otomatis

Contoh alert di cloud:

aws budgets create-budget --account-budget budget.json
# budget.json: 500 USD/bulan, alert di 80% dan 100%

#Rightsizing: Membayar Sesuai yang Dipakai

Rightsizing menyesuaikan ukuran resource dengan kebutuhan nyata — langkah pertama penghematan terbesar.

#Metodologi Rightsizing

1. Ukur utilisasi nyata (30-90 hari, bukan 1 hari)
2. Identifikasi over-provisioned (CPU/RAM < 30-40%)
3. Identifikasi under-provisioned (sedang-sedang saja)
4. Turunkan/naikkan ukuran — satu variabel, ukur ulang
5. Ulangi berkala (beban berubah seiring waktu)

Pola umum di cloud:

#Utilisasi vs Kebutuhan

Jangan rightsize sampai batas tipis — kalian perlu headroom untuk spike (episode 22). Target sehat: utilisasi puncak 50-70%, bukan 90%.

#Lifecycle: Resource Lahir dan Mati

Biaya cloud membengkak paling banyak dari resource yang tidak pernah mati:

#Auto-Stop untuk Non-Produksi

Environment dev/staging tidak perlu menyala 24/7:

Dev/staging : mati 19:00, nyala 07:00 + akhir pekan mati
Environment : boleh mati tanpa dampak (itu bedanya dengan prod)

Otomasikan dengan Instance Scheduler atau Lambda/Cloud Function, atau tool IaC:

resource "aws_scheduler_schedule" "stop_dev" {
  name              = "stop-dev-weekly"
  schedule_expression = "cron(0 19 * * ? *)"
  flexible_time_window { mode = "OFF" }
  target {
    arn      = "arn:aws:scheduler:::aws-services:ec2:stop-instances"
    role_arn = aws_iam_role.scheduler.arn
    input    = jsonencode({ InstanceIds = [aws_instance.app.id] })
  }
}

#Lifecycle Object Storage

Object storage murah — tapi bisa lebih murah. Lifecycle policy menurunkan tier dan menghapus otomatis (lanjutan episode 12):

0-30 hari   : hot (akses cepat)
31-90 hari  : warm (akses jarang)
91-365 hari : cold/archive (murah)
> 365 hari  : hapus (jika sesuai retention regulasi!)

#Pola Penghematan Cloud

#Reserved Instance / Savings Plans

Untuk beban yang pasti jalan 24/7 (baseline), diskon hingga 40-60% dengan komitmen 1-3 tahun. Aturan: jangan beli reserved untuk beban yang berubah-ubah — hanya baseline yang stabil.

#Spot/Preemptible Instance

Untuk job yang boleh diinterupsi (batch, training, stateless worker): diskon hingga 60-90%. Jangan untuk database atau layanan online.

#Memory vs Compute Trade-off

Terkadang mengoptimalkan aplikasi lebih murah daripada menambah instance: query yang efisien, cache yang benar (episode 15), dan autoscaling yang tepat (episode 21) sering mengurangi kebutuhan hardware.

#Akuntabilitas Tim

Optimasi paling tahan lama adalah yang membuat setiap orang merasa biaya adalah tanggung jawabnya:

1. Chargeback/showback: laporan biaya per tim dikirim rutin — tim melihat dampak biaya dari keputusan mereka.
2. Ritual bulanan: 30-60 menit review cost dengan pemilik tim.
3. Unit economics: ukur biaya per unit nilai (biaya per request, per user aktif, per transaksi) — bukan hanya total.
4. Jadikan optimalisasi kebiasaan: setiap PR infrastruktur otomatis ditanya "berapa biaya ini, dan kenapa?"

#Common Pitfalls Cost Optimization

• Optimasi sekali jalan: beban berubah; rightsizing harus berkala.
• Menyentuh instance produksi tanpa perhitungan: menurunkan ukuran database tanpa beban data = outage.
• Tanpa tagging: tidak bisa alokasi biaya, tidak ada akuntabilitas.
• Mengabaikan egress/data transfer: keluar data sering mahal dan tak terlihat di instance cost.
• Reserved instance untuk beban berubah: komitmen panjang yang akhirnya tidak terpakai.
• Menyimpan semua data selamanya: tanpa lifecycle, storage dingin menumpuk dan mahal diam-diam.

#Penutup

Pada episode 24 ini kalian telah membangun disiplin FinOps:

• Siklus FinOps: Inform → Optimize → Operate.
• Tagging wajib adalah fondasi visibilitas dan alokasi biaya.
• Rightsizing berbasis utilisasi nyata, dengan headroom yang tetap dijaga.
• Lifecycle: auto-stop non-produksi, lifecycle storage, reserved untuk baseline, spot untuk batch.
• Akuntabilitas: chargeback, review bulanan, dan unit cost sebagai metrik jujur.

Di episode 25 selanjutnya kita mengubah tim infrastruktur menjadi penyedia produk: infrastructure as product — platform mindset, golden paths, dan dokumentasi. Sampai jumpa di episode 25!