AWS NAT Gateway: What It Is and When to Use It

Definition

AWS NAT Gateway is a managed Network Address Translation service that gives resources in private subnets the ability to initiate outbound connections to the internet (or to other VPCs/on-premises, in the case of private NAT Gateway) while remaining unreachable from the internet. It is a replacement for the older self-managed NAT Instance pattern: AWS handles scaling (up to 45 Gbps), HA within an AZ, software maintenance, and ENI assignment.

NAT Gateway is not a general-purpose firewall — it performs source-NAT on outbound traffic and port-NAT on return packets. It does not allow unsolicited inbound connections, which is exactly why it is a standard component of every well-architected three-tier VPC.

How It Works

A NAT Gateway is deployed into a specific subnet in a specific Availability Zone. Depending on its variant, it gets either a public IP (for internet egress) or only private IPs (for cross-VPC/on-prem egress).

1. A private-subnet instance sends a packet destined for the internet (e.g., 1.2.3.4:443).
2. The subnet's route table has 0.0.0.0/0 → NAT Gateway, so the packet is forwarded to the NAT.
3. The NAT Gateway rewrites the source IP from the instance's private IP to its own (public or private) IP and records the mapping.
4. The packet egresses via the Internet Gateway (for public NAT) or through a Transit Gateway / VPN (for private NAT).
5. The return packet arrives, the NAT Gateway looks up the mapping, and rewrites the destination IP back to the instance's private IP.

Because NAT Gateway is stateful and tracks connections, it enforces the "outbound only" property automatically — there is no way to configure inbound rules on a NAT Gateway.

Variants

• Public NAT Gateway — default. Lives in a public subnet; gets an Elastic IP; routes egress to an IGW. Used for private-subnet instances that need to reach the internet.
• Private NAT Gateway — lives in a private subnet; has only private IPs; routes egress via a Transit Gateway, VPC peering, or VPN. Used for cross-VPC or hybrid NAT when you need to overlap CIDRs or hide private IPs behind a single egress IP without exposing the internet.

Key Features and Limits

• Throughput: bursts from 5 Gbps up to 45 Gbps per NAT Gateway, automatically.
• Connection limit: 55,000 simultaneous connections per unique destination (destination IP + destination port). To a single destination, more than 55K concurrent flows will fail; scale by adding more NAT Gateways or spreading destinations.
• Port allocation: ~64,000 source ports per NAT GW public IP. Attach up to 8 Elastic IPs (secondary IPs, since 2024) to extend port capacity for high-fan-out workloads.
• Availability: HA within a single AZ. For Multi-AZ resilience, deploy one NAT Gateway per AZ and route each private subnet to the NAT in its own AZ.
• Protocols: TCP, UDP, ICMP (for echo only).
• IPv6: NAT Gateway does not perform IPv6 NAT. For IPv6 egress, use an Egress-Only Internet Gateway (EIGW), which is free and outbound-only.
• Security Groups: NAT Gateway does not support SGs; use subnet NACLs or the instance SG for filtering.
• Billing: per-hour + per-GB processed (both ingress and egress data count).

Common Use Cases

1. Private-subnet outbound — EC2 / ECS / EKS / Lambda in private subnets downloading OS updates, container images from public registries, calling third-party APIs.
2. Regulated workloads — instances must not have public IPs but still need internet for patching and telemetry.
3. Cross-VPC NAT (private NAT GW) — overlapping CIDRs between two VPCs joined by Transit Gateway; private NAT in one VPC rewrites the source address so the destination sees a non-overlapping IP.
4. Centralized egress — a "shared services" VPC hosts a NAT Gateway, and spoke VPCs route 0.0.0.0/0 to it via Transit Gateway. Cheaper than a NAT per VPC at scale.
5. On-prem IP consistency — private NAT GW ensures traffic from many VPCs to on-prem appears from a single known CIDR, simplifying on-prem firewall rules.

Pricing Model

• NAT Gateway hourly: per-hour charge per NAT Gateway (billed even when idle), roughly $0.045/hour in us-east-1 (verify current rates).
• Data processing: per-GB charge for all data processed (both directions). Roughly $0.045/GB in us-east-1.
• Data transfer: standard AWS data-transfer charges apply on top (e.g., outbound to internet).
• Elastic IP: the attached EIP is free while associated with a running NAT Gateway. Additional secondary EIPs count against your EIP quota.

NAT Gateway is often the #1 surprise line item on AWS bills. Two common mitigations:

• VPC Endpoints for S3/DynamoDB (Gateway endpoints are free) and for other AWS services (Interface endpoints); they bypass NAT and save both NAT and data-transfer costs.
• Centralized egress via a shared VPC + Transit Gateway to share one NAT Gateway across many VPCs.

Pros and Cons

Pros

