Cloud Platforms Fundamentals Cheat Sheet

#Konsep Dasar Cloud

Model mental yang perlu kamu pegang sebelum nyemplung ke katalog layanan apa pun. Hampir semua istilah di ketiga provider bisa dipetakan ke konsep ini.

Region        = area geografis (contoh: Jakarta, Singapore). Isinya beberapa AZ.
AZ            = Availability Zone, satu atau lebih data center dengan daya dan jaringan terpisah.
Zone (GCP)    = istilah GCP untuk AZ. GCP region punya minimal 3 zone.
Edge Location = titik presence untuk CDN dan cache, jumlahnya jauh lebih banyak dari region.
 
Shared Responsibility Model:
  On-prem   : kamu urus semua, dari fisik sampai aplikasi.
  IaaS      : provider urus fisik, virtualisasi. Kamu urus OS ke atas.
  PaaS      : provider urus runtime dan OS. Kamu urus kode dan data.
  SaaS      : provider urus semuanya. Kamu urus konfigurasi dan akun.
 
IaaS contoh : EC2, Compute Engine, Azure Virtual Machines
PaaS contoh : App Service, Cloud Run, Elastic Beanstalk
SaaS contoh : Google Workspace, Microsoft 365

Poin penting: region menentukan latency, harga, dan kepatuhan data. Ketiga provider sekarang punya kehadiran di Indonesia. AWS dengan region Asia Pacific (Jakarta) atau ap-southeast-3, GCP dengan asia-southeast2 di Jakarta, dan Azure dengan region Indonesia Central di area Greater Jakarta. Kalau target penggunamu di Indonesia, pilih region ini biar latency rendah dan data tetap di dalam negeri.

#Peta Layanan: AWS vs GCP vs Azure

Tabel ini jadi pintu masuk utamamu. Kalau kamu tahu satu layanan di satu provider, cari padanannya di sini sebelum baca dokumentasi provider lain.

Catatan rename yang sering membingungkan: Azure Active Directory sekarang bernama Microsoft Entra ID (per Juli 2023), dan Cloud Functions gen 2 di GCP sudah berganti nama jadi Cloud Run functions (Agustus 2024). Dokumentasi lama masih memakai nama lama, jadi waspadai itu waktu baca tutorial usang.

#Compute

Tiga cara utama jalanin workload di cloud: VM (kendali penuh), container (portabel), dan serverless (tanpa kelola server).

#Virtual Machine

# AWS EC2
aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t3.micro \
  --key-name my-key \
  --region ap-southeast-3
 
# GCP Compute Engine
gcloud compute instances create my-vm \
  --machine-type=e2-small \
  --zone=asia-southeast2-a
 
# Azure Virtual Machines
az vm create \
  --resource-group my-rg \
  --name my-vm \
  --image Ubuntu2204 \
  --size Standard_B1s \
  --admin-username azureuser

Keluarga instance yang perlu kamu hafal:

Burstable (t3, e2-micro, B-series) cocok untuk dev, staging, dan aplikasi kecil. Ia punya kredit CPU yang terkumpul dan habis kalau kamu spike terus.

#Instance Preemptible dan Spot

Ketiga provider jual kapasitas nganggur dengan potongan besar: AWS Spot Instances (klaim resmi hingga 90%), GCP Spot VMs (hingga 91%), dan Azure Spot Virtual Machines (hingga 90%). Konsekuensinya, instance bisa dihentikan provider kapan saja dengan notifikasi singkat (AWS kasih waktu 2 menit, GCP 30 detik). Cocok untuk batch job, CI runner, dan workload yang tahan restart. Nggak cocok untuk database production.

#Container

# Deploy container ke Cloud Run (GCP)
gcloud run deploy my-service \
  --image=asia-southeast2-docker.pkg.dev/my-project/my-repo/app:1.0 \
  --region=asia-southeast2 \
  --allow-unauthenticated
 
# AWS: jalankan task Fargate di ECS
aws ecs run-task \
  --cluster my-cluster \
  --launch-type FARGATE \
  --task-definition my-task:1

