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 null

Bagaimana Custom VPC dan Internet Gateway Bekerja

Saat kamu membuat VPC baru secara manual, AWS tidak otomatis menyertakan Internet Gateway. Berbeda dengan default VPC yang sudah dikonfigurasi lengkap, custom VPC benar-benar kosong dari sisi konektivitas internet. Internet Gateway (IGW) adalah komponen yang menjembatani traffic antara instance di VPC dan internet publik — tanpa IGW, paket tidak punya jalur keluar sama sekali.

Tapi IGW saja tidak cukup. Route table di subnet harus punya entri eksplisit yang mengarahkan traffic 0.0.0.0/0 ke IGW tersebut. Kalau route ini tidak ada, instance tetap tidak bisa menjangkau internet meskipun IGW sudah terpasang. Inilah yang sering terlewat — IGW sudah ada, tapi route table-nya lupa diupdate.

graph LR EC2["EC2 Instance
Public Subnet"] --> SG["Security Group
Outbound Rules"] SG --> RT["Route Table
0.0.0.0/0 → IGW?"] RT -->|"Route tidak ada"| DROP["Paket Di-drop"] RT -->|"Route ada"| IGW["Internet Gateway
State: attached"] IGW --> INET["Internet"]

1. EC2 Instance berada di public subnet dan mencoba mengirim paket ke internet.
2. Route Table diperiksa — jika tidak ada route 0.0.0.0/0 ke IGW, paket di-drop di sini.
3. Internet Gateway menerima traffic dari route table dan meneruskannya ke internet.
4. Security Group mengontrol traffic inbound/outbound di level instance — IGW dan route table tidak bisa menggantikan peran ini.

Langkah 1: Buat dan Attach Internet Gateway ke VPC

Langkah pertama adalah memastikan IGW sudah ada dan terhubung ke VPC yang benar. IGW yang sudah dibuat tapi belum di-attach ke VPC manapun tidak akan berfungsi — statusnya akan detached.

# Buat Internet Gateway baru
aws ec2 create-internet-gateway \
  --query 'InternetGateway.InternetGatewayId' \
  --output text

Catat IGW ID yang dihasilkan (format: igw-xxxxxxxx), lalu attach ke VPC kamu:

# Attach IGW ke VPC
aws ec2 attach-internet-gateway \
  --internet-gateway-id igw-xxxxxxxx \
  --vpc-id vpc-xxxxxxxx

Verifikasi bahwa attachment berhasil. Status yang benar setelah attachment adalah attached, bukan available:

aws ec2 describe-internet-gateways \
  --internet-gateway-ids igw-xxxxxxxx \
  --query 'InternetGateways[0].Attachments'

Output yang diharapkan:

[
    {
        "State": "attached",
        "VpcId": "vpc-xxxxxxxx"
    }
]

Jika State masih detached, periksa apakah --vpc-id yang digunakan sudah benar dan VPC tersebut belum memiliki IGW lain yang terpasang — satu VPC hanya bisa memiliki satu IGW.

Langkah 2: Update Route Table dengan Default Route ke IGW

IGW yang sudah terpasang tidak otomatis membuat traffic mengalir. Route table di subnet harus secara eksplisit mengarahkan traffic 0.0.0.0/0 ke IGW. Ini adalah langkah yang paling sering terlewat oleh engineer yang baru bekerja dengan custom VPC.

Pertama, temukan route table yang terasosiasi dengan public subnet kamu:

aws ec2 describe-route-tables \
  --filters "Name=vpc-id,Values=vpc-xxxxxxxx" \
  --query 'RouteTables[*].{RouteTableId:RouteTableId,Routes:Routes,Associations:Associations}'

Perhatikan output-nya. Jika di bagian Routes hanya ada satu entri untuk local CIDR (10.0.0.0/16 misalnya) dan tidak ada 0.0.0.0/0, itulah masalahnya. Tambahkan route default:

aws ec2 create-route \
  --route-table-id rtb-xxxxxxxx \
  --destination-cidr-block 0.0.0.0/0 \
  --gateway-id igw-xxxxxxxx

Verifikasi route sudah masuk:

aws ec2 describe-route-tables \
  --route-table-ids rtb-xxxxxxxx \
  --query 'RouteTables[0].Routes'

Output yang benar harus menampilkan dua entri: satu untuk local CIDR dan satu untuk 0.0.0.0/0 dengan GatewayId menunjuk ke IGW kamu.

Langkah 3: Pastikan Public Subnet Terasosiasi dengan Route Table yang Benar

Route table yang sudah diupdate tidak akan berpengaruh jika public subnet kamu masih terasosiasi dengan route table yang berbeda — misalnya main route table VPC yang tidak punya route ke IGW. Ini adalah skenario yang cukup sering terjadi ketika ada beberapa route table di satu VPC.

Periksa asosiasi subnet dengan route table menggunakan filter langsung pada route table:

aws ec2 describe-route-tables \
  --route-table-ids rtb-xxxxxxxx \
  --query 'RouteTables[0].Associations[*].{SubnetId:SubnetId,Main:Main}'

Jika subnet ID kamu tidak muncul di output, berarti subnet tersebut belum terasosiasi dengan route table ini. Lakukan asosiasi secara eksplisit:

aws ec2 associate-route-table \
  --route-table-id rtb-xxxxxxxx \
  --subnet-id subnet-xxxxxxxx

Setelah ini, jalankan kembali perintah describe-route-tables di atas untuk konfirmasi bahwa SubnetId sudah muncul di daftar asosiasi.

Langkah 4: Verifikasi Security Group Mengizinkan Traffic Keluar

Sampai di sini, jalur routing sudah benar. Tapi kalau ping google.com masih gagal, Security Group bisa jadi penyebabnya. Security Group default AWS mengizinkan semua outbound traffic, tapi jika kamu membuat Security Group kustom, outbound rules mungkin terlalu ketat.

# Cek Security Group yang digunakan instance
aws ec2 describe-instances \
  --instance-ids i-xxxxxxxxxxxxxxxx \
  --query 'Reservations[0].Instances[0].SecurityGroups'

# Cek outbound rules Security Group tersebut
aws ec2 describe-security-groups \
  --group-ids sg-xxxxxxxx \
  --query 'SecurityGroups[0].IpPermissionsEgress'

Untuk outbound internet access, minimal harus ada rule yang mengizinkan TCP port 80 dan 443 ke 0.0.0.0/0. Untuk ICMP (ping), perlu rule terpisah:

# Izinkan outbound HTTP dan HTTPS
aws ec2 authorize-security-group-egress \
  --group-id sg-xxxxxxxx \
  --protocol tcp \
  --port 80 \
  --cidr 0.0.0.0/0

aws ec2 authorize-security-group-egress \
  --group-id sg-xxxxxxxx \
  --protocol tcp \
  --port 443 \
  --cidr 0.0.0.0/0

Langkah 5: Pastikan Instance Memiliki Public IP

Ini sering jadi titik buntu yang tidak terpikirkan — semua konfigurasi jaringan sudah benar, tapi instance tidak punya public IP sama sekali. Tanpa public IP atau Elastic IP, Internet Gateway tidak punya alamat tujuan untuk melakukan NAT, sehingga traffic outbound tetap tidak bisa keluar.

aws ec2 describe-instances \
  --instance-ids i-xxxxxxxxxxxxxxxx \
  --query 'Reservations[0].Instances[0].{PublicIpAddress:PublicIpAddress,PublicDnsName:PublicDnsName}'

Jika PublicIpAddress bernilai null, ada dua opsi: assign Elastic IP secara manual, atau pastikan subnet memiliki MapPublicIpOnLaunch diaktifkan untuk instance berikutnya.

# Aktifkan auto-assign public IP untuk subnet (berlaku untuk instance baru)
aws ec2 modify-subnet-attribute \
  --subnet-id subnet-xxxxxxxx \
  --map-public-ip-on-launch

# Untuk instance yang sudah berjalan: alokasi dan associate Elastic IP
aws ec2 allocate-address --domain vpc
# Catat AllocationId dari output di atas
aws ec2 associate-address \
  --instance-id i-xxxxxxxxxxxxxxxx \
  --allocation-id eipalloc-xxxxxxxx

Pengalaman Nyata: Diagnosis yang Salah dan Penyebab Sebenarnya

Skenario ini terjadi cukup sering: IGW sudah dibuat, route table sudah diupdate dengan 0.0.0.0/0, Security Group outbound terbuka penuh — tapi instance tetap tidak bisa ping ke luar. Di console, semuanya terlihat benar.

Asumsi pertama biasanya Security Group atau Network ACL. Engineer menghabiskan waktu memeriksa inbound rules, menambahkan ICMP rule, bahkan sempat menonaktifkan Network ACL sementara. Tidak ada perubahan.

Penyebab sebenarnya: subnet yang digunakan masih terasosiasi dengan main route table VPC yang tidak punya route ke IGW. Route table yang sudah diupdate adalah route table terpisah yang belum pernah di-associate ke subnet tersebut. Di console VPC, ini tidak langsung terlihat karena main route table ditampilkan sebagai default tanpa label yang jelas.

Fixnya satu baris:

aws ec2 associate-route-table \
  --route-table-id rtb-xxxxxxxx \
  --subnet-id subnet-xxxxxxxx

Setelah itu, ping langsung berhasil. Pelajarannya: selalu verifikasi asosiasi route table di level subnet, bukan hanya konten route table-nya.

Internet Gateway di AWS bekerja seperti gerbang tol — kamu bisa membangun jalan tol sepanjang apapun, tapi kalau on-ramp (route table) tidak terhubung ke jalan yang benar, kendaraan tidak akan pernah sampai ke gerbang.

IAM Policy Minimum untuk Menjalankan Perintah di Atas

Jika kamu menjalankan perintah-perintah ini menggunakan IAM user atau role dengan permission terbatas, berikut policy minimum yang dibutuhkan:

🔽 Klik untuk melihat IAM Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:CreateInternetGateway",
        "ec2:AttachInternetGateway",
        "ec2:DescribeInternetGateways",
        "ec2:CreateRoute",
        "ec2:DescribeRouteTables",
        "ec2:AssociateRouteTable",
        "ec2:DescribeInstances",
        "ec2:DescribeSecurityGroups",
        "ec2:AuthorizeSecurityGroupEgress",
        "ec2:ModifySubnetAttribute",
        "ec2:AllocateAddress",
        "ec2:AssociateAddress"
      ],
      "Resource": "*"
    }
  ]
}

