Internet Gateway and NAT Gateway are tested together repeatedly on the SAA-C03 exam. The confusion is understandable — both involve internet connectivity — but they solve fundamentally different problems.
Internet Gateway (IGW)
An Internet Gateway enables bidirectional communication between a VPC and the internet:
- Inbound: internet clients can initiate connections to resources in the VPC
- Outbound: resources in the VPC can initiate connections to the internet
Requirements for a resource to use the IGW:
- The resource must have a public or Elastic IP address
- The resource's subnet must have a route
0.0.0.0/0 → Internet Gateway - Security groups and NACLs must allow the traffic
The IGW also performs NAT — it translates the resource's private IP to its public IP for outbound traffic and back for inbound traffic.
One IGW per VPC. It is attached to the VPC, not to a subnet. All public subnets route through the same IGW.
NAT Gateway
A NAT Gateway enables outbound-only internet connectivity for private subnet resources:
- Outbound: private instances can initiate connections to the internet
- Inbound: internet clients cannot initiate connections to private instances (the NAT Gateway rejects unsolicited inbound connections)
NAT Gateway placement and requirements:
- Must be placed in a public subnet (it needs access to the IGW)
- Must have an Elastic IP assigned
- The private subnet's route table must have
0.0.0.0/0 → NAT Gateway
When to Use Each
| Requirement | Use |
|---|---|
| Web server that must be reachable from internet | Internet Gateway |
| Database server that needs to download patches but must not be reachable from internet | NAT Gateway |
| Lambda function in a VPC that needs to call an external API | NAT Gateway |
| EC2 instance that hosts a public website | Internet Gateway (with Elastic IP or Load Balancer) |
| App server behind a load balancer with no public IP | NAT Gateway for outbound; Load Balancer for inbound |
The Exam Trap Scenarios
Scenario 1: "An EC2 instance in a private subnet needs to call a third-party API on the internet. What must be configured?"
Many candidates answer "Internet Gateway" because internet connectivity is needed. The correct answer is NAT Gateway — the instance is in a private subnet and should not be reachable from the internet. The NAT Gateway provides outbound-only internet access.
Scenario 2: "An EC2 instance has a public IP and is in a public subnet, but it cannot reach the internet."
The Internet Gateway is either missing, detached, or the route 0.0.0.0/0 → igw-xxx is missing from the subnet's route table. Having a public IP is not enough — the route must also exist.
Scenario 3: "What is the most cost-effective way to provide internet access for a small number of private instances?"
NAT Gateway costs around $0.045/hour per AZ plus data transfer charges. For very low traffic, a NAT Instance (a small EC2 instance) can be cheaper. The NAT Instance requires disabling source/destination checking on the EC2 instance.
Egress-Only Internet Gateway
For IPv6 VPCs, a NAT Gateway does not apply — IPv6 addresses are all public by design. An Egress-Only Internet Gateway provides outbound-only internet access for IPv6 resources, equivalent to what a NAT Gateway does for IPv4 private instances.
Practice SAA-C03 VPC networking questions to build automatic recognition of IGW vs NAT Gateway scenarios.
The Full Traffic Flow — Traced Step by Step
Understanding what each component does to a packet explains why the order matters and why misplacing any component breaks connectivity.
A private subnet EC2 instance (private IP 10.0.1.50) initiates an HTTP request to 93.184.216.34 (example.com):
EC2 instance → NAT Gateway: The instance sends a packet with source 10.0.1.50, destination 93.184.216.34. The private subnet's route table has a 0.0.0.0/0 route pointing to the NAT Gateway's ENI ID. The packet travels within the VPC to the NAT Gateway.
NAT Gateway translates the source IP: The NAT Gateway replaces the source IP (10.0.1.50) with its own Elastic IP address (e.g., 54.210.1.100). It records this mapping in its connection tracking table so it knows to forward responses back. The translated packet's source is now 54.210.1.100, destination 93.184.216.34.
NAT Gateway → IGW: The public subnet's route table has a 0.0.0.0/0 route pointing to the Internet Gateway. The packet travels to the IGW.
IGW forwards to internet: The IGW doesn't do NAT — it handles the one-to-one mapping between the instance's public IP and the internet. Since the packet is already using the EIP (which is a public IP), the IGW forwards it toward the internet. The destination 93.184.216.34 receives the request from 54.210.1.100.
Response comes back: The response goes to 54.210.1.100 → IGW → NAT Gateway → NAT Gateway translates destination IP back to 10.0.1.50 → EC2 instance receives the response.
The key point: the private EC2 instance's private IP (10.0.1.50) is never visible to the internet. The only IP the external server ever sees is the NAT Gateway's EIP.
NAT Gateway Placement Rule — The One That Trips Everyone
NAT Gateway must be in a public subnet. The private subnet's route table points to it. People mix these up and place the NAT Gateway in the private subnet, then wonder why it doesn't work.
Here's why placement matters: for a NAT Gateway to forward traffic to the internet, it needs a path to the internet itself. That path is an IGW. The IGW route (0.0.0.0/0 → IGW) must be in the NAT Gateway's own subnet's route table. If the NAT Gateway is in a private subnet (no IGW route), it can receive packets from the private instances but has no path to forward them to the internet.
The pattern to remember:
- Public subnet route table: 0.0.0.0/0 → Internet Gateway (this is what the NAT Gateway uses to reach the internet)
- Private subnet route table: 0.0.0.0/0 → NAT Gateway (this is what private instances use to reach the NAT Gateway)
The exam question: "A NAT Gateway was created in the same subnet as the private EC2 instances. Instances cannot reach the internet. What is wrong?" The NAT Gateway is in the wrong subnet — it should be in a public subnet.
High Availability for NAT Gateway
A single NAT Gateway is scoped to one Availability Zone. If that AZ experiences an outage, the NAT Gateway fails and all private instances in all AZs that route through it lose internet access.
For production workloads, the HA pattern is one NAT Gateway per AZ:
- AZ-A private subnet route table: 0.0.0.0/0 → NAT-GW-A (in public subnet of AZ-A)
- AZ-B private subnet route table: 0.0.0.0/0 → NAT-GW-B (in public subnet of AZ-B)
If AZ-A goes down, AZ-A instances lose internet access along with everything else in AZ-A (which is expected). AZ-B instances still have their own NAT Gateway and continue to function.
The exam trap: "A company has private instances in us-east-1a, us-east-1b, and us-east-1c. All three AZs route internet-bound traffic through a single NAT Gateway in us-east-1a. The solution meets availability requirements for a cost-conscious company." This statement is FALSE — cross-AZ routing through a single NAT Gateway creates a single point of failure AND incurs cross-AZ data transfer charges ($0.01/GB each direction). The correct HA solution requires one NAT Gateway per AZ.
Egress-Only Internet Gateway vs NAT Gateway
This distinction shows up in IPv6 questions. The two gateways serve different IP versions and cannot substitute for each other.
NAT Gateway: handles IPv4 outbound from private instances. Translates private IPv4 addresses to a public EIP. Does NOT support IPv6 — not because of a limitation, but because IPv6 doesn't need NAT (all IPv6 addresses are globally routable).
Egress-Only Internet Gateway: handles IPv6 outbound from instances that should initiate connections but not receive inbound connections. Since IPv6 addresses are public, a regular IGW would allow both inbound and outbound IPv6 traffic. The Egress-Only IGW blocks unsolicited inbound IPv6 connections while allowing outbound.
The exam scenario: "EC2 instances have both IPv4 private addresses and IPv6 addresses. IPv6 instances in the private subnet need to download software updates but must not be reachable from the internet via IPv6."
- IPv4 outbound → NAT Gateway
- IPv6 outbound → Egress-Only Internet Gateway
- Two separate route table entries are needed: 0.0.0.0/0 → NAT GW, ::/0 → Egress-Only IGW
Choosing NAT Gateway for IPv6 is wrong — it doesn't handle IPv6 traffic at all.
When NOT to Use NAT Gateway
NAT Gateway is the default answer for "private instance needs internet access," but there are scenarios where it's the wrong (expensive) choice:
Scenario 1: Private instance only needs S3 or DynamoDB A gateway VPC endpoint is free and routes the traffic through AWS's internal network without going to the internet at all. The route table entry for the endpoint prefix list takes priority over the NAT Gateway route. No per-GB charge, no hourly fee.
Scenario 2: Private instance needs to reach another AWS service in the same region An interface VPC endpoint (PrivateLink) connects to the service through an ENI in your VPC. Interface endpoints have hourly and per-GB costs, but for high-volume access to services like Secrets Manager, STS, or CloudWatch Logs, this can be cheaper than routing all traffic through a NAT Gateway.
The exam phrasing that signals "don't use NAT Gateway": "without traversing the internet," "private connectivity to AWS services," "reduce data transfer costs for S3 access from private subnets."
IGW Performance — Why It's Never the Bottleneck
The Internet Gateway is a horizontally scaled, redundant, highly available AWS-managed component. It has no bandwidth limit and no throughput to configure or manage. It doesn't appear in performance troubleshooting for bandwidth constraints.
Contrast this with NAT Gateway, which does have operational characteristics you might need to be aware of in the real world (though the exam doesn't usually test NAT Gateway bandwidth limits directly): a single NAT Gateway supports up to 45 Gbps of bandwidth aggregated across all AZs it serves. For most workloads this isn't a constraint, but it's another reason to have one NAT Gateway per AZ rather than one central NAT Gateway — distributing the load.
The cost model is the bigger difference: IGW is completely free (no hourly charge, no data transfer charge for inbound). NAT Gateway costs $0.045/hour plus $0.045/GB processed. For a 24/7 deployment, the hourly charge alone is about $32/month per NAT Gateway, before data charges. High-throughput workloads that can use VPC endpoints for AWS services should do so specifically to avoid the NAT Gateway per-GB fees.
Practice Question Sets
Working through real SAA-C03 questions is the fastest way to lock in how the exam phrases these scenarios. Pick a session that fits your time: