Cost Optimization di Cloud: Cara Mengurangi Tagihan AWS/GCP Tanpa Mengorbankan Performa

Kalau Anda pernah membuka dashboard billing AWS atau GCP di pagi hari dan langsung menghela napas panjang melihat angkanya, Anda tidak sendirian. Salah satu keluhan paling umum dari tim engineering yang sudah migrasi ke cloud bukan lagi soal reliabilitas atau skalabilitas — itu sudah dianggap solved. Keluhan terbesar sekarang adalah bill shock: tagihan yang membengkak tanpa alasan yang jelas, sering kali dua sampai tiga kali lipat dari estimasi awal saat migrasi. Menurut berbagai laporan industri, rata-rata organisasi membuang 27-30% dari belanja cloud mereka untuk resource yang tidak terpakai atau tidak efisien. Itu bukan angka kecil, apalagi untuk startup yang cash runway-nya terbatas.

Artikel ini akan membahas cost optimization di cloud secara menyeluruh — bukan sekadar "matikan instance yang tidak dipakai", tapi strategi sistematis mulai dari rightsizing, model pricing, storage lifecycle, sampai membangun budaya FinOps di tim engineering. Tujuannya bukan memangkas biaya membabi buta sampai aplikasi lemot, tapi menemukan titik optimal antara biaya dan performa.

Mengapa Tagihan Cloud Bisa Membengkak Tanpa Disadari

Sebelum masuk ke solusi, penting memahami akar masalahnya. Cloud punya karakteristik yang membuatnya rawan pemborosan dibanding infrastruktur on-premise tradisional: provisioning resource semudah satu klik atau satu baris terraform apply, tanpa proses procurement yang biasanya jadi "rem alami" di dunia on-premise. Beberapa penyebab paling umum:

• Over-provisioning — tim memilih instance type yang jauh lebih besar dari kebutuhan riil karena "aman" atau karena estimasi kapasitas dilakukan secara kasar saat awal proyek, lalu tidak pernah direvisi lagi.
• Idle dan orphaned resources — EBS volume yang sudah tidak terpasang ke instance manapun, load balancer yang dibuat untuk testing lalu dilupakan, snapshot lama yang terus tertagih setiap bulan, elastic IP yang tidak di-attach ke apa pun.
• Tidak ada autoscaling yang proper — sistem di-provision untuk menahan traffic peak sepanjang waktu, padahal peak hanya terjadi beberapa jam per hari.
• Environment non-production menyala 24/7 — staging, development, dan QA environment sering kali menyala terus meski hanya dipakai jam kerja.
• Data transfer cost yang tidak disadari — biaya keluar (egress) antar region atau ke internet yang terakumulasi diam-diam, terutama pada arsitektur microservices yang chatty antar service di region berbeda.
• Tidak memanfaatkan pricing model diskon — tetap membayar harga on-demand penuh padahal workload-nya predictable dan cocok untuk reserved pricing.

Kombinasi faktor-faktor ini membuat cost creep terjadi perlahan — tidak ada satu insiden besar yang bisa disalahkan, tapi akumulasi kecil dari ratusan resource yang masing-masing "cuma beberapa dolar per bulan" ujung-ujungnya jadi ribuan dolar.

Memahami Model Pricing: On-Demand, Reserved, dan Spot

Langkah pertama optimasi biaya adalah memahami bahwa cloud provider menawarkan beberapa model pricing untuk komputasi yang sama, dengan trade-off fleksibilitas versus harga.

Strategi yang matang biasanya mengombinasikan ketiganya sesuai karakteristik workload — pendekatan ini sering disebut sebagai "portfolio approach" dalam FinOps. Baseline traffic yang stabil ditutup dengan reserved/committed pricing, traffic yang fluktuatif ditutup dengan on-demand, dan workload yang toleran terhadap interupsi (batch processing, CI/CD runner, rendering) dialihkan ke spot instance.

Rightsizing: Menyesuaikan Ukuran Resource dengan Kebutuhan Riil

Rightsizing adalah proses menganalisis utilisasi resource aktual lalu menyesuaikan instance type, jumlah vCPU, memori, dan storage agar sesuai kebutuhan — tidak kurang, tidak berlebih. Banyak tim men-deploy instance m5.2xlarge padahal utilisasi CPU rata-rata di bawah 15%. Itu berarti membayar untuk kapasitas yang hampir tidak pernah dipakai.

Menggunakan Tools Bawaan Provider

AWS menyediakan Compute Optimizer yang menganalisis metrik CloudWatch selama 14 hari terakhir dan memberi rekomendasi instance type yang lebih hemat berdasarkan pola CPU, memori, network, dan disk I/O. GCP punya fitur serupa lewat Recommender API dan rekomendasi bawaan di Compute Engine console yang menyarankan machine type custom sesuai utilisasi historis.