Beberapa action seperti ec2:DescribeRouteTables dan ec2:DescribeInstances memerlukan "Resource": "*" karena tidak mendukung resource-level permission pada level action Describe. Selalu verifikasi di AWS Service Authorization Reference sebelum menerapkan policy di production.

Wrap-Up: EC2 Internet Access di Custom VPC dan Langkah Selanjutnya

Masalah EC2 no internet access di custom VPC hampir selalu bisa ditelusuri ke satu dari lima titik: IGW tidak ada atau tidak ter-attach, route table tidak punya default route ke IGW, subnet tidak terasosiasi ke route table yang benar, Security Group memblokir outbound traffic, atau instance tidak punya public IP. Periksa secara berurutan — jangan loncat langsung ke Security Group sebelum memastikan routing sudah benar.

Untuk langkah selanjutnya, pertimbangkan untuk menggunakan AWS VPC Reachability Analyzer yang bisa secara otomatis mendiagnosis path connectivity antara dua resource di VPC tanpa harus mengirim traffic nyata. Dokumentasi resmi tersedia di AWS VPC Reachability Analyzer.

Glosarium

Istilah	Penjelasan
Internet Gateway (IGW)	Komponen VPC yang memungkinkan komunikasi antara instance di VPC dan internet. Satu VPC hanya bisa memiliki satu IGW.
Route Table	Kumpulan aturan (routes) yang menentukan ke mana traffic jaringan diarahkan dari subnet atau gateway.
Public Subnet	Subnet yang route table-nya memiliki route ke Internet Gateway, sehingga instance di dalamnya bisa diakses dari internet jika memiliki public IP.
Security Group	Firewall virtual di level instance yang mengontrol inbound dan outbound traffic berdasarkan rules yang didefinisikan.
Elastic IP	Alamat IPv4 publik statis yang bisa dialokasikan ke akun AWS dan di-associate ke instance atau network interface.