AWS Internet Access: IGW vs. NAT Gateway
In the AWS ecosystem, connectivity is the backbone of any architecture. Understanding how resources in a Virtual Private Cloud (VPC) communicate with the outside world is crucial for the SAA-C03 exam. This guide focuses on the two primary mechanisms: the Internet Gateway (IGW) and the NAT Gateway.
The Analogy: Think of an Internet Gateway as the front door of a retail store—customers can come in, and staff can go out. A NAT Gateway is like a security turnstile or a “one-way mirror”: your internal staff can go out to grab supplies, but no one from the outside can push through that door to enter the building.
Core Concepts & Well-Architected Framework
What & Why?
- Internet Gateway (IGW): A horizontally scaled, redundant, and highly available VPC component that allows communication between your VPC and the internet. It provides a target in your VPC route tables for internet-bound traffic.
- NAT Gateway (Network Address Translation): A managed service that enables instances in a private subnet to connect to services outside your VPC, but prevents the external services from initiating a connection with those instances.
The Well-Architected Perspective
- Reliability: NAT Gateways are managed by AWS and automatically scale with your bandwidth needs (up to 100 Gbps).
- Security: By using NAT Gateways, you keep your application servers in private subnets, reducing the “blast radius” and exposure to direct internet attacks.
- Performance Efficiency: IGWs do not have bandwidth limits; they are limited only by the throughput of your EC2 instances.
Comparison: Connectivity Options
| Feature | Internet Gateway (IGW) | NAT Gateway | NAT Instance (Legacy) |
|---|---|---|---|
| Subnet Type | Public Subnets | Private Subnets (via Public) | Private Subnets (via Public) |
| Traffic Direction | Two-way (Inbound/Outbound) | Outbound Only | Outbound Only |
| Management | Managed by AWS | Managed by AWS | Self-managed EC2 |
| High Availability | Built-in (Highly Available) | Highly Available in 1 AZ | User-configured (Scripting) |
| Cost | Free (Data transfer applies) | Hourly charge + Data usage | EC2 Instance cost |
Scenario-Based Decision Matrix
- If you need to host a public-facing web server Then use an Internet Gateway and assign a Public IP/Elastic IP.
- If your backend database needs to download security patches from the internet Then use a NAT Gateway located in a public subnet.
- If you need to minimize costs for a non-production, low-traffic environment Then consider a NAT Instance (though rarely recommended for SAA-C03).
- If you need 45 Gbps of burstable throughput for a private subnet Then use a NAT Gateway.
Exam Tips: Golden Nuggets
- The “Public Subnet” Rule: A subnet is only “public” if its route table has a route to an IGW. Otherwise, it is private.
- NAT Gateway Placement: A NAT Gateway must be placed in a public subnet to work, even though it serves instances in a private subnet.
- Multi-AZ Redundancy: NAT Gateways are redundant within a single AZ. For true regional high availability, create one NAT Gateway in each Availability Zone.
- Security Groups: You cannot associate a Security Group with a NAT Gateway. You control traffic at the Instance level or via Network ACLs.
Architecture Flow: Internet Egress
Key Services
IGW: Gateway for the entire VPC. Required for public IP communication.
NAT GW: Managed translation service for private subnets.
Common Pitfalls
Forgetting to update the Route Table of the private subnet to point 0.0.0.0/0 to the NAT Gateway. NAT Gateways do not support IPv6 (use Egress-Only IGW instead).
Quick Patterns
Bastion Host: Put in Public Subnet (IGW) to SSH into Private Subnet.
Patching: DB in Private Subnet -> NAT GW -> Internet.