NAT Gateway vs Internet Gateway

What each one actually does

Internet Gateway (IGW)

The Internet Gateway is a virtual router that connects the VPC to the public internet. It does three things:

• Routes traffic destined for the internet outbound.
• Accepts inbound traffic destined for public IPs in the VPC.
• Performs 1:1 NAT between the private IP of an instance and its assigned public IP (for instances with public IPs) — at no extra hop.

It has no bandwidth cap, no per-GB charge, no hourly charge. It is purely a route. The bandwidth bottleneck and the cost happen on either end (the instance's bandwidth allocation, and the egress data transfer charge to the internet).

NAT Gateway

The NAT Gateway is a managed appliance that performs port address translation (PAT/NAPT) so that multiple private instances can share a single public IP for outbound connections. It does one thing:

• Translates outbound traffic from private subnets so the source IP becomes the NAT Gateway's public IP. Return traffic is reverse-translated and forwarded back to the originating instance.

It can also be deployed in a "private NAT" mode (AWS) that performs PAT without using a public IP — useful for routing overlapping CIDR ranges between connected networks.

When to use each

The cost reality

This is where the gateway choice has the most operational impact. AWS pricing in 2026 (us-east-1):

• Internet Gateway: $0/hour, $0/GB processed.
• NAT Gateway: $0.045/hour per gateway + $0.045/GB processed.
• Egress to internet: $0.09/GB for the first 10 TB/month, regardless of which gateway it goes through.

For a high-availability setup with one NAT Gateway in each of three AZs, that is $0.135/hour just in NAT idle cost = $99/month before any traffic. Then every GB of outbound traffic costs $0.045 (NAT processing) + $0.09 (internet egress) = $0.135/GB.

For comparison, traffic through an IGW costs only the $0.09/GB egress. So traffic that needs internet but happens to come from a public subnet (with an IGW path) costs 50% less than the same traffic from a private subnet (NAT + IGW). This is rarely the right reason to put workloads in public subnets — security trumps cost — but the gap is real.

AZ-aware NAT placement

A NAT Gateway is a zonal resource. It lives in one specific AZ and survives infrastructure failures within that AZ, but if the whole AZ goes down, the NAT Gateway is unreachable. The correct pattern for HA:

• One NAT Gateway per AZ that contains private subnets.
• Each private subnet's route table points its 0.0.0.0/0 route at the NAT Gateway in its own AZ.

If you instead use a single NAT Gateway in AZ-A as the egress for private subnets in AZ-A, AZ-B, and AZ-C:

1. If AZ-A fails, the entire VPC loses internet egress.
2. Traffic from AZ-B and AZ-C to the NAT Gateway in AZ-A incurs cross-AZ data transfer charges ($0.01/GB each direction).

The cross-AZ charge often equals the cost of running additional NAT Gateways for sufficiently high traffic. Always provision NAT per AZ.

The egress trap: NAT for AWS service traffic

A common cost surprise: an application in a private subnet that downloads heavily from S3 or DynamoDB pays full NAT Gateway data processing + internet egress for that traffic — because the route to S3 goes through the NAT Gateway and out the Internet Gateway, even though S3 is technically inside AWS.

VPC endpoints fix this:

• Gateway endpoints (S3, DynamoDB only): free, route table updates send those service prefixes to the endpoint instead of the NAT.
• Interface endpoints (most other services): hourly cost (~$7/month per endpoint per AZ) plus per-GB processing (~$0.01/GB), but avoid the $0.045/GB NAT processing and the public internet round-trip.

For S3-heavy workloads, gateway endpoints reduce NAT processing costs to zero for that traffic. The savings often pay for the entire VPC's other costs.

NAT instance: the cheap alternative

Before NAT Gateway became a managed service, the common pattern was a NAT instance — a small EC2 with IP forwarding enabled, acting as the NAT. NAT instance is still available and can be appropriate:

• Cost: A t3.nano running 24/7 costs ~$4/month vs ~$32/month for a NAT Gateway in the same AZ.
• Throughput: Limited by instance bandwidth. A t3.nano caps at 32-64 Mbps sustained; large instance types reach multi-Gbps.
• Operations: You patch it, monitor it, replace it on failure. Auto Scaling groups can provide automatic recovery.

NAT instance makes sense for dev/test environments with low traffic where saving $30/month per AZ matters. For production, the operational overhead of running NAT instances usually outweighs the savings, and the throughput ceiling can become a hard limit.

Centralized egress: one NAT for many VPCs

For organizations with many VPCs, deploying a NAT Gateway in every VPC × every AZ is expensive. The centralized egress pattern shares NAT capacity across VPCs:

1. Create an "egress VPC" containing NAT Gateways (one per AZ) and an Internet Gateway.
2. Attach the egress VPC and all spoke VPCs to a transit gateway.
3. Spoke VPCs route 0.0.0.0/0 via the transit gateway.
4. Transit gateway forwards to the egress VPC.
5. Egress VPC NATs the traffic out via its IGW.

Trade-off: transit gateway data processing ($0.02/GB) adds a cost line, but you save on per-VPC NAT Gateway hourly fees. Break-even is around 4-5 VPCs.

Centralized egress also enables consistent egress firewalling — you can place a security appliance (AWS Network Firewall, third-party firewall) in the egress VPC and inspect all outbound traffic before NAT.

IPv6 considerations

IPv6 has no NAT in the cloud equivalent — every IPv6 address is globally routable by design. The closest equivalent is the Egress-Only Internet Gateway (AWS), which allows private subnets to initiate outbound IPv6 connections without accepting inbound. Its semantics mirror NAT Gateway: outbound only, return traffic allowed, but no address translation since none is needed.

For dual-stack VPCs, you typically have:

• IGW for inbound public IPv4 and IPv6.
• NAT Gateway for outbound private IPv4.
• Egress-Only IGW for outbound IPv6 from private subnets.

Frequently Asked Questions

Do I need a NAT Gateway in every availability zone?

Yes for production. A NAT Gateway is a zonal resource — it lives in one specific AZ. If that AZ has an outage, instances in other AZs that route through it lose internet access. The correct pattern is one NAT Gateway per AZ that contains private subnets, with each private subnet's route table pointing at the NAT in its own AZ. This also avoids cross-AZ data transfer charges that would apply if all private subnets routed through a single NAT in one AZ.

What is the difference between a NAT Gateway and a NAT instance?

NAT Gateway is a managed service — AWS, Azure, or GCP handles patching, HA within the AZ, and scaling up to 45 Gbps. NAT instance is an EC2/VM you run yourself; you patch it, monitor it, size it. NAT instances cost less per hour but require operational effort and have lower throughput (limited by instance size). Use NAT Gateway for production. NAT instance is appropriate only for cost-sensitive dev environments and even then, VPC-router-based NAT is increasingly preferred.

Can I use one NAT Gateway for traffic from multiple VPCs?

Yes, via a transit gateway and a centralized egress VPC. The egress VPC contains the NAT Gateway; other VPCs route their default route through the transit gateway, which forwards to the egress VPC, which NATs out via its single Internet Gateway. This pattern reduces total NAT cost across many VPCs but adds transit gateway data-processing charges. The breakeven is roughly 4-5 VPCs.

Why is my NAT Gateway expensive even though my outbound traffic is small?

NAT Gateway has two cost components: an hourly fixed charge (~$0.045/hour = ~$32/month) and a per-GB data processing charge (~$0.045/GB). The hourly charge applies even when the gateway is idle. For workloads with minimal outbound traffic, the hourly cost dominates. Across three AZs that is roughly $100/month before any data transfer. If your egress is small and constant, consider whether a NAT instance ($5-15/month) or VPC endpoints (free for S3/DynamoDB) would be cheaper.

Can a NAT Gateway accept inbound connections from the internet?

No — that is by definition not a NAT Gateway's job. NAT Gateway is one-way: it allows private subnets to initiate connections outbound to the internet and accepts the return traffic for those connections. The internet cannot initiate connections to instances behind a NAT Gateway. For inbound connectivity, use an Internet Gateway with public IPs on the instances, or a load balancer in a public subnet that forwards to private instances.