Cost Optimization #

Cost optimization adalah tentang mendapatkan value maksimum dari setiap rupiah yang dihabiskan di cloud — bukan tentang memotong biaya sampai sistem tidak bisa berfungsi dengan baik. Perbedaan ini penting: tujuannya bukan meminimalkan biaya, tapi memaksimalkan efisiensi. Resource yang mahal tapi memberikan value bisnis yang sepadan adalah investasi yang baik. Resource yang murah tapi tidak digunakan oleh siapapun adalah pemborosan. Artikel ini adalah kompilasi pendekatan praktis untuk menemukan dan mengeliminasi pemborosan, serta mengoptimalkan resource yang benar-benar dibutuhkan.

Framework: Identify, Prioritize, Optimize #

Proses optimasi yang terstruktur:

  1. IDENTIFY — Temukan kandidat optimasi
     → Cost Explorer / billing dashboard
     → Rekomendasi otomatis dari provider (Trusted Advisor, Recommender)
     → Manual review resource yang belum di-optimize

  2. PRIORITIZE — Pilih yang paling berdampak dulu
     → Estimasi penghematan potensial
     → Estimasi effort implementasi
     → Prioritaskan: penghematan besar + effort kecil = quick wins

  3. OPTIMIZE — Implementasikan perubahan
     → Buat perubahan, test, verify tidak ada dampak negatif
     → Dokumentasikan apa yang dilakukan dan mengapa

  4. VERIFY — Konfirmasi penghematan
     → Cek tagihan setelah perubahan
     → Apakah penghematan sesuai estimasi?
     → Apakah ada efek samping yang tidak diinginkan?

  5. ITERATE — Ulangi secara berkala
     → Lingkungan cloud terus berubah
     → Resource baru terus ditambahkan
     → Optimasi adalah proses berkelanjutan

Compute Optimization #

Rightsizing — Instance yang Tepat untuk Workload #

Rightsizing adalah menyesuaikan ukuran instance dengan
actual usage — tidak lebih besar dari yang dibutuhkan.

  Bagaimana mengidentifikasi kandidat rightsizing:
  
  Instance yang over-provisioned (paling umum):
  → CPU average < 10% selama 2 minggu → kemungkinan terlalu besar
  → Memory average < 20% selama 2 minggu → kemungkinan terlalu besar
  
  Instance yang under-provisioned:
  → CPU average > 80% → mungkin perlu dinaikkan
  → Sering mengalami OOM (out of memory) → perlu lebih besar

  Contoh penghematan rightsizing:
  m5.4xlarge (16 vCPU, 64GB): $0.768/jam → average CPU 8%
  
  Hanya butuh: m5.large (2 vCPU, 8GB): $0.096/jam
  Penghematan: 87.5% untuk instance ini!
  
  Tool yang membantu:
  ✓ AWS Compute Optimizer, GCP Recommender, Azure Advisor
  ✓ Grafana / Datadog untuk melihat actual CPU & memory usage
  ✓ Cloud provider cost console yang menampilkan utilization
  
  Tips rightsizing yang aman:
  ✓ Turunkan satu step dulu, monitor selama 2 minggu
  ✓ Cek peak usage, bukan hanya average
  ✓ Pastikan ada headroom untuk spike (targetkan 50-60% average)
  ✓ Test perubahan di staging sebelum production

Terminate Idle dan Orphaned Resources #

