The "NAT problem" in AWS is a familiar one: your private subnets need to reach the internet (or AWS services like S3) for software updates, API calls, and similar — but you do not want those workloads directly accessible from the public internet. The three main solutions are NAT Gateway, NAT Instance, and VPC Endpoints. Each has different cost, performance, and operational profiles. Picking wrong can lead to either security risk or a surprisingly large AWS bill.
This article compares the three, explains when each is the right choice, and shows how a combination is often the optimal answer for cost-conscious architectures.
The three options at a glance
| Feature | NAT Gateway | NAT Instance | VPC Endpoint |
|---|---|---|---|
| Managed by AWS? | Yes | No (you run an EC2) | Yes |
| High availability | Per-AZ built-in | You build it | Yes |
| Throughput | Up to 100 Gbps | Instance dependent | Service dependent |
| Cost | Hourly + per-GB | EC2 hourly only | Hourly (interface) or free (gateway) |
| Reaches | Internet | Internet | Specific AWS services only |
| Operational complexity | Low | Medium-High | Low |
NAT Gateway: the default answer
AWS's managed NAT service. You create one per AZ for HA, route private subnet traffic to it via the route table, and your private workloads can reach the internet.
Pros
- Fully managed — no patching, no replacement
- Scales to 100 Gbps per AZ
- Per-AZ HA built in
- Supports up to 55,000 concurrent connections to a single destination
Cons
- Cost. Roughly $0.045/hour per NAT Gateway plus $0.045 per GB of data processed (us-east-1 as of 2026). A single-AZ NAT Gateway is ~$33/month idle, plus data transfer. Three-AZ NAT Gateways are ~$100/month idle, before any data.
- The per-GB cost dominates at any meaningful scale. A workload that pushes 10 TB/month through NAT pays $450 in NAT data processing fees alone (plus $33-100 for the gateway).
- Per-AZ — cross-AZ NAT traffic incurs additional inter-AZ transfer fees.
When to use it
Almost always the right answer for production unless you have specific cost or feature constraints. The operational simplicity is worth the cost for most workloads.
NAT Instance: the cost-optimized DIY answer
Run an EC2 instance (typically with the legacy NAT AMI or a small Linux instance configured to do NAT) and route private subnet traffic to it. You pay only for the EC2 instance — no per-GB data processing fee.
Pros
- Massive cost savings at scale. A t3.nano running as NAT costs $3-4/month for the instance vs $33+ for NAT Gateway, AND there is no per-GB charge. For high-traffic workloads, savings can be 90%+.
- You control the host — can add IDS, custom logging, traffic shaping, etc.
- Can be used for outbound source NAT with a static IP that you control
Cons
- You operate it. Patching, AMI updates, failover orchestration, monitoring.
- HA is your problem. Either Auto Scaling Group with route table swap on failure, or a multi-instance setup with health checks.
- Throughput limited by instance type. A t3.nano caps around 1-2 Gbps.
- Single-instance NAT is a SPOF unless you build HA.
When to use it
- Dev/staging environments where downtime is acceptable
- Cost-sensitive production workloads with predictable traffic patterns
- Use cases that need IDS/IPS at the NAT boundary
- When you need to control the outbound source IP
VPC Endpoints: the elimination answer
VPC Endpoints let your private subnet workloads reach specific AWS services without going through NAT at all. Traffic stays inside the AWS backbone — no internet, no NAT, no per-GB processing.
Two types:
| Type | Services supported | Cost |
|---|---|---|
| Gateway endpoint | S3, DynamoDB | Free |
| Interface endpoint (PrivateLink) | Most AWS services and SaaS | ~$0.01/hour per AZ per endpoint, plus per-GB |
Gateway endpoints
For S3 and DynamoDB only. Add a route table entry pointing those services through the gateway endpoint. Traffic never leaves the VPC. Completely free.
Every AWS VPC that talks to S3 should have an S3 gateway endpoint. There is no reason not to — it's free, fast, and eliminates NAT processing fees for S3 traffic. The amount you save on a high-S3-traffic workload is substantial.
Interface endpoints (PrivateLink)
For most other AWS services (SQS, SNS, ECR, EC2 API, KMS, Secrets Manager, etc.) and third-party SaaS that supports PrivateLink. Each endpoint costs roughly $7/month per AZ + $0.01/GB of data processed.
The cost calculus: if you push more than ~$10/month of NAT data for a specific service, an interface endpoint is cheaper. For high-volume services like ECR (image pulls) or CloudWatch Logs (log ingestion), the savings are large.
The combined production pattern
Cost-optimized production VPCs use all three:
- NAT Gateway for general internet egress (package updates, third-party APIs)
- S3 gateway endpoint for all S3 traffic (free, no NAT charges)
- DynamoDB gateway endpoint if you use DynamoDB
- Interface endpoints for high-traffic AWS services (ECR, KMS, Secrets Manager, CloudWatch Logs)
- NAT Instance only in dev/staging for cost savings, not in production
This pattern can cut NAT data charges by 80-95% in workloads that talk heavily to AWS services (which is most workloads). The setup cost is one-time; the savings recur monthly.
How to identify NAT savings opportunities
Look at NAT Gateway metrics in CloudWatch:
BytesOutToDestination— total bytes going out from NAT- VPC Flow Logs filtered to NAT IPs — destination service/endpoint analysis
The top destinations by byte volume are your highest-value endpoint candidates. ECR (*.dkr.ecr.region.amazonaws.com) and S3 are almost always near the top.
Egress-only Internet Gateway (IPv6)
For IPv6 traffic, AWS has an analogous concept: the Egress-only Internet Gateway. Lets IPv6 workloads in private subnets reach the internet without being reachable from the internet. Free — no per-GB fee unlike NAT Gateway for IPv4.
If your workloads are dual-stack, route IPv6 egress through the egress-only IGW and reserve NAT Gateway only for IPv4 traffic. Further reduces NAT bills.
Common mistakes
- No S3 gateway endpoint. Easiest free win in any VPC. Always add it.
- Cross-AZ NAT. If all your workloads run in us-east-1a but your NAT Gateway is in us-east-1b, every byte goes cross-AZ. Always create one NAT Gateway per AZ and route per-AZ traffic to its local one.
- Interface endpoint for every service. Cost only pays off for high-traffic services. For low-traffic services (KMS calls happen rarely), the NAT route is cheaper.
- Forgetting that VPC Endpoints have policies. An S3 gateway endpoint defaults to allowing all S3 access. Use endpoint policies to restrict to specific buckets.
Key takeaways
- NAT Gateway is the right default for managed, scalable internet egress. Cost: ~$33/AZ/month + per-GB.
- NAT Instance is dramatically cheaper if you accept the operational burden. Useful for dev/staging.
- S3 gateway endpoint is free and should be in every VPC. Eliminates NAT charges for S3.
- Interface endpoints (PrivateLink) cut costs for high-traffic AWS services like ECR and CloudWatch Logs.
- Egress-only IGW handles IPv6 egress with no NAT fee.
- Use VPC Flow Logs to identify your highest-traffic destinations and prioritize endpoint setup accordingly.