Belajar Cloud Computing - FinOps, Cost Management & Cloud Optimization

#Pendahuluan

Setelah di episode 16 kalian membuat infrastruktur secepat menulis kode, muncul pertanyaan yang sering terlambat disadari: siapa yang membayar semuanya? Kemudahan provisioning di cloud adalah pisau bermata dua — hal yang sama yang membuat tim bisa membangun environment dalam hitungan menit juga bisa membuat tagihan membengkak dalam hitungan hari.

Episode ini membahas FinOps: disiplin yang menyatukan engineering, finance, dan bisnis dalam mengelola biaya cloud. Kalian akan belajar strategi optimasi paling berdampak — right-sizing, auto-shutdown, spot, savings plans, dan lifecycle storage — lalu menutupnya dengan budget dan alert yang menjaga biaya tetap terkendali.

#Pembahasan Utama

#Apa Itu FinOps

FinOps adalah disiplin manajemen biaya cloud yang menyatukan tiga pihak: tim engineering yang memakai resource, tim finance yang membayar tagihan, dan tim bisnis yang menetapkan nilai layanan. Inti filosofinya: biaya bukan urusan finance seorang diri — engineer memikul tanggung jawab langsung atas resource yang mereka buat.

Analogi paling pas adalah dapur restoran. Chef memilih dan memakai bahan (engineering), koki anggaran mengawasi pengeluaran (finance), dan pemilik menentukan menu yang laku (bisnis). Restoran yang sehat tidak menyerahkan seluruh pengendalian dapur ke bagian keuangan — sang chef tahu harga setiap bahan yang ia pakai, karena hanya dia yang tahu bahan mana yang wajib dan mana yang sekedar kebiasaan.

Perjalanan FinOps berputar dalam tiga fase:

1. Inform — visibilitas: tahu berapa yang dibelanjakan dan oleh siapa, terutama lewat tagging dan alokasi biaya.
2. Optimize — menurunkan biaya: right-sizing, menghapus resource tak terpakai, dan memakai diskon yang tersedia.
3. Operate — menjaga biaya tetap terkendali: budget, alert, dan review berkala sebagai rutinitas.

#Strategi Optimasi Biaya

Empat strategi berikut menyumbang sebagian besar penghematan di lapangan. Urutannya disengaja: dari yang paling sering dilupakan sampai yang paling membutuhkan perencanaan.

1. Right-sizing. Instance yang over-provisioned adalah pemborosan paling umum — orang cenderung memilih ukuran besar "biar aman". Gunakan data metrik dari episode 15 (CPU, memory, jaringan) untuk memilih ukuran yang tepat, dan jangan mengukur dari beban puncak sesaat, melainkan dari tren mingguan. Instance yang rata-rata hanya memakai 15 persen CPU layak diturunkan satu atau dua level.

2. Auto-shutdown environment staging dan dev. Environment non-produksi tidak perlu nyala 24 jam. Jadwalkan mati di malam hari dan akhir pekan — AWS Instance Scheduler, GCP dengan Cloud Scheduler, Azure dengan shutdown schedule via Automation account. Langkah ini sendiri bisa menghemat hingga 60 persen biaya compute non-produksi, tanpa mengubah perilaku aplikasi sama sekali.

3. Spot dan Savings Plans. Untuk workload yang toleran terhadap gangguan — batch job, rendering, CI — spot instances bisa hemat hingga 90 persen karena cloud boleh merebut kembali kapasitasnya. Untuk beban produksi yang stabil, Savings Plans atau reserved instances memberikan diskon 30 sampai 60 persen sebagai imbalan komitmen 1 hingga 3 tahun. Gunakan spot untuk yang fleksibel, savings plan untuk yang stabil.

4. Lifecycle storage ke archive. Data yang jarang diakses tidak perlu hidup di tier standar yang mahal. Buat aturan lifecycle agar objek otomatis berpindah dari tier standar ke infrequent access, lalu ke archive setelah periode tertentu:

#Melihat dan Menahan Biaya: Budget dan Alert

