Menghubungkan Dua VPC dengan VPC Peering: Panduan Lengkap Route Table

Saat arsitektur tumbuh dan tim mulai memisahkan workload ke VPC berbeda — misalnya VPC untuk aplikasi dan VPC terpisah untuk database atau layanan internal — pertanyaan yang muncul adalah: bagaimana dua VPC ini bisa saling bicara menggunakan private IP tanpa traffic keluar ke internet publik? VPC Peering adalah jawaban standarnya, tapi banyak engineer yang sudah berhasil membuat peering connection aktif lalu bingung kenapa instance masih tidak bisa ping satu sama lain. Jawabannya hampir selalu ada di route table yang belum diupdate.

TL;DR — Ringkasan Cepat VPC Peering

LangkahAksiCatatan
1Buat VPC Peering ConnectionRequester kirim request, Accepter harus accept
2Accept Peering RequestWajib dilakukan meski same account
3Update Route Table VPC-ATambah route ke CIDR VPC-B via peering connection
4Update Route Table VPC-BTambah route ke CIDR VPC-A via peering connection
5Update Security GroupIzinkan traffic dari CIDR VPC lawan
6Verifikasi konektivitasTest dengan ping atau curl antar instance

Cara Kerja VPC Peering

VPC Peering membuat koneksi jaringan privat antara dua VPC sehingga instance di kedua VPC dapat berkomunikasi seolah-olah berada di jaringan yang sama. Traffic tidak pernah melewati internet publik, tidak melalui gateway, dan tidak melalui VPN — semuanya tetap di dalam infrastruktur AWS.

Yang perlu dipahami: peering connection itu sendiri hanya membuka jalur potensial. Tanpa route table yang mengarahkan traffic ke peering connection tersebut, paket tidak akan tahu harus lewat mana. Ini yang paling sering terlewat.

Syarat teknis yang harus dipenuhi sebelum memulai:

  • CIDR block kedua VPC tidak boleh overlap. Jika VPC-A menggunakan 10.0.0.0/16 dan VPC-B juga 10.0.0.0/16, peering tidak bisa dibuat.
  • VPC Peering bersifat non-transitive — jika VPC-A peering dengan VPC-B, dan VPC-B peering dengan VPC-C, bukan berarti VPC-A bisa langsung bicara ke VPC-C.
  • DNS resolution antar VPC memerlukan konfigurasi tambahan (DNS resolution attribute).
graph LR VPCA["VPC-A 10.0.0.0/16"] -- "Peering Connection pcx-xxxxxxxxx" --> VPCB["VPC-B 10.1.0.0/16"] VPCA --> RTA["Route Table VPC-A Dest: 10.1.0.0/16 Target: pcx-xxxxxxxxx"] VPCB --> RTB["Route Table VPC-B Dest: 10.0.0.0/16 Target: pcx-xxxxxxxxx"] RTA --> SGA["Security Group VPC-A Allow inbound from 10.1.0.0/16"] RTB --> SGB["Security Group VPC-B Allow inbound from 10.0.0.0/16"]
  1. VPC-A (10.0.0.0/16) dan VPC-B (10.1.0.0/16) adalah dua jaringan terpisah di AWS.
  2. Peering Connection adalah jalur logis yang dibuat antara keduanya — statusnya harus active.
  3. Route table di masing-masing VPC harus secara eksplisit mengarahkan traffic ke CIDR lawan melalui peering connection.
  4. Security Group di masing-masing instance harus mengizinkan inbound traffic dari CIDR VPC lawan.

Langkah 1: Buat VPC Peering Connection

Pertama, identifikasi VPC ID kedua VPC yang akan dihubungkan. Dalam contoh ini kita gunakan VPC-A sebagai requester dan VPC-B sebagai accepter, keduanya di account dan region yang sama.

# Ambil VPC ID yang tersedia di region
aws ec2 describe-vpcs \
  --query 'Vpcs[*].{VpcId:VpcId,CIDR:CidrBlock,Name:Tags[?Key==`Name`].Value|[0]}' \
  --output table \
  --region us-east-1

