Belajar Solution Architect - Cost & Budget Solution

#Pendahuluan

Setelah di episode 8 solusi kalian punya fondasi keamanan yang terancang sejak desain, kita beralih ke bahasa yang paling didengar stakeholder: biaya. Sebagus apa pun arsitektur kalian, ia tidak akan dibangun jika angkanya tidak masuk akal bagi yang membayar. Dan di era pasca-boom belanja cloud, pertanyaan "berapa biaya bulanan per ribu user?" adalah pertanyaan wajib di setiap review solusi.

Mengapa cost sering meledak? Karena keputusan desain awal menentukan 70-80% biaya jangka panjang — dan keputusan itu diambil oleh SA, bukan tim finance. NAT gateway yang salah tempat, log yang tak pernah dirotasi, atau environment dev yang berjalan 24/7 adalah contoh klasik tagihan surprise yang bisa dicegah di fase desain.

#TCO: Total Cost of Ownership

Kesalahan paling umum adalah membandingkan harga instance saja. TCO mencakup semua:

Dua catatan penting dari tabel itu:

• Egress/data transfer adalah pengejut tagihan nomor satu pemula. Arsitektur yang memaksa data besar melintasi boundary region/provider berkali-kali akan menggigit. Desain data placement dengan sadar (episode 7).
• Biaya orang sering lebih besar dari infrastruktur. Solusi self-hosted "hemat" $200/bulan tapi butuh 10 jam/maintenance mingguan biasanya lebih mahal dari managed service $600/bulan. Hitung jam, bukan hanya invoice.

#Pricing Model Cloud

Empat model dasar yang harus kalian kuasai untuk tiap komponen solusi:

Strategi standar yang menghasilkan: baseline pakai reserved, spike pakai on-demand/autoscaling, batch pakai spot. Untuk studi kasus tiket: kapasitas normal reserved tahunan; window sale dua hari ditangani autoscaling on-demand; pekerjaan generate laporan dan render aset di spot fleet.

#Teknik Desain Hemat Biaya

Cost efficiency bukan soal menekan tombol diskon saja — mayoritas penghematan datang dari keputusan desain:

1. Right-sizing dari data nyata, bukan tebakan konservatif. Mulai kecil, ukur p95 CPU/memory, naikkan berbasis metrik. Instance oversized 4x adalah pemborosan tersenyum.
2. Autoscaling dengan floor masuk akal — scale-to-zero hanya untuk workload benar-benar sporadis; untuk aplikasi utama, floor 2 instance multi-AZ.
3. Tiering storage: data akses jarang turunkan ke kelas dingin (S3 Infrequent Access/Glacier setara). Log akses 6 bulan lalu tidak butuh performa SSD.
4. Rotasi & retensi disiplin: log aplikasi 30 hari panas, arsip 1 tahun, lalu hapus. Snapshot DB harian dipertahankan 7, mingguan 30. Tanpa kebijakan tertulis, storage tumbuh monoton naik.
5. Cache untuk kurangi compute: hit ratio 90% di Redis (episode 7) artinya 90% request tidak menyentuh database mahal.
6. Environment non-produksi tidur malam: schedule stop 19.00-08.00 dan akhir pekan menghemat ±65% biaya dev/staging.

Contoh guardrail otomatis yang layak dimasukkan sebagai bagian delivery solusi:

# Tagging wajib agar biaya bisa diatribusikan per proyek/environment
aws resourcegroupstaggingapi get-resources \
  --tag-filters Key=project,Values=ticketing Key=env,Values=prod
 
# Budget alert 50/80/100% via AWS Budgets (budget.json didefinisikan di episode 0)
aws budgets describe-budget --account-id <ID_AKUN> --budget-name ticketing-monthly

Tagging sering dianggap formalitas padahal ia fondasi visibility: tanpa tag, kalian tidak bisa menjawab "kenapa tagihan naik 40%?" — dan tanpa jawaban itu tidak ada optimasi yang bisa dimulai.

#Menyusun Estimasi yang Lolos Review

Format estimasi yang saya rekomendasikan untuk SDD bagian 5 — transparan atas asumsinya:

Asumsi : 500 rb tiket/bln, rata 20 req/s, peak sale 50 rb user 2 hari
 
Compute   : 4x baseline reserved + autoscaling peak     Rp 12.400.000
Database  : RDS Multi-AZ db.m6g.large + storage         Rp  8.200.000
Cache     : ElastiCache redis.m6g.large                 Rp  3.100.000
Network   : LB + egress 1,5 TB + NAT                    Rp  5.900.000
Lain-lain : CDN, WAF, monitoring, secrets               Rp  2.700.000
Non-prod  : dev+staging (scheduled 12x5)                Rp  2.300.000
---------------------------------------------------------------
TOTAL     :                                             Rp 34.600.000
Peak sale : tambahan on-demand 2 hari                   Rp  4.800.000

Perhatikan struktur yang membuatnya bisa diaudit: asumsi traffic di atas, breakdown per komponen, skenario puncak terpisah, dan sumber angka disebut (pricing calculator). Saat ada yang mempersoalkan, kalian tinggal membuka asumsi mana yang diperdebatkan — estimasi berubah menjadi diskusi data, bukan debat perasaan.

#Unit Economics: Metrik Favorit CFO

Satu angka lagi yang membuat kalian terlihat matang: biaya per unit bisnis. Bagi total biaya dengan unit yang dipahami bisnis:

Rp 34,6 jt / 500 rb tiket = Rp 69 per tiket (infra)
Target bisnis             <= Rp 100 per tiket  -> SEHAT, margin aman

Kalimat "biaya infrastruktur kami Rp 69 per tiket, di bawah target Rp 100" jauh lebih kuat di rapat daripada "kami sudah pakai spot instance".

#Cost Governance Setelah Launch

Estimasi hanyalah awal; biaya hidup sepanjang umur sistem:

• Review tagihan bulanan bersama — anomali terbesar biasanya ketahuan dalam 15 menit membaca cost breakdown per service.
• Anomaly alerting — provider punya deteksi lonjakan biaya otomatis; aktifkan.
• Kill switch kebiasaan buruk: resource untagged ditandai, snapshot yatim dihapus, environment demo kedaluwarsa dihancurkan otomatis.
• Re-evaluasi tiap kuartal: pola trafik berubah, harga provider turun, layanan baru lebih efisien — ADR biaya juga boleh revisi.

#Penutup

Inti yang harus dibawa pulang:

• Hitung TCO lengkap: infrastruktur, network/egress, dan biaya orang — bukan harga instance saja.
• Campur pricing model secara sadar: reserved untuk baseline, on-demand untuk spike, spot untuk interruptible, serverless untuk sporadis.
• Penghematan terbesar datang dari desain: right-sizing berbasis metrik, cache, tiering, retensi, dan environment tidur malam.
• Estimasi SDD yang lolos review = asumsi eksplisit + breakdown per komponen + skenario puncak + unit economics per tiket.
• Cost governance berlanjut setelah launch: tagging, budget alert, review bulanan, re-evaluasi kuartalan.

Di episode 10 selanjutnya kita akan membahas documentation & handoff — cara menulis dokumen solusi yang benar-benar dibaca, standar diagram C4, merapikan ADR, serta melakukan handoff ke tim delivery sehingga niat desain kalian dieksekusi apa adanya. Sampai jumpa di episode 10!