Optimasi tanpa visibilitas ibarat mengemudi tanpa speedometer. Cloud menyediakan alat untuk melihat dan menahan biaya:

• AWS — Cost Explorer untuk analisis tren, dan Budgets untuk menetapkan batas beserta alert serta otomatisasi.
• GCP — Cloud Billing reports untuk analisis, dan budgets & alerts untuk ambang batas.
• Azure — Cost Management + Billing untuk analisis, dan Azure Advisor untuk rekomendasi optimasi.

Contoh melihat biaya bulan lalu per layanan lewat Cost Explorer API:

aws ce get-cost-and-usage \
  --time-period Start=2026-07-01,End=2026-08-01 \
  --granularity MONTHLY \
  --metrics "UnblendedCost" \
  --group-by Type=DIMENSION,Key=SERVICE

Perintah aws ce get-cost-and-usage di atas mengembalikan pengelompokan biaya per layanan:

{
  "ResultsByTime": [
    {
      "TimePeriod": {
        "Start": "2026-07-01",
        "End": "2026-08-01"
      },
      "Groups": [
        {
          "Keys": ["Amazon Elastic Compute Cloud"],
          "Metrics": {
            "UnblendedCost": { "Amount": "412.50", "Unit": "USD" }
          }
        }
      ]
    }
  ]
}

Angka inilah yang menjadi dasar keputusan: layanan mana yang mendominasi tagihan, apakah polanya wajar, dan strategi optimasi mana yang paling masuk akal untuk diterapkan.

Budget yang baik tidak hanya mencatat — ia mengirim alert lebih awal. Contoh budget bulanan dengan alarm di ambang 80 persen:

{
  "BudgetName": "monthly-production",
  "BudgetType": "COST",
  "BudgetLimit": { "Amount": "1000", "Unit": "USD" },
  "TimeUnit": "MONTHLY",
  "CostFilters": {},
  "CostTypes": {
    "IncludeCredit": false,
    "IncludeRefund": false
  }
}

{
  "Notifications": [
    {
      "Notification": {
        "NotificationType": "ACTUAL",
        "ComparisonOperator": "GREATER_THAN",
        "Threshold": 80,
        "ThresholdType": "PERCENTAGE"
      },
      "Subscribers": [
        { "SubscriptionType": "EMAIL", "Address": "devops@company.id" }
      ]
    }
  ]
}

Ketika pengeluaran melewati 80 persen budget, email masuk lebih awal — jauh sebelum tagihan menjadi kejutan di akhir bulan. Dengan kedua file ini, budget dibuat lewat aws budgets create-budget dalam satu langkah.

#Perbandingan Layanan Biaya Big 3

Seperti episode-episode sebelumnya, konsepnya identik — visibilitas, optimasi, dan operasionalisasi — hanya nama layanannya yang berbeda. Yang membedakan tingkat kedewasaan sebuah tim adalah disiplinnya: tag dikelola dengan benar, review biaya terjadwal, dan budget ditegakkan lewat otomasi.

#Penutup

Pada episode 17 ini kalian telah mempelajari sisi ekonomi cloud: FinOps — kolaborasi engineering, finance, dan bisnis dengan tiga fase inform, optimize, operate; empat strategi optimasi — right-sizing dengan data metrik, auto-shutdown untuk staging dan dev, spot dan savings plans untuk diskon, serta lifecycle storage ke archive untuk data dingin; budget dan alert — menetapkan batas dan otomatisasi tindak lanjut; serta perbandingan alat di AWS, GCP, dan Azure.

Sampai di sini kalian mampu membangun, mengamankan, mengawasi, mengotomasi, dan mengendalikan biaya di satu cloud. Pertanyaan berikutnya muncul saat organisasi tidak cukup dengan satu penyedia: bagaimana menjalankan workload di dua cloud sekaligus, atau menghubungkan cloud dengan data center on-premise milik sendiri? Episode berikutnya, Hybrid Cloud & Multi-Cloud Connectivity, membuka dunia jaringan yang melampaui batas satu provider.