"Instances in a private subnet cannot reach the internet" is one of the most common troubleshooting scenarios on the SAA-C03 exam. The cause is almost always in the routing or NAT configuration, and there is a definitive checklist for finding it.
The Required Components
For a private subnet instance to reach the internet, all of these must be in place:
- An Internet Gateway attached to the VPC
- A NAT Gateway (or NAT Instance) in a public subnet
- The public subnet's route table has a route:
0.0.0.0/0 → Internet Gateway - The private subnet's route table has a route:
0.0.0.0/0 → NAT Gateway - The NAT Gateway has an Elastic IP assigned
- Security groups allow outbound traffic from the private instance
- NACLs allow the relevant outbound and inbound (return) traffic
If any one of these is missing or misconfigured, the instance cannot reach the internet.
Step-by-Step Diagnostic
Step 1: Verify the Internet Gateway
Go to VPC → Internet Gateways. Confirm an IGW exists and is in the "Attached" state to the correct VPC. A detached IGW does nothing.
Step 2: Verify the NAT Gateway
Go to VPC → NAT Gateways. Confirm:
- The NAT Gateway exists and is in "Available" state
- It is in a public subnet (this is a common mistake — placing NAT Gateway in the private subnet)
- An Elastic IP is associated with it
Step 3: Check the Public Subnet's Route Table
The subnet where the NAT Gateway lives must have a route 0.0.0.0/0 → Internet Gateway. Without this, the NAT Gateway cannot send outbound traffic to the internet and return traffic cannot arrive.
Step 4: Check the Private Subnet's Route Table
The private subnet where your instances live must have a route 0.0.0.0/0 → NAT Gateway. If this route points to the Internet Gateway instead, you are routing as if it were a public subnet (and the instance has no public IP, so it still fails). If no default route exists, traffic has nowhere to go.
Step 5: Check Security Groups and NACLs
Security groups: confirm the instance's security group allows outbound traffic. The default security group allows all outbound — if this was modified, check the outbound rules.
NACLs: confirm the subnet's NACL allows outbound traffic (ports needed) and inbound return traffic. Unlike security groups, NACLs are stateless — you must explicitly allow return traffic on the ephemeral port range (1024–65535).
The Most Common Exam Trap
NAT Gateway in the wrong subnet
"A NAT Gateway was created and routes were configured, but private instances still cannot reach the internet."
The scenario description will show the NAT Gateway was placed in the private subnet. A NAT Gateway in a private subnet cannot reach the internet because the private subnet has no route to the Internet Gateway. The NAT Gateway must be in a public subnet.
Second most common: the private subnet route table has 0.0.0.0/0 → Internet Gateway instead of 0.0.0.0/0 → NAT Gateway. This is incorrect for a private subnet — direct routing to IGW would only work if the instance had a public IP, which private subnet instances should not have.
NAT Gateway vs NAT Instance
| NAT Gateway | NAT Instance | |
|---|---|---|
| Managed by | AWS | You |
| Availability | Multi-AZ capable | Single instance (needs HA design) |
| Bandwidth | Up to 100 Gbps | Limited by instance type |
| Cost | Higher | Lower (cheaper EC2 type) |
| Maintenance | None | Must patch and manage |
The exam recommends NAT Gateway for production workloads requiring high availability and no maintenance. NAT Instance is used for cost-sensitive or legacy scenarios.
Practice SAA-C03 VPC troubleshooting questions with route table scenarios to build speed on this diagnostic sequence.
Full Troubleshooting Walkthrough — In Order
When an EC2 instance in a private subnet can't reach the internet, work through the components in the order traffic flows rather than jumping to random checks.
Step 1 — Confirm the NAT Gateway exists and is in Active state
aws ec2 describe-nat-gateways --filter "Name=state,Values=available"
Look for "State": "available". If the NAT Gateway is in pending or failed state it won't pass traffic. A failed NAT Gateway is usually due to an Elastic IP address that was released or disassociated.
Step 2 — Confirm the private subnet's route table has a 0.0.0.0/0 route pointing to the NAT Gateway
aws ec2 describe-route-tables --filters "Name=association.subnet-id,Values=subnet-XXXXXX"
In the output, look for a route with DestinationCidrBlock: "0.0.0.0/0" and a NatGatewayId. If the default route points to an IGW instead of a NAT Gateway, your private instances will try to communicate directly with the internet (and fail, because they have no public IPs). If there's no default route at all, traffic destined for the internet has no path and is dropped.
Step 3 — Confirm the NAT Gateway is in a public subnet
aws ec2 describe-nat-gateways --nat-gateway-ids nat-XXXXXX
Look at the SubnetId in the response. Then check that subnet's route table to confirm it has a 0.0.0.0/0 route to an Internet Gateway. If the NAT Gateway was accidentally placed in a private subnet, it won't be able to route traffic to the internet.
Step 4 — Confirm the Internet Gateway is attached to the VPC
aws ec2 describe-internet-gateways --filters "Name=attachment.vpc-id,Values=vpc-XXXXXX"
The attachment state should be available. An IGW that exists but isn't attached to the VPC does nothing.
Step 5 — Check security groups on the instance
Outbound traffic from the instance must be allowed. The default security group allows all outbound, but custom security groups might restrict it. Check that the outbound rule permits the traffic type (TCP 443 for HTTPS, for example).
Step 6 — Check the subnet's NACL
NACLs are stateless. If the NACL on the private subnet allows outbound port 443 but doesn't allow inbound on ephemeral ports (1024-65535), response traffic will be blocked. The NACL on the public subnet (where NAT Gateway sits) needs to allow both directions as well.
The NAT Gateway Cost Trap
NAT Gateway pricing has two components: an hourly charge (approximately $0.045/hour per NAT Gateway) and a per-GB data processing charge ($0.045/GB). On a workload that transfers a lot of data to S3 — log ingestion, ETL, backups — the per-GB charge adds up fast.
The exam specifically tests this in "cost optimization" scenarios. If a private subnet instance needs to reach S3, the correct answer is to create a Gateway VPC Endpoint for S3. Gateway endpoints are completely free — no hourly fee, no per-GB fee. Traffic routes through AWS's internal network without leaving the VPC, without touching NAT Gateway, and without generating any additional charges.
The trap answer is "add a NAT Gateway" or "keep using the existing NAT Gateway." For S3 and DynamoDB, that's the expensive option. Gateway endpoint is always cheaper.
Real cost scenario the exam likes: "A company runs a data pipeline that transfers 50 TB per month from EC2 to S3. They want to reduce costs. Their EC2 instances are in private subnets with a NAT Gateway." At $0.045/GB and 50 TB, the NAT Gateway data processing charge alone is over $2,300/month. A gateway endpoint reduces that to zero.
NAT Gateway vs NAT Instance — When the Exam Prefers Each
NAT Gateway is the AWS-managed service. It scales automatically, is highly available within an AZ, doesn't require OS patching, and doesn't support security groups (it uses NACLs at the subnet level). You can't SSH into it.
NAT Instance is an EC2 instance running NAT software (typically the Amazon Linux NAT AMI). It requires disabling the source/destination check — aws ec2 modify-instance-attribute --instance-id i-XXXXX --no-source-dest-check — because by default EC2 drops packets where the source or destination IP doesn't match the instance's own IP. NAT relies on forwarding packets for other hosts, so source/dest check must be off.
The exam scenario words that point to NAT Instance:
- "cost-effective solution for low-traffic workloads" — NAT Instance on a t3.micro is cheaper than NAT Gateway's flat hourly fee
- "need to perform port forwarding or protocol-level filtering" — NAT Gateway doesn't support this; NAT Instance can run custom iptables rules
- "need to apply security groups to the NAT device" — NAT Gateway has no SG; NAT Instance does
The scenario words that point to NAT Gateway:
- "managed service," "no administrative overhead," "highly available," "automatically scales"
- Anything mentioning high throughput or large data transfer where you don't want to size and manage instances
IPv6 and Egress-Only Internet Gateway
This trips candidates who haven't studied IPv6 in the VPC context. IPv6 addresses are globally unique — there is no RFC 1918 equivalent for IPv6. Every IPv6 address is routable on the internet. This means NAT is conceptually unnecessary for IPv6 (and AWS doesn't support NAT for IPv6).
The problem: if your IPv6 instances are in a "private" subnet and you want them to initiate outbound connections to the internet without being directly reachable from the internet, you can't use NAT Gateway (it doesn't handle IPv6). Instead, you use an Egress-Only Internet Gateway.
The Egress-Only IGW allows outbound-initiated IPv6 traffic from your VPC to the internet. It blocks inbound IPv6 connections initiated from the internet. Think of it as a one-way door for IPv6.
The exam trap: a question describes a subnet with IPv6 addresses that needs outbound internet access, and one of the answer choices is "configure a NAT Gateway." This is wrong for IPv6. The correct answer is Egress-Only Internet Gateway.
What Elastic IP Association Failure Looks Like
A NAT Gateway requires an Elastic IP address. When you create a NAT Gateway, you either allocate a new EIP or specify an existing one. If that EIP is later released or disassociated, the NAT Gateway loses its public IP and can no longer forward traffic to the internet.
In the AWS console, a NAT Gateway with a missing EIP will show as failed rather than available. In CLI output, the NatGatewayAddresses array will be empty or show the address without an allocation ID.
To fix it, you must delete the failed NAT Gateway and create a new one — you cannot reassociate an EIP to an existing NAT Gateway that has lost its address. The exam doesn't usually test the fix procedure, but it does test the symptom recognition: "The private instances recently lost internet connectivity. The NAT Gateway exists in the VPC. What should be checked?" — look at the EIP association status.
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: