VPC Gateway Endpoints for S3/DynamoDB (Free vs NAT)

A VPC Gateway Endpoint is a logical gateway component that allows instances within a VPC to access Amazon S3 or DynamoDB without traversing the public internet. It is a horizontally scaled, highly available service that uses AWS's internal network. The key motivation is cost and security: traffic to S3/DynamoDB via Gateway Endpoints incurs no data transfer charges (unlike NAT Gateway which charges per GB) and never leaves the AWS network, reducing exposure to internet-based threats.

Gateway Endpoints work by adding a prefix list to the VPC's route table. When you create a Gateway Endpoint for S3, AWS creates a prefix list (e.g., pl-6da54004 for S3 in us-east-1) representing the IP address ranges of S3 in that region. You then add a route in your route table pointing the prefix list to the endpoint ID (e.g., vpce-xxxx). When an instance in a private subnet sends a packet destined for S3, the VPC router matches the destination IP to the prefix list and forwards the packet to the Gateway Endpoint instead of the internet gateway. The endpoint then forwards the traffic to S3 over the AWS backbone. The response follows the reverse path. No NAT is needed, and the source IP of the instance is preserved (not translated), which is useful for S3 bucket policies that restrict access by VPC endpoint or source IP.

Creating a Gateway Endpoint (AWS CLI):

aws ec2 create-vpc-endpoint --vpc-id vpc-12345678 --service-name com.amazonaws.us-east-1.s3 --route-table-ids rtb-12345678

Adding a route to route table:

aws ec2 create-route --route-table-id rtb-12345678 --destination-prefix-list-id pl-6da54004 --vpc-endpoint-id vpce-12345678

Verification: - Check route table: aws ec2 describe-route-tables --route-table-ids rtb-12345678 — look for a route with destination prefix list ID and target vpce-xxx. - From an instance, run curl -I https://s3.us-east-1.amazonaws.com — if the route is correct, the response should succeed. Use traceroute to see hops stay within AWS. - Check endpoint state: aws ec2 describe-vpc-endpoints --vpc-endpoint-ids vpce-12345678 — status should be "available".

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringNotEquals": {
      "aws:SourceVpce": "vpce-12345678"
    }
  }
}

Route tables have a most specific match rule. If you have a route to 0.0.0.0/0 via NAT Gateway and a route to the S3 prefix list via Gateway Endpoint, traffic to S3 will match the more specific prefix list route. However, if you accidentally add a more specific route (e.g., a /16 that overlaps with S3 IPs) pointing to NAT, traffic could be misrouted. Always verify route table entries.

Gateway Endpoints scale automatically with traffic. There is no need to provision capacity. AWS uses a distributed system that handles bursts. Latency is minimal because traffic stays within the AWS network. For very high throughput workloads (e.g., big data analytics), Gateway Endpoints perform well without additional cost.

Because traffic never leaves AWS, Gateway Endpoints reduce attack surface. However, you must still secure access with bucket policies and endpoint policies. The source IP of the instance is preserved, so you can restrict by VPC or subnet CIDR if needed. Also, Gateway Endpoints support VPC Flow Logs, so you can monitor traffic.

A financial services company runs a data lake on Amazon S3. They have hundreds of EC2 instances in private subnets that constantly upload and download terabytes of data daily. Initially, they used a NAT Gateway for internet access, which also routed S3 traffic through the NAT. Their monthly NAT data processing charges exceeded $10,000. The network team created a Gateway Endpoint for S3 and added the route to all private route tables. After the change, NAT data processing dropped to near zero (only internet traffic remained). The team also applied an endpoint policy restricting access to specific S3 buckets used by the data lake. They used bucket policies with aws:SourceVpce condition to ensure only traffic from the endpoint could access the buckets. Result: $9,000/month savings and improved security. Misconfiguration risk: If they had forgotten to remove the S3 route from the NAT route table, traffic would have still gone through NAT, incurring charges. They verified by checking Flow Logs and seeing destination IPs in the S3 range.

A healthcare company uses DynamoDB for patient records. They have on-premises backup servers that need to write to DynamoDB. They use AWS Direct Connect to connect their on-premises network to the VPC. They need to access DynamoDB privately. Gateway Endpoints are not accessible from on-premises (they are VPC-only), so they use an Interface Endpoint (AWS PrivateLink) for DynamoDB instead. However, for EC2 instances within the VPC that process backups, they use a Gateway Endpoint for DynamoDB to avoid data transfer costs. The on-premises servers use the Interface Endpoint, paying per hour and per GB. This hybrid approach optimizes cost: VPC instances pay nothing for DynamoDB traffic, while on-premises traffic incurs Interface Endpoint charges. Common mistake: Trying to use Gateway Endpoint for on-premises access, which fails because the route table only applies to VPC traffic.

An enterprise uses AWS Organizations with multiple accounts. They want to centralize S3 access through a shared services VPC. They create a Gateway Endpoint in the shared services VPC. However, other VPCs (in other accounts) cannot use this endpoint directly because Gateway Endpoints are not transitive across VPC peering or Transit Gateway. Instead, they use Transit Gateway with a centralized NAT instance or a proxy. Alternatively, each VPC deploys its own Gateway Endpoint. The exam tests this limitation: Gateway Endpoints are VPC-scoped. For cross-account or cross-VPC access, use Interface Endpoints or a proxy.