Setelah mengetahui VPC ID keduanya, buat peering connection:

# Buat VPC Peering Connection
# Ganti vpc-aaaaaaaa dengan VPC-A ID dan vpc-bbbbbbbb dengan VPC-B ID
aws ec2 create-vpc-peering-connection \
  --vpc-id vpc-aaaaaaaa \
  --peer-vpc-id vpc-bbbbbbbb \
  --region us-east-1

Output akan menyertakan VpcPeeringConnectionId dengan format pcx-xxxxxxxxxxxxxxxxx. Catat ID ini — dibutuhkan di semua langkah berikutnya.

Langkah 2: Accept Peering Request

Meski kedua VPC berada di account yang sama, AWS tetap mengharuskan peering request di-accept secara eksplisit. Status awal adalah pending-acceptance dan akan expired jika tidak di-accept dalam 7 hari.

# Accept peering connection
# Ganti pcx-xxxxxxxxxxxxxxxxx dengan Peering Connection ID dari langkah sebelumnya
aws ec2 accept-vpc-peering-connection \
  --vpc-peering-connection-id pcx-xxxxxxxxxxxxxxxxx \
  --region us-east-1

Verifikasi status sudah berubah menjadi active:

# Verifikasi status peering connection
aws ec2 describe-vpc-peering-connections \
  --vpc-peering-connection-ids pcx-xxxxxxxxxxxxxxxxx \
  --query 'VpcPeeringConnections[0].Status.Code' \
  --output text \
  --region us-east-1

Output yang diharapkan: active. Jika masih pending-acceptance, ulangi langkah accept.

Langkah 3: Update Route Table — Ini Bagian yang Sering Terlewat

Peering connection sudah active tapi instance masih tidak bisa saling reach? Hampir pasti route table belum diupdate. Ini harus dilakukan di kedua sisi — route table VPC-A perlu tahu cara mencapai CIDR VPC-B, dan sebaliknya.

Bayangkan peering connection seperti terowongan yang sudah dibangun antara dua kota. Terowongan sudah ada, tapi kalau peta jalan (route table) di masing-masing kota tidak mencantumkan terowongan itu sebagai rute, pengemudi tidak akan tahu harus lewat mana.

Pertama, temukan Route Table ID yang digunakan subnet di masing-masing VPC:

# Lihat route table yang terkait dengan subnet di VPC-A
aws ec2 describe-route-tables \
  --filters Name=vpc-id,Values=vpc-aaaaaaaa \
  --query 'RouteTables[*].{RouteTableId:RouteTableId,SubnetAssociations:Associations[*].SubnetId}' \
  --output table \
  --region us-east-1
# Lihat route table yang terkait dengan subnet di VPC-B
aws ec2 describe-route-tables \
  --filters Name=vpc-id,Values=vpc-bbbbbbbb \
  --query 'RouteTables[*].{RouteTableId:RouteTableId,SubnetAssociations:Associations[*].SubnetId}' \
  --output table \
  --region us-east-1

Tambahkan route di route table VPC-A yang mengarahkan traffic ke CIDR VPC-B melalui peering connection:

# Tambah route di VPC-A: traffic ke 10.1.0.0/16 (CIDR VPC-B) lewat peering connection
# Ganti rtb-aaaaaaaa dengan Route Table ID VPC-A
# Ganti 10.1.0.0/16 dengan CIDR block VPC-B yang sebenarnya
aws ec2 create-route \
  --route-table-id rtb-aaaaaaaa \
  --destination-cidr-block 10.1.0.0/16 \
  --vpc-peering-connection-id pcx-xxxxxxxxxxxxxxxxx \
  --region us-east-1
