NAT Gateway vs NAT Instance: Pilihan Tepat untuk Private Instance Mengakses Internet

Saat private instance di subnet terisolasi perlu mengunduh update atau memanggil API eksternal, pertanyaan pertama yang muncul biasanya sama: pakai NAT Gateway yang managed atau jalankan NAT Instance sendiri di EC2? Keduanya menyelesaikan masalah yang sama — memberi jalur keluar ke internet tanpa mengekspos instance ke inbound traffic — tapi trade-off operasional di antara keduanya sangat berbeda dan sering disalahpahami.

TL;DR: NAT Gateway vs NAT Instance

Aspek NAT Gateway NAT Instance
Manajemen Fully managed AWS Self-managed EC2
Ketersediaan Built-in redundancy dalam satu AZ Bergantung pada konfigurasi manual
Skalabilitas Auto-scaling bandwidth Dibatasi oleh tipe instance
Security Group Tidak didukung Didukung
Biaya awal Lebih tinggi (per jam + per GB) Lebih rendah (hanya biaya EC2)
Overhead operasional Minimal Tinggi (patching, failover, monitoring)
Rekomendasi Produksi dan sebagian besar use case Hanya jika biaya sangat kritis atau butuh kontrol penuh

Cara Kerja NAT di AWS

Kedua solusi mengandalkan mekanisme yang sama: Network Address Translation. Private instance mengirim paket dengan source IP private, NAT menerjemahkan source IP ke Elastic IP (EIP) publik, meneruskan ke internet, lalu memetakan respons kembali ke instance asal. Dari sudut pandang internet, semua traffic keluar dari private subnet terlihat berasal dari satu IP publik.

Perbedaan krusialnya ada di lapisan implementasi. NAT Gateway adalah layanan managed yang dijalankan oleh AWS di infrastruktur mereka sendiri — kamu tidak punya akses ke underlying instance. NAT Instance adalah EC2 biasa yang dikonfigurasi sebagai router dengan fitur Source/Destination Check dinonaktifkan, menjalankan software NAT (biasanya iptables di Amazon Linux AMI khusus). Karena ini EC2 biasa, semua tanggung jawab operasional ada di tanganmu.

