Cloud Computing: Keputusan di Balik "Naik ke Cloud"

Tim founder startup bilang "kita pindah ke cloud biar scalable" — lalu bulan pertama tagihan AWS us-east-1 Rp 40 juta untuk traffic yang sebenarnya cuma 200 user. Bukan karena cloud mahal, tapi karena mereka nyalakan 3 node EKS, RDS Multi-AZ, dan NAT Gateway untuk aplikasi yang sebenarnya cukup 1 VPS 4 GB. "Cloud" bukan magnet scalable; ia adalah model bayar-per-pakai untuk resource yang kamu provisi sendiri. Artikel ini tidak akan mendefinisikan IaaS/PaaS/SaaS dari buku. Kita bedah keputusan nyata: kapan pakai VPS murah vs AWS, di mana biaya tersembunyi, kenapa lock-in terjadi, dan gimana keluar kalau sudah kejebak.

Tiga model, tiga tingkat tanggung jawab

Beda paling mendasar bukan harga, tapi seberapa banyak yang harus kamu kelola sendiri.

  • IaaS (Infrastructure): kamu dapat VM, disk, network. OS, patch, runtime, app — urusanmu. AWS EC2, GCP Compute, DigitalOcean Droplet, Hetzner Cloud, Vultr.

  • PaaS (Platform): runtime sudah disediakan, kamu cuma deploy kode. AWS Elastic Beanstalk, GCP App Engine, Render, Fly.io, Vercel (untuk frontend/edge).

  • SaaS (Software): produk jadi. Gmail, Notion, Supabase hosted. Kamu cuma pakai.

Untuk tim kecil, PaaS sering lebih masuk akal daripada IaaS karena kamu tidak bayar orang untuk patch OS. Tapi PaaS mengecilkan kontrol — kalau butuh kernel tweak atau custom network, kembali ke IaaS.

# IaaS: kamu yang urus semuanyassh root@ec2 | apt update | install deps | systemd | nginx | app# PaaS: cuma push
git push render main  # runtime + TLS + scaling otomatis

Jangan beli AWS kalau cuma butuh VPS

Ini salah kaprah paling mahal. AWS bukan "standar wajib". Untuk aplikasi menengah (beberapa ribu user, 1 backend + 1 DB), VPS di Hetzner (€5–10/bulan, 4–8 GB RAM) atau DigitalOcean ($12) sudah cukup dan jauh lebih bisa ditebak tagihannya.

Kapan AWS/GCP/Azure baru masuk akal: - Butuh managed service matang (BigQuery, S3 durability 11x9, IAM granular). - Traffic naik tidak terprediksi dan butuh auto-scaling nyata. - Tim sudah punya kompetensi cloud tersebut (orang mahal = biaya tersembunyi).

Kapan tidak pakai hyperscaler: - Traffic stabil, 1–2 server cukup. - Tim tidak punya engineer cloud → kamu bayar kompleksitas tanpa ambil manfaatnya. - Budget ketat dan butuh prediksi bulanan.

Oracle Cloud punya free tier gen-z: 2 VM Always Free (Ampere A1, 4 core + 24 GB RAM gratis selamanya). Untuk lab atau app kecil, itu sulit dikalahkan harganya.

Biaya tersembunyi #1: Egress

Semua hyperscaler kasih inbound gratis, tapi egress (data keluar) dibayar mahal — AWS ~$0.09/GB, GCP ~$0.12/GB di atas free tier. Aplikasi yang serve banyak gambar/video ke user bisa membakar tagihan dari traffic keluar, bukan compute.

# Hitung: 1 TB egress/bulan di AWS = ~$90
# Di Hetzner: traffic 20 TB included, lewat itu €1/TB

Mitigasi: - Taruh static asset di CDN (Cloudflare gratis 0 egress ke end-user untuk cache). - Kompresi (gzip/zstd) kurangi volume. - Pilih region dekat user supaya latency turun, tapi egress rate sama per region. - Untuk data besar antar layanan, taruh di satu region/provider supaya antar-service tidak kenakan egress cross-region.

Biaya tersembunyi #2: Managed service yang lupa dimatikan

Tim dev buat RDS untuk test, lupa delete, jalan 3 bulan = Rp 8 juta. Atau NAT Gateway $0.045/jam (~$32/bulan) padahal aplikasi tidak butuh outbound ke internet terus. Load balancer, EIP idle, log storage — semua counter jalan terus.

Fix: budget alert wajib sejak hari pertama. Di AWS: Billing → Budgets → alert 80%. Di GCP: Billing → Budgets & notifications. Plus jadwalkan "destroy dev env tiap Jumat malam" lewat Terraform/Terraform Cloud atau script cron. Alasan: hyperscaler tidak pernah ingatkan kamu "ini mahal, matiin ya?" — itu tugasmu.

