NAT gateway, NAT instance or no NAT?
How private-subnet workloads reach the internet — or avoid needing to.
NAT Gateway is the default for private-subnet egress — AWS recommends it for availability, bandwidth and zero administration. A NAT instance is now a niche, legacy choice: pick it only for a feature the gateway lacks — port forwarding, doubling as a bastion, or very low traffic where its hourly cost wins. You can skip NAT entirely when private workloads only talk to AWS services (a free Gateway endpoint, or Interface endpoints), or when a workload is genuinely public. The deciding factor is cost: the NAT Gateway data-processing charge applies to every GB — including AWS-service traffic a cheaper endpoint could carry.
Answer the questions — the helper scores both the options against the sourced table below and shows its reasoning. A heuristic, not an oracle: the verdict above stays the authority.
| Criterion | NAT Gateway | NAT instance | No NAT |
|---|---|---|---|
| Managed? | Fully managed by AWS | You manage it — OS and patches | Endpoints and gateways fully managed |
| Availability | Redundant within its AZ | Single instance — you script failover | HA, horizontally scaled |
| Bandwidth | 5 Gbps, auto-scales to 100 Gbps | Limited by the instance type | No NAT bandwidth limit |
| Hourly cost | Per-gateway hourly charge | EC2 instance hourly rate | Gateway endpoint: none. Interface: ~$0.01/AZ-hr |
| Data-processing cost | A per-GB charge on all traffic | None — pay EC2 data transfer only | Gateway endpoint: none. Interface: ~$0.01/GB |
| Port forwarding / bastion | Not supported | Supported — can also serve as a bastion | Not applicable |
| Maintenance | None | OS patches; build your own NAT AMI | None |
| AWS-service-only egress | Works, but billed per GB | Works, with management overhead | Best fit — a free Gateway endpoint |
Pick NAT Gateway when
- Private workloads need general outbound internet — it is the AWS-recommended default.
- You want zero maintenance and built-in per-AZ redundancy.
- Traffic is moderate-to-high and the per-GB charge is acceptable.
Pick a NAT instance when
- You need port forwarding, which a NAT Gateway does not support.
- You want one instance to also serve as a bastion / jump host.
- Egress is tiny and infrequent, where a small instance undercuts the gateway.
Skip NAT entirely when
- Private workloads only reach S3 or DynamoDB — use a free Gateway endpoint.
- Egress is only to other AWS services — Interface endpoints usually undercut NAT.
- The workload is genuinely public — put it in a public subnet behind an internet gateway.
- NAT gateway vs NAT instance comparison — https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-comparison.html
- NAT gateway basics — bandwidth and limits — https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-basics.html
- NAT gateway pricing — https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-pricing.html
- Amazon VPC pricing — https://aws.amazon.com/vpc/pricing/
- Work with NAT instances — https://docs.aws.amazon.com/vpc/latest/userguide/work-with-nat-instances.html
- Gateway endpoints for S3 and DynamoDB — https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html
- Egress-only internet gateways — https://docs.aws.amazon.com/vpc/latest/userguide/egress-only-internet-gateway.html