# Tambah route di VPC-B: traffic ke 10.0.0.0/16 (CIDR VPC-A) lewat peering connection
# Ganti rtb-bbbbbbbb dengan Route Table ID VPC-B
# Ganti 10.0.0.0/16 dengan CIDR block VPC-A yang sebenarnya
aws ec2 create-route \
  --route-table-id rtb-bbbbbbbb \
  --destination-cidr-block 10.0.0.0/16 \
  --vpc-peering-connection-id pcx-xxxxxxxxxxxxxxxxx \
  --region us-east-1

Verifikasi route sudah masuk dengan benar:

# Verifikasi route di VPC-A
aws ec2 describe-route-tables \
  --route-table-ids rtb-aaaaaaaa \
  --query 'RouteTables[0].Routes[?VpcPeeringConnectionId!=null]' \
  --output table \
  --region us-east-1

Langkah 4: Update Security Group

Route table sudah benar tapi koneksi masih ditolak? Security Group adalah layer berikutnya. Instance di VPC-B perlu mengizinkan inbound traffic dari CIDR VPC-A (dan sebaliknya). Banyak yang lupa bahwa Security Group bersifat stateful — cukup izinkan inbound, outbound response otomatis diizinkan.

# Izinkan ICMP (ping) dari VPC-A ke instance di VPC-B
# Ganti sg-bbbbbbbb dengan Security Group ID instance di VPC-B
# Ganti 10.0.0.0/16 dengan CIDR VPC-A
aws ec2 authorize-security-group-ingress \
  --group-id sg-bbbbbbbb \
  --protocol icmp \
  --port -1 \
  --cidr 10.0.0.0/16 \
  --region us-east-1
# Izinkan ICMP (ping) dari VPC-B ke instance di VPC-A
# Ganti sg-aaaaaaaa dengan Security Group ID instance di VPC-A
# Ganti 10.1.0.0/16 dengan CIDR VPC-B
aws ec2 authorize-security-group-ingress \
  --group-id sg-aaaaaaaa \
  --protocol icmp \
  --port -1 \
  --cidr 10.1.0.0/16 \
  --region us-east-1

Untuk mengizinkan traffic TCP spesifik (misalnya port 443 untuk HTTPS atau port 5432 untuk PostgreSQL), ganti --protocol icmp --port -1 dengan --protocol tcp --port 443 atau port yang relevan.

Langkah 5: Verifikasi Konektivitas End-to-End

Setelah semua konfigurasi selesai, verifikasi dari dalam instance menggunakan private IP. Pastikan instance memiliki akses SSH atau Systems Manager Session Manager untuk masuk ke dalamnya.

# Dari instance di VPC-A, ping private IP instance di VPC-B
# Ganti 10.1.x.x dengan private IP instance di VPC-B
ping 10.1.x.x -c 4

Jika ping berhasil, routing dan security group sudah benar. Untuk memverifikasi konektivitas aplikasi:

# Test koneksi TCP ke port tertentu (contoh: port 80)
# Ganti 10.1.x.x dengan private IP instance di VPC-B
curl -v --connect-timeout 5 http://10.1.x.x:80

Pola Kesalahan Umum: Peering Active tapi Tidak Bisa Connect

Ini skenario yang paling sering terjadi di production: engineer membuat peering connection, status sudah active, tapi ping dari satu instance ke instance lain tetap timeout. Asumsi pertama biasanya 'mungkin peering-nya gagal' atau 'mungkin ada masalah di AWS'. Padahal hampir selalu bukan itu masalahnya.

Urutan investigasi yang tepat:

