Belajar Cloud Architect - Cost Architecture & FinOps

#Pendahuluan

Di episode 8 kita menghitung reliability; kali ini kita menghitung biaya. Cost adalah sisi lain dari trade-off arsitektur (episode 3): reliability tinggi bisa dibeli, tapi harganya harus masuk akal secara bisnis. Inilah domain FinOps — praktik mengelola biaya cloud secara berkelanjutan, dengan arsitek sebagai pemain kuncinya.

Banyak organisasi baru sadar biaya saat tagihan bulanan melonjak. Arsitek yang baik mencegah kejutan itu: biaya diproyeksikan saat desain, dikontrol dengan tagging, dan diaudit secara rutin. Episode ini membangun tiga kemampuan: cost modeling, tagging & accountability, dan proyeksi/audit.

#Cost Modeling: Menghitung Sejak Desain

#Unit Economics

Jangan menghitung total biaya — hitung biaya per unit bisnis. Pertanyaan utamanya: berapa biaya melayani satu pengguna, satu order, satu request?

Metrik	Cara Menghitung	Makna
Cost per user	Total cost bulanan ÷ active users	Apakah unit economics sehat?
Cost per request	Total cost compute+data ÷ jumlah request	Efisiensi per transaksi
Cost per GB	Total cost storage ÷ data yang disimpan	Efisiensi penyimpanan

Unit economics membuat biaya bisa dibandingkan lintas waktu: apakah efisiensi membaik saat skala bertambah? Dan bisa diproyeksikan: jika user naik 3x, berapa biayanya?

#Model Biaya Komponen

Breakdown biaya khas per komponen arsitektur:

Proyeksi biaya bulanan sederhana

Compute (EC2/EKS)     : $400  (2× reserved)
Serverless (Lambda)   : $60   (3 juta eksekusi)
Database (RDS)        : $180  (multi-AZ, 2 AZ)
Storage (S3)          : $40   (5 TB + GET/PUT)
Networking (transfer) : $90   (10 TB keluar)
Observability         : $30   (CloudWatch + OTel)
─────────────────────────────────────────────
Total proyeksi        : $800/bulan
Unit cost per 100k user: $0.80

Model di atas dibuat sebelum membangun, bukan setelah tagihan datang. Arsitek yang mengerti struktur biaya komponen bisa memperkirakan dampak setiap pilihan desain sejak episode 4.

#Tagging: Accountability dan Insight

Tagging adalah metadata pada resource cloud (env, team, app, cost-center). Tanpa tagging, tagihan adalah satu angka besar yang tidak bisa dipetakan. Dengan tagging:

Siapa pemilik biaya ini? (team/owner)
Environment mana? (prod/staging/dev)
Untuk aplikasi apa? (app/cost-center)
Boleh di-stop malam hari? (schedule)

Contoh tag wajib (tagging policy)

env: prod
team: checkout
app: payment-gateway
cost-center: cc-1042
schedule: always-on

Konsistensi tagging harus ditegakkan — sebaiknya dengan policy-as-code (episode 11). Tag yang tidak konsisten lebih buruk daripada tidak ada, karena membuat laporan biaya menyesatkan.

Tip

Terapkan tagging policy di awal, bukan nanti. Menambal tag ke ribuan resource yang sudah berjalan adalah pekerjaan menyakitkan dan sering tidak pernah selesai. Mulai dari aturan tag wajib yang sederhana (env, team, app) dan perketat seiring waktu.

#Memahami Pricing Model

Setiap provider menawarkan variasi pricing; yang penting memahami tiga model dasarnya:

Model	Karakter	Dipakai Untuk
On-demand	Bayar per jam, fleksibel, paling mahal	Workload tak terduga, eksperimen
Reserved / Savings Plan	Komitmen 1-3 tahun, diskon besar	Beban stabil 24/7 (base load)
Spot / Preemptible	Diskonto besar, bisa direbut provider	Batch, stateless, fault-tolerant

Strategi optimal biasanya kombinasi: reserved untuk base load (yang pasti jalan), on-demand untuk puncak tak terduga, spot untuk workload fleksibel.

#Arsitektur yang "Cost-Aware"

Cost architecture juga berarti mendesain agar resource tidak idle. Pola penghematan yang sering muncul dari keputusan arsitektur:

Serverless untuk workload spike — biaya mengikuti pemakaian, nol saat idle (episode 4).
Auto-scaling ke nol untuk environment non-produksi di luar jam kerja (episode 22).
Tiering storage — data jarang diakses dipindah ke tier murah (S3 Glacier / archive) (episode 5).
Enkripsi & deduplikasi pada data besar — hemat ruang, hemat biaya.

#Proyeksi dan Audit Biaya

#Siklus Proyeksi

Saat desain: buat model biaya per komponen (seperti di atas) dan dokumentasikan di ADR.
Saat rilis: bandingkan proyeksi vs realisasi pada bulan pertama.
Secara berkala: audit tagihan bulanan, cari anomali (resource baru, lonjakan transfer).

#Audit: Mencari Pemborosan

Daftar periksa audit bulanan yang umum:

Checklist audit biaya bulanan

[ ] Resource idle / tidak terpakai (stale instances, unattached volumes)
[ ] Environment non-prod mati di luar jam kerja
[ ] Lonjakan network transfer (yang mahal)
[ ] Database over-provisioned (CPU util < 20%?)
[ ] Storage tier yang salah (panas vs arsip)
[ ] Savings plan coverage cukup? Ada yang on-demand padahal stabil?

Temuan audit diubah menjadi action item arsitektur: mengubah ukuran instance, memindahkan storage ke tier murah, atau menyesuaikan skema scaling. Ini bukan urusan finance semata — hampir semua perbaikan biaya adalah keputusan arsitektur.

#Penutup

Inti yang harus dibawa pulang:

Hitung unit economics (cost per user/request/GB), bukan total tagihan.
Model biaya dibuat saat desain, lalu dibandingkan dengan realisasi.
Tagging konsisten = accountability; terapkan sejak awal dengan policy-as-code.
Kombinasikan on-demand, reserved, dan spot sesuai pola beban.
Audit berkala: idle resource, env non-prod, storage tier, transfer.

Di episode 10 selanjutnya kita akan membahas observability by design — telemetry sebagai input desain: metrics, logs, traces dengan OpenTelemetry, serta SLI/SLO. Sampai jumpa di episode 10!