AWS NAT Gateway Complete Guide: Zonal vs Regional + Architecture

Secure, Scalable Internet Egress for Private VPC Workloads

In a well-designed AWS environment, the most important systems are usually the least visible. Databases, application backends, internal APIs, and worker services are placed in private subnets, deliberately isolated from direct internet access. This isolation is a deliberate security decision. Yet isolation does not mean disconnection.

Operating systems still need patches. Applications still need to pull dependencies. Services still need to call external APIs. The challenge is enabling outbound connectivity without sacrificing inbound isolation. This is the problem the AWS NAT Gateway is designed to solve.

This guide explains what a NAT Gateway is, why it exists, how it works in practice, how it should be deployed in production, and where it fits and does not fit in a modern AWS network architecture.

Before we take a closer look at NAT Gateways, what is NAT?

What Is NAT (Network Address Translation)

Before cloud services and managed gateways, NAT emerged as a practical response to a simple constraint: IPv4 addresses are scarce, but private networks are everywhere.

At its core, Network Address Translation (NAT) is a networking technique that allows multiple devices using private IP addresses to communicate with external networks using one or a small number of public IP addresses.

It works by rewriting packet headers at the network boundary:

• When traffic leaves a private network, NAT replaces the private source IP with a public IP
• It records this mapping in a translation table
• When responses return, NAT uses that table to forward the traffic back to the correct private host

From the outside, all traffic appears to originate from the public IP. Internally, each private system remains isolated and unexposed.

Two properties of NAT are especially important:

1. Address conservation: Many private hosts can share a single public IP
2. Implicit inbound protection: External systems cannot initiate connections unless a mapping already exists, which naturally limits unsolicited inbound access

It is important to note that NAT is not a firewall. It does not inspect intent or enforce security policy. It simply translates addresses. Any security benefits are a side effect of connection state, not explicit access control.

What a NAT Gateway Actually Is

A NAT Gateway (Network Address Translation Gateway) is a managed AWS network service that allows resources in private subnets to initiate outbound connections to the internet or public AWS endpoints while preventing unsolicited inbound connections from reaching those resources.

A real-world analogy is a corporate office with no public entrance. Employees can leave the building to attend meetings or make deliveries, but no one from the street can walk in uninvited. All outbound traffic is visible and controlled; inbound access is blocked by design.

Technically, the NAT Gateway performs source network address translation (SNAT):

• A private instance sends traffic using its private IP (for example, 10.0.2.15)
• The NAT Gateway replaces that source IP with its own public IP
• Responses return to the NAT Gateway
• The NAT Gateway maps the response back to the original private IP and forwards it internally

Crucially, the NAT Gateway does not allow inbound session initiation. It only forwards return traffic for connections that were started from inside the VPC.

Why NAT Gateways Exist

In a standard VPC design, subnets fall into two broad categories:

• Public subnets: These have a route to an Internet Gateway (IGW) and are used for internet-facing components such as load balancers or bastion hosts
• Private subnets: These have no route to the IGW and are intentionally unreachable from the internet

The problem is straightforward. A private subnet with no default route to the internet cannot reach external services at all.

The NAT Gateway solves this by acting as a controlled egress point. Private subnets send outbound traffic to the NAT Gateway, which may reside in a public subnet or, for Regional NAT, operate without requiring a dedicated public subnet. The private resources remain private but are no longer isolated from the world they need to interact with.

This pattern delivers several concrete benefits:

• Reduced attack surface: No public IPs on application or database servers
• Operational necessity: OS updates, container image pulls, dependency downloads still work
• Clear trust boundary: All internet egress flows through a known, auditable component
• Managed reliability: No need to operate or scale NAT infrastructure yourself

Architecture: How a NAT Gateway Fits into a VPC

NAT Gateways only work when deployed with the correct network layout. Misplacing them is a common and costly mistake.

Required Components

1. Internet Gateway (IGW): Required for all internet egress
2. Public Subnet:
   • Required for Zonal NAT Gateways (one NAT per AZ)
   • Optional for Regional NAT Gateways, which can operate without separate public subnets
3. Elastic IP (EIP):
   • Assigned to NAT Gateway in Zonal NAT
   • For Regional NAT, EIP is allocated automatically if public access is needed
4. Private Subnets: Required for all workloads using NAT

Traffic Flow for Zonal NAT

Private EC2 Instance (10.0.2.15)
        |
        | outbound request
        v
Private Route Table: 0.0.0.0/0 → NAT Gateway in same AZ
        |
        v
NAT Gateway (Public Subnet, EIP)
        |
        v
Internet Gateway
        |
        v
Public Internet

Private instances never receive a public IP, and no inbound path exists from the internet back to them.

Traffic Flow for Regional NAT (2025+)

Private Subnet AZ1 → Regional NAT (auto-expands to AZ1)
Private Subnet AZ2 → Regional NAT (auto-expands to AZ2)
                       ↓ (Single NAT ID: nat-abc123)
Internet Gateway ← Public Internet

• Only one route table entry per VPC is required: 0.0.0.0/0 → nat-abc123
• Regional NAT automatically spreads endpoints to each AZ containing private subnets

How a NAT Gateway Handles Return Traffic

The NAT Gateway maintains a stateful translation table for every outbound connection it creates. That table allows return traffic to be delivered correctly.

Each translation entry maps:

• Public IP and public source port (owned by the NAT Gateway)
• to private IP and private source port of the originating resource

Conceptually:

Public IP : Public Port   ↔   Private IP : Private Port
203.0.113.10 : 62001      ↔   10.0.2.15 : 54321

Entries are temporary and removed when the connection expires.

Step-by-step flow

1. Private instance sends an outbound request:

10.0.2.15:54321 → 8.8.8.8:443

2. NAT Gateway rewrites the source and allocates a unique public port:

203.0.113.10:62001 → 8.8.8.8:443

3. NAT Gateway records the translation mapping

When the response returns:

8.8.8.8:443 → 203.0.113.10:62001

NAT Gateway:

1. Looks up destination port (62001)
2. Finds the corresponding private IP and port
3. Rewrites the packet:

8.8.8.8:443 → 10.0.2.15:54321

4. Forwards it to the private resource

If no matching entry exists, the packet is dropped.

Why unsolicited inbound traffic is dropped

1.2.3.4 → 203.0.113.10

There is no mapping, so the packet cannot be forwarded. NAT Gateways only allow return traffic.

High Availability: NAT Gateways in Multi-AZ Deployments

Traditionally, NAT Gateways were highly coming-soon only within a single AZ. If all private subnets were routed to a single NAT Gateway in one AZ, an AZ failure would leave workloads in other AZs without internet access, creating a cross-AZ dependency.

Classic Best Practice: One NAT Gateway Per AZ

For production workloads prior to November 2025:

• Deploy one NAT Gateway per AZ that contains private subnets
• Place each NAT Gateway in a public subnet in the same AZ
• Configure AZ-local route tables so private subnets send traffic only to their local NAT Gateway

This pattern:

• Avoids cross-AZ data transfer
• Preserves outbound connectivity during AZ failure
• Matches AWS fault-isolation model

The trade-off is cost. More NAT Gateways incur higher hourly and data processing charges. For workloads with strict AZ-level redundancy, this cost is justified.

Regional NAT Gateway

AWS introduced Regional NAT Gateways in late 2025:

• A single NAT Gateway can span all AZs in the VPC automatically
• It scales across AZs without separate NATs per zone
• Private subnets route to it at the VPC level
• Still requires an Internet Gateway for actual egress

Benefits:

• Simpler architecture: no need for multiple public subnets or route tables per AZ
• Automatic high availability: AZ failures do not block outbound connectivity
• Operational efficiency: reduces NAT management overhead

Pricing Note: Billed per hour per active AZ (3 AZs = 3 gateway-hours), plus standard data processing fees. No cost reduction compared to multiple zonal NATs.

Limitations (Jan 2026):

• Does not support private NAT (VPC-to-VPC only) - use zonal NATs
• Cannot mix zonal and regional NATs in the same route table
• Maximum of 32 IPs per AZ (vs 8 per zonal NAT)
• AZ expansion/contraction can take up to 60 minutes
• No cross-VPC peering support yet

When to choose Regional NAT:

• Automatic, AZ-agnostic high availability is desired
• Architecture does not require strict per-AZ isolation or compliance
• Route table simplicity is preferred

Classic “one NAT per AZ” remains valid for explicit AZ separation, deterministic routing, or traffic cost control.

NAT Gateway vs NAT Instance: Why the Managed Model Wins

NAT instances are now mostly relevant for narrow use cases. For general internet egress, NAT Gateways are the correct default.

Throughput and Scaling

Zonal NAT: Scales to approximately 100 Gbps per gateway automatically
Regional NAT: Higher limits, tested to 200+ Gbps VPC-wide, auto-scales across AZs

Key difference: Regional NAT endpoints appear in all AZs automatically, avoiding cross-AZ routing bottlenecks.

Cost Model: What You Are Actually Paying For

NAT Gateway pricing has two components:

1. Hourly charge: Every hour the NAT Gateway exists
2. Data processing charge: Volume of traffic processed for outbound connections, including responses

Regional NAT Note: Billed per hour per active AZ. Three AZs = three gateway-hours, same as running three zonal NATs.

Reducing NAT Gateway Cost (and When to Avoid It)

If private resources only access AWS services, prefer VPC Endpoints:

• Gateway Endpoints: S3, DynamoDB
• Interface Endpoints: ECR, Secrets Manager, SSM, SNS, SQS

Benefits:

• No NAT data processing charges
• Lower latency
• Traffic stays within AWS network
• Stronger security posture

In many mature architectures, NAT Gateways are used only for:

• OS updates
• External APIs
• Truly public endpoints

Everything else remains private.

Operational Notes Worth Knowing

• NAT Gateways expose CloudWatch metrics: packet drops, bytes processed
• Deleting a NAT Gateway immediately releases its Elastic IP
• Misconfigured route tables are the most common cause of “no internet” issues
• Cross-AZ routing to a zonal NAT is both costly and fragile

Regional NAT specifics:

• Appears as nat-xxxx in all AZs but has a single state backend
• Deletion cascades across all AZs
• Route propagation takes 5-10 minutes after VPC changes
• No requirement for separate public subnets in each AZ

Conclusion: What the NAT Gateway Really Represents

The NAT Gateway is a boundary between private and public, trusted and untrusted, internal and external.

Used correctly, it enables:

• Strong network isolation
• Predictable egress behavior
• Scalable, low-maintenance operations

Used carelessly, it becomes:

• A silent cost sink
• A cross-AZ dependency
• An architectural shortcut hiding better alternatives

The most mature AWS environments do not eliminate NAT Gateways. They consciously constrain their role. Understanding that distinction is what separates a working VPC from a well-architected one.