VPC Connectivity Patterns: NAT Gateways, Endpoints, and Peering

Connectivity questions are about who can reach what: internet vs private resources, and VPC-internal vs AWS-service traffic. Three building blocks cover most scenarios: NAT gateways, VPC endpoints, and VPC peering/Transit Gateway.

Outbound internet from private subnets

Private-subnet instances reach the internet outbound-only through a NAT gateway deployed in a public subnet. The instance initiates; the internet cannot initiate back. This is the default pattern for patching, external API calls, and package downloads.

Private access to AWS APIs

VPC endpoints keep traffic to AWS services on the AWS network. Gateway endpoints (free, route-table based) exist for S3 and DynamoDB — they also eliminate NAT data-processing charges for that traffic. Interface endpoints (PrivateLink ENIs) cover most other services.

VPC-to-VPC and hybrid

• VPC peering — direct, non-transitive connection between two VPCs
• Transit Gateway — hub-and-spoke for many VPCs and on-prem networks
• Site-to-site VPN — encrypted tunnel over the internet
• Direct Connect — dedicated private connection from on-premises; consistent bandwidth, not internet-dependent

Cost note

NAT gateways bill hourly plus per-GB processed — a common hidden cost in scenarios. If S3/DynamoDB traffic flows through NAT, a free gateway endpoint removes those data-processing charges; that is a favorite exam trick in the cost-optimization domain.