graph LR A["Private Instance
10.0.1.x"] --> B["Route Table
0.0.0.0/0 → NAT"] B --> C["NAT Gateway / Instance
Public Subnet"] C --> D["Internet Gateway"] D --> E["Internet"] E --> D D --> C C --> A F["Security Group"] -.->|"NAT Instance only"| C
  1. Private Instance mengirim request ke internet (misal, apt-get update ke repository publik).
  2. Route table di private subnet mengarahkan traffic 0.0.0.0/0 ke NAT (Gateway atau Instance) di public subnet.
  3. NAT menerjemahkan source IP private ke Elastic IP publik dan meneruskan ke Internet Gateway.
  4. Respons dari internet masuk melalui Internet Gateway, NAT memetakan kembali ke IP private instance asal.
  5. Pada NAT Instance, Security Group instance tersebut juga dievaluasi — ini yang tidak ada di NAT Gateway.

NAT Gateway: Arsitektur dan Keterbatasan yang Perlu Dipahami

NAT Gateway di-deploy per Availability Zone. Ini poin yang sering menyebabkan kesalahan arsitektur: satu NAT Gateway di us-east-1a tidak otomatis melayani private subnet di us-east-1b. Untuk high availability yang benar, kamu perlu satu NAT Gateway per AZ, masing-masing dengan EIP sendiri, dan route table per AZ yang menunjuk ke NAT Gateway di AZ yang sama.

Bayangkan NAT Gateway seperti kasir di satu lantai gedung. Semua orang di lantai itu bisa antri ke kasir yang sama, tapi orang di lantai lain harus punya kasir sendiri. Memaksa mereka naik tangga ke lantai lain bisa jalan, tapi kalau kasir itu tutup, semua orang dari dua lantai kehilangan akses sekaligus.

NAT Gateway mendukung TCP, UDP, dan ICMP. Bandwidth di-scale secara otomatis. Kamu tidak perlu memikirkan kapasitas kecuali ada kebutuhan khusus — cek dokumentasi resmi AWS untuk batas throughput terkini karena angka ini bisa berubah.

Deploy NAT Gateway via CLI

# Alokasikan Elastic IP
aws ec2 allocate-address \
  --domain vpc \
  --region us-east-1

# Catat AllocationId dari output, lalu buat NAT Gateway
aws ec2 create-nat-gateway \
  --subnet-id subnet-0abc12345def67890 \
  --allocation-id eipalloc-0abc12345def67890 \
  --region us-east-1

# Tunggu hingga NAT Gateway status 'available'
aws ec2 wait nat-gateway-available \
  --nat-gateway-ids nat-0abc12345def67890 \
  --region us-east-1

# Update route table private subnet
aws ec2 create-route \
  --route-table-id rtb-0abc12345def67890 \
  --destination-cidr-block 0.0.0.0/0 \
  --nat-gateway-id nat-0abc12345def67890 \
  --region us-east-1

Verifikasi Konfigurasi NAT Gateway

# Cek status NAT Gateway
aws ec2 describe-nat-gateways \
  --nat-gateway-ids nat-0abc12345def67890 \
  --query 'NatGateways[*].{ID:NatGatewayId,State:State,SubnetId:SubnetId}' \
  --output table \
  --region us-east-1

# Verifikasi route table sudah menunjuk ke NAT Gateway
aws ec2 describe-route-tables \
  --route-table-ids rtb-0abc12345def67890 \
  --query 'RouteTables[*].Routes[?DestinationCidrBlock==`0.0.0.0/0`]' \
  --output table \
  --region us-east-1

NAT Instance: Kapan Masih Relevan

NAT Instance bukan pilihan usang sepenuhnya. Ada skenario spesifik di mana ia masih masuk akal: lingkungan development dengan budget sangat terbatas, atau kebutuhan untuk melakukan port forwarding dan deep packet inspection yang tidak bisa dilakukan NAT Gateway. Tapi di produksi, overhead operasionalnya nyata.

Yang paling sering dilupakan saat setup NAT Instance: Source/Destination Check harus dinonaktifkan. Secara default, EC2 memverifikasi bahwa ia adalah source atau destination dari setiap paket. NAT Instance perlu meneruskan paket yang bukan miliknya, jadi check ini harus dimatikan. Lupa langkah ini dan traffic tidak akan mengalir — tanpa error message yang jelas.

Setup NAT Instance via CLI

🔽 Klik untuk melihat perintah lengkap NAT Instance setup 
# Launch EC2 dengan AMI Amazon Linux 2 (gunakan AMI ID terbaru untuk region kamu)
# Pastikan instance berada di public subnet dan memiliki EIP
aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t3.small \
  --subnet-id subnet-0public12345678 \
  --associate-public-ip-address \
  --security-group-ids sg-0abc12345def67890 \
  --key-name my-keypair \
  --region us-east-1

# Nonaktifkan Source/Destination Check — WAJIB untuk NAT berfungsi
aws ec2 modify-instance-attribute \
  --instance-id i-0abc12345def67890 \
  --no-source-dest-check \
  --region us-east-1

# Verifikasi Source/Destination Check sudah nonaktif
aws ec2 describe-instances \
  --instance-ids i-0abc12345def67890 \
  --query 'Reservations[*].Instances[*].SourceDestCheck' \
  --output text \
  --region us-east-1

# Di dalam instance, aktifkan IP forwarding dan konfigurasi iptables
# (jalankan via SSH atau SSM Session Manager)
sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# Buat rule permanen
echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf
sudo service iptables save

# Update route table private subnet untuk menunjuk ke NAT Instance
aws ec2 create-route \
  --route-table-id rtb-0private12345678 \
  --destination-cidr-block 0.0.0.0/0 \
  --instance-id i-0abc12345def67890 \
  --region us-east-1

Pola Kegagalan yang Sering Terjadi di Produksi

Ini skenario yang cukup sering muncul: tim deploy NAT Gateway di satu AZ, semua berjalan lancar selama berbulan-bulan. Lalu suatu hari private instance di AZ lain tiba-tiba tidak bisa mengakses internet. Tidak ada alarm yang berbunyi karena NAT Gateway-nya sendiri sehat. Masalahnya ada di route table — private subnet di AZ kedua masih menunjuk ke NAT Gateway di AZ pertama, dan koneksi lintas AZ itu memiliki implikasi latensi dan biaya data transfer yang tidak terdeteksi sampai tagihan datang.

Diagnosisnya selalu dimulai dari route table, bukan dari NAT Gateway itu sendiri.

graph TD S["Symptom: Private Instance AZ-B
tidak bisa akses internet"] --> M1["Misdiagnosis: Cek Security Group
dan Network ACL — bersih"] M1 --> M2["Misdiagnosis: Cek NAT Gateway
status 'available' di AZ-A"] M2 --> R["Root Cause: Route Table AZ-B
menunjuk ke NAT GW di AZ-A"] R --> F1["Risiko: Single point of failure
untuk dua AZ sekaligus"] R --> F2["Risiko: Biaya data transfer
lintas AZ tidak terdeteksi"] R --> Fix["Fix: Deploy NAT GW di AZ-B
Update route table AZ-B"]
  1. Symptom: Private instance di AZ-B tidak bisa keluar ke internet, padahal NAT Gateway di AZ-A berstatus 'available'.
  2. Misdiagnosis awal: Tim memeriksa Security Group dan Network ACL — keduanya bersih.
  3. Penyebab sebenarnya: Route table private subnet AZ-B menunjuk ke NAT Gateway di AZ-A. Ini berfungsi, tapi traffic lintas AZ menambah latensi dan biaya. Jika NAT Gateway AZ-A bermasalah, semua private instance di kedua AZ kehilangan akses sekaligus.
  4. Perbaikan: Deploy NAT Gateway terpisah di AZ-B, update route table private subnet AZ-B untuk menunjuk ke NAT Gateway lokal.

Diagnosa Route Table via CLI

# Temukan semua route table di VPC dan cek ke mana 0.0.0.0/0 menunjuk
aws ec2 describe-route-tables \
  --filters 'Name=vpc-id,Values=vpc-0abc12345def67890' \
  --query 'RouteTables[*].{RTID:RouteTableId,Routes:Routes[?DestinationCidrBlock==`0.0.0.0/0`]}' \
  --output json \
  --region us-east-1

# Cek subnet mana yang terhubung ke route table tertentu
aws ec2 describe-route-tables \
  --route-table-ids rtb-0abc12345def67890 \
  --query 'RouteTables[*].Associations[*].{SubnetId:SubnetId,Main:Main}' \
  --output table \
  --region us-east-1

IAM Policy untuk Monitoring NAT Gateway

Jika kamu memberikan akses terbatas kepada tim operasional untuk memantau NAT Gateway, berikut contoh policy dengan least privilege. Tindakan ec2:DescribeNatGateways, ec2:DescribeAddresses, dan ec2:DescribeRouteTables mendukung izin tingkat sumber daya, namun dalam contoh ini "Resource": "*" digunakan untuk kesederhanaan — di lingkungan produksi, pertimbangkan untuk membatasi ke resource ARN spesifik sesuai kebutuhan.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "NATGatewayReadOnly",
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeNatGateways",
        "ec2:DescribeAddresses",
        "ec2:DescribeRouteTables",
        "ec2:DescribeSubnets",
        "ec2:DescribeVpcs"
      ],
      "Resource": "*"
    },
    {
      "Sid": "CloudWatchNATMetrics",
      "Effect": "Allow",
      "Action": [
        "cloudwatch:GetMetricStatistics",
        "cloudwatch:ListMetrics"
      ],
      "Resource": "*"
    }
  ]
}