flowchart TD Start(["Instance tidak bisa connect via peering"]) --> CheckPeering{"Status peering connection?"} CheckPeering -- "pending / expired" --> FixPeering["Accept atau buat ulang peering connection"] CheckPeering -- "active" --> CheckRouteA{"Route ke CIDR lawan ada di route table source?"} CheckRouteA -- "Tidak ada" --> AddRouteA["Tambah route di route table VPC source"] CheckRouteA -- "Ada" --> CheckRouteB{"Route ke CIDR lawan ada di route table dest?"} CheckRouteB -- "Tidak ada" --> AddRouteB["Tambah route di route table VPC dest"] CheckRouteB -- "Ada" --> CheckSG{"Security Group dest izinkan CIDR source?"} CheckSG -- "Tidak" --> AddSGRule["Tambah inbound rule di Security Group dest"] CheckSG -- "Ya" --> CheckNACL{"Network ACL blokir traffic?"} CheckNACL -- "Ya" --> FixNACL["Update Network ACL inbound dan outbound"] CheckNACL -- "Tidak" --> CheckSubnet["Verifikasi subnet pakai route table yang benar"] FixPeering --> Done(["Koneksi berhasil"]) AddRouteA --> Done AddRouteB --> Done AddSGRule --> Done FixNACL --> Done CheckSubnet --> Done
  1. Cek status peering connection — harus active, bukan pending-acceptance atau expired.
  2. Cek route table di subnet source — apakah ada route ke CIDR destination via peering connection ID yang benar?
  3. Cek route table di subnet destination — route harus ada di kedua sisi.
  4. Cek Security Group instance destination — apakah CIDR source diizinkan untuk protocol dan port yang digunakan?
  5. Cek Network ACL — jika digunakan, Network ACL bersifat stateless sehingga inbound DAN outbound harus diizinkan secara eksplisit.

Satu hal yang sering diabaikan: jika subnet menggunakan custom route table (bukan main route table VPC), route harus ditambahkan ke route table yang benar-benar ter-associate dengan subnet tersebut. Menambahkan route ke main route table tidak akan berpengaruh jika subnet sudah di-associate ke custom route table.

Verifikasi asosiasi subnet ke route table:

# Cek route table mana yang digunakan oleh subnet tertentu
# Ganti subnet-xxxxxxxx dengan Subnet ID yang digunakan instance
aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-xxxxxxxx \
  --query 'RouteTables[*].{RouteTableId:RouteTableId,Routes:Routes[*].{Dest:DestinationCidrBlock,Target:GatewayId,PeeringTarget:VpcPeeringConnectionId}}' \
  --output json \
  --region us-east-1

Mengaktifkan DNS Resolution Antar VPC (Opsional tapi Sering Dibutuhkan)

Secara default, instance di VPC-A tidak bisa resolve DNS hostname private instance di VPC-B melalui peering connection. Jika aplikasi menggunakan hostname (bukan IP langsung), DNS resolution attribute perlu diaktifkan di kedua sisi peering connection.

# Aktifkan DNS resolution dari VPC-A ke VPC-B
# (modifikasi sisi requester)
aws ec2 modify-vpc-peering-connection-options \
  --vpc-peering-connection-id pcx-xxxxxxxxxxxxxxxxx \
  --requester-peering-connection-options AllowDnsResolutionFromRemoteVpc=true \
  --region us-east-1
# Aktifkan DNS resolution dari VPC-B ke VPC-A
# (modifikasi sisi accepter)
aws ec2 modify-vpc-peering-connection-options \
  --vpc-peering-connection-id pcx-xxxxxxxxxxxxxxxxx \
  --accepter-peering-connection-options AllowDnsResolutionFromRemoteVpc=true \
  --region us-east-1

Selain itu, pastikan opsi enableDnsHostnames dan enableDnsSupport diaktifkan di kedua VPC:

# Aktifkan DNS hostnames di VPC-A
aws ec2 modify-vpc-attribute \
  --vpc-id vpc-aaaaaaaa \
  --enable-dns-hostnames \
  --region us-east-1

# Aktifkan DNS support di VPC-A
aws ec2 modify-vpc-attribute \
  --vpc-id vpc-aaaaaaaa \
  --enable-dns-support \
  --region us-east-1

IAM Permissions yang Dibutuhkan

Untuk menjalankan semua perintah di atas, IAM principal membutuhkan permissions berikut. Terapkan principle of least privilege — batasi ke resource yang relevan jika memungkinkan.