Biaya tersembunyi #3: Request dan operasi

S3 tampak murah per GB, tapi kalau aplikasi bikin 10 juta GET ke S3 tiap bulan, biaya request bisa lewat biaya storage. DynamoDB on-demand mahal kalau traffic rendah tapi spike sering. Baca pricing model sebelum pilih, bukan cuma "per GB".

Lock-in: kenapa sulit keluar

Lock-in terjadi bukan karena provider jahat, tapi karena kamu pakai layanan proprietary yang tidak ada padanan di provider lain: - AWS Lambda (runtime khusus) vs fungsi di GCP (berbeda API). - DynamoDB (NoSQL proprietary) vs Bigtable (berbeda). - IAM policy format beda tiap cloud.

Semakin banyak layanan proprietary yang kamu pakai, semakin mahal migrasi. Itu bukan berarti jangan pakai — tapi sadari trade-off: managed service menghemat operasional hari ini, menambah biaya keluar hari depan.

Mitigasi pragmatis: - Pilih layanan berbasis standar terbuka: Postgres managed (ada di semua cloud, dump/restore portabel) vs Aurora/DynamoDB proprietary. - Abstraksi lewat Terraform: infra di-code, pindah provider = tulis provider block baru (sebagian). - Simpan data di format netral (SQL dump, Parquet) bukan API proprietary.

Multi-cloud itu bukan untuk semua orang

Banyak CTO mau "multi-cloud biar tidak lock-in". Realitanya: multi-cloud menambah kompleksitas operasional 2–3x, butuh tim yang paham tiap cloud, dan sering cuma jadi beban. Multi-cloud masuk akal kalau: - Regulasi wajib data di dua yurisdiksi. - Negosiasi kontrak enterprise (diskon besar kalau bagi beban). - Resilience ekstrem (satu cloud down, lainnya jalan).

Untuk 99% tim, single cloud + exit plan jauh lebih murah dan aman daripada multi-cloud tanpa alasan. Hybrid (on-prem + cloud, sudah dibahas di artikel Networking) berbeda — itu untuk kasus data lama tidak bisa pindah.

Strategi keluar: yang sering diabaikan

Exit plan bukan "kalau perlu pindah nanti". Ia keputusan arsitektur sekarang: 1. Data di engine portabel (Postgres, not Aurora-only feature). 2. Infra di Terraform, bukan klik console. 3. App stateless — jangan simpan session di disk lokal (pakai Redis managed). 4. Jangan hardcode region/endpoint proprietary di kode aplikasi; pakai env/secret.

Alasan: saat kamu perlu keluar (harga naik, layanan di-stop), tim bisa redeploy dalam hari, bukan bulan. Tanpa exit plan, "lock-in" jadi permanen.

Contoh keputusan nyata

Skenario A — Startup 3 orang, MVP, budget Rp 3 jt/bulan: - Hetzner CX22 (4 GB, €5) + managed Postgres Hetzner (€3) + Cloudflare CDN. - Deploy via Coolify atau dokcer compose + Caddy. - Exit plan: dump Postgres berkala ke S3-compatible (Wasabi murah).

Skenario B — Scale-up, 50k user, butuh auto-scaling: - AWS: ECS Fargate + RDS Multi-AZ + ALB + CloudFront. - Budget alert + destroy dev env otomatis. - Exit: Terraform memungkinkan redeploy ke GCP sebagian.

Skenario C — Data berat, analitik: - GCP BigQuery (biaya query, bukan storage mahal) atau warehouse managed. - Bukan VPS biasa — butuh kolom store.

Kesalahan umum

  1. Beli AWS untuk app yang cukup 1 VPS.

  2. Lupa budget alert → tagihan bom di akhir bulan.

  3. Managed service test lupa dimatikan.

  4. Abaikan egress cost sampai tagihan membengkak.

  5. Pakai layanan proprietary semua → lock-in permanen.

  6. Multi-cloud tanpa alasan bisnis.

  7. Tidak ada exit plan (infra di-klik manual).

  8. App stateful di disk lokal → tidak bisa scale horizontal.

Takeaways

  • Cloud = bayar per pakai resource yang kamu provisi; bukan otomatis scalable.

  • VPS murah (Hetzner/DO) cukup untuk mayoritas app menengah; hyperscaler untuk skala/ managed service nyata.

  • Biaya tersembunyi: egress, managed service lupa mati, request/operasi.

  • Pasang budget alert hari pertama; jadwalkan destroy dev env.

  • Lock-in dari layanan proprietary; mitigasi dengan standar terbuka + Terraform + format netral.

  • Multi-cloud hanya untuk regulasi/resilience/diskon; single cloud + exit plan untuk sisanya.

  • Exit plan adalah keputusan arsitektur, bukan rencana darurat.

  • App harus stateless supaya bisa scale horizontal dan portabel.