• Managed: no OS patching, no failover scripts.
• Highly scalable: bursts to 45 Gbps and 55K connections per destination.
• Secure by design: outbound only, cannot accept inbound connections.
• Integrates with CloudWatch: BytesIn/Out, ActiveConnectionCount, ErrorPortAllocation metrics.
• Public and private variants cover both internet and cross-VPC/on-prem use cases.

Cons

• Pricy at scale: $0.045/GB data-processing fee adds up quickly for data-heavy workloads.
• Single-AZ HA: for multi-AZ resilience you need one NAT per AZ (doubling cost).
• No Security Groups: can't filter at the NAT itself.
• No IPv6: use Egress-Only IGW for IPv6.
• 55K-per-destination connection cap: can be a real bottleneck for applications that hammer a small number of APIs.

Comparison with Alternatives

| Feature | NAT Gateway | NAT Instance | Egress-Only IGW | VPC Endpoints | | --- | --- | --- | --- | --- | | Management | AWS-managed | Self-managed EC2 | AWS-managed | AWS-managed | | IP version | IPv4 only | IPv4 (IPv6 possible) | IPv6 only | IPv4 + IPv6 | | HA | Per-AZ | Self-configure ASG | Regional | Regional (Interface) / Regional (Gateway) | | Max throughput | 45 Gbps | Instance-size dependent | Scales automatically | Scales automatically | | Security group | No | Yes | No | Yes (Interface) | | Cost | Hourly + per-GB | Instance cost only | Free | Per-hour + per-GB (Interface); Gateway free | | Direction | Outbound only (public) | Outbound (can be inbound too) | Outbound only | Bidirectional to AWS service | | Best for | Standard private egress | Legacy / cost-sensitive lab | IPv6 egress | Private access to AWS services |

NAT Instance was the original pattern before NAT Gateway launched in 2015 — you run an EC2 instance with sysctl net.ipv4.ip_forward=1 and source-NAT iptables rules. It can be cheaper at low scale but you manage OS updates and HA yourself; NAT Gateway is the default choice today for production.

Exam Relevance

• Solutions Architect Associate (SAA-C03) — very common: NAT Gateway placement (public subnet with EIP), one per AZ for HA, private vs public NAT, cost-optimization via VPC Endpoints for S3/DynamoDB.
• SysOps Administrator (SOA-C02) — CloudWatch metrics, ErrorPortAllocation diagnosis (assign more EIPs or more NAT GWs), troubleshooting lost connectivity when NAT is missing a route.
• Developer Associate (DVA-C02) — Lambda in VPC reaching the internet requires a NAT Gateway (because Lambda ENIs are in private subnets).
• Advanced Networking Specialty (ANS-C01) — centralized egress via TGW + shared NAT, private NAT GW for CIDR overlap, multi-EIP port extension, IPv6 egress-only IGW.

Classic exam traps: NAT Gateway is AZ-scoped — for HA, deploy one per AZ. NAT Gateway does not allow inbound — use an ALB/NLB with a target in a private subnet for that. NAT Gateway does not support Security Groups — control at subnet NACL or target SG. For IPv6 egress, use an Egress-Only IGW, which is free.

Frequently Asked Questions

Q: Why do I need one NAT Gateway per Availability Zone?

A: A NAT Gateway is highly available within a single AZ but has no cross-AZ redundancy — if the AZ fails, so does the NAT. For a resilient architecture, deploy one NAT Gateway in each AZ's public subnet and point each private subnet's route table at the NAT in its own AZ. This also avoids unnecessary cross-AZ data-transfer charges, which apply when traffic leaves one AZ to enter another. The tradeoff is cost: three AZs mean three NAT Gateways, each with its own hourly fee.

Q: How can I reduce NAT Gateway costs?

A: Two of the biggest wins are VPC Endpoints and centralized egress. VPC Gateway Endpoints for S3 and DynamoDB are free and bypass the NAT entirely — for S3-heavy workloads, this single change can cut NAT bills dramatically. For other AWS services, Interface Endpoints (PrivateLink) are cheaper than NAT data processing in most scenarios. Centralized egress via a shared-services VPC + Transit Gateway consolidates many workloads onto one NAT Gateway rather than one per VPC. You can also monitor CloudWatch BytesOut and BytesIn to identify chatty workloads.

Q: What's the difference between a NAT Gateway and an Internet Gateway?

A: An Internet Gateway (IGW) is attached to a VPC and enables bidirectional internet connectivity for any resource with a public IP — it does not do NAT. A NAT Gateway is a consumer of an IGW: it sits in a public subnet, uses its own Elastic IP, and performs source-NAT so private-subnet instances (with no public IPs) can initiate outbound connections. The IGW is the "door to the internet"; the NAT Gateway is the "proxy" that lets private-IP residents use it without exposing themselves. Both are required for the classic public/private subnet design.

---

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official NAT Gateway documentation before making production decisions.