NAT Gateway vs NAT Instance: Cost and Operational Tradeoffs

A NAT device lets resources in a private subnet reach the internet for updates, package downloads and API calls without accepting unsolicited inbound connections. On AWS you can provide that path with a managed NAT gateway or with an EC2 instance you configure as a NAT instance. The right choice depends on how much traffic you send, how much availability you need, and who on your team will operate it.

Quick answer: use a NAT gateway when managed availability and low administration are worth its hourly and per-gigabyte charges, which is the right default for most production workloads. Use a NAT instance only when you have a specific reason, such as very low traffic in a non-production environment, port forwarding, or custom traffic handling, and when you accept owning its patching, sizing and failover.

What a NAT device does

Instances in a private subnet have no public IP address. A route in the subnet's route table sends internet-bound traffic to the NAT device, which sits in a public subnet, translates the private source address, and sends the traffic out through the internet gateway. Replies come back the same way. Connections must be started from inside the VPC, so the internet cannot open a connection to your private instances through the NAT device. If the idea of public and private subnets is new, read What Is a VPC in AWS? first.

NAT gateway vs NAT instance at a glance

Area	NAT gateway	NAT instance
Availability	Redundant within its Availability Zone; create one per AZ for a zone-independent design	You script and test failover between instances
Bandwidth	Scales up to 100 Gbps	Limited by the instance type
Maintenance	Managed by AWS	You apply OS and software updates
Cost model	Hours provisioned plus data processed	Instance hours (type and size) plus your operating time
Sizing	Nothing to choose	You pick an instance type for the expected load
Security groups	Cannot be attached; apply them to the resources behind it	Can be attached to the instance
Port forwarding and bastion use	Not supported	Possible with manual configuration
Fragmented packets	UDP only; fragmented TCP and ICMP packets are dropped	Reassembles UDP, TCP and ICMP
Observability	CloudWatch metrics and flow logs	CloudWatch metrics for the instance and flow logs

The fragmented-packet difference matters in practice. If an application sends fragmented TCP traffic through the NAT path, a NAT gateway will drop it, and you would only find out when a specific workload misbehaves.

Zonal and regional NAT gateways

A NAT gateway has traditionally lived in a single Availability Zone, in a public subnet. To avoid one zone failure cutting off outbound access for every private subnet, you create a NAT gateway in each zone and route each zone's private subnets to its local gateway.

AWS also offers a regional NAT gateway. It is created at the VPC level without choosing subnets and expands into the Availability Zones where your workloads run. Expansion into a newly used zone can take up to about an hour, and traffic from a new zone is processed through an existing zone until it completes. Regional NAT gateways do not support private NAT, so use a zonal gateway for that case. A regional gateway is billed per Availability Zone where it is configured, so it removes routing work rather than the per-zone hourly charge. Check the AWS documentation for current availability before planning around it.

How NAT gateway cost adds up

A NAT gateway is billed on two dimensions: each hour it is provisioned (a partial hour counts as a full hour) and each gigabyte it processes. Standard data transfer charges still apply, and public IPv4 addresses are billed separately.

As an example, AWS's pricing page lists US East (Ohio) at $0.045 per NAT gateway hour and $0.045 per GB processed. At those example rates, one gateway running a 730-hour month costs about $33 before any traffic. Three gateways, one per zone, cost about $99. Every 1,000 GB sent through them adds about $45. Rates differ by Region and change over time, so confirm yours on the Amazon VPC pricing page before you model anything.

Two details commonly surprise teams:

• Cross-zone traffic. If an instance sends traffic to a NAT gateway in a different Availability Zone, data transfer charges apply between them. Routing every zone through one gateway to save the hourly charge can cost more in transfer, and it makes that zone a single point of failure.
• Hidden heavy traffic. Container image pulls, OS and package updates, backups to external services and large downloads all count. The bill is driven by bytes, not by how many instances sit behind the gateway.

How NAT instance cost adds up

A NAT instance has no per-gigabyte processing fee. You pay for the EC2 instance by the hour, so the cost depends on the instance type and size you choose. That can look much cheaper at high volume, but the comparison is incomplete without:

• an instance large enough for peak bandwidth, since throughput depends on the instance type
• a second instance and failover automation if you need resilience
• patching, monitoring and the time of the person who will be paged when it fails
• the same cross-zone transfer charges, if instances use a NAT in another zone

A small saving on the monthly bill is easy to lose to one outage or a few engineering days. Count operating time as a real cost.

Reduce NAT traffic before you choose

The cheapest NAT traffic is traffic that never goes through NAT. Many bills improve by changing the path rather than the device.

• Gateway endpoints for S3. AWS states there is no additional charge for gateway endpoints, so traffic to S3 can bypass the NAT gateway entirely. DynamoDB also has a gateway endpoint; confirm its terms on the AWS endpoint pages.
• Interface endpoints cost extra. They suit services that have no gateway endpoint, but they have their own charges, so compare them with the NAT cost for that traffic. If you enable private DNS on an interface endpoint for a service that also has a gateway endpoint, you may pay interface endpoint charges for traffic the free gateway endpoint could have carried.
• Pull images and packages from inside AWS where practical, for example by using a registry or mirror in the same Region.
• Find the top destinations. VPC flow logs and NAT gateway CloudWatch metrics show which subnets and destinations send the most bytes. A single noisy job can account for most of the bill.

When a NAT instance still makes sense

A NAT instance is a reasonable choice when all of these are true: the environment is non-production or low traffic, an outage is tolerable, you need a feature a NAT gateway lacks such as port forwarding or bastion use, and someone owns the instance. It also works as a deliberate stopgap when measured NAT gateway traffic is small and a short outage is acceptable.

If you use one, disable the source/destination check on the instance so it can forward traffic, size it for peak rather than average bandwidth, keep it patched, alarm on its health, and test the failover you are relying on.

Practical scenarios

Production web app with a private application tier. Use a NAT gateway in each Availability Zone, route each zone's private subnets to its local gateway, add an S3 gateway endpoint, and watch NAT bytes by subnet.

Staging or development environment. One NAT gateway or a small NAT instance can be enough. Pick the one whose weaker availability the team can live with, and consider switching it off outside working hours if nothing needs to reach the internet.

Heavy outbound data transfer. If large volumes go to a single AWS service, an endpoint may remove most of the NAT cost. If they go to the public internet, model the per-gigabyte charge at peak volume before committing.

Cost review after a bill increase. Start with where the bytes go. Our guide to reducing your AWS monthly bill and the AWS cost audit checklist cover the surrounding checks.

A short decision checklist

1. Measure bytes per private subnet and destination for a representative month.
2. Move eligible AWS-service traffic to endpoints before sizing the NAT path.
3. Decide how much outbound downtime each environment can tolerate.
4. Price the gateway option per zone, including data processing, at typical and peak traffic.
5. Price the instance option including a standby, patching and engineering time.
6. Test failover for whichever option you choose, and document who owns it.

Verify with AWS

• Compare NAT gateways and NAT instances
• NAT gateways
• Regional NAT gateways
• Gateway endpoints for Amazon S3
• Amazon VPC pricing

The practical takeaway

Default to a NAT gateway per zone for production, reduce the traffic that needs it with endpoints, and treat a NAT instance as a deliberate exception that you can operate. The monthly bill is only part of the cost; availability and the time spent running the device count too. If your NAT charges are a large part of your bill, an AWS cost optimization review or a look at your network and routing design can show where the bytes are going. You can also book a free AWS audit.

Related reading: What Is a VPC in AWS?, How to Reduce Your AWS Monthly Bill, AWS Cost Audit Checklist