Aplikasi pertama saya yang benar-benar "hidup" di internet dulu berjalan di satu server sewaan seharga secangkir kopi per bulan. Ia melayani beberapa ratus pengguna dengan gagah, sampai suatu pagi sebuah tautan viral membawa puluhan ribu orang sekaligus. Server itu tersengal, lalu diam. Saya menghabiskan tiga jam panik: menyalakan ulang, menambah RAM, memindahkan basis data. Malam itu saya belajar pelajaran yang tidak pernah saya lupa — kapasitas yang tidak bisa berubah cepat adalah utang yang menunggu ditagih.

Buku ini tentang cara membayar utang itu dengan bijak: memindahkan beban dari "satu mesin yang saya rawat sendiri" ke infrastruktur cloud yang bisa tumbuh dan menyusut mengikuti kebutuhan. Kita akan membahas dua pemain terbesar — Amazon Web Services (AWS) dan Google Cloud Platform (GCP) — lalu dua teknologi yang menyatukan cara kita mengemas dan menjalankan aplikasi di mana pun: Docker dan Kubernetes.

Everything fails, all the time.

Werner Vogels, CTO Amazon

Kalimat Werner Vogels di atas bukan pesimisme; itu adalah filosofi desain. Di cloud, kita berhenti berharap komponen tidak akan rusak, dan mulai merancang sistem yang tetap sehat ketika sebagian komponennya rusak. Region bisa terganggu, disk bisa penuh, sebuah instance bisa mati diam-diam. Insinyur infrastruktur yang baik menyiapkan sistemnya untuk semua itu — dan buku ini akan menunjukkan caranya, satu konsep pada satu waktu.

Saya menulis buku ini untuk Anda yang sudah bisa membuat aplikasi — sudah paham menulis backend, memanggil basis data, menaruh sesuatu di Vercel atau sebuah VPS — tetapi belum pernah menyentuh "cloud besar" dan merasa istilahnya seperti sup alfabet: VPC, IAM, AZ, CIDR, ALB, IGW, NAT, EKS. Kabar baiknya: di baliknya cuma ada beberapa ide inti yang berulang. Setelah Anda memegang ide-ide itu, sisanya tinggal kosakata.

Dan karena kita hidup di zaman ketika mesin pun ikut membaca dokumen, ada satu bab khusus — Cara Dibaca AI — yang membuat buku ini ramah bagi manusia sekaligus model bahasa yang mungkin Anda minta meringkasnya. Selamat membaca, dan selamat membangun sesuatu yang tetap berdiri saat tautan Anda menjadi viral.

Buku ini bisa dibaca berurutan atau dilompati. Tapi karena konsep infrastruktur saling bertumpuk, saya sarankan pemula membaca Bab 1–3 dulu sebelum melompat. Berikut peta besarnya.

Struktur buku

• Bab 1–2 — Fondasi. Kapan Anda benar-benar butuh cloud (dan kapan tidak), lalu konsep universal: region, AZ, IAM, billing, tagging.
• Bab 3–8 — Dunia AWS. IAM, S3, EC2, VPC & multi-VPC, RDS & layanan pendukung, sampai DNS & subdomain. Ini bagian terbesar karena AWS punya kosakata paling padat.
• Peta Layanan (interaktif) & Bab 9–11 — Dunia GCP. Alat interaktif untuk memetakan kebutuhan Anda ke layanan AWS & GCP, lalu IAM, Cloud Storage, Compute Engine, Cloud Run, dan Cloud SQL.
• Bab 12–15 — Container & Produksi. Docker, Kubernetes, CI/CD, load balancer, dan auto-scaling. Bagian ini berlaku di kedua cloud (dan di mana pun).
• Bab 16–19 — Matang & Aman. Keamanan, biaya, pohon keputusan "kapan pakai apa", bab Cara Dibaca AI, lalu penutup dengan FAQ, glosarium, dan checklist produksi.

Rambu-rambu di dalam teks

Beberapa elemen visual berulang. Kenali artinya sekali, lalu Anda akan membacanya sekilas:

Anda juga akan sering menemukan diagram arsitektur (gambar SVG yang tajam di layar apa pun dan bisa dicetak), mockup konsol/terminal yang meniru sesi sungguhan, serta satu komponen interaktif — Pemetaan Layanan AWS ↔ GCP — yang berfungsi saat dibuka di peramban.

Ada godaan besar di dunia teknologi untuk memakai alat paling canggih hanya karena ia canggih. Kubernetes, multi-region, service mesh — semuanya terdengar seperti kelas atas. Tapi infrastruktur yang benar bukan yang paling rumit; ia yang paling pas dengan masalah Anda hari ini dan cukup lentur untuk masalah Anda enam bulan lagi. Bab ini soal mengenali kapan tangga cloud benar-benar perlu dinaiki.

Sinyal bahwa Anda butuh cloud

Kebanyakan aplikasi kecil tidak butuh AWS atau GCP. Sebuah landing page, blog, atau MVP dengan seratus pengguna hidup nyaman di Vercel, Netlify, atau satu VPS. Cloud besar mulai masuk akal ketika Anda mengalami satu atau lebih dari ini:

• Beban tidak rata. Trafik melonjak di jam tertentu (misal aplikasi absensi jam 7 pagi) lalu sepi. Anda ingin membayar saat ramai saja, bukan menyewa kapasitas puncak 24 jam.
• Butuh banyak layanan yang saling terhubung. Backend, worker antrean, basis data terkelola, penyimpanan file, CDN, dan pengiriman email — semuanya di satu tempat dengan jaringan privat di antaranya.
• Kebutuhan keandalan. Anda tak boleh mati saat satu data center bermasalah. Cloud menyediakan beberapa Availability Zone yang terpisah secara fisik.
• Regulasi & lokasi data. Data harus berada di region tertentu (misalnya Jakarta), atau audit menuntut kontrol akses berbutir halus.
• Tim membesar. Anda perlu memberi izin berbeda ke orang berbeda tanpa saling menimpa — inilah kerja IAM.

Vercel vs VPS vs Cloud besar

Tiga tingkat abstraksi ini bukan saingan; mereka titik berbeda pada spektrum "berapa banyak yang Anda urus sendiri". Semakin ke kanan, semakin banyak kendali dan tanggung jawab.

Pola yang sehat: mulai dari kiri, geser ke kanan hanya saat perlu. Banyak tim sukses menjalankan frontend di Vercel dan backend berat di AWS sekaligus — memakai tiap alat pada titik terkuatnya. Cloud besar bukan tujuan akhir yang wajib; ia alat untuk masalah tertentu.

Simplicity is a prerequisite for reliability.

Edsger W. Dijkstra

Sebelum menyentuh tombol apa pun di konsol AWS atau GCP, ada empat gagasan yang muncul berulang di setiap layanan. Kuasai keempatnya sekarang, dan sembilan puluh persen kebingungan nanti akan lenyap: geografi (region & AZ), identitas (IAM), uang (billing), dan label (tagging).

Region, Availability Zone, dan Edge

Cloud secara fisik adalah bangunan berisi ribuan komputer. Untuk menatanya, penyedia membagi dunia menjadi tiga tingkat geografi:

