While preparing for the AWS SAA-C03, many candidates confuse NAT Gateway placement, subnet types, and availability zone architecture. In the real world, this is fundamentally a decision about High Availability vs. Monthly Infrastructure Spend. Let’s drill into a simulated scenario.
The Scenario #
MedTech Innovations is deploying a new cloud-native patient data processing platform on AWS. The infrastructure team has designed a multi-tier VPC spanning three Availability Zones in us-east-1. Each AZ contains:
- One public subnet (for load balancers and bastion hosts)
- One private subnet (for application servers and batch processing EC2 instances)
The VPC uses IPv4 CIDR blocks, and an Internet Gateway has been attached to enable inbound traffic to public resources. The application tier runs in private subnets and requires outbound internet access to:
- Download security patches from vendor repositories
- Pull Docker images from Docker Hub
- Send telemetry data to third-party monitoring SaaS platforms
The architecture must comply with MedTech’s availability SLA of 99.9% uptime and follow AWS Well-Architected Framework principles.
Key Requirements #
Enable secure outbound internet access for EC2 instances in private subnets while maintaining high availability and minimizing operational complexity.
The Options #
-
A) Create three NAT Gateways, one in the public subnet of each Availability Zone. Configure private route tables for each AZ to route non-VPC traffic (0.0.0.0/0) to the NAT Gateway in the same AZ.
-
B) Create three NAT Instances, one in the private subnet of each Availability Zone. Configure private route tables for each AZ to route non-VPC traffic to the NAT Instance in the same AZ.
-
C) Create a second Internet Gateway and attach it to one of the private subnets. Update the private subnet route tables to forward non-VPC traffic to this private Internet Gateway.
-
D) Create an Egress-Only Internet Gateway in one of the public subnets. Update all private subnet route tables to route non-VPC traffic to the Egress-Only Internet Gateway.
Correct Answer #
Option A – Deploy NAT Gateways in public subnets across all three Availability Zones.
Step-by-Step Winning Logic #
This solution achieves the core requirement through three AWS architectural principles:
-
Proper Resource Placement: NAT Gateways must reside in public subnets because they require an Elastic IP address and direct internet connectivity via the Internet Gateway. Private subnets, by definition, lack direct IGW routes.
-
Availability Zone Independence: By deploying one NAT Gateway per AZ and creating AZ-specific route tables, each private subnet routes through its local NAT Gateway. If
us-east-1aexperiences an outage, private resources inus-east-1bandus-east-1cmaintain internet access. -
Managed Service Benefits: AWS manages NAT Gateway patching, scaling (up to 45 Gbps), and redundancy within the AZ. Unlike NAT Instances, there’s no OS to patch, no instance type to rightsize, and no need for custom failover scripts.
Cost Reality Check: For MedTech’s three-AZ deployment:
- Base cost: 3 NAT Gateways × $32.85/month = $98.55/month
- Data processing (estimated 500 GB/month): 500 × $0.045 = $22.50/month
- Total: ~$121/month for HA internet egress
💎 Professional-Level Analysis #
This section breaks down the scenario from a professional exam perspective, focusing on constraints, trade-offs, and the decision signals used to eliminate incorrect options.
🔐 Expert Deep Dive: Why Options Fail #
This walkthrough explains how the exam expects you to reason through the scenario step by step, highlighting the constraints and trade-offs that invalidate each incorrect option.
Prefer a quick walkthrough before diving deep?
[Video coming soon] This short walkthrough video explains the core scenario, the key trade-off being tested, and why the correct option stands out, so you can follow the deeper analysis with clarity.
🔐 The Traps (Distractor Analysis) #
This section explains why each incorrect option looks reasonable at first glance, and the specific assumptions or constraints that ultimately make it fail.
The difference between the correct answer and the distractors comes down to one decision assumption most candidates overlook.
Why not Option B? (NAT Instances in private subnets) #
Fatal Flaw #1: NAT Instances require public IP addresses and must be placed in public subnets, not private ones. The question’s wording is technically impossible to implement.
Fatal Flaw #2: Even if corrected to public subnet placement, NAT Instances introduce operational burden:
- Manual AMI patching and security updates
- Instance sizing decisions (t3.small vs. c5.large affects throughput)
- Required source/destination check disabling
- Custom CloudWatch monitoring and failover automation
When NAT Instances Make Sense: Only in cost-constrained dev/test environments where a single t3.nano ($3.80/month) suffices and downtime is acceptable.
Why not Option C? (Second Internet Gateway in private subnet) #
Architectural Impossibility: AWS VPCs support exactly one Internet Gateway per VPC. You cannot attach multiple IGWs, and IGWs are VPC-level resources, not subnet-level. Additionally, Internet Gateways only work with resources that have public IP addresses—private subnet instances lack this by design.
The Conceptual Confusion: This distractor tests whether you understand that “private” subnets are defined by their route table (no 0.0.0.0/0 → IGW route), not by a separate gateway type.
Why not Option D? (Egress-Only Internet Gateway) #
Protocol Mismatch: Egress-Only Internet Gateways are exclusively for IPv6 traffic. The scenario explicitly states “IPv4 CIDR blocks.”
Real-World Use Case: EOIGWs enable IPv6-addressed instances in private subnets to initiate outbound connections while blocking inbound IPv6 traffic from the internet—useful for dual-stack architectures, but irrelevant here.
🔐 The Solution Blueprint #
This blueprint visualizes the expected solution, showing how services interact and which architectural pattern the exam is testing.
Seeing the full solution end to end often makes the trade-offs—and the failure points of simpler options—immediately clear.
graph TB
subgraph VPC["VPC (10.0.0.0/16)"]
subgraph AZ1["us-east-1a"]
PubSub1["Public Subnet
10.0.1.0/24"]
PrivSub1["Private Subnet
10.0.11.0/24"]
NAT1["NAT Gateway
EIP: 54.x.x.1"]
EC2_1["EC2 Instances"]
end
subgraph AZ2["us-east-1b"]
PubSub2["Public Subnet
10.0.2.0/24"]
PrivSub2["Private Subnet
10.0.12.0/24"]
NAT2["NAT Gateway
EIP: 54.x.x.2"]
EC2_2["EC2 Instances"]
end
subgraph AZ3["us-east-1c"]
PubSub3["Public Subnet
10.0.3.0/24"]
PrivSub3["Private Subnet
10.0.13.0/24"]
NAT3["NAT Gateway
EIP: 54.x.x.3"]
EC2_3["EC2 Instances"]
end
IGW["Internet Gateway"]
end
Internet["Internet
(Package Repos, SaaS APIs)"]
EC2_1 -->|"Route: 0.0.0.0/0 → NAT1"| NAT1
EC2_2 -->|"Route: 0.0.0.0/0 → NAT2"| NAT2
EC2_3 -->|"Route: 0.0.0.0/0 → NAT3"| NAT3
NAT1 --> PubSub1
NAT2 --> PubSub2
NAT3 --> PubSub3
PubSub1 --> IGW
PubSub2 --> IGW
PubSub3 --> IGW
IGW --> Internet
style NAT1 fill:#FF9900,stroke:#232F3E,stroke-width:3px,color:#fff
style NAT2 fill:#FF9900,stroke:#232F3E,stroke-width:3px,color:#fff
style NAT3 fill:#FF9900,stroke:#232F3E,stroke-width:3px,color:#fff
style IGW fill:#3F8624,stroke:#232F3E,stroke-width:3px,color:#fff
Diagram Note: Each private subnet’s route table contains a default route (0.0.0.0/0) pointing to its AZ-local NAT Gateway, ensuring fault isolation and minimizing cross-AZ data transfer charges ($0.01/GB).
🔐 Real-World Practitioner Insight #
This section connects the exam scenario to real production environments, highlighting how similar decisions are made—and often misjudged—in practice.
This is the kind of decision that frequently looks correct on paper, but creates long-term friction once deployed in production.
Exam Rule #
“When private subnets need internet access for IPv4 traffic, always deploy NAT Gateway in public subnet. For high availability across N Availability Zones, deploy N NAT Gateways with AZ-specific routing.”
Real World #
In production environments, we layer additional optimizations:
-
Cost Optimization Pattern: For non-production environments (dev/staging), many teams deploy a single NAT Gateway in one AZ and route all private subnets through it. This cuts costs to ~$40/month but sacrifices AZ-level redundancy. Use lifecycle policies to automatically rebuild NAT Gateway configurations when promoting to production.
-
VPC Endpoints for AWS Services: Before implementing NAT Gateways, audit outbound traffic. If 80% of “internet” traffic goes to S3, DynamoDB, or other AWS services, deploy VPC Gateway Endpoints (free) or Interface Endpoints ($7.20/month/AZ) to avoid NAT Gateway data processing charges entirely.
-
Hybrid Approach for Cost Control: Use AWS Transit Gateway with centralized egress VPC. Route internet-bound traffic from multiple VPCs through a single set of NAT Gateways in a shared services VPC. This works well for organizations with 10+ VPCs where NAT Gateway costs become material ($1,000+/month).
-
IPv6 Migration Strategy: For greenfield applications, consider dual-stack (IPv4 + IPv6) with Egress-Only Internet Gateways for IPv6 traffic. This eliminates NAT Gateway costs for IPv6 flows while maintaining IPv4 compatibility during transition periods.
The Hidden Cost: Cross-AZ data transfer. If your application in us-east-1a routes through a NAT Gateway in us-east-1b, you pay $0.01/GB for the cross-AZ hop before the $0.045/GB NAT processing fee. Always use same-AZ routing.