NAT Gateway vs VPC Endpoint
Compare general outbound internet egress with private service-specific access for routing, exposure, availability, and data cost.
Open editable diagramArchitecture diagram
Edit this exact diagram
Open on the canvasNAT Gateway vs VPC endpoint architecture diagram comparing private subnet internet egress with a private service-specific route to Amazon S3. The image links to a fully editable BuildPlane starter.
Overview
A NAT Gateway gives private-subnet workloads outbound IPv4 connectivity through a public subnet and internet gateway without accepting unsolicited inbound sessions. A VPC endpoint gives private connectivity to one supported AWS service or endpoint service without using public addressing or NAT. NAT is broad egress; an endpoint is a narrow private route.
Components
- Shared decision context: Compute with no public address that must reach external or AWS-managed services.
- NAT Gateway: Translates outbound IPv4 connections through a public subnet and internet gateway. Package repositories, vendor APIs, and public endpoints outside the VPC.
- VPC Endpoint: Keeps supported AWS or endpoint-service traffic on private addressing without NAT. S3 through a gateway endpoint or another service through an interface endpoint.
Comparison Flow
- Private Subnet Workload can enter the NAT Gateway path and continue to Internet APIs.
- Private Subnet Workload can instead enter the VPC Endpoint path and continue to Supported AWS Service.
- Choose the path whose operating model and constraints match the workload, then delete the unused branch in the editable diagram.
Customize First
- Inventory every outbound destination before removing NAT paths.
- Compare gateway endpoints, interface endpoints, and NAT data processing by traffic volume.
- Route each private subnet to a NAT Gateway in the same Availability Zone.
Side-by-side decision
NAT Gateway vs VPC Endpoint
Use endpoints for supported service-specific private access. Use NAT Gateway for general outbound IPv4 destinations. Keep both when the workload needs private AWS access and the wider internet.
| Decision factor | NAT Gateway | VPC Endpoint |
|---|---|---|
| Reach | General outbound IPv4 destinations | One supported service or endpoint service |
| Path | Private subnet to public NAT and internet gateway | Private route through gateway or interface endpoint |
| Inbound | No unsolicited inbound connection | Service-specific private connectivity and policy |
| Availability | Zonal resource; deploy and route per zone | Gateway endpoints are route targets; interface endpoints use zonal ENIs |
| Cost | Hourly plus data processing and transfer path | Gateway or interface endpoint pricing model |
| Typical use | Public APIs, updates, package repositories | S3, DynamoDB, AWS APIs, PrivateLink services |
Related AWS guides
Understand the decisions behind this diagram
Use these practical explanations to compare services, failure boundaries, and operating tradeoffs before adapting the architecture.
Design rationale
Decisions that shape this architecture
Inventory destinations before removing egress
Endpoints cover supported services, not the whole internet. Build a destination inventory from flow logs, DNS, application configuration, and dependency scanning so package downloads, certificate checks, and vendor APIs do not fail after a cost project removes NAT.
Gateway and interface endpoints are different
S3 and DynamoDB gateway endpoints integrate with route tables and have a different cost model. Interface endpoints create private ENIs, security groups, DNS behavior, hourly cost, and per-data charges. Price and operate the exact endpoint type.
Zonal alignment controls resilience and cost
A NAT Gateway belongs to one Availability Zone. Private subnets should normally route to a NAT in the same zone so another zone is not a dependency and cross-zone traffic is not accidental. Interface endpoint ENIs deserve similar placement thinking.
Before production
Operational checks
Inventory outbound domains, IPs, ports, AWS APIs, and traffic volume.
Deploy and route NAT gateways per Availability Zone where resilience requires it.
Test private DNS, endpoint policies, security groups, and SDK endpoint resolution.
Compare NAT processing with endpoint hourly and data charges using actual bytes.
Scope and tradeoffs
What this diagram does not solve
Endpoints can multiply quickly
A large set of interface endpoints across many VPCs and zones has meaningful fixed cost and policy surface. Centralized endpoint architectures can help, but add routing and DNS complexity.
NAT Gateway is IPv4-specific
IPv6 egress uses an egress-only internet gateway or direct routes according to the security model. Do not copy IPv4 NAT assumptions into an IPv6 design.
Common questions
Frequently asked questions
Does a VPC endpoint replace a NAT Gateway?
Only for traffic to the specific supported service. General internet destinations still need NAT, a proxy, another egress design, or native IPv6 routing.
Are VPC endpoints cheaper than NAT Gateway?
Gateway endpoints for S3 and DynamoDB are often compelling. Interface endpoints add hourly and data charges per zone. The result depends on service support, zones, VPC count, and bytes.
Can a NAT Gateway receive inbound internet traffic?
It permits response traffic for outbound connections but does not create a public inbound path to private instances. Use a load balancer or other explicit ingress architecture for inbound traffic.
Keep exploring
Related AWS architectures
AWS Transit Gateway vs VPC Peering
Choose VPC peering for a small, stable number of direct VPC relationships where pairwise routes remain easy to understand. Choose Transit Gateway when many VPCs, accounts, hybrid networks, segmentation domains, or centralized inspection paths need one governed routing hub. Count future connections and traffic paths before cost, because a full peering mesh grows quadratically and becomes the expensive option operationally even when service charges are lower.
Explore the architecture
Security Groups vs Network ACLs in an AWS VPC
Use security groups to express which application tiers and resources may communicate, ideally through references to other security groups rather than broad IP ranges. Use network ACLs when a subnet needs an explicit deny, coarse IP-based boundary, or backup control against a missing resource rule. Because NACLs are stateless, inbound and outbound rules must both allow response ports, which makes aggressive policies harder to operate.
Explore the architecture
Public and Private Subnets in an AWS VPC
This VPC pattern makes exposure decisions explicit and auditable. The load balancer and NAT gateway are the only resources in the public path; application compute accepts traffic solely from the load balancer security group; the database accepts connections solely from the application security group and has no route to or from the internet. Because every layer is enforced by a route table and a security group reference rather than by convention, you can answer "what is reachable from the internet?" by reading the diagram. Everything else in a production build, such as a second Availability Zone, VPC endpoints, and flow logs, attaches to this skeleton without changing it.
Explore the architectureFrom reference to working draft
Adapt this architecture with your AWS AI Agent
Start from the exact diagram in this guide. Change requirements, challenge a decision, or ask what fails first, while keeping the architecture editable.