• Region — area geografis luas, misalnya ap-southeast-1 (Singapura) di AWS atau asia-southeast2 (Jakarta) di GCP. Region menentukan di mana data Anda tinggal (penting untuk latensi & regulasi).
• Availability Zone (AZ) — satu atau beberapa data center terpisah di dalam region, dengan listrik dan jaringan mandiri. Satu region biasanya punya 3 AZ. Menyebar aplikasi ke beberapa AZ membuatnya tahan terhadap kegagalan satu data center.
• Edge / PoP (Point of Presence) — lokasi kecil dekat pengguna, dipakai CDN (CloudFront/Cloud CDN) untuk menyimpan salinan konten agar cepat diakses dari mana saja.

IAM: identitas sebagai fondasi

IAM (Identity and Access Management) adalah sistem yang menjawab satu pertanyaan di setiap tindakan: "Siapa boleh melakukan apa, pada sumber daya mana, dengan syarat apa?" Ini bukan fitur sampingan — ia lapisan pertama keamanan cloud. Salah mengatur IAM adalah penyebab paling umum kebocoran data cloud.

Tiga kata kunci yang akan berulang:

• Principal — siapa yang bertindak: seorang user, sebuah role, atau sebuah layanan.
• Policy — dokumen aturan (biasanya JSON) yang menyatakan izin: aksi apa (misal s3:GetObject) diizinkan/ditolak pada sumber daya apa.
• Least privilege — prinsip memberi izin sekecil mungkin yang cukup untuk tugas. Kita bahas dalam di Bab 3.

Security is not a product, but a process.

Bruce Schneier

Billing & tagging: melihat ke mana uang pergi

Di VPS, tagihan adalah angka tetap. Di cloud, tagihan adalah penjumlahan ratusan baris kecil: jam compute, GB storage, GB transfer, jumlah request, jam load balancer. Tanpa disiplin, tagihan menjadi kejutan tiap bulan. Dua kebiasaan menyelamatkan Anda:

• Budget alert. Set anggaran (misal 50 USD/bulan) dan minta email/notifikasi saat mencapai 50%, 80%, 100%. Ini rem pertama Anda.
• Tagging. Beri label pada tiap sumber daya: env=prod, team=checkout, project=tokoku. Nanti Anda bisa memfilter tagihan per tag dan tahu persis fitur mana yang mahal.

Ketika Anda pertama masuk ke konsol AWS, godaannya adalah langsung menyalakan server. Jangan. Hal pertama yang benar untuk dilakukan bukan compute, melainkan identitas. Akun yang salah diatur di awal adalah pintu terbuka yang baru Anda sadari sudah dilewati orang lain saat tagihan penambangan kripto tiba.

Root account: pakai sekali, lalu kunci

Saat mendaftar AWS, Anda mendapat root account — identitas maha kuasa yang bisa melakukan apa saja, termasuk menutup akun dan mengubah billing. Root tidak untuk pemakaian harian. Aturan mainnya:

• Aktifkan MFA (Multi-Factor Authentication) pada root segera.
• Buat satu IAM user admin untuk diri Anda, lalu simpan kredensial root dan nyaris tak pernah pakai lagi.
• Jangan pernah membuat access key untuk root.

User, Group, Role, dan Policy

Empat objek IAM yang harus Anda bedakan dengan jelas:

Perbedaan paling penting: role tidak punya password atau access key permanen. Ia memberi kredensial sementara yang berlaku beberapa jam lalu kedaluwarsa. Inilah cara aman memberi izin ke sebuah EC2 atau fungsi Lambda — alih-alih menempelkan access key ke dalam kode (yang bisa bocor), Anda melekatkan role ke sumber daya itu.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "BacaBucketTertentu",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::tokoku-uploads",
        "arn:aws:s3:::tokoku-uploads/*"
      ]
    }
  ]
}

Bacalah policy di atas seperti kalimat: "Izinkan (Allow) aksi s3:GetObject dan s3:ListBucket pada bucket tokoku-uploads dan seluruh isinya." Setiap policy AWS punya bentuk yang sama: Effect (Allow/Deny), Action (aksi API), Resource (ARN target), dan opsional Condition (syarat, misal hanya dari IP tertentu).

ARN: alamat unik setiap sumber daya

ARN (Amazon Resource Name) adalah "alamat lengkap" sebuah sumber daya, berformat arn:aws:service:region:account-id:resource. Contoh: arn:aws:s3:::tokoku-uploads (S3 bersifat global sehingga region & account kosong) atau arn:aws:ec2:ap-southeast-1:123456789012:instance/i-0abc. Anda akan sering menempelkan ARN di policy.

Least privilege: seni memberi izin secukupnya

Prinsip least privilege berkata: beri sebuah identitas izin seminimal yang cukup untuk tugasnya — tidak lebih. Godaan pemula adalah melekatkan policy AdministratorAccess ke semuanya "supaya tidak error". Itu seperti memberi kunci semua ruangan kepada tukang kebun karena satu kali ia perlu masuk gudang.

Given enough eyeballs, all bugs are shallow — tetapi given enough permissions, all breaches are deep.

Adaptasi dari Linus's Law

Jika ada satu layanan AWS yang hampir semua aplikasi pakai, itu S3. Ia adalah tempat menyimpan "file" — foto profil, unggahan pengguna, backup, aset statis, log — dengan daya tahan yang nyaris tak masuk akal dan harga per gigabyte yang murah. Memahami S3 dengan benar akan mengubah cara Anda merancang penyimpanan selamanya.

Bucket, object, dan key

S3 adalah object storage, bukan filesystem. Perbedaannya penting:

• Bucket — wadah tingkat atas dengan nama unik secara global (tidak ada dua bucket bernama sama di seluruh AWS). Contoh: tokoku-uploads.
• Object — file yang Anda simpan, plus metadata. Ukuran hingga 5 TB per object.
• Key — "nama lengkap" object di dalam bucket, misalnya users/42/avatar.png. Meski terlihat seperti folder, sebenarnya key hanyalah string; S3 tidak punya folder sungguhan (hanya prefix).

Object diakses lewat URL berpola https://<bucket>.s3.<region>.amazonaws.com/<key>. S3 dirancang untuk daya tahan sangat tinggi (Amazon mengiklankan "eleven nines", 99,999999999% durabilitas — angka pemasaran, verifikasi ke dokumentasi resmi) dengan mereplikasi object ke banyak perangkat di beberapa AZ.

Storage class: bayar sesuai pola akses

Tidak semua data diakses sama sering. S3 menawarkan beberapa storage class dengan trade-off harga simpan vs harga ambil:

Static hosting & CDN di depan bucket

S3 bisa menyajikan situs statis (HTML/CSS/JS) langsung. Tapi pola produksi yang benar adalah menaruh CloudFront (CDN) di depan bucket: CDN menyimpan salinan aset di Edge dekat pengguna, memberi HTTPS, dan menyembunyikan bucket dari akses langsung.

Presigned URL, bucket policy, dan versioning

Tiga fitur S3 yang sering menyelamatkan Anda:

• Presigned URL — URL sementara bertanda tangan yang memberi akses terbatas-waktu ke satu object, tanpa membuka bucket. Ideal untuk "unggah file langsung dari browser" atau "tautan unduh berlaku 15 menit". Backend Anda membuatnya dengan SDK; klien memakainya langsung ke S3.
• Bucket policy — policy JSON di level bucket (mirip IAM policy) untuk aturan akses berbasis sumber daya, misalnya "hanya CloudFront distribution ini yang boleh baca".
• Versioning — menyimpan setiap versi object saat ditimpa/dihapus, sehingga penghapusan tak sengaja bisa dipulihkan. Kombinasikan dengan MFA Delete untuk perlindungan ekstra.

import { S3Client, PutObjectCommand } from "@aws-sdk/client-s3";
import { getSignedUrl } from "@aws-sdk/s3-request-presigner";

const s3 = new S3Client({ region: "ap-southeast-1" });

// URL berlaku 300 detik untuk mengunggah 1 object
const url = await getSignedUrl(
  s3,
  new PutObjectCommand({ Bucket: "tokoku-uploads", Key: "users/42/avatar.png" }),
  { expiresIn: 300 }
);
// kirim `url` ke browser; browser PUT langsung ke S3

EC2 (Elastic Compute Cloud) adalah "menyewa komputer per jam". Anda memilih ukuran mesin, sistem operasi, dan jaringannya; AWS menyalakannya dalam detik. Di balik semua layanan mewah, banyak beban kerja pada akhirnya berjalan di sebuah EC2. Memahaminya berarti memahami satuan compute paling dasar di AWS.

Instance type, AMI, dan siklus hidup

Saat menyalakan EC2, tiga pilihan utama:

• Instance type — ukuran & karakter mesin, ditulis seperti t3.micro, m6i.large, c7g.xlarge. Huruf awal menandai keluarga: t (murah, burstable), m (seimbang), c (compute-berat), r (memori-berat), g/p (GPU). Angka = generasi; sufiks = ukuran.
• AMI (Amazon Machine Image) — "cetakan" disk berisi OS dan software awal (Amazon Linux, Ubuntu, atau image kustom Anda).
• Key pair — pasangan kunci SSH untuk masuk ke instance. AWS menyimpan kunci publik; Anda menyimpan kunci privat (jangan pernah hilang/dibagikan).

Security group & key pair

Security group (SG) adalah firewall virtual di depan instance. Ia stateful: jika Anda mengizinkan koneksi masuk, respons keluarnya otomatis diizinkan. Anda menulis inbound rule (apa yang boleh masuk) dan outbound rule (apa yang boleh keluar), masing-masing menyebut protokol, port, dan sumber/tujuan.

# INBOUND
# HTTPS dari mana saja
allow tcp 443  from 0.0.0.0/0
# HTTP (untuk redirect ke HTTPS)
allow tcp 80   from 0.0.0.0/0
# SSH HANYA dari IP kantor Anda
allow tcp 22   from 203.0.113.10/32

# OUTBOUND
allow all      to   0.0.0.0/0

EBS, Elastic IP, dan penyimpanan

• EBS (Elastic Block Store) — disk virtual yang dilekatkan ke EC2 (seperti SSD/HDD). Tipe umum: gp3 (SSD serbaguna, default bagus), io2 (IOPS tinggi untuk DB), st1 (HDD throughput, untuk log/big data). EBS hidup terpisah dari instance: instance bisa dimatikan, disk tetap ada. Ambil snapshot berkala (tersimpan di S3) untuk backup.
• Instance store — disk fisik sementara yang menempel pada host; sangat cepat tapi hilang saat instance berhenti. Hanya untuk cache/scratch.
• Elastic IP — alamat IP publik statis yang bisa Anda pindah antar-instance. Berguna agar DNS tak perlu diubah saat mengganti server. Catatan: EIP yang tidak terpakai (tidak melekat) justru dikenai biaya kecil.

Treat servers like cattle, not pets.

Bill Baker (mempopulerkan analogi cattle vs pets)

Filosofi "cattle, not pets" adalah inti berpikir cloud: jangan memelihara satu server istimewa yang Anda beri nama dan rawat manual. Buat server bisa dibuang dan digantikan otomatis dari AMI/skrip, dengan semua state penting di luar (RDS, S3). Server yang sakit tidak diobati — ia diganti.

VPC (Virtual Private Cloud) adalah jaringan privat Anda sendiri di dalam cloud — sebuah "kavling" yang Anda tata sesuka hati: jalan mana yang tembus ke internet, ruangan mana yang terkunci, siapa bouleh bicara dengan siapa. Bagi banyak orang, VPC adalah bab yang paling menakutkan. Ia tidak sulit; ia hanya butuh gambar yang benar di kepala Anda. Mari kita bangun gambar itu.

CIDR, subnet, dan route table

Sebuah VPC diberi rentang alamat IP privat dalam notasi CIDR, misalnya 10.0.0.0/16 (berarti ~65.536 alamat, dari 10.0.0.0 sampai 10.0.255.255). Angka setelah garis miring adalah jumlah bit "tetap": makin besar angkanya, makin kecil rentangnya. /16 besar, /24 (256 alamat) kecil.

VPC dibagi menjadi subnet — potongan CIDR lebih kecil, masing-masing hidup di satu AZ. Dua jenis penting:

• Subnet publik — punya rute ke internet lewat Internet Gateway. Tempat yang boleh dijangkau dari luar (load balancer, bastion).
• Subnet privat — tidak bisa dijangkau langsung dari internet. Tempat server aplikasi dan basis data. Jauh lebih aman.

Yang menentukan sebuah subnet "publik" atau "privat" bukan namanya, melainkan route table-nya — tabel yang berkata "trafik ke tujuan X lewat gateway Y". Subnet publik punya rute 0.0.0.0/0 → Internet Gateway; subnet privat tidak.

Internet Gateway vs NAT Gateway

Dua gateway yang sering tertukar:

• Internet Gateway (IGW) — pintu dua arah antara VPC dan internet. Sumber daya di subnet publik dengan IP publik bisa menerima dan mengirim lewat IGW.
• NAT Gateway — pintu satu arah keluar untuk subnet privat. Server privat perlu mengunduh update atau memanggil API luar, tapi tak boleh dijangkau dari luar. NAT membiarkan mereka "keluar" lewat IP publik NAT, sementara koneksi masuk dari internet tetap tertutup.

Multi-VPC: peering dan Transit Gateway

Saat organisasi membesar, satu VPC sering tak cukup: Anda memisahkan lingkungan (prod vs staging), tim, atau akun. Menghubungkan VPC-VPC ini dilakukan dengan:

• VPC Peering — koneksi privat satu-lawan-satu antara dua VPC. Sederhana, tapi tidak transitif (jika A↔B dan B↔C, A tetap tak bisa ke C). Untuk banyak VPC, jaringan peering menjadi rumit (mesh).
• Transit Gateway — "hub" pusat tempat banyak VPC (dan koneksi on-premise) tersambung. Menggantikan mesh peering yang berantakan dengan topologi bintang yang rapi.

Syarat mutlak peering: rentang CIDR tidak boleh tumpang tindih. Jika VPC-A dan VPC-B sama-sama 10.0.0.0/16, mereka tak bisa di-peer — alamatnya bertabrakan. Rencanakan alokasi CIDR sejak awal (misal prod 10.0.0.0/16, staging 10.1.0.0/16).

Security Group vs Network ACL