Ini adalah quick win yang paling mudah — resource yang tidak
dibutuhkan tapi masih berjalan dan ditagih.

  Jenis resource yang sering jadi orphaned:

  Instance yang tidak dipakai:
  → Dev/test instance yang lupa di-terminate setelah eksperimen
  → Instance dari project yang sudah selesai
  → "Liferay server dari 2021 yang tidak ada yang tahu fungsinya"
  
  Deteksi: CPU average 0-2% selama 2 minggu = kemungkinan tidak terpakai

  Volume (disk) yang tidak ter-attach:
  → Block volume yang di-detach saat instance dihapus
  → "Available" state tapi tidak di-attach ke instance manapun
  → Tetap ditagih per GB per bulan
  
  Deteksi: list semua volume dengan state "available"

  Snapshot lama:
  → Snapshot dari volume yang sudah dihapus
  → Snapshot yang lebih tua dari retention policy
  → Tidak ada yang akan pakai tapi tetap ditagih

  Load balancer tanpa target:
  → Load balancer yang tidak punya instance sehat di belakangnya
  → Tetap ditagih per jam

  IP elastis yang tidak ter-assign:
  → Elastic IP yang di-reserve tapi tidak di-attach ke instance
  → Biaya kecil per IP tapi tetap ada

  Cara sistematis membersihkan:
  ✓ Audit semua resource secara berkala (minimal bulanan)
  ✓ Automation: script yang kirim laporan resource yang idle
  ✓ Tagging "owner" — jika owner tidak bisa diidentifikasi → kandidat hapus
  ✓ "TTL" (time to live) tag: resource akan dihapus pada tanggal X
    jika tidak ada yang klaim kepemilikannya

Storage Optimization #

Object Storage:

  Lifecycle policy untuk tiering otomatis:
  → Data panas di hot tier: > 30 hari → pindah ke IA
  → Data IA: > 365 hari → pindah ke archive
  → Data archive: > 7 tahun → delete
  → Potensi penghematan: 50-80% dibanding simpan semua di hot tier

  Hapus incomplete multipart uploads:
  → Upload gagal di tengah jalan menyisakan data yang ditagih
  → Lifecycle policy: hapus incomplete multipart setelah 7 hari

  Identifikasi bucket dengan data yang tidak diakses:
  → Bucket yang tidak ada access dalam 90 hari → candidate archive atau delete

Block Storage:

  Identifikasi volume yang over-provisioned:
  → Volume 1TB yang hanya terisi 50GB
  → Resize volume ke ukuran yang lebih sesuai
  
  Hapus snapshot yang tidak diperlukan:
  → Snapshot lebih dari 1 tahun untuk dev/staging → hapus
  → Pertahankan hanya sesuai retention policy

  Ubah storage type jika performa tidak butuh SSD:
  → Data warehouse, log → HDD-based lebih murah
  → Hanya database production yang butuh SSD provisioned IOPS

Network Optimization #

Data Transfer Cost Reduction:

  Minimalkan cross-AZ traffic:
  → Tempatkan service yang sering berkomunikasi di AZ yang sama
  → Gunakan AZ-local deployment untuk workload yang tidak butuh HA penuh
  → Multi-AZ tetap untuk database, tapi application bisa AZ-local

  CDN untuk mengurangi egress:
  → Static assets (gambar, video, CSS, JS) di-serve via CDN
  → CDN punya harga egress yang lebih murah dari origin cloud
  → Cache di edge mengurangi request yang harus ke origin

  VPC Endpoint untuk private connectivity:
  → Akses S3, DynamoDB dari EC2 dalam VPC tanpa lewat internet
  → Tanpa VPC endpoint: trafik ke S3 → keluar VPC → masuk lagi
    = biaya NAT Gateway + data processing
  → Dengan VPC endpoint: trafik tetap dalam jaringan AWS
    = tidak ada biaya NAT, tidak ada biaya egress

  Compress data sebelum transfer:
  → API response compression (gzip/brotli): kurangi 60-80% ukuran transfer
  → Gunakan efficient serialization (Protocol Buffers vs JSON)
    untuk service-to-service communication volume tinggi

Database Optimization #