Rekomendasi ini bukan sekadar tebakan — mereka berbasis data pemakaian riil, sehingga jauh lebih akurat dibanding estimasi manual saat provisioning awal proyek. Praktik yang baik adalah menjadwalkan review rightsizing bulanan, bukan sekali saat awal proyek lalu dilupakan selamanya.

Autoscaling sebagai Bentuk Rightsizing Dinamis

Rightsizing statis (memilih instance type yang tepat) hanya separuh cerita. Separuh lainnya adalah autoscaling — menyesuaikan jumlah instance secara dinamis mengikuti traffic. Contoh konfigurasi Auto Scaling Group di AWS lewat Terraform yang scale berdasarkan target CPU utilization:

resource "aws_autoscaling_policy" "scale_by_cpu" {
  name                   = "target-cpu-tracking"
  autoscaling_group_name = aws_autoscaling_group.app.name
  policy_type            = "TargetTrackingScaling"

  target_tracking_configuration {
    predefined_metric_specification {
      predefined_metric_type = "ASGAverageCPUUtilization"
    }
    target_value = 60.0
  }
}

resource "aws_autoscaling_group" "app" {
  name                = "app-asg"
  min_size            = 2
  max_size            = 10
  desired_capacity    = 2
  vpc_zone_identifier = var.private_subnet_ids

  launch_template {
    id      = aws_launch_template.app.id
    version = "$Latest"
  }
}

Dengan konfigurasi seperti ini, jumlah instance akan mengikuti beban riil — scale up saat traffic naik, scale down otomatis saat sepi, misalnya tengah malam. Ini jauh lebih efisien dibanding provisioning statis untuk peak capacity 24 jam sehari.

Optimasi Storage: Lifecycle Policy dan Storage Class

Storage sering jadi silent cost driver karena volumenya terus bertambah sementara jarang ada yang aktif menghapus data lama. Baik S3 maupun Google Cloud Storage menawarkan beberapa storage class dengan harga berbeda sesuai frekuensi akses.

• Standard/Hot — untuk data yang sering diakses, harga per GB paling mahal.
• Infrequent Access / Nearline — untuk data yang diakses kurang dari sebulan sekali, harga simpan lebih murah tapi ada biaya retrieval.
• Glacier / Coldline / Archive — untuk arsip jangka panjang, harga simpan sangat murah tapi retrieval lambat (jam) dan mahal.

Lifecycle policy memungkinkan transisi otomatis antar storage class berdasarkan umur objek. Contoh S3 lifecycle policy yang memindahkan log aplikasi secara bertahap:

{
  "Rules": [
    {
      "ID": "log-lifecycle",
      "Status": "Enabled",
      "Filter": { "Prefix": "logs/" },
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER" }
      ],
      "Expiration": { "Days": 365 }
    }
  ]
}

Selain lifecycle policy, jangan lupakan pembersihan rutin untuk snapshot EBS/persistent disk lama, AMI/image yang tidak terpakai, dan multipart upload S3 yang gagal (sering luput dan tetap ditagih meski uploadnya tidak pernah selesai).

Reserved Instances, Savings Plans, dan Committed Use Discounts

Untuk workload yang predictable — misalnya database production yang selalu menyala — komitmen jangka panjang memberikan diskon signifikan. AWS Savings Plans menawarkan fleksibilitas lebih dibanding Reserved Instances klasik karena komitmennya berbasis dolar per jam, bukan instance type spesifik, sehingga tetap bisa berpindah family instance tanpa kehilangan diskon. GCP Committed Use Discounts bekerja mirip, dengan komitmen 1 atau 3 tahun untuk vCPU dan memori.

Kuncinya adalah tidak berkomitmen berlebihan. Aturan praktis yang umum dipakai tim FinOps: komit hanya untuk baseline yang benar-benar konsisten dipakai minimal 70-80% dari waktu, sisanya biarkan on-demand atau autoscaling. Analisis penggunaan historis 3-6 bulan sebelum membuat komitmen 1-3 tahun.

Spot Instance untuk Workload yang Toleran Interupsi

Spot instance (AWS) atau preemptible/spot VM (GCP) memanfaatkan kapasitas idle milik provider dengan diskon hingga 90% dari harga on-demand, dengan konsekuensi instance bisa di-terminate provider kapan saja dengan notice singkat (2 menit di AWS). Ini sangat cocok untuk:

• CI/CD runner dan build job.
• Batch processing dan data pipeline yang bisa di-retry.
• Rendering, machine learning training dengan checkpoint.
• Stateless web worker di belakang load balancer dengan mix strategy (sebagian on-demand, sebagian spot).

