VPC endpoints
Gateway versus interface endpoints, endpoint and bucket policies, centralizing endpoints for many VPCs, and when endpoints beat a NAT gateway.
Exam tasks: 1.1 (use service endpoints for service integrations), 2.3 (restrict access to AWS services from private networks)
The decision: is the service S3 or DynamoDB used only from inside the VPC (gateway endpoint), or does it need to be reached from elsewhere or is it another service (interface endpoint)? And where should the endpoints live when you have 100 VPCs?
Choosing an endpoint
Side by side
| Gateway endpoint | Interface endpoint | |
|---|---|---|
| Services | S3 and DynamoDB only | Most AWS services, including S3 and DynamoDB, plus PrivateLink endpoint services |
| How it works | A route table entry pointing a service prefix list at the endpoint | ENIs with private IPs in the subnets you choose, one per AZ |
| DNS | Public service names still used. Routing does the work | Private DNS makes the default service name resolve to the ENI IPs |
| Reachable from on-premises, peered VPCs, TGW spokes | No | Yes |
| Security groups | No. Use endpoint and bucket policies | Yes, on the ENIs |
| Cost | No charge | Per endpoint per AZ-hour + per GB processed |
| Scope | Same Region only | Same Region by default. Cross-Region PrivateLink is available for endpoint services |
Gateway endpoints don't extend
A gateway endpoint only serves traffic that starts in its own VPC. On-premises servers over Direct Connect, peered VPCs and Transit Gateway spokes can't use it, because edge-to-edge routing isn't supported. For those callers, create an S3 interface endpoint.
Interface endpoints
- Each endpoint gets ENIs in the subnets you pick, protected by security groups that must allow HTTPS (443) from the callers.
- Private DNS (on by default for AWS services) creates a hidden private hosted zone, so
sqs.eu-west-1.amazonaws.comresolves to the ENIs and SDKs need no changes. It requires the VPC DNS attributes to be on. - S3 interface endpoints support private DNS with an option to apply it only to inbound Resolver endpoint traffic. VPC workloads keep using the free gateway endpoint while on-premises callers resolve S3 to the interface endpoint.
- DynamoDB also has an interface endpoint option now, for on-premises and cross-VPC access.
- Other PrivateLink endpoint types exist: Gateway Load Balancer endpoints for inline inspection, and resource and service-network endpoints for VPC Lattice. See Connecting VPCs.
Endpoint policies
An endpoint policy is a resource-based policy on the endpoint. It restricts what can pass through the endpoint. It never grants anything: the caller still needs IAM permissions, and the resource's own policy still applies.
- Default policy: full access to the service.
- Typical use: allow only the organization's buckets through the S3 endpoint, with
aws:ResourceOrgID, so a compromised instance can't copy data into an attacker's bucket. - Combine with
aws:PrincipalOrgIDto allow only your organization's principals.
Locking resources to an endpoint
Use condition keys in the bucket policy (or other resource policy) to allow access only through your network.
| Key | Matches | Use when |
|---|---|---|
aws:SourceVpce | A specific endpoint ID, like vpce-0a1b2c3d | You want exactly one endpoint, or a list of them |
aws:SourceVpc | Any endpoint in a VPC, like vpc-111aaa | Several endpoints in the same VPC should work |
aws:VpcSourceIp | The caller's private IP, seen through an endpoint | Narrowing further to specific subnets |
aws:SourceIp | Public IPs only | Callers on the internet. It never matches traffic that comes through an endpoint |
Locking yourself out
A bucket policy that denies everything unless aws:SourceVpce matches also blocks the console, CI pipelines and
administrators outside the VPC. Real designs add an exception, for example aws:PrincipalArn for a break-glass
role. And a policy that relies on aws:SourceIp with private addresses never matches.
Exam signal
"Data must only be accessible from the VPC" means: a gateway or interface endpoint, plus a bucket policy with
aws:SourceVpce or aws:SourceVpc, plus an endpoint policy restricting which buckets are reachable. For
more S3 patterns, see S3 private access.
Centralized interface endpoints
With 100 VPCs each needing 10 endpoints in 3 AZs, per-VPC endpoints mean 3,000 billed endpoint-AZ units. The hub pattern puts one set in a shared-services VPC.
- Create the endpoints in the hub with private DNS turned off (private DNS only works in the endpoint's own VPC).
- For each service, create a PHZ named after the service's Regional endpoint, with an alias record to the endpoint's Regional DNS name.
- Associate the PHZs with every spoke VPC (cross-account association, or a Route 53 Profile), and with the VPC holding the inbound Resolver endpoint for on-premises callers. See Hybrid DNS.
- Allow spoke CIDRs in the endpoint security groups.
| Endpoints in every VPC | Central endpoints | |
|---|---|---|
| Endpoint-hour charges | Multiply with every VPC | Paid once |
| Data charges | Endpoint per GB only | Endpoint per GB + Transit Gateway per GB |
| Operations | Many endpoints, automatic private DNS | Few endpoints, but PHZs to manage |
| Blast radius and policy | Per-VPC endpoint policies | One policy for everyone |
| Best for | High-volume services, few VPCs | Many VPCs with light, spread-out usage |
Don't centralize S3 gateway endpoints
Gateway endpoints can't be reached across a Transit Gateway, so they can't be centralized. Keep a free gateway endpoint in every VPC that talks to S3 heavily, and centralize only interface endpoints.
Endpoints vs NAT gateway
- A NAT gateway charges per hour and per GB processed. S3 or DynamoDB traffic through NAT pays that per-GB fee for nothing. A gateway endpoint removes it at no cost.
- For other services, an interface endpoint's per-GB rate is usually lower than NAT processing. At high volume it pays for itself, and it also keeps traffic off the internet path.
- Low-volume calls to many different services can still be cheaper through one NAT gateway than through 20 interface endpoints across 3 AZs. The exam usually signals cost with "large amounts of data to S3".
Scenarios
A gateway endpoint has no hourly or per-GB charge and takes S3 traffic away from the NAT gateway through a route table entry, so the code doesn't change. An interface endpoint also works but adds per-hour and per-GB charges. NAT instances add operational burden and still process every byte. Transfer Acceleration speeds up long-distance uploads over the internet and costs extra.
Gateway endpoints only serve traffic that starts inside the VPC, so on-premises needs an interface endpoint. The bucket policy then restricts access to the two endpoints. aws:SourceIp never matches private addresses arriving through an endpoint. An on-premises route can't target a gateway endpoint, because gateway endpoints only work through VPC route tables. A public VIF reaches S3's public endpoints without passing through any VPC endpoint, so an aws:SourceVpce policy would block it.
Central endpoints cut endpoint-hour charges by a factor of about 150, and light traffic keeps the extra Transit Gateway data charge small. Private DNS only takes effect in the endpoint's own VPC, so spokes need PHZs that point the service names at the central endpoints. Gateway endpoints exist only for S3 and DynamoDB.
Further reading
Hybrid DNS
Resolving names between on-premises and many AWS accounts with Resolver endpoints, shared rules, private hosted zones and Route 53 Profiles.
Cross-account access
Role assumption vs resource-based policies, how AWS evaluates a cross-account request, external IDs, and the S3 and KMS patterns the exam loves.