Dua lapis firewall di VPC yang sering membingungkan:

The network is the computer.

John Gage, Sun Microsystems

Menjalankan basis data sendiri di EC2 memungkinkan, tapi berarti Anda yang mengurus backup, patch, replikasi, dan failover pada jam tiga pagi. Managed services membalik ini: AWS mengurus operasional yang membosankan, Anda fokus ke data. Bab ini menyapu tiga tetangga penting S3/EC2 — RDS, Lambda, dan trio jaringan CloudFront/Route 53.

RDS: basis data relasional terkelola

RDS (Relational Database Service) menjalankan mesin basis data populer — PostgreSQL, MySQL, MariaDB, SQL Server, Oracle — sebagai layanan terkelola. Yang Anda dapat:

• Backup otomatis & point-in-time recovery (kembali ke keadaan menit tertentu).
• Multi-AZ deployment — salinan siaga (standby) di AZ lain yang otomatis mengambil alih (failover) jika primary jatuh.
• Read replica — salinan baca untuk membagi beban query berat.
• Patch & upgrade versi yang dikelola AWS.

Ada juga Aurora, mesin buatan AWS yang kompatibel PostgreSQL/MySQL dengan performa & skalabilitas lebih tinggi, dan Aurora Serverless yang menyesuaikan kapasitas otomatis. Untuk data non-relasional, DynamoDB (NoSQL key-value/dokumen, sangat skalabel) adalah pilihan AWS.

Lambda: menjalankan kode tanpa server

AWS Lambda adalah serverless compute: Anda mengunggah fungsi, dan AWS menjalankannya hanya saat dipanggil — oleh HTTP request (via API Gateway), event S3, pesan antrean, atau jadwal. Anda tidak mengelola server; Anda membayar per invocation dan per milidetik waktu jalan.

Kapan Lambda bersinar: tugas pendek dan event-driven — memproses gambar yang baru diunggah, webhook, cron job, glue antar-layanan. Kapan kurang cocok: proses yang berjalan lama, butuh koneksi persisten, atau sensitif terhadap cold start (jeda saat fungsi "dingin" dibangunkan).

export const handler = async (event) => {
  const nama = event.queryStringParameters?.nama ?? "dunia";
  return {
    statusCode: 200,
    headers: { "content-type": "application/json" },
    body: JSON.stringify({ pesan: `Halo, ${nama}!` }),
  };
};

CloudFront & Route 53

• CloudFront — CDN AWS. Menyimpan cache aset di ratusan Edge, memberi HTTPS, dan bisa berdiri di depan S3, ALB, atau origin mana pun. Mengurangi latensi & beban origin sekaligus.
• Route 53 — layanan DNS AWS (namanya dari port DNS, 53). Selain menerjemahkan nama ke alamat, ia punya routing policy canggih: latency-based, geolocation, weighted (untuk canary), dan failover (arahkan ke cadangan saat health check gagal).

Kombinasi khas produksi: pengguna mengetik tokoku.com → Route 53 menerjemahkannya → ke CloudFront → yang menyajikan aset statis dari S3 dan meneruskan request dinamis ke ALB → ke aplikasi di EC2/ECS. Kita lihat sisi DNS-nya di bab berikut.

There are only two hard things in Computer Science: cache invalidation and naming things.

Phil Karlton

DNS adalah buku telepon internet: ia menerjemahkan nama yang manusia ingat (api.tokoku.com) menjadi alamat yang mesin pakai (sebuah IP atau nama lain). Kedengarannya sepele, tapi salah konfigurasi DNS adalah penyebab paling umum "kok situs saya tidak bisa dibuka padahal servernya jalan". Bab ini membuat DNS jelas dan memberi Anda strategi subdomain yang rapi.

Jenis record: A, AAAA, CNAME, dan kawan

Sebuah domain punya sekumpulan record di zone-nya. Yang paling sering Anda pakai:

Dua hal yang sering menjebak pemula:

• CNAME tak bisa di root (apex) domain. Standar DNS melarang CNAME pada tokoku.com polos (hanya di subdomain seperti www.tokoku.com). Solusinya adalah record Alias (Route 53) atau ANAME/flattening (Cloudflare) yang berperilaku seperti CNAME tapi legal di apex.
• TTL & propagasi. Setiap record punya TTL (time-to-live) — berapa lama resolver menyimpan cache jawabannya. Ubah record dengan TTL 24 jam, dan perubahan bisa "terlihat lambat" hingga cache lama kedaluwarsa. Turunkan TTL sebelum migrasi.

Subdomain per layanan

Saat aplikasi tumbuh, memisahkan bagian ke subdomain membuat arsitektur bersih dan mudah dirutekan:

• tokoku.com & www.tokoku.com — situs utama (frontend).
• api.tokoku.com — backend API.
• cdn.tokoku.com / static.tokoku.com — aset statis via CDN.
• admin.tokoku.com — panel internal (batasi aksesnya).
• staging.tokoku.com — lingkungan uji.

Route 53 vs Cloudflare

Anda tak wajib memakai DNS dari cloud yang sama dengan server. Dua pilihan populer:

• Route 53 — terintegrasi erat dengan AWS (record Alias ke ALB/CloudFront, health check + failover). Pilihan alami jika seluruh infra di AWS.
• Cloudflare — DNS cepat + proxy/CDN + proteksi DDoS + WAF, dengan tier gratis yang murah hati. Banyak tim memakai Cloudflare di depan apa pun, termasuk AWS/GCP.

Sebelum masuk ke dunia GCP, mari pasang jembatan mental. Hampir setiap layanan AWS punya padanan di GCP — nama beda, konsep sama. Alat di bawah ini interaktif: pilih kebutuhan Anda, dan ia menampilkan layanan AWS & GCP yang cocok, kapan dipakai, dan catatan biaya. Klik nama layanan untuk menyalinnya.

Perhatikan polanya: storage, compute, database, jaringan, dan "perekat" (queue/secrets) ada di kedua cloud. Setelah Anda menguasai satu cloud, mempelajari yang lain sebagian besar adalah menerjemahkan nama. Sisa bab GCP akan memakai peta ini sebagai kompas.

Google Cloud terasa berbeda dari AWS bukan karena konsepnya lain, tapi karena penataannya lain. Di mana AWS berpusat pada "akun", GCP berpusat pada project, dan membungkusnya dengan hierarki organisasi yang rapi. Sekali Anda paham perbedaan penataan ini, sisa GCP mengalir dengan mudah karena kosakata layanannya sudah Anda kenali dari peta tadi.

Project, folder, dan organisasi

Hierarki resource GCP dari atas ke bawah:

• Organization — puncak, mewakili perusahaan/domain Anda.
• Folder — pengelompokan opsional (per departemen, per lingkungan).
• Project — unit inti. Semua sumber daya (VM, bucket, database) tinggal di dalam sebuah project. Project adalah batas billing, izin, dan kuota. Ini padanan terdekat "akun kerja" di AWS, tapi jauh lebih ringan untuk dibuat banyak.

Praktik umum: satu project per lingkungan (tokoku-prod, tokoku-staging) atau per tim/layanan, sehingga izin dan biaya terpisah bersih. Membuat project baru di GCP semudah beberapa klik — berbeda dengan AWS di mana orang cenderung menahan diri membuat banyak akun.