Yang tidak cocok untuk spot: database stateful tanpa replikasi yang baik, sistem yang butuh uptime ketat tanpa toleransi interupsi. Strategi umum adalah mix instance — misalnya 70% kapasitas ASG dipenuhi spot, 30% on-demand sebagai fallback, dikombinasikan dengan beberapa instance type agar risiko capacity shortage di satu jenis instance tidak melumpuhkan sistem.

Data Transfer dan Network Cost yang Sering Terlewat

Biaya egress — data yang keluar dari cloud provider ke internet, atau bahkan antar region/availability zone dalam provider yang sama — kerap jadi kejutan di tagihan. Beberapa praktik untuk menekannya:

• Gunakan CDN (CloudFront, Cloud CDN) untuk konten statis agar traffic tidak selalu hit origin server, sekaligus menekan biaya egress origin.
• Desain arsitektur agar service yang chatty (saling komunikasi intensif) ditempatkan di availability zone atau region yang sama, karena traffic lintas AZ/region biasanya dikenakan biaya tambahan.
• Manfaatkan VPC endpoint / Private Service Connect untuk akses ke layanan managed (S3, BigQuery, dll) tanpa lewat internet gateway, yang biasanya lebih murah dan lebih cepat.
• Kompresi payload API dan penggunaan format data yang efisien (Protobuf/Avro dibanding JSON verbose) untuk mengurangi volume transfer pada skala besar.

Governance dan Automasi: Membangun Kebiasaan, Bukan Sekali Bersih-bersih

Optimasi biaya yang dilakukan sekali lalu ditinggalkan akan kembali membengkak dalam beberapa bulan. Yang berkelanjutan adalah governance dan automasi.

Tagging Strategy

Setiap resource wajib memiliki tag standar — misalnya team, environment, project, dan cost-center — agar cost allocation bisa dianalisis per tim atau proyek. Tanpa tagging yang konsisten, mustahil mengetahui siapa penyebab lonjakan biaya. Banyak organisasi menegakkan ini lewat policy-as-code (AWS Config Rules, GCP Organization Policy) yang menolak provisioning resource tanpa tag wajib.

Auto-Shutdown untuk Environment Non-Produksi

Environment development dan staging yang hanya dipakai jam kerja bisa dimatikan otomatis di luar jam kerja. Contoh sederhana Lambda function yang mematikan instance bertag environment=dev setiap malam:

import boto3

def lambda_handler(event, context):
    ec2 = boto3.client("ec2")
    instances = ec2.describe_instances(
        Filters=[
            {"Name": "tag:environment", "Values": ["dev", "staging"]},
            {"Name": "instance-state-name", "Values": ["running"]},
        ]
    )
    ids = [
        i["InstanceId"]
        for r in instances["Reservations"]
        for i in r["Instances"]
    ]
    if ids:
        ec2.stop_instances(InstanceIds=ids)
    return {"stopped": ids}

Dijadwalkan lewat EventBridge setiap pukul 20.00 dan dinyalakan kembali pukul 07.00, ini bisa memangkas biaya compute non-produksi hingga 60-65% karena instance hanya menyala ~11 jam dari 24 jam sehari, dan tidak menyala sama sekali di akhir pekan jika ditambah pengecualian hari kerja.

Budget Alert dan Anomaly Detection

AWS Budgets dan GCP Budgets & Alerts memungkinkan notifikasi otomatis saat pengeluaran mendekati atau melampaui ambang batas tertentu, termasuk forecast alert yang memprediksi apakah bulan ini akan melebihi budget berdasarkan tren pemakaian sejauh ini. AWS Cost Anomaly Detection dan GCP Cost Anomaly Detection menggunakan machine learning untuk mendeteksi pola pengeluaran yang tidak wajar dibanding baseline historis — berguna menangkap kesalahan konfigurasi sebelum jadi tagihan besar di akhir bulan.

Studi Kasus Sederhana: Dampak Kombinasi Strategi

Sebagai ilustrasi, bayangkan sebuah startup dengan fleet 20 instance m5.xlarge on-demand yang menyala 24/7 untuk production, plus 10 instance serupa untuk staging yang sebenarnya hanya dipakai jam kerja. Setelah audit:

• Rightsizing menurunkan 8 dari 20 instance production ke m5.large karena utilisasi CPU rata-rata hanya 20% — potensi hemat sekitar 20-25% dari biaya compute production.
• Migrasi baseline production ke Savings Plan 1 tahun — hemat tambahan 30-40% dari sisa biaya on-demand.
• Auto-shutdown staging di luar jam kerja — hemat sekitar 60% dari biaya staging.
• Lifecycle policy pada bucket log yang menumpuk 3 tahun tanpa dihapus — hemat signifikan pada biaya storage yang sebelumnya tidak disadari.

