AWS Networking

A workload in a private subnet needs to call an external API. Should it use a NAT gateway, a VPC endpoint, AWS PrivateLink, or no new network component at all?

The answer is not in the service name. It is in the packet path.

AWS networking becomes simpler when you see VPCs, subnets, route tables, security groups, NAT gateways, and endpoints as stages in one process. A request resolves a name, selects a route, passes security controls, and then uses a gateway or endpoint to reach its destination.

Start with a simple request:

Before the request reaches its destination, AWS networking must answer several questions:

This order matters. A NAT gateway cannot help when DNS resolves to an unexpected address. A correct route does not bypass a security group. An open security group cannot create a missing route.

A Virtual Private Cloud (VPC) is a logically isolated virtual network in AWS. You assign one or more IP address ranges to it using CIDR notation, such as 10.0.0.0/16. Subnets divide that VPC address space into smaller ranges.

Each subnet belongs to one Availability Zone and cannot span multiple AZs. If an application runs in more than one AZ, it needs subnet capacity, routes, and supporting components in each relevant AZ.

The most important beginner correction is this:

AWS describes a subnet as public when its route table includes a direct route to an internet gateway. A subnet is private when it does not have that direct internet gateway route. A private subnet can still initiate internet connections through a NAT gateway. This is a routing distinction, not a label permanently attached to the subnet. Check this AWS subnet configuration guidance.

Use one workload throughout this article: an EC2 instance, container, or pod runs in a private subnet. It makes an HTTPS request to an external API, reads data from Amazon S3, and calls a service exposed through AWS PrivateLink.

The workload may remain in the same subnet for all three requests. What changes is the DNS answer and the route selected for the destination.

“Private” therefore means “not directly reachable through an internet gateway route.” It does not mean “unable to communicate outside the subnet” or “unable to make outbound requests.”

Every subnet uses one route table. You can explicitly associate a route table with a subnet, or the subnet can use the VPC’s main route table. A route has a destination and a target.

The local route is created for the VPC CIDR. It enables AWS to route traffic between resources in that VPC. It is not an authorization rule. A workload can still be blocked by security groups, network ACLs, host firewalls, an unavailable listener, or application authentication.

AWS route tables use longest-prefix matching. In simple terms, the most specific matching route wins.

For example, a private subnet can have both an S3 prefix-list route to a gateway endpoint and a broad 0.0.0.0/0 route to a NAT gateway. Traffic for S3 follows the more-specific endpoint route. Other public IPv4 traffic follows the default route to NAT.

This is why an S3 gateway endpoint can remove S3 traffic from the NAT path without requiring an application change.

A route table answers only one question:

It does not answer whether the packet is allowed. That is the job of security controls.

A security group applies to an Elastic Network Interface (ENI) or a resource that uses one. Security groups are stateful and support allow rules. When an outbound TCP connection is allowed, return traffic for that established connection is automatically allowed.

A network ACL, or NACL, applies at the subnet boundary. NACLs are stateless, support both allow and deny rules, and evaluate rules in numerical order. Because they are stateless, request and return traffic both need matching rules. AWS documents these differences in its guidance on VPC infrastructure security and network ACL behavior.

A common failure pattern is an incomplete NACL:

The route may be correct, and the security group may be correct, but the stateless NACL still breaks the connection.

DNS is another early dependency. Applications usually request names rather than IP addresses. Inside a VPC, the Amazon-provided resolver is part of Route 53 Resolver. Private hosted zones can return private addresses for names that resolve differently on the public internet. Interface endpoint private DNS can return private endpoint ENI addresses for supported AWS service names. Go through VPC DNS settings and Amazon DNS concepts once.

When a request fails, begin by confirming the IP address DNS returned. That answer determines which route AWS evaluates.

An internet gateway, or IGW, attaches to a VPC and provides a path for internet-routed traffic. A typical public subnet includes a route like this:

That route alone does not make an EC2 instance publicly reachable.

