Cloud Pricing Model #

“Bayar hanya untuk apa yang kita gunakan” adalah semboyan utama komputasi cloud yang paling sering dikampanyekan oleh penyedia layanan. Skema penetapan harga ini menjanjikan efisiensi maksimal karena kita tidak perlu lagi membeli perangkat keras mahal di depan (Capital Expenditure / CapEx) dan cukup membayar biaya operasional bulanan (Operating Expenditure / OpEx). Namun, dalam praktiknya, model penetapan harga cloud (cloud pricing model) tidak sesederhana mematikan lampu saat meninggalkan ruangan. Tagihan cloud bersifat multi-dimensi dan terdiri dari ratusan komponen biaya yang sering kali tidak terlihat secara kasat mata, seperti biaya transfer data keluar (egress), biaya per panggilan API, biaya provisioning kapasitas penyimpanan, hingga beban biaya managed service. Tanpa pemahaman mendalam tentang dimensi-dimensi biaya ini, kita akan sering menghadapi lonjakan tagihan (cloud bill shock) di akhir bulan yang dapat mengganggu profitabilitas proyek kita.

Dimensi Utama Biaya Cloud #

Untuk merancang arsitektur cloud yang sadar biaya (cost-aware architecture), kita harus memahami bahwa tagihan akhir untuk suatu layanan tidak pernah tunggal. Setiap layanan cloud umumnya memecah tagihannya ke dalam enam dimensi utama berikut:

1. Compute (Biaya Pemrosesan) #

Dimensi ini dihitung berdasarkan waktu aktif unit pemroses (vCPU dan RAM) yang dikonsumsi oleh aplikasi kita.

• Virtual Machine / VM: Ditagih per jam atau per detik sejak mesin dinyalakan hingga dimatikan.
• Container (Managed): Ditagih berdasarkan alokasi kapasitas vCPU dan memori (GB RAM) yang dikonsumsi per jam.
• Serverless (FaaS): Ditagih berdasarkan jumlah eksekusi fungsi (invocations) dikombinasikan dengan durasi waktu eksekusi dikalikan alokasi memori (GB-detik).

2. Storage (Biaya Penyimpanan Data) #

Biaya penyimpanan data di cloud memiliki karakteristik penagihan yang bervariasi tergantung pada jenis media penyimpanan yang digunakan:

• Object Storage (seperti AWS S3 atau Google Cloud Storage): Ditagih berdasarkan kapasitas aktual data yang disimpan (per GB/bulan) serta kelas penyimpanan (storage tier) yang dipilih.
• Block Storage (seperti AWS EBS atau Google Persistent Disk): Ditagih berdasarkan kapasitas penyimpanan yang dialokasikan (provisioned capacity), terlepas dari apakah ruang penyimpanan tersebut kosong atau terisi penuh.
• File Storage (seperti AWS EFS): Ditagih berdasarkan rata-rata volume data yang disimpan per bulan, dengan opsi biaya tambahan untuk performa throughput yang dialokasikan.

3. Network & Data Transfer (Biaya Jaringan) #

Biaya perpindahan data merupakan salah satu komponen yang paling sering terabaikan namun berpotensi membengkak sangat besar. Secara umum, lalu lintas data masuk (ingress) ke cloud bersifat gratis, namun lalu lintas data keluar (egress) ke internet, transfer data lintas region (cross-region), dan transfer data lintas zona ketersediaan (cross-AZ) dikenakan biaya per gigabyte (GB).

4. API Requests (Biaya Panggilan Layanan) #

Setiap interaksi dengan layanan cloud melalui API (seperti membaca berkas dari object storage, menulis data ke database NoSQL, atau mengirim pesan ke antrean) mengenakan biaya berdasarkan kuantitas request. Contohnya adalah biaya per 10.000 request GET atau per 1.000 request PUT/POST.

5. Managed Services Capacity #

Layanan terkelola (managed services) seperti Load Balancer dan NAT Gateway menyertakan kombinasi biaya dasar per jam berjalan ditambah dengan biaya volume data yang diproses. Load Balancer modern juga menggunakan metrik kapasitas dinamis seperti LCU (Load Balancer Capacity Unit) yang menghitung jumlah koneksi aktif secara simultan.

6. Support Plans (Rencana Dukungan Teknis) #

Untuk akun bisnis dan enterprise, penyedia cloud mengenakan biaya bulanan tetap atau persentase dari total tagihan bulanan (mana yang lebih besar) guna menyediakan layanan bantuan insinyur dukungan (technical support engineer) dengan jaminan waktu respon cepat (Service Level Agreement / SLA).

Data Transfer — Komponen Biaya Tersembunyi #

Salah satu hukum dasar jaringan cloud yang harus kita ingat adalah: data masuk ke cloud gratis, data keluar dari cloud berbayar. Pembatasan biaya ini dirancang oleh penyedia cloud untuk mempermudah migrasi data ke sistem mereka (cloud lock-in), namun mengenakan biaya tinggi saat data tersebut dipindahkan ke luar.

flowchart TD
    subgraph InternetZone ["Internet Eksternal"]
        User["Pengguna Internet"]
    end

    subgraph RegionCloud ["Cloud Region (ap-southeast-1)"]
        subgraph AZA ["Availability Zone A (AZ-A)"]
            AppA["App Server A (VM)"]
        end
        
        subgraph AZB ["Availability Zone B (AZ-B)"]
            AppB["App Server B (VM)"]
            DB["Primary Database (Managed)"]
        end
    end

    subgraph RegionLain ["Region Cloud Lain (us-east-1)"]
        Backup["Disaster Recovery Storage"]
    end

    User -->|"1. Request Masuk (Ingress)
[GRATIS]"| AppA

    AppA -->|"2. Egress ke Internet
[BERBAYAR: ~$0.09/GB]"| User

    AppA <-->|"3. Komunikasi Lintas AZ
[BERBAYAR: ~$0.01/GB per arah]"| DB

    AppB <-->|"4. Komunikasi Dalam AZ
[GRATIS]"| DB

    AppB -. "5. Replikasi Lintas Region
[BERBAYAR: ~$0.02-0.08/GB]" .-> Backup

1. Struktur Biaya Jaringan Komparatif #

• Data Ingress (Gratis): Mengunduh file dari server eksternal ke dalam mesin virtual cloud kita tidak memakan biaya jaringan.
• Internet Egress (Mahal): Mengirimkan data dari cloud ke pengguna di internet. Biaya standar berkisar antara $0.08 hingga $0.09 per GB. Jika aplikasi kita menyajikan file gambar, video, atau dokumen berukuran besar langsung dari VM, biaya ini akan membengkak dengan cepat. Kita harus menggunakan Content Delivery Network (CDN) untuk meringankan biaya egress ini.
• Transfer Lintas Region (Sedang): Mengirimkan data dari satu cloud region ke region lainnya (misal dari Singapura ke Virginia). Biaya ini berkisar antara $0.02 hingga $0.08 per GB tergantung pada rute geografisnya.
• Transfer Lintas AZ (Murah tapi Sering Terjadi): Mengirimkan data antar Availability Zone dalam satu region yang sama. Biayanya relatif murah, sekitar $0.01 per GB per arah. Meskipun murah, volume komunikasinya bisa sangat tinggi jika arsitektur mikro kita tidak dirancang secara lokal di satu zona.

2. Studi Kasus: Kerugian Komunikasi Lintas AZ yang Buruk #

Bayangkan kita membangun aplikasi web di mana server aplikasi ditempatkan di Availability Zone A (AZ-A) sedangkan database utamanya ditempatkan di Availability Zone B (AZ-B).

• Setiap request pengguna memicu query database yang mengembalikan response data sebesar 50 KB.
• Aplikasi kita melayani trafik sebesar 2.000 request per detik secara konsisten.

Mari kita hitung akumulasi biaya transfer data lintas AZ yang terjadi dalam satu bulan (30 hari):

$$\text{Volume Data per Detik} = 2.000 \times 50 \text{ KB} = 100.000 \text{ KB} = 100 \text{ MB/detik}$$

$$\text{Volume Data per Hari} = 100 \text{ MB} \times 86.400 \text{ detik} = 8.640.000 \text{ MB} = 8.640 \text{ GB/hari}$$

$$\text{Volume Data per Bulan} = 8.640 \text{ GB} \times 30 = 259.200 \text{ GB/bulan}$$

$$\text{Biaya Lintas AZ (2 Arah)} = 259.200 \text{ GB} \times $0.01 \text{ per GB} \times 2 = $5.184\text{/bulan}$$

Hanya untuk mengalirkan data antara server aplikasi dan database lintas AZ, kita harus membayar sekitar $5.184 per bulan (atau sekitar Rp80 juta).

Solusi Arsitektur: Kita harus memastikan server aplikasi utama berkomunikasi dengan database primer atau read-replica yang berada di Availability Zone yang sama (komunikasi lokal = gratis). Gunakan replikasi lintas AZ hanya untuk kebutuhan sinkronisasi cadangan (failover) database sekunder secara asinkron.

Strategi Compute Pricing #

