AWS NAT Gateway explained in practical cloud networking terms
AWS NAT Gateway is the managed service that allows resources in private subnets to initiate outbound connectivity without making those resources directly reachable from the internet. It is one of the key building blocks behind secure AWS application architectures.
This page goes beyond the basic definition. It explains where NAT Gateway sits in a VPC, how route tables and Internet Gateway work with it, why NAT Gateway placement matters, when one NAT Gateway per Availability Zone is the safer design, and where teams often make design or troubleshooting mistakes.
At a glance
A quick summary before the deeper sections on route flow, resiliency, Terraform, and real-world NAT Gateway design.
NAT Gateway is about outbound access
Its job is not to make private workloads public. Its job is to let them initiate external communication safely.
Routing defines the behavior
NAT Gateway only makes sense when private subnet route tables send internet-bound traffic to it correctly.
Availability Zone design is important
A single NAT Gateway for multi-AZ workloads may look simpler, but it can create resiliency problems.
Managed does not mean “design-free”
You still need correct subnet placement, Elastic IP handling, route logic, and operational awareness.
What is an AWS NAT Gateway?
A NAT Gateway is the AWS managed Network Address Translation service used to give private subnet resources outbound connectivity to destinations outside the subnet’s private address space. In the common internet-access scenario, this means private subnet resources can reach the internet without being directly reachable from it.
In practical terms, NAT Gateway exists because many workloads should stay inside private subnets. Application servers, worker nodes, internal APIs, background jobs, and private compute often need to install updates, pull packages, call third-party APIs, or reach public endpoints. At the same time, those workloads should not be exposed to direct unsolicited inbound internet traffic.
NAT Gateway solves that by acting as a controlled outbound path. It is part of a broader route design where:
- The NAT Gateway is created in a public subnet
- The public subnet has internet-facing routing through an Internet Gateway
- Private subnets route outbound traffic to the NAT Gateway
- Return traffic comes back through the established translation path
Simple definition
AWS NAT Gateway is the managed outbound path for private subnet resources.
What it is good at
- Outbound internet access from private subnets
- Reducing direct exposure of application instances
- Simplifying NAT operations compared with self-managed NAT instances
- Supporting common secure VPC architecture patterns
What it is not
- It is not an inbound internet entry point
- It is not a replacement for an Internet Gateway
- It is not a security group or firewall
- It is not a universal answer when VPC endpoints or private connectivity options fit better
Why NAT Gateway matters in AWS networking
NAT Gateway matters because secure cloud networking is rarely about making everything public. Most mature AWS environments want a clear separation between public entry points and private workloads.
Private workloads still need outbound access
Internal compute often needs package repositories, updates, external APIs, or vendor endpoints even if it should never accept direct inbound internet requests.
Security architecture becomes cleaner
Keeping app and worker tiers private reduces exposure while still supporting practical operational requirements.
Managed service reduces NAT operations
Many teams prefer a managed NAT service over maintaining EC2-based NAT instances and patching or scaling them manually.
Typical reasons NAT Gateway appears in architecture
- Application servers download packages or OS updates
- Private containers pull dependencies or reach external services
- Internal jobs call payment, messaging, or SaaS APIs
- Private compute needs outbound access without public exposure
What NAT Gateway helps prevent
- Making private instances public just for updates
- Overusing public subnets where private subnets are more appropriate
- Confusing outbound internet needs with inbound access design
AWS NAT Gateway through the 5 W’s + How
What
A managed NAT service used to let private subnet resources initiate outbound connectivity.
Why
To keep workloads private while still allowing updates, package downloads, and external API access.
When
When private subnets need outbound internet access and direct inbound exposure is not desired.
Where
Created in a public subnet and used by private subnets through route-table configuration.
Who should care
- Cloud engineers
- DevOps engineers
- Platform engineers
- Security architects
- Teams running private compute in VPCs
How it works conceptually
- Create a public NAT Gateway in a public subnet
- Associate the required addressing for public internet use
- Point private subnet default routes to the NAT Gateway
- Allow outbound traffic initiation from private resources
- Keep unsolicited inbound internet initiation blocked
How AWS NAT Gateway works in practice
NAT Gateway works as part of a route design, not as a standalone magic box. The most common operational pattern is private subnet outbound internet access through a public NAT Gateway.
Step-by-step flow
- A private resource initiates outbound traffic.
- The private subnet route table sends default internet-bound traffic to the NAT Gateway.
- The NAT Gateway, which sits in a public subnet, forwards traffic outward.
- The public subnet’s path to the Internet Gateway supports internet egress.
- Response traffic returns through the NAT translation path to the originating private resource.
What must exist for a common public NAT design
- A public subnet for the NAT Gateway
- Correct internet-facing routing for that public subnet
- Private subnet route tables with a default route to the NAT Gateway
- Correct subnet associations
- Thoughtful multi-AZ design when workloads span multiple Availability Zones
What people often miss
- The NAT Gateway itself is in a public subnet, not a private subnet
- Private subnet behavior depends on its route table
- “Private” does not mean “can never go out”; it means “not directly internet-reachable”
AWS NAT Gateway architecture diagram
The diagram below shows the correct common NAT Gateway pattern: an Internet Gateway attached to the VPC, NAT Gateways placed in public subnets, private subnet route tables pointing outbound traffic to NAT Gateways, and private workloads remaining non-public while still reaching the internet or external services outbound.
Route flow and route-table relationship
NAT Gateway behavior is inseparable from route-table design. A private subnet becomes “internet-capable outbound” through the route table, not by magic and not merely by being called private.
Public subnet route table
0.0.0.0/0 ---> Internet Gateway
Private subnet route table
0.0.0.0/0 ---> NAT GatewayPublic subnet role
The public subnet is where the NAT Gateway lives in the common design, and its route path must allow outward access toward the Internet Gateway.
Private subnet role
The private subnet sends internet-bound traffic to the NAT Gateway instead of directly to the Internet Gateway, which preserves the private architecture pattern.
NAT Gateway vs other networking options
NAT Gateway vs Internet Gateway
| Area | NAT Gateway | Internet Gateway |
|---|---|---|
| Main role | Outbound connectivity path for private resources | Internet connectivity component for public internet routing |
| Common use | Private subnets need outbound access | Public subnet internet access pattern |
| Inbound public reachability | No unsolicited inbound initiation | Supports public routing patterns when architecture allows |
NAT Gateway vs NAT instance
| Area | NAT Gateway | NAT Instance |
|---|---|---|
| Operational model | Managed AWS service | Self-managed EC2-based design |
| Maintenance | Lower operational burden | More instance management responsibility |
| When people compare them | Standard managed VPC egress design | Custom or legacy NAT patterns |
NAT Gateway vs VPC endpoints
| Question | NAT Gateway | VPC Endpoints |
|---|---|---|
| Main fit | General outbound connectivity path | Private access path to specific supported AWS services |
| Why compare them | Used for broader external reach | Often reduces need to traverse public internet for supported AWS services |
| Architecture outcome | General egress pattern | Service-specific private connectivity pattern |
High-availability and multi-AZ NAT Gateway design
NAT Gateway is Availability Zone-specific. That matters a lot in resilient architectures.
Each NAT Gateway belongs to one AZ
That means its failure domain and its routing implications are tied to that Availability Zone design.
Shared single NAT can create risk
If workloads across multiple AZs depend on one NAT Gateway and that AZ has an issue, other AZ resources can lose outbound access.
One NAT per AZ is the safer pattern
For resilient multi-AZ architectures, route each AZ’s private resources to a NAT Gateway in the same AZ.
AWS NAT Gateway videos
These are embedded as large videos with short bridge text so the page feels guided rather than like a plain video stack.
Terraform example for NAT Gateway basics
Below is a simple example showing the kind of Terraform resources often involved in a public NAT Gateway pattern.
resource "aws_eip" "nat_eip" {
domain = "vpc"
tags = {
Name = "nat-eip-a"
}
}
resource "aws_nat_gateway" "nat_a" {
allocation_id = aws_eip.nat_eip.id
subnet_id = aws_subnet.public_a.id
tags = {
Name = "nat-gateway-a"
}
}
resource "aws_route" "private_default_route" {
route_table_id = aws_route_table.private_a.id
destination_cidr_block = "0.0.0.0/0"
nat_gateway_id = aws_nat_gateway.nat_a.id
}What this shows
- An address allocation for the public NAT use case
- A NAT Gateway placed in a public subnet
- A private route table sending default outbound traffic to the NAT Gateway
What a full design would also include
- VPC and subnet resources
- Internet Gateway
- Public subnet route table
- Optional multi-AZ duplication for resiliency
Real-world NAT Gateway use cases
Application servers in private subnets
App servers can install updates, fetch packages, and call external APIs without being directly internet-exposed.
Private worker nodes
Workers, jobs, or backend compute can reach required public endpoints while remaining behind private networking boundaries.
Platform-managed private compute
Organizations often standardize NAT Gateway in shared network patterns so private workloads behave consistently across environments.
Typical three-tier example
- Public subnets host internet-facing load balancers
- Private app subnets host application servers
- Private database subnets host databases
- App subnets use NAT Gateway for outbound-only internet reach
Useful memory trick
Internet Gateway is the public front gate. NAT Gateway is the controlled outbound exit path for private internal teams that need to go out but should not let strangers come in directly.
Common NAT Gateway mistakes
Placing it in the wrong subnet
A public NAT Gateway belongs in a public subnet, not a private subnet.
Missing route-table logic
Private subnet outbound traffic must actually point to the NAT Gateway, or the design will not work.
Assuming NAT allows inbound internet access
It does not. NAT Gateway is about outbound initiation for private resources.
Using one NAT for multi-AZ without thinking about resiliency
A single shared NAT may look simpler but can create Availability Zone dependency for outbound connectivity.
Ignoring alternatives
For some service-specific AWS access patterns, VPC endpoints may be the more targeted design.
Forgetting cost-aware architecture review
NAT Gateway is managed and convenient, but architecture should still be intentional, especially at scale.
AWS NAT Gateway troubleshooting guide
Troubleshooting NAT Gateway is usually about route logic, placement, subnet design, or misunderstanding what NAT Gateway does and does not do.
| Issue | Likely cause | What to check | Fix direction |
|---|---|---|---|
| Private instance cannot reach internet | Route issue or placement issue | Private route table, NAT placement, public subnet internet path | Validate end-to-end route design |
| NAT exists but traffic still fails | Subnet or route association mismatch | Correct route table attached to the private subnet | Re-check route-table association and default route |
| Multi-AZ app loses outbound access during AZ issue | Single-NAT dependency | Whether each AZ has its own NAT path | Use per-AZ NAT design for better resiliency |
| Team expects inbound access through NAT | Design misunderstanding | Architecture intent and routing assumptions | Use proper public entry components instead of NAT for inbound internet access |
Quick check list
- Is the NAT Gateway in the correct public subnet?
- Does the public subnet have the required outward routing relationship?
- Does the private subnet route default traffic to the NAT Gateway?
- Is the private workload actually in the private subnet you think it is?
Architecture check list
- Should this workload use NAT Gateway at all?
- Would VPC endpoints reduce unnecessary general internet egress?
- Should each Availability Zone have its own NAT path?
- Are teams confusing public and private subnet behavior?