Definition
- Internet Gateway (IGW) – A horizontally-scaled, highly available VPC component that provides two-way internet connectivity, allowing resources with a public IP to both receive and send internet traffic.
- NAT Gateway – A managed service in a public subnet that performs source network address translation, allowing private instances to initiate outbound connections while blocking unsolicited inbound.
- Source NAT – The NAT Gateway rewrites the source IP of outbound packets from the private instance's IP to its own public Elastic IP.
- Connection Tracking – The NAT Gateway tracks connections initiated by private instances and routes replies back, but rejects connection attempts from outside.
- VPC Gateway Endpoint – A free alternative for S3 and DynamoDB traffic that avoids NAT data-processing costs entirely.
An Internet Gateway is National Bank of India's main front door to the street – people can walk in and staff can walk out, traffic flows both ways. A NAT Gateway is the outgoing-only mailroom: back-office staff can post letters to the outside world and receive the specific replies to those letters, but no stranger can use the mailroom to push a letter directly onto a back-office desk.
Understanding the Concepts
What is an Internet Gateway?
An Internet Gateway (IGW) attaches to the VPC itself, one per VPC. It is the component that makes two-way internet possible. For an instance to use it, three things must be true: the instance is in a subnet whose route table sends 0.0.0.0/0 to the IGW, the instance has a public or Elastic IP, and the Security Group and NACL allow the traffic. The IGW also performs the translation between the instance's public IP and its private IP. It is fully managed, scales automatically, and never becomes a bottleneck. There is no charge for an IGW itself.
# Attach an Internet Gateway to the VPC
aws ec2 create-internet-gateway
# Output: igw-0abc123
aws ec2 attach-internet-gateway --internet-gateway-id igw-0abc123 --vpc-id vpc-0abc
# Add route to the public subnet's route table
aws ec2 create-route --route-table-id rtb-public \
--destination-cidr-block 0.0.0.0/0 --gateway-id igw-0abc123
What is a NAT Gateway?
A NAT Gateway sits in a public subnet, has its own Elastic IP, and performs source network address translation. When a private instance sends an outbound request, the NAT Gateway rewrites the source IP to its own public IP, forwards the request through the Internet Gateway, and when the reply comes back it rewrites the destination and forwards it to the private instance. Because it only tracks connections the private instance initiated, there is no way for an outsider to start a connection inward.
# Create a NAT Gateway in the public subnet
aws ec2 allocate-address # get an Elastic IP
# Output: eipalloc-0abc
aws ec2 create-nat-gateway \
--subnet-id subnet-public-a \
--allocation-id eipalloc-0abc
# Output: nat-0abc123
# Route private subnet outbound through NAT
aws ec2 create-route --route-table-id rtb-private-a \
--destination-cidr-block 0.0.0.0/0 --nat-gateway-id nat-0abc123
How do their route tables differ?
The route tables make the behavior clear:
# Public subnet route table (where the NAT Gateway lives) 10.0.0.0/16 → local 0.0.0.0/0 → igw-0abc (two-way internet) # Private subnet route table 10.0.0.0/16 → local 0.0.0.0/0 → nat-0abc (outbound only via NAT; no inbound possible)
Why does a private subnet need a NAT Gateway?
The reason is the asymmetry we want: outbound yes, inbound no. The settlement database must be able to download security patches and call an external fraud API, but it must be impossible for anyone on the internet to open a connection to it. A NAT Gateway delivers exactly that asymmetry, whereas giving the subnet a direct IGW route plus a public IP would open it both ways.
public class WhyNATGateway {
// Settlement database needs:
// 1. Download OS security patches (outbound)
// 2. Call external fraud-scoring API (outbound)
// 3. Block ALL inbound from internet (security requirement)
// NAT Gateway: outbound YES, inbound NO
// Internet Gateway: outbound YES, inbound YES ← unacceptable for DB
}
How is an Internet Gateway different from a NAT Gateway?
| Aspect | Internet Gateway | NAT Gateway |
|---|---|---|
| Direction | Two-way (inbound + outbound) | Outbound only (blocks unsolicited inbound) |
| Attaches to | VPC (one per VPC) | Public subnet (one per AZ recommended) |
| Requires on instance | Public IP or Elastic IP | No public IP needed (NAT rewrites source) |
| Cost | Free | Per hour + per GB processed |
| Availability | Fully managed, automatically scaled | Zonal; deploy one per AZ for HA |
| Use case | Public-facing resources (ALB, bastion) | Private resources needing outbound internet |
Internet Gateway: two-way door to the street
NAT Gateway: one-way mailroom (outbound only)
What about VPC Gateway Endpoints to avoid NAT costs?
NAT Gateways bill per hour and per gigabyte processed. For traffic to AWS services like S3 or DynamoDB, a VPC Gateway Endpoint routes privately within the AWS network at no charge, avoiding NAT data-processing costs entirely.
# Create a free Gateway Endpoint for S3
aws ec2 create-vpc-endpoint \
--vpc-id vpc-0abc \
--service-name com.amazonaws.ap-south-1.s3 \
--route-table-ids rtb-private-a rtb-private-b
# S3 traffic now goes directly through the endpoint, not through NAT
# Saves NAT data-processing charges
What are common mistakes?
The first mistake is deploying a single NAT Gateway for all Availability Zones. A NAT Gateway is zonal; if that AZ goes down, all private instances in other AZs lose outbound internet. Deploy one per AZ.
The second mistake is routing S3 and DynamoDB traffic through the NAT Gateway when a free Gateway Endpoint exists. This wastes money on data-processing charges.
The third mistake is confusing an Internet Gateway with a NAT Gateway and adding an IGW route to a private subnet, which makes it public and exposes sensitive resources.
# WRONG: one NAT Gateway for all AZs Private AZ-a → nat-0abc (AZ-a) Private AZ-b → nat-0abc (AZ-a) ← cross-AZ + single point of failure Private AZ-c → nat-0abc (AZ-a) ← cross-AZ + single point of failure # CORRECT: one NAT per AZ Private AZ-a → nat-0abc-a Private AZ-b → nat-0abc-b Private AZ-c → nat-0abc-c
What about NAT instances vs NAT Gateways?
A NAT instance is a self-managed EC2 instance configured to perform NAT. It is cheaper for very low traffic but requires you to manage patching, scaling, and failover. The managed NAT Gateway is preferred for reliability and simplicity in production banking environments.
public class NATInstanceVsGateway {
// NAT Instance: cheaper, but you manage it (patch, scale, failover)
// NAT Gateway: managed by AWS, highly available within AZ
// For banking: always NAT Gateway (reliability > small cost savings)
}
What should a senior engineer know?
A senior engineer designs the NAT topology for both cost and resilience. They deploy one NAT Gateway per AZ, use Gateway Endpoints for S3 and DynamoDB to avoid NAT charges, and use Interface Endpoints for other AWS services when the traffic volume justifies the endpoint cost. They monitor NAT Gateway CloudWatch metrics (BytesOutToDestination, PacketsDropCount) to detect capacity issues.
They also know that NAT Gateways support up to 55,000 simultaneous connections per destination and 900 Mbps bandwidth, and exceeding these causes packet drops. For very high-throughput workloads, they use multiple NAT Gateways with routing.
# Monitor NAT Gateway for capacity issues
aws cloudwatch get-metric-statistics \
--namespace AWS/NATGateway \
--metric-name PacketsDropCount \
--dimensions Name=NatGatewayId,Value=nat-0abc \
--start-time 2024-01-15T00:00:00Z \
--end-time 2024-01-15T23:59:59Z \
--period 3600 --statistics Sum
Visual Overview
┌──────── Internet Gateway vs NAT Gateway ────────┐ │ │ │ Internet │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────┐ │ │ │ Internet Gateway (IGW) │ │ │ │ Two-way: inbound + outbound │ │ │ │ Free, fully managed, scales auto │ │ │ │ Translates public IP ↔ private IP │ │ │ └────────────────┬────────────────────────┘ │ │ │ │ │ ┌─────────────┼─────────────┐ │ │ ▼ ▼ ▼ │ │ Public Public Public │ │ Subnet-a Subnet-b Subnet-c │ │ (ALB) (ALB) (ALB) │ │ NAT-a ←─┐ NAT-b ←─┐ NAT-c ←─┐ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ Private │ Private │ Private │ │ │ Sub-a ──┘ Sub-b ──┘ Sub-c ──┘ │ │ (settlement) (transfer) (reporting) │ │ │ │ NAT Gateway: outbound only │ │ ┌────────────────────────────────────────┐ │ │ │ Private instance → NAT GW → IGW → Internet │ │ │ │ Reply: Internet → IGW → NAT GW → Private │ │ │ │ Unsolicited inbound: BLOCKED by NAT │ │ │ └────────────────────────────────────────┘ │ └───────────────────────────────────────────────────┘
Key Takeaway
An Internet Gateway is the VPC component that provides two-way internet connectivity. It attaches to the VPC, one per VPC, and for an instance to use it three things must line up: the instance's subnet route table sends 0.0.0.0/0 to the IGW, the instance has a public or Elastic IP, and the firewalls allow the traffic. It is fully managed, scales automatically, and is free.
A NAT Gateway solves the opposite-sided problem. Instances in a private subnet have no public IP and we deliberately do not want them reachable from the internet, but they still need outbound access for things like OS patches and calling external APIs. The NAT Gateway sits in a public subnet with its own Elastic IP and performs source network address translation: when a private instance sends an outbound request, the NAT Gateway rewrites the source to its own public IP, sends it out through the Internet Gateway, and routes the reply back to the private instance. Because it only tracks connections the private instance itself started, there is no way for an outsider to initiate a connection inward.
That asymmetry is exactly why a private subnet needs a NAT Gateway rather than an Internet Gateway. We want outbound yes and inbound no. At National Bank of India our settlement database lives in a private subnet and it has to download security patches and call an external fraud-scoring API, but it must be impossible for anyone on the internet to open a connection to it. A NAT Gateway gives us precisely that.
One senior point is cost and resilience. A NAT Gateway is zonal, so for high availability I deploy one per Availability Zone and route each private subnet to its zone-local NAT, which also avoids cross-zone data charges. NAT Gateways bill per hour and per gigabyte processed, so when the destination is an AWS service like S3 or DynamoDB, I use a VPC Gateway Endpoint instead, which routes privately and avoids the NAT data-processing cost entirely.
Remember one sentence: The Internet Gateway provides two-way internet for public subnets, while the NAT Gateway gives private subnets outbound-only internet by translating the source IP and blocking all unsolicited inbound.
---