Compute adalah komponen terbesar dalam tagihan cloud sebagian besar organisasi. Untuk mengoptimalkannya, kita harus memilih model harga compute yang tepat berdasarkan profil beban kerja (workload profile):

Storage Pricing — Provisioned Capacity vs. Actual Storage Used #

Banyak insinyur berasumsi bahwa penyimpanan cloud ditagih sesuai dengan data yang disimpan. Ini adalah kesalahpahaman yang mahal. Kita harus membedakan cara penagihan antara Block Storage dan Object Storage.

1. Block Storage (Penyimpanan Berbasis Provisioning) #

Pada Block Storage (seperti AWS EBS gp3), kita membayar kapasitas yang kita pesan di depan, bukan yang kita gunakan.

• ANTI-PATTERN: Seorang developer membuat database uji coba dan mengalokasikan EBS volume sebesar 1 TB dengan alasan “jaga-jaga agar disk tidak penuh saat pengujian”. Namun, data aktual pengujian hanya sebesar 20 GB.
• Dampak Biaya: Perusahaan tetap membayar penuh tagihan untuk kapasitas 1 TB tersebut. Jika tarif penyimpanan adalah $0.08 per GB/bulan, maka tagihan bulanan adalah $80, padahal data aktual hanya membutuhkan biaya $1.60.
• BENAR: Mulailah dengan volume yang kecil (misalnya 50 GB) dan aktifkan fitur ekspansi volume otomatis (auto-grow) atau lakukan resize disk secara manual ketika ruang penyimpanan sudah terisi 80%. Cloud modern mendukung perluasan ukuran block storage secara dinamis tanpa waktu mati (zero-downtime).

2. Object Storage (Penyimpanan Berbasis Penggunaan Aktual) #

Pada Object Storage (seperti AWS S3), kita hanya membayar untuk kapasitas data yang benar-benar tersimpan. Namun, kita harus waspada terhadap biaya manipulasi data:

• Biaya Operasi API: Membaca data (GET request) dan menulis data (PUT/POST request) memiliki tarif per seribu operasi. Panggilan API yang sangat intensif dari aplikasi mikro dapat melebihi biaya penyimpanan data fisik itu sendiri.
• Biaya Retrieval & Transit: Kelas penyimpanan dingin (cold storage seperti Glacier) menawarkan harga per GB yang sangat murah untuk pengarsipan jangka panjang. Namun, jika kita sering membaca kembali data dingin tersebut (retrieval), kita akan dikenakan biaya penarikan data yang sangat mahal.

Serverless Pricing dan Skenario Break-Even #

Layanan Serverless FaaS (seperti AWS Lambda) menawarkan model penagihan yang sangat menarik: kita tidak membayar sepeser pun saat kode kita tidak berjalan (scale-to-zero). Kita ditagih berdasarkan jumlah pemanggilan (invocations) dan durasi waktu eksekusi dikalikan dengan alokasi memori yang disiapkan.

Namun, apakah serverless selalu lebih murah daripada menyewa mesin virtual (VM) tradisional? Kita harus menghitung titik impas (break-even point) dari kedua model ini.

1. Simulasi Kasus Trafik Tinggi #

Misalkan kita memiliki microservice yang melayani API dengan karakteristik sebagai berikut:

• Trafik konsisten: 50.000.000 request per bulan (sekitar 19 request per detik secara stabil).
• Alokasi memori fungsi: 512 MB (setara dengan 0.5 GB).
• Rata-rata durasi eksekusi: 200 ms (0.2 detik) per request.

Mari kita hitung total biaya menggunakan FaaS (AWS Lambda):

1. Biaya Pemanggilan (Invocations Cost): Tarif standar: $0.20 per 1.000.000 request.

   $$\text{Biaya Invokasi} = 50 \times $0.20 = $10$$

2. Biaya Durasi Eksekusi (Duration Cost): Tarif standar: $0.0000166667 per GB-detik. Total GB-detik per bulan:

   $$\text{Total GB-detik} = 50.000.000 \times 0.2 \text{ detik} \times 0.5 \text{ GB} = 5.000.000 \text{ GB-detik}$$

   $$\text{Biaya Durasi} = 5.000.000 \times $0.0000166667 = $83.33$$

3. Total Biaya Serverless:

   $$\text{Total Biaya Lambda} = $10 + $83.33 = $93.33\text{/bulan}$$

2. Perbandingan dengan Virtual Machine (VM) #

Mari kita bandingkan jika workload yang sama kita jalankan di atas satu instans VM AWS EC2 bertipe t3.medium (2 vCPU, 4 GB RAM) yang dapat dengan mudah menangani 19 request per detik secara stabil:

• Harga On-Demand t3.medium: ~$0.0416 per jam.

  $$\text{Biaya Bulanan On-Demand} = 730 \text{ jam} \times $0.0416 = $30.37\text{/bulan}$$

• Harga Reserved Instance t3.medium (Komitmen 1 Tahun): ~$0.025 per jam.

  $$\text{Biaya Bulanan Reserved} = 730 \text{ jam} \times $0.025 = $18.25\text{/bulan}$$

3. Evaluasi Keputusan Arsitektural #

Dari perhitungan matematis di atas, secara finansial langsung, menyewa VM tradisional jauh lebih murah ($18.25 - $30.37) dibandingkan dengan serverless ($93.33) untuk beban kerja yang berjalan secara konsisten 24 jam sehari dengan trafik tinggi.

Kriteria Pemilihan Compute Model:

  PILIH SERVERLESS (FaaS) jika:
  ✓ Beban kerja bersifat sporadis (misal hanya ramai di jam kantor, sepi di malam hari).
  ✓ Membutuhkan fitur scale-to-zero untuk memangkas biaya saat aplikasi tidak digunakan.
  ✓ Tim pengembang ingin fokus penuh pada penulisan kode tanpa beban operasional server.

  PILIH VIRTUAL MACHINE (IaaS/PaaS) jika:
  ✗ Trafik aplikasi berjalan stabil, kontinu, dan dapat diprediksi 24 jam sehari.
  ✗ Aplikasi membutuhkan waktu startup yang instan (menghindari cold start).
  ✗ Total biaya gabungan VM lebih rendah setelah melewati kalkulasi break-even.

Membaca dan Menganalisis Laporan Tagihan #

Ketika mengelola akun cloud skala besar, laporan tagihan bulanan kita bisa berisi ribuan baris baris transaksi yang membingungkan. Kita harus melatih tim kita untuk membaca dan menganalisis laporan tagihan secara sistematis guna mendeteksi anomali sejak dini.

1. Gunakan Layanan Cost Explorer #

Gunakan perangkat lunak bawaan provider (seperti AWS Cost Explorer atau GCP Billing Reports) untuk melakukan visualisasi tren belanja bulanan kita.

• Deteksi Anomali: Buat aturan alarm otomatis untuk mengirimkan notifikasi ke Slack jika biaya harian suatu layanan melonjak lebih dari 20% dibandingkan rata-rata harian minggu sebelumnya.
• Analisis Egress: Pantau bagian “Data Transfer - Out” secara berkala untuk mendeteksi jika ada kebocoran trafik atau penarikan data yang tidak normal oleh pihak luar.

2. Terapkan Tagging Wajib (Tagging Policy) #

Kita tidak akan bisa mengendalikan biaya jika kita tidak tahu layanan mana atau tim mana yang bertanggung jawab atas pengeluaran tersebut. Kita harus menerapkan aturan Tagging Policy yang ketat (misalnya tag Owner, Project, dan Environment wajib disertakan pada setiap pembuatan resource baru). Resource yang tidak memiliki tag terstandar harus otomatis dimatikan oleh sistem pembersih otomatis (cron cleaner script) untuk mencegah pemborosan tanggungan biaya.

Ringkasan #

• Biaya cloud bersifat multi-dimensi — Tagihan akhir tidak hanya ditentukan oleh komputasi, melainkan dipengaruhi oleh storage provisioning, panggilan API, dan transfer data.
• Biaya transfer data keluar (egress) ke internet berbayar mahal — Rancang arsitektur aplikasi agar meminimalkan transfer data lintas region dan lintas Availability Zone guna menghindari kebocoran biaya.
• Block storage ditagih berdasarkan alokasi kapasitas — Hindari over-provisioning volume disk kosong; mulailah dengan ukuran minimal dan ekspansi secara dinamis saat disk mulai penuh.
• Pilih model komputasi yang sesuai dengan beban kerja — Gunakan Reserved Instances untuk baseline trafik stabil, Spot Instances untuk pengolahan batch, dan On-Demand hanya untuk eksperimen awal.
• Kalkulasikan break-even point sebelum memilih serverless — Serverless sangat efisien untuk beban kerja fluktuatif, namun bisa menjadi lebih mahal daripada VM tradisional pada trafik konsisten berskala besar.
• Terapkan alarm pemantauan biaya (billing alerts) sejak hari pertama — Agar kita mendapat peringatan dini sebelum tagihan membengkak tidak terkendali di akhir bulan.

← Sebelumnya: Observability vs Monitoring   Berikutnya: Cost Allocation & Tagging →