IAM di GCP: role, member, dan binding

IAM GCP menjawab pertanyaan yang sama seperti AWS ("siapa boleh apa"), dengan model yang sedikit berbeda:

• Member (principal) — siapa: akun Google, service account (identitas non-manusia untuk aplikasi/VM), grup, atau seluruh domain.
• Role — kumpulan permission. Tiga jenis: basic (Owner/Editor/Viewer — terlalu luas, hindari di prod), predefined (dibuat Google per layanan, mis. roles/storage.objectViewer), dan custom (Anda rakit sendiri).
• Binding — ikatan "member ini punya role itu pada resource ini". Kebijakan IAM adalah kumpulan binding, dan diwariskan ke bawah hierarki (izin di level folder berlaku ke project di dalamnya).

gcloud projects add-iam-policy-binding tokoku-prod \
  --member="serviceAccount:app@tokoku-prod.iam.gserviceaccount.com" \
  --role="roles/storage.objectViewer"

Focus on the user and all else will follow.

Google, "Ten things we know to be true"

Jika Anda sudah paham S3 dari Bab 4, Cloud Storage (GCS) akan terasa seperti bertemu sepupu yang mirip. Konsep intinya identik — bucket, object, storage class, akses berbutir. Yang berbeda hanya nama dan beberapa detail. Bab pendek ini memetakan perbedaannya agar Anda bisa langsung produktif.

Bucket, object, dan storage class GCS

Sama seperti S3, GCS menyimpan object dalam bucket bernama unik global, diidentifikasi oleh name (mirip key). Storage class-nya:

Perbedaan menarik: di GCS, storage class melekat per-object tapi bucket punya default. GCS juga menawarkan location type: regional (satu region), dual-region, atau multi-region (tersebar, untuk ketersediaan tinggi). Object diakses lewat gs://bucket/name (di tooling) atau https://storage.googleapis.com/bucket/name.

Akses, signed URL, dan lifecycle

• Uniform bucket-level access — mode akses yang disarankan: kendali lewat IAM saja (bukan ACL per-object yang lama). Lebih sederhana dan lebih aman.
• Signed URL — padanan presigned URL S3: tautan sementara untuk unggah/unduh satu object tanpa membuka bucket.
• Object Lifecycle Management — padanan Lifecycle Policy S3: pindahkan ke Nearline/Coldline atau hapus object otomatis berdasarkan umur.
• Object Versioning — simpan versi lama saat ditimpa/dihapus.

# buat bucket regional di Jakarta
gcloud storage buckets create gs://tokoku-uploads \
  --location=asia-southeast2 \
  --uniform-bucket-level-access

# aktifkan versioning
gcloud storage buckets update gs://tokoku-uploads --versioning

Trio compute GCP menutupi tiga cara berbeda menjalankan beban kerja: mesin virtual penuh (Compute Engine), container serverless yang menskala ke nol (Cloud Run), dan basis data terkelola (Cloud SQL). Ketiganya adalah padanan langsung EC2, Fargate, dan RDS. Bab ini menunjukkan apa yang setara dan di mana GCP menawarkan kenyamanan ekstra.

Compute Engine: VM ala Google

Compute Engine (GCE) adalah "EC2-nya GCP": Anda menyalakan VM dengan tipe mesin pilihan, image OS, dan disk. Bedanya dengan AWS yang terasa nyaman:

• Custom machine type — Anda bisa menentukan jumlah vCPU dan RAM secara bebas (bukan hanya ukuran preset), menghindari membayar kapasitas yang tak terpakai.
• Sustained use discount — diskon otomatis jika VM berjalan sebagian besar bulan, tanpa komitmen di muka.
• Preemptible / Spot VM — padanan Spot AWS: jauh lebih murah, bisa dicabut.
• Live migration — Google memindahkan VM Anda saat maintenance host tanpa mematikannya.

Tipe mesin ditulis seperti e2-standard-4 (seri e2, seimbang, 4 vCPU) atau n2-highmem-8. Jaringan memakai VPC GCP yang — menariknya — bersifat global: satu VPC bisa mencakup banyak region, dengan subnet per-region. Ini berbeda dari VPC AWS yang terikat satu region.

Cloud Run: container serverless

Cloud Run mungkin fitur GCP yang paling disukai developer. Anda memberi sebuah container image (yang mendengarkan port HTTP), dan Cloud Run menjalankannya — menskala otomatis dari nol (tidak ada biaya saat tak ada trafik) sampai banyak instance saat ramai. Tak ada server yang diurus, tak ada cluster yang dipelihara.

# bangun & deploy langsung dari source (atau dari image yang sudah ada)
gcloud run deploy tokoku-api \
  --image=asia-southeast2-docker.pkg.dev/tokoku-prod/app/api:1.4.0 \
  --region=asia-southeast2 \
  --allow-unauthenticated \
  --min-instances=0 --max-instances=20

Cloud Run adalah titik manis antara Lambda dan Kubernetes: lebih fleksibel dari Lambda (container apa pun, bahasa apa pun, request lebih panjang), jauh lebih sederhana dari Kubernetes (tak ada cluster). Untuk banyak API dan web service, Cloud Run adalah default yang sangat baik. Padanan AWS terdekat: AWS Fargate (via ECS) atau App Runner.

Cloud SQL & basis data GCP

Cloud SQL adalah RDS-nya GCP: PostgreSQL, MySQL, dan SQL Server terkelola dengan backup otomatis, replika baca, dan opsi ketersediaan tinggi (HA) lintas-zone. Untuk skala lebih besar atau global, GCP menawarkan:

• Cloud Spanner — basis data relasional terdistribusi global dengan konsistensi kuat (kelas berat, mahal, untuk skala ekstrem).
• Firestore — NoSQL dokumen (padanan arah DynamoDB), cocok untuk aplikasi web/mobile realtime.
• Bigtable — NoSQL wide-column untuk data besar & analitik throughput tinggi.
• BigQuery — data warehouse serverless untuk analitik SQL atas data raksasa.

"Tapi di komputer saya jalan!" adalah keluhan setua industri perangkat lunak. Docker membunuh kalimat itu. Ia mengemas aplikasi Anda beserta seluruh lingkungannya — runtime, pustaka, konfigurasi — menjadi satu image yang berjalan identik di laptop Anda, di server rekan, dan di cloud. Container adalah fondasi cara modern men-deploy, dan bab ini membangunnya dari nol.

Image, container, dan layer

Dua kata yang harus dibedakan:

• Image — "cetakan" yang tidak berubah (immutable): berisi filesystem aplikasi + instruksi menjalankannya. Seperti kelas dalam OOP.
• Container — instance berjalan dari sebuah image. Seperti object dari kelas. Anda bisa menjalankan banyak container dari satu image.

Image tersusun dari layer yang bertumpuk — tiap instruksi di Dockerfile menambah satu layer. Layer di-cache dan dibagikan antar-image, sehingga build ulang cepat dan penyimpanan hemat. Container berbeda dari VM: ia tak membawa OS penuh, hanya berbagi kernel host, sehingga jauh lebih ringan dan cepat start (milidetik, bukan menit).

Dockerfile & multi-stage build

