Internet Gateways, NAT, Endpoints, and Private Connectivity

A VPC is private until you attach paths that let packets leave it or let outside systems reach it. Internet Gateways, NAT Gateways, VPC endpoints, PrivateLink, VPN, and Direct Connect are the main AWS mechanisms for those paths. After this lesson, you should be able to choose the right option, predict which route wins, and verify the result from AWS evidence.

This topic matters because many AWS failures that look like application or SDK defects are path problems: patching fails, a VPC Lambda cannot call Secrets Manager, or S3 traffic leaves through paid NAT. The fix is usually found by reading route targets, DNS answers, address assignment, and policy together.

Purpose and Outcome

An Internet Gateway is a horizontally scaled VPC attachment that gives public subnets a target for internet-routable traffic. It does not make every resource public. A working public path also needs a subnet route to the gateway, a public IPv4 address or Elastic IP, rules that allow the flow, and a listener.

A NAT Gateway lets private subnet resources initiate outbound IPv4 connections while blocking unsolicited inbound internet flows. It is placed in a public subnet, uses an Elastic IP address, and translates private source addresses and ports to its public address and ephemeral ports.

VPC endpoints keep supported AWS service access private. Gateway endpoints add route table entries for S3 or DynamoDB. Interface endpoints create elastic network interfaces with private IPs and use AWS PrivateLink to place service endpoints inside your VPC. VPN and Direct Connect extend private routes to other networks; VPN uses encrypted tunnels over the internet, while Direct Connect uses dedicated physical connectivity.

How the Mechanisms Work

AWS route tables use longest-prefix matching. The local VPC route, such as 10.0.0.0/16, keeps internal traffic in the VPC. A 0.0.0.0/0 route is the IPv4 default. An AWS-managed prefix list for S3 can beat the default route, so S3 uses a gateway endpoint while other internet destinations still use NAT.

An Internet Gateway attaches to one VPC at a time. For instances with public IPv4 addresses or Elastic IPs, it performs one-to-one public address mapping at the VPC edge. Inbound traffic to the public address maps to the instance private address; outbound traffic maps the private source back to the public address.

A NAT Gateway is stateful and Availability Zone scoped. When a private instance connects to 198.51.100.20:443, the NAT Gateway records the private source IP and port, then sends traffic from its public IP and a selected source port. Return traffic matching that state is forwarded back. New inbound flows with no translation entry are dropped. Production designs deploy one NAT Gateway per AZ and route each private subnet to the NAT Gateway in the same AZ.

A gateway endpoint changes routing, not DNS. Creating an S3 gateway endpoint and associating it with route tables adds a route whose destination is an AWS-managed prefix list and whose target is the endpoint. An interface endpoint changes DNS and packet destination. With private DNS enabled, a regional service name such as secretsmanager.us-east-1.amazonaws.com resolves inside the VPC to private endpoint ENI addresses. Security groups on those ENIs control which clients can connect.

PrivateLink is provider-consumer connectivity. A provider publishes a Network Load Balancer as an endpoint service. A consumer creates an interface endpoint to that service and connects to private IPs in the consumer VPC. AWS carries traffic to the provider without VPC peering, overlapping route concerns, or internet exposure.

Configuration Anatomy

Mechanism Primary object Route or DNS effect Common use
Internet Gateway VPC attachment 0.0.0.0/0 route to igw-... Internet-facing load balancers or controlled direct public access
NAT Gateway AZ-scoped managed NAT Private subnet default route to nat-... Outbound repositories, APIs, and patching from private subnets
Gateway endpoint S3 or DynamoDB endpoint Prefix-list route to vpce-... Private, lower-cost access to S3 or DynamoDB
Interface endpoint PrivateLink ENIs Private DNS to endpoint IPs Private access to AWS APIs, partner services, or internal endpoint services
VPN or Direct Connect Virtual private gateway or transit gateway attachment Routes to on-premises CIDR blocks Hybrid networks with private address reachability

The critical fields are destination, target, subnet association, addressing, DNS, and policy. Any one can break the path, so inspect them together.

{
  "PublicSubnetRoute": {
    "DestinationCidrBlock": "0.0.0.0/0",
    "GatewayId": "igw-0123456789abcdef0"
  },
  "PrivateSubnetRoute": {
    "DestinationCidrBlock": "0.0.0.0/0",
    "NatGatewayId": "nat-0123456789abcdef0"
  },
  "S3EndpointRoute": {
    "DestinationPrefixListId": "pl-63a5400a",
    "VpcEndpointId": "vpce-0123456789abcdef0"
  }
}

This fragment shows three route target shapes. The public subnet sends default traffic to the Internet Gateway. The private subnet sends default traffic to NAT. S3 traffic can bypass NAT when the destination matches the S3 prefix list route.

Worked Example 1: Public Web Subnet

A public subnet is defined by its route table, not by its name. If subnet 10.0.1.0/24 is associated with a table that has 0.0.0.0/0 pointing to an Internet Gateway, resources in that subnet have a route toward the internet. For an EC2 web server to answer internet clients, it also needs a public IPv4 address or Elastic IP, a security group allowing the listener port, and a network ACL that permits return traffic.

