Reserved & Savings Plans #

Dalam komputasi cloud, fleksibilitas penuh adalah fitur premium yang sangat mahal. Ketika kita menggunakan model harga standar On-Demand, kita membayar tarif penuh per jam atau per detik dengan keuntungan bebas mematikan atau mengubah tipe mesin kapan saja. Namun, bagi beban kerja aplikasi yang telah stabil dan dapat diprediksi secara jangka panjang, model On-Demand ini menjadi sangat tidak ekonomis. Penyedia layanan cloud menawarkan diskon harga yang sangat besar (mencapai lebih dari 70%) melalui skema komitmen jangka panjang yang dikenal sebagai Reserved Instances (RI) dan Savings Plans. Dengan berkomitmen untuk menggunakan sejumlah kapasitas komputasi minimum dalam jangka waktu 1 atau 3 tahun, kita dapat memangkas pengeluaran infrastruktur secara drastis. Kunci sukses dari strategi ini adalah menyeimbangkan tingkat penghematan finansial dengan risiko kehilangan fleksibilitas arsitektur (over-commitment).

Konsep: Menukar Fleksibilitas dengan Diskon #

Model penetapan harga komitmen cloud didasarkan pada prinsip pertukaran ekonomi sederhana: penyedia cloud mendapatkan kepastian pendapatan jangka panjang guna merencanakan pembelian perangkat keras fisik mereka, dan sebagai imbalannya, kita mendapatkan potongan harga yang signifikan.