Aturan praktis: pakai Kubernetes (EKS, GKE, AKS) kalau timmu sudah paham operasinya atau butuh kontrol penuh atas orkestrasi. Pakai platform container managed (Cloud Run, App Runner, Container Apps, Fargate) kalau kamu cuma mau jalanin container tanpa mikirin control plane. GKE terkenal paling matang untuk pengalaman Kubernetes managed, sementara Cloud Run unggul dalam kesederhanaan deploy satu service.

#Storage

#Object Storage

Object storage untuk file statis, backup, media, dan data lake. Semua bisa diakses via HTTP dan SDK.

# AWS S3
aws s3 cp app.zip s3://my-bucket/releases/
 
# GCP Cloud Storage
gcloud storage cp app.zip gs://my-bucket/releases/
 
# Azure Blob Storage
az storage blob upload \
  --account-name mystorageacct \
  --container-name releases \
  --file app.zip \
  --auth-mode login

Tingkat storage menentukan harga per GB dan biaya akses:

AWS punya S3 Intelligent-Tiering yang otomatis mindahin objek antar tier berdasarkan pola akses, tanpa biaya monitorisasi untuk objek standar. Berguna kalau pola aksesmu nggak bisa diprediksi.

#Block dan File Storage

• Block storage nempel ke satu VM: EBS (AWS), Persistent Disk (GCP), Managed Disks (Azure). Ukurannya menentukan IOPS dan throughput. Dilepas dan dipasang ke VM lain kalau perlu.
• File storage berbagi lintas VM via NFS atau SMB: EFS, Filestore, Azure Files. Umum dipakai untuk konten web bersama atau workload legacy yang butuh shared disk.

#Networking

Blok bangunan jaringan di ketiga provider hampir identik secara konsep, beda nama saja.

VPC / VNet        = jaringan privat virtual milikmu di dalam region.
Subnet            = bagian dari VPC, punya CIDR sendiri, terikat di satu AZ (AWS)
                    atau satu region (GCP). Azure subnet hidup di dalam VNet region.
Internet Gateway  = pintu keluar masuk traffic internet.
NAT Gateway       = bikin VM di private subnet bisa keluar internet tanpa bisa diakses dari luar.
Peering           = sambungkan dua VPC/VNet supaya saling komunikasi lewat jaringan internal.

#Firewall dan Security Group

Aturan main yang sama di semua provider: izinkan hanya port yang perlu (80, 443, port app), batasi sumber IP kalau bisa, dan jangan pernah buka SSH atau RDP ke 0.0.0.0/0. Pakai SSH lewat bastion, SSM Session Manager (AWS), atau Cloud Shell sebagai gantinya.

#Load Balancer dan DNS

• L7 (HTTP/HTTPS, routing berdasarkan path atau host): AWS Application Load Balancer, GCP Global External HTTP(S) Load Balancer, Azure Application Gateway.
• L4 (TCP/UDP): AWS Network Load Balancer, GCP External Passthrough Network Load Balancer, Azure Load Balancer.
• Global entry + CDN + WAF: CloudFront, Cloud CDN, Azure Front Door.
• DNS: Route 53, Cloud DNS, dan Azure DNS semuanya mendukung hosted zone, record standar, health check, dan routing berbasis latency atau geografi.

Pola umum untuk aplikasi web: DNS pointing ke CDN, CDN ambil aset statis dari object storage, load balancer terima traffic dinamis lalu sebar ke VM atau container di beberapa AZ.

#IAM

Bagian paling sering jadi sumber insiden sekaligus bagian yang paling sering diabaikan waktu belajar. Kuasai model satu provider, sisanya tinggal translasi.