Expected behavior: inbound HTTPS reaches the instance only if all controls allow it. Outbound responses return through the same Internet Gateway mapping. If the instance lacks a public address, the route alone is insufficient; outbound packets have no public source mapping and internet clients cannot initiate a connection to it.

Worked Example 2: Private Subnet With NAT

Move the application server to subnet 10.0.2.0/24 and associate it with a route table whose default route points to a NAT Gateway. The NAT Gateway must be in a public subnet with its own route to the Internet Gateway. The private server can call an external API or package repository, but an internet host cannot open a new inbound TCP connection to the private server through that NAT Gateway.

Expected behavior: from the private instance, curl https://example.com succeeds if routing, DNS, security groups, and NACLs are correct. From a laptop on the internet, connecting to the instance private address fails because RFC 1918 addresses are not internet-routable. Connecting to the NAT Gateway Elastic IP also fails for arbitrary inbound sessions because no matching NAT state exists.

Worked Example 3: Keep AWS API Traffic Private

Suppose the private application reads S3 objects and Secrets Manager secrets. Without endpoints, both flows may use the NAT Gateway because SDKs resolve public AWS service names and the subnet default route sends traffic to NAT. Add an S3 gateway endpoint to the private route table and an interface endpoint for Secrets Manager with private DNS enabled.

Expected behavior changes by destination. S3 traffic matches the S3 prefix-list route and uses the gateway endpoint. Secrets Manager resolves to private interface endpoint addresses and connects to endpoint ENIs over port 443. Other internet destinations still use NAT. This reduces NAT processing charges for S3 and removes public internet egress dependency for that AWS API path.

{
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": ["s3:GetObject"],
      "Resource": ["arn:aws:s3:::example-private-bucket/*"]
    }
  ]
}

This endpoint policy is intentionally narrow. It allows object reads from one bucket path through the endpoint. It does not replace IAM identity policy or bucket policy evaluation; every applicable policy must still allow the request.

Design Choices and Trade-Offs

Use an Internet Gateway when the workload must be directly reachable from the internet, commonly through an internet-facing load balancer. Prefer EC2 instances in private subnets behind that load balancer unless direct public addressing is required. The trade-off is simplicity versus exposure: public addressing removes path components, but increases the number of resources that must be hardened against unsolicited traffic.

Use NAT Gateway for broad outbound IPv4 internet access from private subnets. It is managed and highly available within an AZ, but it adds hourly and data processing cost and can become an AZ dependency if many private subnets route to one gateway. NAT instances offer more control and sometimes lower cost for small workloads, but you own scaling, patching, failover, and host security.

Use gateway endpoints for S3 and DynamoDB when private subnets need those services. They are route-table based and require no endpoint ENIs. Use interface endpoints for AWS APIs and PrivateLink services where DNS-based private access is needed. Interface endpoints cost per AZ and per data processed, and their ENI security groups must be maintained. Use VPC peering for simple nontransitive VPC-to-VPC routing, Transit Gateway for many networks, VPN for fast encrypted hybrid setup, and Direct Connect for steadier latency and private bandwidth planning.

Failure Modes and Troubleshooting

Symptom: an EC2 instance in a supposed public subnet cannot be reached on HTTPS. Cause: the subnet route table lacks a default route to the Internet Gateway, the instance has no public address, or the security group blocks port 443. Diagnose: check subnet association, route target, instance public IP, security group inbound rules, and NACL ephemeral return rules.

Symptom: a private instance cannot run package updates. Cause: its default route points nowhere, points to an unhealthy or cross-AZ NAT dependency, or DNS resolution is disabled. Diagnose: inspect the private route table, NAT Gateway state, public subnet route to the Internet Gateway, VPC DNS settings, and flow logs for rejects. Correct: route the private subnet to a healthy same-AZ NAT Gateway, enable DNS support and hostnames when needed, and allow outbound 443 plus ephemeral return traffic.

Symptom: S3 access works before adding an endpoint but fails afterward. Cause: the endpoint policy, bucket policy, or IAM policy does not allow the requested action through the endpoint. Diagnose: compare the SDK error, review endpoint policy, review bucket conditions such as aws:SourceVpce, and confirm the route table contains the S3 prefix-list route. Correct: align IAM, bucket, and endpoint policies to the same bucket, action, and source endpoint.

Symptom: an interface endpoint exists but clients still use NAT. Cause: private DNS is disabled, the client uses a name not covered by the endpoint, or custom DNS forwards incorrectly. Diagnose: run DNS lookup from inside the VPC and confirm it returns private endpoint IPs; check endpoint security group inbound rules for port 443 from client subnets. Correct: enable private DNS where supported, update resolver rules, and allow client security group or subnet CIDR access to endpoint ENIs.

Security, Performance, and Reliability

