VPC networking adalah bagian dari infrastruktur cloud yang kebanyakan developer hindari hingga sesuatu rusak — layanan tidak bisa menjangkau database, container tidak bisa menarik dari registry, atau dua layanan di VPC berbeda perlu berkomunikasi. Saya menghindari pengetahuan VPC yang mendalam selama tahun pertama mengelola infrastruktur cloud di Commsult Indonesia, mengandalkan pengaturan default dan berharap semuanya berfungsi. Kemudian saya harus men-debug masalah koneksi GCP Cloud SQL yang ternyata adalah masalah konfigurasi Private Service Access — sesuatu yang belum pernah saya dengar. Setelah itu, saya menghabiskan dua minggu secara sistematis mempelajari jaringan cloud. Panduan ini adalah apa yang saya harap sudah saya miliki saat itu.
Virtual Private Cloud (VPC) adalah jaringan yang terisolasi secara logis dalam infrastruktur cloud provider. Tidak seperti jaringan fisik, VPC didefinisikan oleh perangkat lunak — topologi, routing, dan aturan firewallnya semuanya adalah konfigurasi, bukan hardware. Di GCP, VPC bersifat global secara default: satu VPC GCP dapat mencakup semua region, dengan subnet di berbagai region yang semuanya merupakan bagian dari jaringan yang sama. Di AWS dan DigitalOcean, VPC bersifat regional — Anda membuat VPC terpisah per region. Perbedaan arsitektur ini penting: di GCP, VM di us-central1 dapat berkomunikasi dengan VM di asia-southeast1 dalam VPC yang sama tanpa konfigurasi tambahan apa pun (tergantung aturan firewall).
Subnet membagi ruang alamat IP VPC menjadi blok-blok yang lebih kecil, masing-masing terkait dengan zone atau region tertentu. Subnet di 10.0.1.0/24 menyediakan 254 alamat IP yang dapat digunakan untuk resource yang di-deploy ke dalamnya. Subnet publik melakukan routing ke internet melalui internet gateway — resource di subnet publik dapat menerima traffic masuk dari internet jika aturan firewall mengizinkan. Subnet privat tidak memiliki internet gateway langsung — resource hanya dapat menjangkau internet melalui NAT gateway, dan tidak dapat menerima koneksi masuk yang tidak diminta dari internet. Praktik terbaik: deploy server aplikasi dan database di subnet privat, dan tempatkan hanya load balancer dan bastion host di subnet publik.
Aturan firewall cloud beroperasi pada model default-deny untuk traffic ingress (masuk) — kecuali aturan secara eksplisit mengizinkan traffic, traffic tersebut diblokir. Traffic egress (keluar) diizinkan secara default dalam sebagian besar konfigurasi. GCP menggunakan aturan firewall ingress/egress dengan nilai prioritas (nomor prioritas lebih rendah = dievaluasi lebih dulu). DigitalOcean menggunakan Cloud Firewall dengan aturan allow eksplisit. Disiplin kritis: jangan pernah membuat aturan firewall yang mengizinkan semua traffic masuk (0.0.0.0/0) kecuali untuk pengecualian yang dibenarkan secara spesifik seperti load balancer yang menghadap publik di port 80 dan 443. Port database tidak boleh pernah diekspos ke 0.0.0.0/0.
Dari pengalaman saya: gunakan network tag GCP untuk aturan firewall daripada alamat IP VM individual. Beri tag VM web server Anda dengan tag 'web-server' dan VM database Anda dengan tag 'database'. Tulis aturan firewall yang mengizinkan traffic dari tag 'web-server' ke tag 'database' di port 5432. Ketika Anda menambahkan web server baru, menerapkan tag 'web-server' secara otomatis memberikan mereka akses database — tidak perlu pengeditan aturan firewall. Ini dapat diskalakan ke puluhan VM tanpa manajemen IP manual dan jauh lebih mudah dibaca daripada aturan berbasis IP.
Resource di subnet privat tidak dapat memulai koneksi ke internet secara default. Tetapi mereka sering membutuhkannya — untuk mengunduh paket, memanggil API eksternal, atau menarik image container. NAT (Network Address Translation) gateway berada di subnet publik dan memproksi koneksi internet keluar untuk resource subnet privat. Traffic resource privat tampak berasal dari IP publik NAT gateway. Cloud NAT GCP adalah layanan terkelola yang sangat tersedia — tidak ada VM yang perlu dikelola. DigitalOcean memerlukan Droplet yang dikonfigurasi sebagai NAT gateway (atau menggunakan add-on NAT terkelola mereka). Selalu gunakan NAT gateway untuk resource subnet privat daripada memberi mereka IP publik.
┌───────────────────────────────────────────────────────┐
│ VPC Network Architecture │
├───────────────────────────────────────────────────────┤
│ │
│ Internet │
│ │ │
│ ┌───▼──────────────────────────┐ │
│ │ Public Subnet 10.0.1.0/24 │ │
│ │ [Load Balancer] [Bastion] │ │
│ └───┬──────────────────────────┘ │
│ │ NAT Gateway │
│ ┌───▼──────────────────────────┐ │
│ │ Private Subnet 10.0.2.0/24 │ │
│ │ [App Servers] [Workers] │ │
│ └───┬──────────────────────────┘ │
│ │ │
│ ┌───▼──────────────────────────┐ │
│ │ Private Subnet 10.0.3.0/24 │ │
│ │ [Database] [Redis] │ │
│ └──────────────────────────────┘ │
└───────────────────────────────────────────────────────┘Ketika dua VPC perlu berkomunikasi — misalnya, VPC aplikasi utama dan VPC layanan, atau VPC Anda dan VPC layanan terkelola Google — Anda menggunakan VPC peering. VPC peering membuat koneksi langsung dan privat antara dua VPC tanpa traffic melewati internet publik. Di GCP, Private Service Access adalah jenis peering VPC tertentu yang menghubungkan VPC Anda ke jaringan produsen layanan Google — diperlukan untuk IP privat Cloud SQL, Memorystore Redis, dan layanan terkelola lainnya. Menyiapkan Private Service Access memerlukan pembuatan rentang layanan privat di VPC Anda dan mengaktifkan API servicenetworking.googleapis.com.
Saya menghabiskan tiga jam men-debug setup peering VPC yang gagal antara VPC klien (10.0.0.0/16) dan VPC manajemen kami (10.0.0.0/24). Pembuatan peering berhasil di konsol tetapi traffic tidak akan mengalir — route tidak diimpor. Penyebabnya: kedua VPC menggunakan rentang IP yang tumpang tindih, dan peering VPC GCP memerlukan rentang CIDR yang tidak tumpang tindih. Perbaikannya memerlukan penomoran ulang satu VPC, yang berarti membuat ulang subnet dan memigrasikan VM. Pelajaran: rencanakan skema pengalamatan IP Anda sebelum menyediakan apa pun. Gunakan rentang yang tidak tumpang tindih di semua VPC yang mungkin perlu Anda peer: 10.0.0.0/16 untuk VPC A, 10.1.0.0/16 untuk VPC B, 10.2.0.0/16 untuk VPC C.
Dalam VPC GCP, semua instance VM mendapatkan nama DNS internal berdasarkan nama instance dan zone mereka: my-instance.asia-southeast1-b.c.my-project.internal. Layanan dapat berkomunikasi melalui nama DNS ini daripada alamat IP yang dikodekan secara keras. Untuk workload Kubernetes di GKE, Kubernetes DNS (CoreDNS) menyediakan DNS level layanan dalam cluster. Untuk skenario service mesh di mana Anda membutuhkan kontrol traffic yang halus, Istio atau Anthos Service Mesh GCP menambahkan model sidecar proxy di atas VPC networking. Untuk sebagian besar aplikasi, internal DNS dan network tag VPC-native sudah cukup tanpa service mesh penuh.
# Create VPC with non-overlapping CIDR ranges
gcloud compute networks create my-vpc --subnet-mode=custom --bgp-routing-mode=regional
# Create private subnet for app servers
gcloud compute networks subnets create app-subnet --network=my-vpc --region=asia-southeast1 --range=10.0.2.0/24 --enable-private-ip-google-access
# Firewall rule using network tags (not IP addresses)
gcloud compute firewall-rules create allow-web-to-db --network=my-vpc --direction=INGRESS --action=ALLOW --rules=tcp:5432 --source-tags=web-server --target-tags=database
# Enable Cloud NAT for private subnet outbound internet access
gcloud compute routers create my-router --network=my-vpc --region=asia-southeast1
gcloud compute routers nats create my-nat --router=my-router --region=asia-southeast1 --auto-allocate-nat-external-ips --nat-all-subnet-ip-rangesDalam VPC yang dikonfigurasi dengan benar, server database dan backend aplikasi berada di subnet privat tanpa IP publik. Akses SSH untuk administrasi harus melalui bastion host (jump server) — VM kecil di subnet publik dengan IP publik, diperkuat dengan fail2ban, SSH dibatasi ke IP tertentu, dan MFA diaktifkan. Bastion adalah satu-satunya titik masuk ke jaringan privat. Di GCP, alternatif modern yang lebih disukai adalah tunnel Identity-Aware Proxy (IAP) — Anda SSH ke VM privat melalui IAP Google tanpa IP publik apa pun pada VM target atau bastion sama sekali. Tunnel IAP diautentikasi melalui kredensial akun Google dan tidak memerlukan pengecualian aturan firewall untuk SSH.
Sebelum membuat resource jaringan apa pun, buat diagram. Subnet mana yang publik? Mana yang privat? Layanan mana yang membutuhkan akses internet? Layanan mana yang perlu berkomunikasi satu sama lain? Layanan eksternal mana yang perlu menjangkau VPC Anda? Langkah desain 30 menit ini mencegah masalah CIDR yang tumpang tindih, sprawl aturan firewall, dan sesi debugging 'mengapa layanan Cloud Run saya tidak bisa menjangkau Cloud SQL' yang memakan berjam-jam. Saya kini menggunakan draw.io untuk memelihara diagram arsitektur VPC terkini untuk setiap proyek GCP yang kami kelola di Commsult Indonesia — ini adalah dokumen pertama yang saya lihat saat men-debug masalah jaringan.
Sumber & Bacaan Lanjutan