Monitoring NAT Gateway dengan CloudWatch

NAT Gateway mempublikasikan metrik ke CloudWatch secara otomatis. Metrik yang paling berguna untuk dipantau adalah ErrorPortAllocation — jika ini muncul, NAT Gateway kehabisan port untuk koneksi baru, yang biasanya terjadi saat banyak instance membuka koneksi ke sedikit destination IP secara bersamaan.

# Cek metrik ErrorPortAllocation untuk NAT Gateway
aws cloudwatch get-metric-statistics \
  --namespace AWS/NATGateway \
  --metric-name ErrorPortAllocation \
  --dimensions Name=NatGatewayId,Value=nat-0abc12345def67890 \
  --start-time 2024-01-15T00:00:00Z \
  --end-time 2024-01-15T23:59:59Z \
  --period 300 \
  --statistics Sum \
  --region us-east-1

# Cek total bytes yang diproses
aws cloudwatch get-metric-statistics \
  --namespace AWS/NATGateway \
  --metric-name BytesOutToDestination \
  --dimensions Name=NatGatewayId,Value=nat-0abc12345def67890 \
  --start-time 2024-01-15T00:00:00Z \
  --end-time 2024-01-15T23:59:59Z \
  --period 3600 \
  --statistics Sum \
  --region us-east-1