The security benefit of private connectivity is reducing reachable surfaces and making policy conditions precise. Endpoint policies and bucket policies can require a specific VPC endpoint. Security groups on interface endpoints can allow only application subnets. PrivateLink lets a provider expose one service without opening routes to every provider subnet.

Performance and cost depend on path length and processing points. Sending large S3 transfers through NAT is usually unnecessary when a gateway endpoint can keep that traffic on the AWS network path and avoid NAT data processing. Cross-AZ NAT routing adds an inter-AZ dependency and may add cross-AZ data cost. Interface endpoints should exist in the AZs where clients run so clients can use local endpoint ENIs.

Reliability follows AZ boundaries. A single NAT Gateway may be acceptable for a small noncritical environment, but production private subnets usually route to NAT in their own AZ. For hybrid connectivity, redundant VPN tunnels, multiple customer gateway devices, and redundant Direct Connect links reduce single points of failure. Review route propagation and prefix advertisement as carefully as firewall rules.

Hands-On Lab

Prerequisites: an AWS sandbox account, AWS CLI credentials, a chosen Region, and permission for EC2 VPC operations. NAT Gateways and interface endpoints can incur charges, so use a short-lived environment and clean up immediately.

  1. Create or select a VPC with DNS support enabled and two subnets in one Region: one public subnet and one private subnet.
  2. Attach an Internet Gateway to the VPC and associate the public subnet with a route table containing 0.0.0.0/0 to the Internet Gateway.
  3. Create a NAT Gateway in the public subnet with an Elastic IP, then associate the private subnet with a route table containing 0.0.0.0/0 to the NAT Gateway.
  4. Add an S3 gateway endpoint and associate it with the private route table.
  5. Optionally add an interface endpoint for Secrets Manager with private DNS enabled and a security group allowing port 443 from the private subnet.
  6. Verify routes and DNS from the CLI before launching workloads.
  7. Clean up by deleting interface endpoints, gateway endpoints, NAT Gateway, releasing the Elastic IP, detaching and deleting the Internet Gateway, and deleting temporary route tables and subnets.
set -euo pipefail

REGION="us-east-1"
VPC_ID="vpc-replace-me"
PRIVATE_ROUTE_TABLE_ID="rtb-replace-me"
PRIVATE_SUBNET_ID="subnet-replace-me"

aws ec2 describe-route-tables \
  --region "$REGION" \
  --filters "Name=vpc-id,Values=$VPC_ID" \
  --query "RouteTables[].{RouteTable:RouteTableId,Associations:Associations[].SubnetId,Routes:Routes[].{Destination:DestinationCidrBlock,PrefixList:DestinationPrefixListId,Gateway:GatewayId,Nat:NatGatewayId,Endpoint:VpcEndpointId,State:State}}" \
  --output table

aws ec2 describe-vpc-endpoints \
  --region "$REGION" \
  --filters "Name=vpc-id,Values=$VPC_ID" \
  --query "VpcEndpoints[].{Endpoint:VpcEndpointId,Type:VpcEndpointType,Service:ServiceName,State:State,PrivateDns:PrivateDnsEnabled,Subnets:SubnetIds}" \
  --output table

aws ec2 describe-subnets \
  --region "$REGION" \
  --subnet-ids "$PRIVATE_SUBNET_ID" \
  --query "Subnets[].{Subnet:SubnetId,Az:AvailabilityZone,MapPublicIp:MapPublicIpOnLaunch,RouteTableHint:'check association above'}" \
  --output table

Verification: the public route table should show a default route with an igw- target. The private route table should show a default route with a nat- target and, after the S3 endpoint is added, a prefix-list route with a vpce- target. The endpoint list should show Gateway for S3 and Interface for Secrets Manager if you created it. Cleanup is verified when no temporary endpoints, NAT Gateways, Elastic IP allocations, or Internet Gateway attachments remain.

Assessment Exercises

  1. A private EC2 instance can reach https://example.com, but S3 downloads are expensive. Which route change would you make, and how would you prove S3 no longer uses NAT?
  2. A subnet has 0.0.0.0/0 to an Internet Gateway, but an instance in it has only a private IPv4 address. Predict whether inbound internet SSH works and explain every required condition.
  3. Your team created an interface endpoint for Secrets Manager, but DNS still resolves to public addresses from EC2. List three likely causes and the fastest check for each.
  4. Two private subnets in different AZs both route to one NAT Gateway. Describe the reliability and cost trade-off, then propose a more resilient route table layout.
  5. A bucket policy requires aws:SourceVpce, and application reads fail after recreating the endpoint. What changed, and where should the new identifier be updated?

Summary

Internet Gateways provide public VPC edge routing when resources also have public addressing. NAT Gateways provide outbound IPv4 translation for private subnets. Gateway endpoints use route tables for S3 and DynamoDB. Interface endpoints use PrivateLink ENIs and private DNS for AWS APIs and provider services. VPN and Direct Connect extend private routes beyond AWS. Read the route table, DNS answer, address assignment, and policy together, then choose the narrowest path that satisfies reachability, security, cost, and failure requirements.