🔽 Klik untuk melihat IAM Policy 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VpcPeeringSetup",
      "Effect": "Allow",
      "Action": [
        "ec2:CreateVpcPeeringConnection",
        "ec2:AcceptVpcPeeringConnection",
        "ec2:DescribeVpcPeeringConnections",
        "ec2:ModifyVpcPeeringConnectionOptions",
        "ec2:DescribeVpcs",
        "ec2:DescribeRouteTables",
        "ec2:CreateRoute",
        "ec2:DeleteRoute",
        "ec2:DescribeSubnets",
        "ec2:AuthorizeSecurityGroupIngress",
        "ec2:DescribeSecurityGroups",
        "ec2:ModifyVpcAttribute"
      ],
      "Resource": "*"
    }
  ]
}

Catatan: Beberapa aksi seperti DescribeVpcs dan DescribeRouteTables memerlukan "Resource": "*" karena tidak mendukung resource-level permission. Verifikasi di AWS Service Authorization Reference sebelum membatasi lebih lanjut.

Wrap-Up dan Langkah Selanjutnya untuk VPC Peering

VPC Peering untuk dua VPC di account dan region yang sama adalah setup yang relatif straightforward, tapi tiga layer harus benar semua: peering connection harus active, route table di kedua sisi harus punya route yang tepat, dan security group harus mengizinkan traffic. Melewatkan salah satu dari ketiganya adalah alasan paling umum koneksi tidak berhasil.

Untuk arsitektur yang lebih kompleks — misalnya menghubungkan lebih dari dua VPC, VPC lintas account, atau lintas region — pertimbangkan AWS Transit Gateway yang dirancang untuk mengelola konektivitas mesh antar banyak VPC tanpa harus membuat peering connection satu per satu. VPC Peering tidak mendukung routing transitive, sehingga untuk topologi hub-and-spoke atau full mesh dengan banyak VPC, Transit Gateway adalah pilihan yang lebih scalable.

Glossary

IstilahPenjelasan
VPC Peering ConnectionKoneksi jaringan privat antara dua VPC yang memungkinkan routing traffic menggunakan private IP tanpa melalui internet publik.
Route TableTabel aturan routing yang menentukan ke mana traffic diarahkan berdasarkan destination CIDR block.
CIDR BlockNotasi untuk mendefinisikan rentang IP address, misalnya 10.0.0.0/16 mencakup IP dari 10.0.0.0 hingga 10.0.255.255.
Non-transitive RoutingSifat VPC Peering di mana koneksi A-B dan B-C tidak otomatis membuat A bisa berkomunikasi dengan C.
Security GroupFirewall stateful di level instance yang mengontrol inbound dan outbound traffic berdasarkan protocol, port, dan source/destination.

Related Posts

Komentar

Posting Komentar

Postingan populer dari blog ini

EC2 Tidak Bisa Akses Internet di Custom VPC: Cara Pasang Internet Gateway dan Update Route Table

Kamu baru saja membuat custom VPC, meluncurkan EC2 instance di public subnet, lalu mencoba ping google.com — dan tidak ada respons sama sekali. Ini adalah salah satu jebakan paling umum saat pertama kali bekerja dengan EC2 no internet access di custom VPC , dan penyebabnya hampir selalu kombinasi dari tiga hal: tidak ada Internet Gateway, route table yang belum diupdate, atau Security Group yang memblokir traffic. TL;DR: Checklist EC2 Tidak Bisa Internet di Custom VPC Komponen Yang Harus Dicek Kondisi Benar Internet Gateway Sudah dibuat dan di-attach ke VPC State: attached Route Table Ada route 0.0.0.0/0 ke IGW Target: igw-xxxxxxxx Subnet Association Public subnet terhubung ke route table yang benar Subnet ID muncul di associations Security Group Inbound HTTP/HTTPS/ICMP diizinkan Rule eksplisit untuk port 80, 443, atau ICMP Public IP Instance punya public IP atau Elastic IP PublicIpAddress tidak n...
Baca selengkapnya