VPC Networking untuk Developer: Panduan Praktis Isolasi Jaringan Cloud

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.

Apa Sebenarnya VPC

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 Jaringan Anda

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: Model Default-Deny

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.

NAT Gateway: Internet Keluar untuk Resource Privat

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]          │                     │
│  └──────────────────────────────┘                     │
└───────────────────────────────────────────────────────┘

VPC Peering dan Private Service Access

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.

Internal DNS dan Service Discovery

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-ranges

Bastion Host dan Akses SSH yang Aman

Dalam 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.

Pendapat Saya: Mulailah dengan Diagram

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.

Artikel Terkait

• Optimasi Biaya Cloud: Mengurangi Pengeluaran Egress dan Jaringan
• HashiCorp Vault: Manajemen Secrets dalam VPC Privat