For a typical IPv4 workload to accept inbound public traffic, it generally needs an internet gateway route, public addressing, security group permission, suitable NACL rules, and an application listening on the intended port. AWS provides routing examples in its route table documentation.

This is why many production architectures use a public-facing load balancer as the deliberate entry point. Application services and databases can remain in private subnets, with only the load balancer accepting selected public traffic.

A public NAT gateway solves a different problem: allowing private IPv4 workloads to initiate outbound connections.

The path is:

AWS has documented this behavior in its NAT gateway overview.

NAT does not make a private instance publicly reachable. It supports connections initiated from the private side. It is not an inbound reverse proxy, load balancer, or firewall replacement.

NAT gateways also do not have security groups. Security control remains the responsibility of workload security groups and subnet NACLs- NAT gateway basics.

A NAT gateway is created in one AZ. A private subnet in another AZ can route to it, but doing so creates an AZ dependency and can introduce cross-AZ traffic. As an engineering recommendation, deploy a NAT gateway per AZ and route each private subnet to its local NAT gateway when the workload’s resilience requirements justify the added fixed and data-processing costs. This is a design choice, not an AWS requirement.

AWS also documents operational behavior that can explain incidents:

If many short-lived outbound connections begin failing, inspect NAT metrics and connection behavior before assuming the remote service is unavailable.

A NAT gateway provides broad outbound connectivity. VPC endpoints provide private paths to specific supported services.

The simplest type is a gateway endpoint. Gateway endpoints are available for Amazon S3 and DynamoDB. They add routes to selected route tables, commonly using AWS-managed prefix lists.

When a workload accesses S3, that specific route can win over the default NAT route. The traffic reaches S3 without traversing a NAT gateway or internet gateway. AWS explains this model in its gateway endpoint documentation.

Gateway endpoints are useful but limited in scope. They are not a generic tool for every AWS API or private service.

An interface endpoint works differently. AWS creates endpoint ENIs in the subnets you select. Those ENIs receive private IP addresses. The workload connects to those private addresses, and security groups control traffic to the endpoint ENIs.

When private DNS is enabled, a standard AWS service hostname can resolve to those endpoint IPs. This often allows an application to keep using the normal AWS service name while its traffic uses private connectivity. AWS documents endpoint ENIs, security groups, subnet selection, and private DNS in Create an interface endpoint.

AWS PrivateLink is the service model behind interface endpoints. Its central idea is narrow service exposure.

With PrivateLink, a consumer does not receive general routed access to a provider VPC. Instead, the consumer creates interface endpoint ENIs that connect to a specific service published by the provider.

A provider can publish an endpoint service behind a Network Load Balancer or Gateway Load Balancer. The consumer creates an interface endpoint in its own VPC. Provider permissions, acceptance settings, endpoint security groups, DNS configuration, and AZ coverage remain separate concerns. A configured endpoint service does not guarantee that every consumer-side dependency is correct - AWS PrivateLink endpoint service documentation.

PrivateLink is not VPC peering.

VPC peering provides direct private connectivity between VPC networks through routes to peer CIDR ranges. PrivateLink exposes a specific service without broadly exposing the provider network.

Use the smallest connectivity pattern that meets the requirement:

Return to the private workload calling an external HTTPS API.

DNS returns a public IP address. The packet leaves the workload ENI and reaches the subnet route table. If no more-specific route exists, 0.0.0.0/0 selects the NAT gateway.

The workload security group must allow outbound HTTPS. The NACL must allow the outbound request and the return path. NAT translates the source address and forwards traffic through the IGW. The response returns through NAT, which reverses the translation.

S3 uses a different path:

The S3 prefix-list route is more specific than the default NAT route, so S3 traffic uses the gateway endpoint.

An interface endpoint uses another path:

Here, private DNS can return endpoint ENI addresses in the VPC. Endpoint security groups and endpoint policies can still deny access.

Debug failed requests in layers:

Follow the packet path first, and AWS networking becomes easier to explain, test, and operate.

👋 Find me on Twitter | Linkedin | Connect 1:1

Thank you for supporting this newsletter.
Y’all are the best.