Dockerfile adalah resep membangun image: daftar instruksi yang dijalankan berurutan. Contoh naif untuk aplikasi Node.js:

FROM node:20
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build
EXPOSE 3000
CMD ["node", "dist/server.js"]

Masalahnya: image ini besar (membawa seluruh toolchain build dan devDependencies). Multi-stage build memisahkan tahap "membangun" dari tahap "menjalankan", sehingga image akhir hanya berisi yang perlu untuk runtime:

# --- tahap build ---
FROM node:20 AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# --- tahap runtime ---
FROM node:20-slim AS runtime
WORKDIR /app
ENV NODE_ENV=production
COPY package*.json ./
RUN npm ci --omit=dev
COPY --from=build /app/dist ./dist
EXPOSE 3000
USER node
CMD ["node", "dist/server.js"]

Compose & registry

Docker Compose mendefinisikan beberapa container yang bekerja bersama (app + database + cache) dalam satu file compose.yaml, dijalankan dengan satu perintah docker compose up. Ideal untuk pengembangan lokal dan setup kecil.

services:
  app:
    build: .
    ports: ["3000:3000"]
    environment:
      DATABASE_URL: postgres://app:secret@db:5432/tokoku
    depends_on: [db]
  db:
    image: postgres:16
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: tokoku
    volumes: ["dbdata:/var/lib/postgresql/data"]
volumes:
  dbdata:

Setelah image dibangun, ia disimpan di registry — gudang image. Ada Docker Hub (publik/privat), dan registry per-cloud: Amazon ECR, Google Artifact Registry (dulu GCR). Alur bakunya: docker build → docker tag → docker push ke registry → lingkungan produksi pull image itu.

Build, ship, run — anywhere.

Moto awal Docker Inc.

Satu container mudah dijalankan. Tetapi lima puluh container di sepuluh mesin, yang harus tetap hidup saat sebagian mati, menskala saat ramai, dan menerima update tanpa downtime — itu masalah orkestrasi. Kubernetes (sering disingkat K8s) adalah konduktor orkestra itu. Ia kuat, dan — jujur saja — rumit. Bab ini memberi Anda model mental yang benar, dan yang lebih penting: kejujuran tentang kapan Anda belum membutuhkannya.

Objek inti: Pod, Deployment, Service, Ingress

Kubernetes bekerja secara deklaratif: Anda menyatakan "keadaan yang diinginkan" (misalnya "aku mau 3 salinan aplikasi ini selalu berjalan"), dan K8s terus bekerja menjaga kenyataan cocok dengan keinginan itu. Empat objek yang wajib Anda kenal:

• Pod — unit terkecil yang bisa dijalankan: satu (atau beberapa) container yang berbagi jaringan & storage. Pod bersifat fana — ia bisa mati dan diganti kapan saja.
• Deployment — mengelola sekumpulan Pod identik: menjaga jumlah replika, dan melakukan rolling update (mengganti pod lama dengan baru bertahap tanpa downtime) serta rollback.
• Service — alamat jaringan stabil untuk sekumpulan Pod yang fana. Karena IP pod berubah-ubah, Service memberi satu nama/IP tetap dan membagi trafik (load balance) ke pod-pod di belakangnya.
• Ingress — aturan routing HTTP/HTTPS dari luar ke Service, berbasis host/path (misal api.tokoku.com → service api). Ditangani oleh ingress controller.

Ditambah dua objek konfigurasi: ConfigMap (konfigurasi non-rahasia) dan Secret (data sensitif seperti password — walau perlu diamankan lebih lanjut, lihat Bab 16).

kubectl & manifest YAML

Anda berbicara dengan cluster lewat kubectl, dan menyatakan keinginan dalam file manifest YAML. Contoh Deployment + Service:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  selector:
    matchLabels: { app: api }
  template:
    metadata:
      labels: { app: api }
    spec:
      containers:
        - name: api
          image: registry.example.com/tokoku/api:1.4.0
          ports: [{ containerPort: 3000 }]
          readinessProbe:
            httpGet: { path: /healthz, port: 3000 }
          resources:
            requests: { cpu: "100m", memory: "128Mi" }
            limits:   { cpu: "500m", memory: "512Mi" }
---
apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  selector: { app: api }
  ports: [{ port: 80, targetPort: 3000 }]

EKS/GKE & kapan Anda benar-benar perlu K8s

Menjalankan cluster K8s sendiri (mengurus control plane, etcd, upgrade) itu berat. Karena itu ada managed Kubernetes: Amazon EKS, Google GKE (GKE Autopilot bahkan mengelola node untuk Anda), dan Azure AKS. Mereka menangani control plane; Anda fokus ke workload.

Kubernetes is a platform for building platforms. It's a better place to start; not the endgame.

Kelsey Hightower

Men-deploy dengan tangan — SSH ke server, tarik kode, restart — bekerja sampai ia tidak. Ia lambat, mudah lupa langkah, dan tak ada jejak siapa mengubah apa. CI/CD mengubah deploy menjadi konsekuensi otomatis dari git push: setiap perubahan diuji, dikemas jadi image, dan diluncurkan tanpa drama. Bab ini merangkai semua yang sudah Anda pelajari menjadi satu pipa mulus.

CI vs CD: dua huruf, dua ide

• CI (Continuous Integration) — setiap push otomatis menjalankan build + test + lint. Tujuannya menangkap masalah sebelum masuk ke branch utama.
• CD (Continuous Delivery/Deployment) — setelah lolos CI, artefak (image) otomatis dikirim ke registry lalu di-deploy. Delivery = siap deploy dengan satu tombol; Deployment = deploy otomatis penuh.

Contoh workflow GitHub Actions

Berikut workflow lengkap yang membangun image, mendorong ke registry, lalu men-deploy — contoh untuk Cloud Run (pola serupa untuk EKS/GKE dengan kubectl):

name: build-and-deploy
on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20, cache: npm }
      - run: npm ci
      - run: npm test

  deploy:
    needs: test
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write   # untuk OIDC (tanpa menyimpan secret key jangka panjang)
    steps:
      - uses: actions/checkout@v4

      # autentikasi ke GCP via Workload Identity Federation (OIDC)
      - uses: google-github-actions/auth@v2
        with:
          workload_identity_provider: ${{ secrets.GCP_WIF_PROVIDER }}
          service_account: ${{ secrets.GCP_SA_EMAIL }}

      - uses: google-github-actions/setup-gcloud@v2

      - name: Build & push image
        run: |
          IMAGE=asia-southeast2-docker.pkg.dev/$PROJECT/app/api:${{ github.sha }}
          gcloud auth configure-docker asia-southeast2-docker.pkg.dev -q
          docker build -t "$IMAGE" .
          docker push "$IMAGE"
          echo "IMAGE=$IMAGE" >> "$GITHUB_ENV"
        env:
          PROJECT: tokoku-prod

      - name: Deploy ke Cloud Run
        run: |
          gcloud run deploy tokoku-api \
            --image="$IMAGE" --region=asia-southeast2 \
            --min-instances=1 --max-instances=20