Kombinasi langkah-langkah ini, tanpa mengubah arsitektur aplikasi sama sekali, sering kali bisa memangkas total tagihan cloud 30-45% dalam satu hingga dua bulan.

Kesalahan Umum yang Perlu Dihindari

Dalam praktiknya, upaya cost optimization sering gagal atau bahkan kontraproduktif karena beberapa kesalahan klasik berikut:

• Memangkas biaya tanpa memahami dependency. Mematikan atau men-downsize resource tanpa memastikan tidak ada service lain yang bergantung padanya bisa memicu insiden produksi — yang ujungnya jauh lebih mahal dibanding penghematan yang didapat.
• Berkomitmen berlebihan pada Reserved Instance/CUD. Membeli komitmen 3 tahun untuk workload yang ternyata akan dimigrasi ke arsitektur serverless enam bulan kemudian berarti membayar untuk kapasitas yang tidak lagi dipakai, tanpa bisa membatalkan komitmen tersebut.
• Mengejar diskon spot instance untuk workload yang salah. Menaruh database primary atau service yang butuh session affinity ketat di spot instance tanpa mekanisme failover yang matang akan menyebabkan downtime berulang yang justru merusak kepercayaan user.
• Optimasi sekali jalan lalu ditinggalkan. Tim melakukan "cost cleanup sprint" satu kali, merasa puas dengan hasilnya, lalu tidak pernah meninjau ulang. Dalam 6-12 bulan, resource baru yang tidak efisien akan menumpuk lagi dan tagihan kembali membengkak ke titik semula.
• Tidak melibatkan tim engineering dalam keputusan biaya. Jika hanya tim finance yang memantau billing tanpa konteks teknis, keputusan yang diambil sering kali tidak tepat sasaran — misalnya meminta downsize instance yang sebenarnya memang butuh kapasitas besar karena alasan teknis tertentu, bukan pemborosan.
• Mengabaikan cost of engineering time. Menghabiskan berminggu-minggu waktu engineer senior untuk menghemat beberapa puluh dolar per bulan bukan trade-off yang masuk akal. Prioritaskan optimasi berdasarkan potensi penghematan riil, bukan sekadar mengejar "resource yang terlihat boros".

Membangun Budaya FinOps di Tim Engineering

FinOps — kependekan dari Financial Operations — adalah pendekatan kolaboratif yang menyatukan engineering, finance, dan product agar keputusan teknis mempertimbangkan dampak biaya secara real-time, bukan setelah tagihan keluar sebulan kemudian. Beberapa praktik yang biasa diadopsi tim yang serius menerapkan FinOps:

• Menampilkan estimasi biaya cloud langsung di dashboard engineering (bukan hanya di laporan finance bulanan), sehingga developer melihat dampak biaya dari keputusan arsitektur yang mereka buat.
• Memasukkan cost review sebagai bagian dari proses code review atau design review untuk perubahan infrastruktur signifikan, mirip seperti security review.
• Menetapkan "cost champion" di setiap tim yang bertanggung jawab memantau anomali biaya pada resource timnya masing-masing.
• Melakukan retrospective biaya bulanan yang membahas tren pengeluaran, bukan hanya insiden teknis.

Organisasi yang menjalankan FinOps dengan matang biasanya melihat cost optimization bukan sebagai proyek pemadam kebakaran yang dilakukan saat CFO mulai bertanya, melainkan sebagai bagian rutin dari cara tim membangun dan mengoperasikan sistem — sama seperti reliability atau security sudah menjadi tanggung jawab bersama, bukan hanya satu tim khusus.

Kesimpulan

Cost optimization di cloud bukan proyek sekali jalan, melainkan disiplin berkelanjutan yang menggabungkan visibility (tahu ke mana uang pergi lewat tagging dan reporting), efisiensi teknis (rightsizing, autoscaling, storage tiering), dan strategi komersial (memanfaatkan reserved/committed pricing serta spot instance secara tepat). Yang membedakan tim yang berhasil menekan biaya secara signifikan dari yang terus membiarkan bill membengkak biasanya bukan tools yang lebih canggih, tapi kebiasaan: review billing rutin, budget alert yang aktif dipantau, dan budaya di mana setiap engineer sadar bahwa setiap resource yang mereka provision punya harga nyata. Mulailah dari langkah paling mudah — matikan yang idle, terapkan lifecycle policy, dan pasang budget alert — sebelum masuk ke optimasi arsitektural yang lebih kompleks. Efeknya pada laporan keuangan biasanya terasa jauh lebih cepat daripada yang dibayangkan.