VPC Endpoint

What is a VPC endpoint?

A VPC endpoint lets resources inside your VPC connect privately to AWS services — S3, DynamoDB, and many others — without the traffic ever traversing the public internet. Normally, an EC2 instance in a private subnet reaching S3 would send that traffic out through an internet gateway or a NAT gateway and across the public internet to S3’s public endpoint. A VPC endpoint replaces that path with a private connection over Amazon’s own internal network, so the data stays inside AWS the whole way. The benefits are better security (data isn’t exposed to the internet), and often lower cost and latency.

The two types, and why the distinction matters

There are two kinds, and picking the wrong one is a common stumble. Gateway endpoints are a special, free type available only for S3 and DynamoDB; you add a route to your route table pointing that service’s traffic through the gateway endpoint, and it works within your region at no charge. Interface endpoints (powered by AWS PrivateLink) are the general type used for most other AWS services (and for your own or third-party services); they create an elastic network interface with a private IP inside your subnet that acts as the entry point, and they carry an hourly charge plus data-processing fees. So the quick rule: for S3 and DynamoDB, use the free gateway endpoint; for nearly everything else, use an interface endpoint and budget for its cost. PrivateLink, the technology behind interface endpoints, is also what lets you privately expose your own service to other VPCs or consume a SaaS vendor’s service without going over the internet — an increasingly important pattern for private, multi-VPC and vendor connectivity.

Why teams use them — security and cost

Two motivations drive adoption. Security and compliance: keeping traffic to AWS services off the public internet is a core requirement in regulated and zero-trust environments — it shrinks the attack surface and satisfies auditors who don’t want sensitive data flowing over public paths. You can even attach endpoint policies to restrict which resources the endpoint may reach (e.g., only specific S3 buckets), adding another control layer. Cost: this is the underappreciated one. Instances in private subnets that reach S3 through a NAT gateway pay NAT data-processing charges on every byte — and for data-heavy S3 workloads, an S3 gateway endpoint (which is free) can eliminate a large NAT bill, a classic FinOps win that pays for itself immediately. The recurring mistakes: routing S3/DynamoDB traffic through expensive NAT gateways when a free gateway endpoint would do; forgetting that interface endpoints themselves cost money (deploying dozens without accounting for the hourly + data fees); and misconfiguring the route table or DNS so traffic silently keeps taking the internet path anyway.

What people get wrong

• Paying NAT charges for S3/DynamoDB — a free gateway endpoint removes that data-processing cost; not using one is money left on the table.
• Confusing the two types: gateway endpoints are free but only for S3/DynamoDB; interface endpoints cover other services but bill hourly plus data.
• Assuming it “just works” — without the right route-table entry or private DNS setting, traffic quietly keeps going over the internet, defeating the purpose.

Primary source: AWS PrivateLink and VPC endpoints