Managed Database:

  Rightsize instance database:
  → Database sering over-provisioned karena "takut lambat"
  → Monitor actual CPU, RAM, IOPS usage
  → Turunkan secara bertahap, monitor performa

  Aurora Serverless untuk database dengan trafik tidak menentu:
  → Scale up saat trafik tinggi, scale down (bahkan ke nol) saat sepi
  → Bayar per ACU-hour yang digunakan, bukan per instance-hour
  → Cocok untuk: dev database, aplikasi dengan trafik sangat fluktuatif

  Read Replica untuk scale read:
  → Daripada scale up instance utama, tambahkan read replica
  → Read-heavy workload: query analitik, laporan → arahkan ke replica
  → Lebih murah dari scale up instance utama

  Connection pooling:
  → Banyak koneksi database yang tidak efisien menyebabkan
    kebutuhan instance yang lebih besar
  → PgBouncer (PostgreSQL), ProxySQL (MySQL) untuk pool koneksi
  → Kurangi jumlah koneksi aktual ke database

Scheduling — Matikan yang Tidak Perlu #

Banyak resource tidak perlu berjalan 24/7:

  Dev dan Test Environments:
  → Tim kerja jam 8-18, tapi instance jalan 24/7
  → Matikan di luar jam kerja dan akhir pekan:
    Running: 8 jam/hari × 5 hari × 4 minggu = 160 jam/bulan
    vs selalu on: 24 jam × 30 hari = 720 jam/bulan
    → Hemat 78%!
  
  Implementasi:
  → AWS Instance Scheduler
  → Cloud Function/Lambda yang trigger start/stop via cron
  → Terraform yang di-run dengan schedule jika pakai IaC penuh

  Batch workload yang tidak butuh dedicated instance:
  → ETL pipeline yang jalan 2 jam per hari
  → Spin up instance saat job mulai → terminate setelah selesai
  → Atau: gunakan managed batch service yang provision on-demand

  Staging environment:
  → Tidak perlu selalu running di luar jam kerja
  → Scale down atau matikan di malam hari
  → Restore di pagi hari sebelum jam kerja

Cost Optimization sebagai Proses, Bukan Proyek #

Pemborosan tidak terjadi sekali lalu selesai — ia terus muncul:
  → Setiap sprint baru, resource baru ditambahkan
  → Requirement berubah, resource lama tidak lagi dibutuhkan
  → Tim baru belum tahu best practices

  Automasi untuk deteksi berkelanjutan:
  ✓ Weekly report: instance dengan CPU < 5% selama 7 hari
  ✓ Daily report: resource baru yang untagged
  ✓ Monthly report: kandidat rightsizing berdasarkan 30 hari data
  ✓ Alert: spending per tim melebihi budget
  ✓ Alert: resource idle > 14 hari (candidate untuk review)

  Integrasi ke workflow engineering:
  ✓ Cost estimate menjadi bagian dari design review
  ✓ Cleanup checklist saat project selesai
  ✓ "Berapa biaya feature ini per bulan?" sebagai pertanyaan normal
  ✓ Cost optimization sebagai salah satu metrik dalam quarterly review

  Target yang realistis:
  Bukan "nol waste" (tidak realistis dan menghambat inovasi)
  Tapi "waste teridentifikasi dan ditangani dalam 30 hari"
  dan "resource baru dibuat dengan size yang tepat dari awal"

Ringkasan #

• Framework Identify → Prioritize → Optimize → Verify → Iterate — optimasi bukan satu kali; ia adalah siklus yang berkelanjutan.
• Rightsizing adalah quick win terbesar — instance yang over-provisioned sangat umum; instance dengan CPU rata-rata 10% adalah kandidat untuk diturunkan ukurannya.
• Resource idle dan orphaned adalah pemborosan murni — volume tidak ter-attach, snapshot lama, IP elastis yang tidak dipakai, load balancer tanpa target; audit berkala untuk membersihkannya.
• Storage lifecycle policy menghemat 50-80% biaya storage — otomasi perpindahan data ke tier yang lebih murah seiring bertambahnya usia data.
• Scheduling dev/test environment bisa hemat hingga 78% — instance non-produksi tidak perlu berjalan di luar jam kerja dan akhir pekan.
• Cost optimization yang efektif adalah proses, bukan proyek — automasi deteksi pemborosan, integrasikan ke workflow engineering, dan jadikan cost awareness bagian dari kultur tim.