#AWS IAM

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::my-bucket/releases/*"
    }
  ]
}

• Root account: hanya dipakai untuk bikin akun pertama dan setel billing. Kasih MFA, lalu simpan kredensialnya.
• IAM user: identitas permanen untuk manusia. Trend sekarang: manusia pakai SSO (IAM Identity Center) dengan role sementara, bukan access key permanen.
• IAM role: identitas dengan kredensial sementara, dipakai oleh service (EC2, Lambda) atau di-assume oleh manusia. Ini pola yang harus jadi defaultmu.
• Policy: dokumen JSON yang menyatakan allow atau deny terhadap action pada resource.

#GCP Cloud IAM

GCP punya hierarki resource: Organization, lalu Folder, lalu Project. Semua resource hidup di dalam Project, dan permission diwariskan dari atas ke bawah. Role di folder otomatis berlaku untuk semua project di dalamnya.

• Principal: siapa pun yang bisa diberi akses (user, group, service account, domain).
• Role adalah kumpulan permission. Predefined role buatan Google, custom role buatanmu sendiri.
• Service account: identitas untuk workload, bukan manusia. VM dan Cloud Run memakai service account untuk panggil API.
• Workload Identity Federation: izinkan kode dari luar GCP (misal GitHub Actions) minta token akses tanpa menyimpan kunci JSON. Selalu pilih ini dibanding file kunci service account.

#Azure: Microsoft Entra ID dan RBAC

Azure pisah antara identitas (Microsoft Entra ID, dulu Azure Active Directory) dan otorisasi (RBAC, Role-Based Access Control). Role assignment punya tiga komponen: security principal (siapa), role definition (apa yang boleh, misal Reader, Contributor, Owner), dan scope (di mana: management group, subscription, resource group, atau resource tunggal).

# Beri akses Contributor ke resource group untuk user
az role assignment create \
  --assignee user@contoso.com \
  --role Contributor \
  --scope /subscriptions/xxxx/resourceGroups/my-rg

Managed identity di Azure adalah padanan service account: identitas managed yang menempel di VM atau App Service dan otomatis dapat token, tanpa kredensial yang perlu kamu simpan.

#Prinsip yang Sama di Mana-mana

1. Least privilege: beri akses paling kecil yang cukup, tingkatkan kalau terbukti perlu.
2. Nggak ada kredensial jangka panjang di kode. Pakai role, workload identity, atau managed identity.
3. Audit: aktifkan log akses (AWS CloudTrail, GCP Audit Logs, Azure Activity Log) dan alarm untuk akses mencurigakan.
4. Group dulu, assign ke group, bukan ke individu satu per satu.

#Managed Databases

Jalanin database sendiri di VM artinya kamu urus backup, patching, failover, dan monitoring. Managed database ngalihin pekerjaan itu ke provider dengan biaya tambahan sekitar 10 sampai 30 persen.

#Relasional

#NoSQL dan Cache

• DynamoDB (AWS): key-value dengan latensi milidetik tunggal di skala apa pun, on-demand atau provisioned capacity.
• Firestore (GCP): document store dengan sync realtime, cocok untuk aplikasi mobile dan web.
• Cosmos DB (Azure): multi-model dengan konsistensi yang bisa kamu pilih dari lima level, dan SLA latensi terkontrak.
• Redis managed: ElastiCache (AWS), Memorystore (GCP), Azure Cache for Redis. Sebelum ambil managed Redis, cek apakah managed Postgres dengan ekstensi key-value sudah cukup. Managed Redis mahal.

Aturan pemilihan sederhana: mulai dari Postgres managed kalau datamu relasional atau belum jelas bentuknya. Pindah ke NoSQL khusus kalau ada alasan konkret (skala tulis ekstrem, akses key-value murni, atau pola dokumen yang lepas dari join).

#Serverless

Serverless artinya kamu bayar per eksekusi dan provider yang urus scaling, patching OS, dan kapasitas. Nggak ada server yang idle dan menagihmu.

#Fungsi

// AWS Lambda handler (Node.js)
export const handler = async (event) => {
  const name = event.queryStringParameters?.name ?? "dunia";
  return {
    statusCode: 200,
    body: JSON.stringify({ pesan: `hai ${name}` }),
  };
};

# Deploy Azure Functions dari lokal
func init MyFunctionApp --javascript
cd MyFunctionApp && func new --template "HTTP Trigger" --name HttpHello
func azure functionapp publish my-function-app
 
# Deploy Cloud Run functions (GCP)
gcloud functions deploy hello \
  --gen2 \
  --runtime=nodejs20 \
  --trigger-http \
  --region=asia-southeast2

Batas penting yang harus kamu inget:

Untuk API publik di depan fungsi, kamu butuh API gateway: AWS API Gateway, GCP API Gateway, atau Azure API Management. Gateway ini yang urus rate limiting, autentikasi, dan routing ke fungsi.

#Kapan Pakai Serverless

Cocok untuk: event handler (file diupload ke S3, pesan masuk queue), API dengan traffic tidak merata, cron job ringan, dan glue code antar service. Kurang cocok untuk: koneksi database persisten (tiap instance fungsinya punya koneksi sendiri, cepat habisin connection pool), workload long-running, atau sistem yang butuh latency sangat stabil.

#Model Harga

Cara tagih ketiga provider sama di fondasinya: bayar sesuai pemakaian (pay-as-you-go), tanpa biaya di muka untuk instance. Yang bikin tagihan bengkak biasanya bukan compute, tapi egress data dan layanan yang lupa dimatikan.

#Model Diskon untuk Commitment

Angka-angka di atas adalah klaim maksimal dari halaman resmi masing-masing provider. Realitanya tergantung region, tipe instance, dan keluarga mesin.

#Egress dan Biaya Tersembunyi

• Egress (data keluar dari cloud ke internet) ditagih per GB dan naik seiring volume. Data masuk umumnya gratis. Traffic antar service di region yang sama biasanya gratis atau murah.
• Load balancer, IP pubik statis yang nggak kepakai, snapshot dan volume orphan setelah VM dihapus, semuanya tetap menagih. Tagihan kejutan hampir selalu dari sini.
• NAT Gateway di AWS itu mahal per GB yang diproses. Contoh klasik: staging environment yang diam tapi NAT-nya memproses traffic update package terus.

# Pasang alarm budget (AWS)
aws budgets create-budget \
  --account-id 123456789012 \
  --budget '{"BudgetName":"monthly-500","BudgetLimit":{"Amount":"500","Unit":"USD"},"TimeUnit":"MONTHLY","BudgetType":"COST"}'
 
# Estimasi biaya VM GCP
gcloud billing pricing ?  # tidak ada command pricing; pakai kalkulator web Google Cloud Pricing Calculator

Kalkulator harga resmi: AWS Pricing Calculator (calculator.aws), Google Cloud Pricing Calculator, Azure Pricing Calculator. Selalu hitung dulu sebelum deploy workload baru, terutama yang stateful.

#Infrastruktur sebagai Kode

Perubahan infrastruktur lewat console itu cepat sekali jalan dan menyiksa selamanya. Semua yang kamu bangun harus bisa dibangun ulang dari kode. Terraform jadi standar de facto untuk lintas provider, Pulumi kalau timmu lebih nyaman bahasa pemrograman umum, dan Bicep atau CloudFormation kalau kamu single-cloud dan mau dukungan native.

# Contoh Terraform: resource group Azure + storage account
resource "azurerm_resource_group" "rg" {
  name     = "my-rg"
  location = "Indonesia Central"
}
 
resource "azurerm_storage_account" "st" {
  name                     = "stmystorageacct01"
  resource_group_name      = azurerm_resource_group.rg.name
  location                 = azurerm_resource_group.rg.location
  account_tier             = "Standard"
  account_replication_type = "LRS"
}

Terraform punya provider resmi untuk AWS, GCP, dan Azure, jadi satu tool ini cukup untuk seluruh kebutuhanmu, termasuk kombinasi multi-cloud. Simpan state di remote backend (S3 + DynamoDB, GCS, Azure Storage, atau Terraform Cloud), jangan di mesin lokal.

#Memilih Provider

Pertanyaan yang paling sering aku terima dari orang baru: "harus mulai dari yang mana?" Jawaban jujurnya: ketiganya setara secara fondasi, pilihannya ditentukan konteks, bukan fitur.

Kondisi kamu                          -> Rekomendasi
------------------------------------------------------
Kantor pakai Microsoft 365,           -> Azure
ada tim Windows Server atau .NET
 
Butuh BigQuery, ML, atau              -> GCP
data pipeline kuat
 
Butuh katalog layanan terluas,        -> AWS
lowongan kerja terbanyak, atau
komunitas terbesar
 
Target pengguna di Indonesia          -> pilih region Jakarta
di provider mana pun yang kamu kuasai
 
Belum tahu apa-apa                    -> AWS atau Azure free tier,
                                        fokus satu provider sampai dalam

Pertimbangan praktis yang sering lebih menentukan daripada fitur:

1. Kebijakan kantor. Kalau kantor sudah invest di satu provider (kontrak enterprise, skill tim, sistem internal), ikuti itu. Melawan arus organisasi itu lebih mahal dari selisih fitur.
2. Region dan latency. Semua aplikasi yang sensitif delay untuk pengguna Indonesia harusnya jalan di region Jakarta dari provider pilihanmu.
3. Biaya belajar. Free tier ketiganya cukup untuk belajar dasar. Bedanya, jumlah materi komunitas untuk AWS masih yang terbesar.
4. Portabilitas. Konsep (VPC, IAM role, auto scaling) itu bisa dipindah antar provider. Kode spesifik service biasanya nggak. Makanya kuasai konsepnya, bukan cuma klik-klik console.

Soal multi-cloud: pakai dua provider sekaligus hanya kalau ada alasan kuat (regulasi, akuisisi, bargaining harga). Operasional multi-cloud itu dobel kerja: dobel IaC, dobel IAM, dobel skill set, dan dobel titik kegagalan. Kebanyakan tim lebih baik jalanin satu provider dengan disiplin daripada dua setengah-setengah.

#Glosarium

• Region: area geografis berisi beberapa Availability Zone, unit terbesar untuk memilih lokasi deploy.
• Availability Zone (AZ): satu atau lebih data center dengan listrik, pendingin, dan jaringan terpisah di dalam satu region.
• Shared Responsibility Model: pembagian tanggung jawab keamanan antara provider (fisik sampai virtualisasi) dan kamu (OS sampai data).
• IaaS / PaaS / SaaS: tiga lapis model layanan, dari kamu kelola OS sendiri sampai provider kelola semuanya.
• Burstable instance: instance murah dengan kredit CPU terbatas, cocok untuk workload ringan dan tidak stabil.
• Spot / preemptible instance: kapasitas diskon besar yang bisa dihentikan provider sewaktu-waktu, untuk workload yang tahan interrupt.
• VPC / VNet: jaringan privat virtual tempat semua resource compute-mu hidup.
• Security Group: firewall stateful di level instance atau NIC di AWS dan Azure.
• IAM role: identitas dengan kredensial sementara untuk service atau user, pengganti access key permanen.
• Service account / managed identity: identitas untuk workload (bukan manusia) di GCP dan Azure.
• Least privilege: prinsip memberi izin paling kecil yang masih cukup untuk menyelesaikan pekerjaan.
• Managed database: database yang operasionalnya (backup, patching, failover) ditangani provider.
• Serverless: model di mana kamu bayar per eksekusi dan provider mengatur kapasitas, tanpa server yang kamu kelola.
• Cold start: jeda eksekusi pertama fungsi atau instance serverless karena environment harus disiapkan dulu.
• Egress: biaya untuk traffic data yang keluar dari cloud menuju internet atau provider lain.
• Savings Plan / CUD (Committed Use Discount): komitmen pemakaian 1 atau 3 tahun sebagai tukar diskon besar.
• IaC (Infrastructure as Code): mendefinisikan infrastruktur dalam file deklaratif yang bisa diversion dan dijalankan ulang.
• Multi-cloud: strategi memakai lebih dari satu provider cloud secara bersamaan, dengan biaya operasional ganda.
• Hybrid cloud: kombinasi on-premise dan cloud yang terhubung, biasa untuk migrasi bertahap atau regulasi data.
• Control plane: lapisan yang mengatur resource (scheduling, orkestrasi), lawan dari data plane yang menjalankan workload.