Panduan Keputusan: NAT Gateway atau NAT Instance?

graph TD Start["Private instance butuh
akses internet?"] --> Q1["Apakah ini lingkungan produksi?"] Q1 -->|"Ya"| Q2["Apakah butuh port forwarding
atau deep packet inspection?"] Q1 -->|"Tidak / Dev"| Q3["Apakah biaya sangat kritis?"] Q2 -->|"Ya"| NI["NAT Instance
(dengan HA manual)"] Q2 -->|"Tidak"| NGW["NAT Gateway ✓
Rekomendasi utama"] Q3 -->|"Ya"| NI Q3 -->|"Tidak"| NGW

Gunakan panduan ini sebagai titik awal. Untuk sebagian besar workload produksi, NAT Gateway adalah pilihan yang tepat karena menghilangkan seluruh overhead operasional. NAT Instance hanya masuk akal jika kamu memiliki alasan teknis spesifik yang tidak bisa dipenuhi NAT Gateway, atau jika biaya benar-benar menjadi kendala utama di lingkungan non-produksi.

Wrap-Up: NAT Gateway vs NAT Instance untuk Private Instance

Untuk kebutuhan private instance mengakses internet — mengunduh update, memanggil API eksternal, atau mengambil dependency — NAT Gateway adalah pilihan default yang tepat untuk hampir semua skenario produksi. Managed, scalable, dan tidak membutuhkan intervensi operasional setelah dikonfigurasi dengan benar.

NAT Instance masih relevan untuk skenario sangat spesifik: budget development yang sangat ketat, atau kebutuhan teknis seperti port forwarding yang tidak didukung NAT Gateway. Tapi masuk ke produksi dengan NAT Instance berarti kamu mengambil alih tanggung jawab patching, monitoring, dan failover — overhead yang jarang sebanding dengan penghematan biaya.

Satu hal yang tidak boleh diabaikan: deploy NAT Gateway per AZ, bukan satu untuk seluruh VPC. Route table yang salah konfigurasi adalah sumber masalah yang paling sering ditemukan di arsitektur NAT, dan paling mudah dicegah sejak awal.

Referensi resmi: AWS NAT Gateway Documentation dan AWS NAT Instance Documentation.

Glosarium

Istilah Penjelasan
NAT (Network Address Translation) Mekanisme penerjemahan IP private ke IP publik untuk memungkinkan koneksi keluar ke internet tanpa mengekspos IP private.
Elastic IP (EIP) IP publik statis yang dialokasikan ke akun AWS dan dapat dilampirkan ke resource seperti NAT Gateway atau EC2 instance.
Source/Destination Check Fitur EC2 yang memverifikasi instance sebagai source atau destination paket. Harus dinonaktifkan pada NAT Instance agar bisa meneruskan traffic.
Route Table Tabel aturan routing di VPC yang menentukan ke mana traffic diarahkan berdasarkan destination CIDR.
Internet Gateway (IGW) Komponen VPC yang memungkinkan komunikasi antara resource di VPC dan internet. NAT Gateway dan NAT Instance keduanya membutuhkan IGW di public subnet.

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