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.
| 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 |