flowchart TD
    subgraph SkenarioBeban ["Pola Penggunaan Komputasi & Alokasi Biaya"]
        direction TB
        BebanPuncak["Beban Puncak (Burst Traffic)
- Tidak terprediksi / fluktuatif"]
        BebanDasar["Beban Dasar (Baseline Workload)
- Stabil berjalan 24/7"]
        BebanBatch["Beban Batch / Background Jobs
- Fleksibel waktu mulainya"]
    end

    subgraph StrategiHarga ["Model Pembelian Optimal"]
        direction TB
        OnDemand["1. On-Demand Pricing
- Fleksibilitas tinggi
- Tarif reguler"]
        Committed["2. Reserved / Savings Plans
- Diskon (30-72%)
- Terikat komitmen (1-3 tahun)"]
        Spot["3. Spot / Preemptible Instance
- Diskon (60-90%)
- Bisa diterminasi sepihak"]
    end

    BebanPuncak -. "Dialokasikan ke" .-> OnDemand
    BebanDasar -. "Dialokasikan ke" .-> Committed
    BebanBatch -. "Dialokasikan ke" .-> Spot

1. Analogi Penyewaan Properti #

Untuk mempermudah pemahaman tim, kita dapat menyamakan ketiga model pembelian komputasi cloud dengan opsi akomodasi fisik:

• On-Demand (Sewa Hotel Harian): Kita dapat melakukan check-in hari ini dan check-out besok pagi tanpa denda. Tarif per malam sangat tinggi karena kita membeli kebebasan mutlak.
• Reserved / Savings Plans (Kontrak Apartemen Tahunan): Kita menandatangani kontrak sewa selama 12 bulan. Tarif bulanan jauh lebih murah daripada tarif hotel harian. Namun, jika kita memutuskan pindah kota di bulan ketiga, kita tetap berkewajiban membayar sisa sewa apartemen tersebut hingga kontrak berakhir.
• Spot / Preemptible (Sewa Kamar Siaga): Kita menyewa kamar kosong sisa dengan diskon 85%, namun dengan syarat jika ada tamu utama yang datang membayar harga penuh, kita harus mengosongkan kamar tersebut dalam waktu singkat.

2. Kapan Harus Menggunakan Komitmen? #

Kita sebaiknya hanya membeli komitmen ketika:

• Beban kerja infrastruktur telah berjalan stabil selama minimal 3 bulan berturut-turut.
• Tidak ada rencana migrasi teknologi besar (seperti pindah dari VM ke Serverless) dalam waktu dekat.
• Arsitektur sistem inti (seperti cluster database primer) telah disepakati dan tidak akan diubah spesifikasinya.

Reserved Instances (RI) secara Mendalam #

Reserved Instances adalah mekanisme komitmen generasi pertama yang ditawarkan oleh cloud provider seperti AWS. Penting untuk dicatat bahwa membeli RI tidak berarti kita menyewa server fisik baru; RI adalah sebuah instrumen diskon akuntansi yang akan secara otomatis diaplikasikan oleh sistem billing ke instans aktif yang sesuai kriteria komitmen kita.

1. Parameter Utama Pembelian RI #

Saat membeli Reserved Instance, kita harus mengunci beberapa parameter berikut:

• Term (Jangka Waktu): Pilihan 1 tahun atau 3 tahun. Komitmen 3 tahun memberikan diskon yang jauh lebih besar, namun memiliki risiko perubahan teknologi yang tinggi.
• Instance Family: Mengunci jenis CPU/RAM mesin (misal keluarga m5, c6g, atau t3).
• Region: Lokasi fisik datacenter (misal ap-southeast-1).
• Payment Option (Metode Pembayaran):
  • All Upfront: Membayar seluruh biaya komitmen 1 atau 3 tahun di muka. Menawarkan diskon terbesar.
  • Partial Upfront: Membayar sebagian biaya di muka, dan sisanya ditagih secara mencicil setiap bulan.
  • No Upfront: Tidak membayar apa pun di muka; kita cukup membayar cicilan biaya komitmen yang didiskon setiap bulan.

2. Perbandingan Standard RI vs. Convertible RI #

Untuk memberikan sedikit kelonggaran bagi konsumen, penyedia cloud membagi instrumen RI menjadi dua jenis:

Savings Plans (Mekanisme Komitmen Modern) #

Untuk mengatasi kerumitan administrasi dan kekakuan dari Reserved Instances, cloud provider meluncurkan Savings Plans. Perbedaan utamanya adalah: alih-alih berkomitmen pada tipe instans spesifik (misal 5 unit server m5.large), kita berkomitmen pada nilai belanja minimum per jam (misalnya berkomitmen membelanjakan $10.00 per jam).

1. Kategori Utama Savings Plans #

Terdapat dua jenis utama Savings Plans yang dapat kita pilih:

• Compute Savings Plans (Sangat Fleksibel):
  • Berlaku otomatis untuk semua jenis VM (EC2), layanan container serverless (AWS Fargate), dan fungsi serverless (AWS Lambda).
  • Diskon berlaku lintas region, lintas OS, dan lintas keluarga instans secara instan.
  • Memberikan ketenangan pikiran bagi tim pengembang yang sering kali memodifikasi tumpukan teknologi mereka.
• EC2 Instance Savings Plans (Diskon Lebih Tinggi):
  • Mengunci komitmen kita pada keluarga instans tertentu di region tertentu (misalnya keluarga c6g di wilayah Singapura).
  • Menawarkan diskon yang lebih besar daripada Compute Savings Plans, namun kita kehilangan fleksibilitas jika di masa depan ingin memindahkan beban kerja ke region lain atau ke serverless container.

2. Mekanisme Konsumsi Billing per Jam #

Mari kita pelajari contoh simulasi bagaimana sistem billing mengaplikasikan Savings Plans secara hourly:

Misalkan kita membeli Compute Savings Plans sebesar $5.00/jam untuk jangka waktu 1 tahun.

• Kasus Jam Pertama (Penggunaan Normal): Aplikasi kita berjalan dengan total biaya on-demand sebesar $8.00 pada jam tersebut. Sistem billing akan mengaplikasikan tarif diskon Savings Plans hingga batas komitmen $5.00 kita habis. Sisa pengunaan ($3.00) akan ditagih menggunakan tarif On-Demand reguler.
• Kasus Jam Kedua (Penggunaan Turun / Under-utilization): Aplikasi kita sepi dan banyak instans dimatikan oleh autoscaling, sehingga biaya penggunaan aktual hanya $3.00. Sistem billing akan memotong komitmen $5.00 kita secara penuh. Kita mengalami kerugian non-efisiensi sebesar $2.00 karena kita wajib membayar nilai komitmen terendah yang telah disepakati.

{
  "SavingsPlansRecommendations": [
    {
      "RecommendationDetail": {
        "SavingsPlansType": "COMPUTE_SP",
        "TermInYears": 1,
        "PaymentOption": "NO_UPFRONT",
        "HourlyCommitmentToPurchase": "3.45",
        "EstimatedAverageHourlySavings": "1.25",
        "EstimatedMonthlySavings": "900.00",
        "EstimatedROI": "36.2"
      }
    }
  ]
}

Format respon JSON di atas adalah contoh laporan rekomendasi dari AWS Cost Explorer API yang membantu kita menghitung komitmen optimal berdasarkan histori penggunaan 30 hari terakhir.

Metode Kalkulasi Kebutuhan Komitmen #

Membeli komitmen tanpa perhitungan matang adalah spekulasi finansial yang berbahaya. Kita harus menerapkan formula kalkulasi sistematis sebelum menyetujui kontrak:

1. Tentukan Nilai Beban Kerja Dasar (Baseline Workload) #

Kumpulkan data historis penggunaan komputasi kita selama 3 hingga 6 bulan terakhir. Cari nilai penggunaan minimum (floor value) yang selalu aktif 24 jam sehari, 7 hari seminggu.

$$\text{Beban Kerja Dasar (Baseline)} = \min(\text{Usage Hour}_1, \text{Usage Hour}_2, \dots, \text{Usage Hour}_n)$$

Gunakan nilai baseline ini sebagai batas maksimal komitmen yang akan kita beli. Jangan pernah membeli komitmen yang mendekati nilai beban puncak (peak traffic).

2. Hitung Penghematan Finansial (ROI) #

Mari kita simulasikan perhitungan ROI untuk 10 instans c5.2xlarge di AWS region Singapura yang berjalan terus-menerus selama 1 tahun:

• Biaya Tanpa Komitmen (On-Demand): Tarif On-Demand = $0.34 per jam per instans.

  $$C_{\text{on-demand}} = 10 \text{ instans} \times $0.34 \times 24 \text{ jam} \times 365 \text{ hari} = $29.784\text{/tahun}$$

• Biaya Dengan Komitmen (1-Year No Upfront RI): Tarif Reserved (No Upfront) = $0.22 per jam per instans (diskon ~35%).

  $$C_{\text{reserved}} = 10 \text{ instans} \times $0.22 \times 24 \text{ jam} \times 365 \text{ hari} = $19.272\text{/tahun}$$

• Kalkulasi ROI Bersih:

  $$\text{Penghematan Tahunan} = $29.784 - $19.272 = $10.512$$

  $$\text{ROI (Persentase)} = \frac{$10.512}{$19.272} \times 100% \approx 54.5%$$

Dengan membeli komitmen No Upfront, kita berhasil menghemat biaya operasional sebesar $10.512 per tahun (sekitar Rp160 juta) tanpa perlu mengeluarkan modal uang tunai di awal kontrak.

Strategi Mitigasi Risiko Over-Commitment #

Risiko terbesar dari pembelian komitmen jangka panjang adalah perubahan teknologi yang tidak terduga (technology obsolescence). Misalnya, kita membeli komitmen 3 tahun untuk instans Intel c5. Namun, di tahun kedua, cloud provider meluncurkan instans ARM c6g berbasis chip Graviton yang menawarkan performa 40% lebih baik dengan harga 20% lebih murah. Kita akan terjebak dalam dilema finansial: tetap menggunakan server Intel lama yang mahal demi menghabiskan kontrak komitmen, atau pindah ke ARM namun tetap membayar denda sisa komitmen Intel yang tidak terpakai.

1. Gunakan Aturan 70% (The 70% Rule) #

Untuk meminimalisir risiko, jangan pernah membeli komitmen untuk 100% kapasitas baseline kita secara sekaligus. Mulailah dengan membeli komitmen sebesar 70% dari nilai baseline. Biarkan sisa 30% berjalan dengan skema On-Demand atau Spot. Seiring berjalannya waktu, jika data historis membuktikan baseline kita terus naik secara stabil, kita dapat membeli komitmen tambahan secara bertahap (staggered commitments).

2. Pantau Dua Metrik Kunci #

Kita wajib memantau dua metrik utama di dasbor penagihan cloud:

• Commitment Coverage Rate: Persentase total biaya komputasi kita yang dicakup oleh diskon komitmen. Target optimal berkisar antara 70% hingga 80%.
• Commitment Utilization Rate: Persentase dari komitmen yang kita beli yang benar-benar dikonsumsi oleh aplikasi aktif. Target optimal adalah di atas 95%. Jika utilization rate di bawah 80%, itu adalah indikator kuat bahwa kita sedang membuang-buang uang untuk komitmen kosong.

Komitmen untuk Layanan Database dan Non-Compute #

Program diskon komitmen jangka panjang tidak terbatas pada mesin virtual komputasi (EC2/VM) saja. Kita juga harus menerapkan strategi komitmen pada komponen infrastruktur pendukung lainnya:

1. Database Terkelola (Managed Databases) #

Layanan database terkelola (seperti AWS RDS, Amazon Aurora, atau Google Cloud SQL) berjalan terus-menerus selama 24 jam sehari dan jarang sekali mengalami perubahan tipe instans secara mendadak. Oleh karena itu, database adalah kandidat terbaik dan paling aman untuk pembelian Reserved DB Instances.

2. Node Cache & Pencarian (Cache & Search Clusters) #

Cluster cache memori (seperti ElastiCache Redis) dan mesin pencari (seperti OpenSearch/Elasticsearch) umumnya memiliki pola beban kerja dasar yang sangat teratur. Menerapkan komitmen Reserved Nodes pada kluster ini dapat memangkas tagihan database pendukung hingga 45%.

Ringkasan #

• Reserved Instances dan Savings Plans menukar fleksibilitas dengan diskon — Memberikan potongan harga sebesar 30% hingga 72% dengan syarat komitmen kontrak selama 1 atau 3 tahun.
• Convertible RI memberikan kelonggaran mengubah parameter — Dibandingkan Standard RI yang kaku, Convertible RI mengizinkan kita mengubah keluarga instans jika kebutuhan arsitektur berubah.
• Compute Savings Plans adalah opsi paling fleksibel — Berlaku otomatis lintas wilayah region, tipe instans, sistem operasi, serta layanan container Fargate dan serverless Lambda.
• Terapkan komitmen hanya pada kapasitas baseline — Hitung nilai penggunaan komputasi minimum historis, dan batasi pembelian awal maksimal sebesar 70% dari baseline tersebut.
• Gunakan formula ROI untuk mengukur titik break-even — Evaluasi secara transparan perbandingan penghematan tahunan model komitmen terhadap skema On-Demand.
• Database produksi adalah sasaran utama komitmen — Karena database berjalan stabil 24/7 dan tipe instansnya jarang berubah, risiko over-commitment menjadi sangat rendah.

← Sebelumnya: Cost Allocation & Tagging   Berikutnya: FinOps →