Satu server punya batas. Ketika pengunjung melampaui batas itu, Anda punya dua pilihan: membuat server lebih besar (scale up), atau menambah lebih banyak server dan membagi beban (scale out). Cloud sangat pandai pada yang kedua — asal ada dua komponen: load balancer yang membagi trafik, dan auto-scaling yang menambah/mengurangi server otomatis. Bab ini membuat aplikasi Anda elastis.

Load balancer: pembagi trafik

Load balancer (LB) duduk di depan sekumpulan server dan membagikan request masuk ke antara mereka, sambil menjauhkan trafik dari server yang sakit. Jenis LB di AWS:

• ALB (Application Load Balancer) — Layer 7 (HTTP/HTTPS). Bisa merutekan berdasarkan host/path (/api ke satu grup, / ke lain), terminasi TLS, dan cocok untuk web/microservice.
• NLB (Network Load Balancer) — Layer 4 (TCP/UDP). Sangat cepat, latensi rendah, untuk trafik non-HTTP atau throughput ekstrem.
• GLB / Gateway LB — untuk appliance jaringan (firewall).

Di GCP, padanannya adalah Cloud Load Balancing (global, satu IP anycast bisa melayani seluruh dunia — keunggulan arsitektur GCP). Konsep intinya sama: LB → target group/backend → instance/pod sehat.

Auto-scaling & health check

Health check adalah denyut nadi: LB (atau K8s) memanggil sebuah endpoint (misal GET /healthz) secara berkala. Jika sebuah instance gagal beberapa kali, ia dianggap sakit dan trafik dialihkan darinya — lalu (di auto-scaling group) diganti otomatis. Dua jenis probe yang penting (istilah K8s, tapi konsepnya universal):

• Liveness — "apakah proses masih hidup?" Jika gagal, restart.
• Readiness — "apakah siap menerima trafik?" (misal koneksi DB sudah siap). Jika gagal, jangan kirim trafik dulu, tapi jangan restart.

Auto-scaling menyesuaikan jumlah instance berdasarkan metrik — paling umum CPU, tapi bisa juga jumlah request, panjang antrean, atau metrik kustom. Anda menetapkan batas min dan max, target metrik (misal "jaga CPU rata-rata 60%"), dan aturan main. Di AWS ini Auto Scaling Group; di K8s ada Horizontal Pod Autoscaler; Cloud Run melakukannya otomatis per-request.

Hope is not a strategy.

Prinsip Google SRE

Dua hal yang paling sering membuat orang menyesal di cloud: sistem yang tak aman, dan tagihan yang mengejutkan. Keduanya berbagi akar yang sama — kurang visibilitas dan kurang disiplin. Bab ini adalah kumpulan kebiasaan yang, bila dipasang sejak awal, menyelamatkan Anda dari malam-malam buruk di masa depan.

Keamanan berlapis

Keamanan cloud bukan satu tombol; ia lapisan. Prioritaskan dari yang paling berdampak:

• Identitas. MFA di mana-mana, least privilege (Bab 3 & 9), role/service account alih-alih key jangka panjang, rotasi kredensial berkala.
• Jaringan. DB & app di subnet privat, Security Group ketat, tak ada port admin terbuka ke 0.0.0.0/0, WAF di depan aplikasi publik.
• Data. Enkripsi at-rest (S3/EBS/RDS/GCS mendukungnya, sering default) dan in-transit (HTTPS/TLS). Bucket privat + Block Public Access.
• Rahasia. Jangan pernah di kode/image/git. Pakai secrets manager.
• Audit. Aktifkan CloudTrail (AWS) / Cloud Audit Logs (GCP) untuk jejak siapa melakukan apa.

Secrets manager

Rahasia (password DB, API key, token) harus hidup di layanan khusus: AWS Secrets Manager / Parameter Store, atau Google Secret Manager. Aplikasi mengambilnya saat runtime lewat identitas (role/service account), bukan menyimpannya di file. Keuntungan: rotasi terpusat, akses ter-audit, dan tak ada rahasia yang bocor lewat git.

Kontrol biaya

Tagihan cloud yang meledak hampir selalu bisa dicegah dengan beberapa kebiasaan:

An ounce of prevention is worth a pound of cure.

Benjamin Franklin

Anda kini punya banyak alat. Bahaya berikutnya adalah paradoks pilihan: begitu banyak layanan sehingga tiap keputusan terasa berat. Bab ini adalah kompas — kumpulan pohon keputusan yang menyaring "apa yang saya butuhkan" menjadi "pakai ini". Ingat prinsip pemandu: pilih yang paling sederhana yang menyelesaikan masalah, dan naik kompleksitas hanya saat dipaksa.

Pohon keputusan: menjalankan aplikasi

Pohon keputusan: menyimpan data

Pohon keputusan: AWS atau GCP?

Jujur: untuk kebanyakan tim, keduanya bekerja dengan baik, dan keputusan lebih dipengaruhi keakraban tim, harga negosiasi, dan ekosistem daripada keunggulan teknis mutlak. Beberapa kecenderungan:

Make it work, make it right, make it fast — dalam urutan itu.

Kent Beck

Buku ini ditulis untuk dua jenis pembaca. Yang pertama Anda — manusia dengan terminal terbuka. Yang kedua adalah model bahasa yang mungkin Anda minta meringkas, menjelaskan ulang, atau menjawab pertanyaan berdasarkan buku ini. Bab ini menjelaskan bagaimana teks ini dirancang agar keduanya mendapat manfaat maksimal — dan bagaimana Anda bisa memanfaatkannya.

Mengapa memikirkan pembaca AI?

Semakin banyak orang belajar lewat percakapan dengan AI: menempelkan dokumen, lalu bertanya. Dokumen yang terstruktur baik — dengan istilah yang didefinisikan, klaim yang ditandai tingkat kepastiannya, dan ringkasan padat — menghasilkan jawaban AI yang lebih akurat dan sedikit halusinasi. Menulis untuk AI, ternyata, juga membuat tulisan lebih baik untuk manusia.

Fitur yang membantu pembacaan AI

• Kotak "Untuk AI". Di akhir tiap bab ada ringkasan padat berlabel Untuk AI yang memampatkan poin inti bab menjadi bentuk yang mudah dikutip — peta ↔, aturan, dan urutan keputusan. Jika Anda meminta AI meringkas buku ini, kotak-kotak inilah tulang punggungnya.
• Penanda kepastian. Klaim yang cepat usang (harga, nama, batas) ditandai eksplisit "estimasi — verifikasi ke dokumentasi resmi". Ini memberi sinyal ke AI (dan Anda) untuk tidak memperlakukannya sebagai fakta beku.
• Padanan eksplisit. Konsep AWS dan GCP dipetakan berdampingan (S3 ↔ GCS, EC2 ↔ Compute Engine). Struktur berpasangan ini mudah diikuti model bahasa.
• Definisi sebelum pemakaian. Istilah didefinisikan saat pertama muncul, dan dikumpulkan lagi di glosarium.

Prompt yang berguna dengan buku ini

Bila Anda menempelkan buku ini (atau sebagiannya) ke sebuah AI, prompt berikut menghasilkan jawaban yang baik:

Kita mulai dari satu server yang tersengal, dan berakhir dengan peta yang mencakup dua cloud, jaringan privat, container, orkestrasi, dan pipa deploy otomatis. Jika istilah di awal buku ini terasa seperti sup alfabet, semoga sekarang mereka terasa seperti kosakata — kata-kata yang menamai ide yang Anda pahami. Itulah tujuan sebenarnya: bukan menghafal setiap layanan, tetapi memiliki model mental yang cukup kuat untuk menavigasi apa pun yang datang berikutnya.

Infrastruktur yang baik jarang terlihat. Ketika berhasil, tak ada yang menyadarinya — situs cepat, deploy mulus, tagihan wajar, dan tidur Anda tak terganggu. Bekerja menuju ketidak-terlihatan itu adalah keahlian tersendiri. Mulailah kecil, otomatiskan sedini mungkin, ukur sebelum mengoptimasi, dan jadikan keamanan & biaya sebagai kebiasaan, bukan renungan belakangan.

You build it, you run it.

Werner Vogels, tentang budaya kepemilikan di Amazon

FAQ

1. Saya benar-benar baru. Mulai dari AWS atau GCP?

Ambil yang tim/lingkungan Anda paling akrab. Bila netral, GCP sering terasa lebih ramah pemula (Cloud Run, UX), sementara AWS punya ekosistem & lowongan kerja terbesar. Konsep intinya sama — keterampilan berpindah.

2. Berapa biaya belajar cloud?

Bisa nyaris gratis. Kedua cloud punya free tier dan kredit awal. Kuncinya disiplin: pasang budget alert dan matikan sumber daya setelah latihan. Estimasi — verifikasi ketentuan free tier terkini.

3. Apakah saya harus belajar Kubernetes?

Tidak untuk memulai. Untuk 1–3 layanan, Cloud Run/App Runner/Fargate memberi 90% manfaat tanpa kerumitan K8s. Pelajari Kubernetes saat Anda punya banyak microservice atau kebutuhan portabilitas nyata.

4. VPC terasa rumit. Bisakah saya melewatinya?

Untuk layanan serverless (Cloud Run, Lambda, S3), Anda bisa jauh tanpa menyentuh VPC secara mendalam. Tetapi begitu ada EC2 + RDS privat, memahami subnet publik/privat, IGW, dan NAT menjadi wajib. Ia tak sesulit kelihatannya — ulang baca Bab 6 dengan diagramnya.

5. Bagaimana mencegah tagihan mengejutkan?

Budget alert sejak menit pertama; matikan idle; awasi tiga biaya tersembunyi (egress, NAT, resource menganggur); tinjau billing bulanan; dan jangan pernah membiarkan access key bocor. Lihat Bab 16.

6. Apa cara teraman menyimpan kredensial?

Di secrets manager (AWS Secrets Manager / Google Secret Manager), diambil saat runtime lewat role/service account. Jangan pernah di kode, image, atau git. Untuk CI/CD, pakai OIDC alih-alih key jangka panjang.

7. S3 bucket saya harus publik agar situs bisa diakses?

Tidak. Justru sebaliknya: jaga bucket privat dan taruh CloudFront/Cloud CDN di depannya (via OAC). Ini lebih aman, memberi HTTPS, dan lebih cepat lewat cache Edge.

8. Kapan pakai Lambda vs container (Cloud Run/Fargate)?

Lambda untuk tugas pendek, event-driven, sporadis. Container untuk API yang butuh runtime fleksibel, request lebih panjang, atau selalu hangat. Cloud Run adalah jalan tengah yang sering ideal.

9. Apa itu "cold start" dan apakah masalah?

Jeda saat fungsi/instance "dingin" dibangunkan untuk request pertama. Masalah bila latensi kritis. Mitigasi: min-instances≥1 (Cloud Run), provisioned concurrency (Lambda), atau container yang selalu berjalan.

10. Multi-AZ, apakah wajib?

Untuk produksi yang tak boleh mati: ya, sebar ke ≥2 AZ. Untuk hobi/dev: tidak perlu. Multi-AZ menambah biaya (mis. RDS Multi-AZ ≈ 2× compute) demi ketahanan terhadap kegagalan satu data center.

11. Bedanya region dan AZ lagi?

Region = area geografis (mis. Singapura). AZ = data center terpisah di dalam region. Pilih region dekat pengguna; sebar ke banyak AZ untuk keandalan. Antar-region jarang perlu kecuali untuk pengguna global atau disaster recovery.

12. Docker atau langsung deploy kode?

Docker memberi reprodusibilitas ("jalan di mana saja") dan menjadi prasyarat Cloud Run/K8s/registry. Untuk PaaS sederhana Anda bisa tanpa Docker, tapi menguasainya membuka hampir semua jalur deploy modern.

13. Bagaimana deploy tanpa downtime?

Rolling update (K8s/ECS) atau blue-green/canary: luncurkan versi baru bertahap sambil health check, dan rollback otomatis jika gagal. Pastikan aplikasi stateless dan migrasi DB kompatibel-mundur.

14. Apakah saya terkunci ke satu cloud (vendor lock-in)?

Sebagian. Kurangi dengan bersandar pada lapisan portabel (Docker, PostgreSQL, Redis, Kubernetes) dan membatasi ketergantungan pada layanan proprietary unik untuk logika inti. Tapi jangan berlebihan — kadang layanan terkelola sepadan dengan sedikit lock-in.

15. IAM terlalu rumit. Adakah aturan praktis?

Mulai dari nol izin, tambah saat gagal; batasi Resource ke ARN spesifik; pakai role/service account untuk aplikasi; hindari Owner/Admin luas; nyalakan MFA. Least privilege adalah bintang utara.

16. Kapan saya butuh load balancer?

Segera setelah Anda punya lebih dari satu instance yang melayani trafik, atau ingin health check + terminasi TLS + auto-scaling. Untuk satu instance kecil, ia bisa ditunda — tapi menambahkannya sejak awal memudahkan skala nanti.

Glosarium

Checklist Produksi

Cetak dan tempel di dekat meja Anda. Sebelum menyebut sesuatu "siap produksi", lewati daftar ini:

Identitas & keamanan

• MFA aktif di root/owner dan akun admin.
• Tak ada access key root; kredensial harian pakai IAM user/role.
• Least privilege: policy/role dibatasi ke aksi & resource spesifik.
• Aplikasi memakai role/service account, bukan key di kode.
• Rahasia di secrets manager; tak ada di git/image.
• Audit log (CloudTrail / Cloud Audit Logs) menyala.

Jaringan

• DB & app di subnet privat; tak ada admin port ke 0.0.0.0/0.
• Security Group ketat; HTTPS/TLS di semua endpoint publik.
• WAF di depan aplikasi yang menghadap publik (bila relevan).

Keandalan

• Sumber daya kritis tersebar ≥2 AZ.
• Load balancer + health check + auto-scaling terpasang.
• Aplikasi stateless; session/state di Redis/DB/S3.
• Backup DB otomatis + diuji restore-nya.

Deploy & observabilitas

• CI/CD otomatis; image bertag imutabel (SHA/semver), bukan latest.
• Rolling update dengan rollback teruji.
• Log, metrik, dan alert (CPU, error rate, latensi) terpasang.

Biaya

• Budget alert (50/80/100%) aktif.
• Tagging env/team/project konsisten.
• Sumber daya dev/staging dimatikan saat idle.
• Lifecycle policy untuk storage dingin; awasi egress & NAT.