VPC Endpoint

A VPC Endpoint enables private connectivity between your VPC and supported AWS services without requiring an internet gateway, NAT device, VPN, or AWS Direct Connect. Traffic between your VPC and the service stays on the Amazon network.

Types

• Gateway endpoints: for S3 and DynamoDB; free; configured via route tables
• Interface endpoints (PrivateLink): for 100+ services; creates an ENI in your subnet with a private IP; costs per hour + per GB

Gateway endpoints do not use PrivateLink: when you create one, AWS adds a route to each route table you select, with the service's managed prefix list as the destination and the endpoint as the target. Note that S3 and DynamoDB support both endpoint types, so you can choose gateway (free, VPC-internal) or interface (paid, reachable through private IPs) per use case. The endpoint family has also grown beyond the classic two: the API distinguishes Interface, Gateway, GatewayLoadBalancer, Resource, and ServiceNetwork endpoint types.

How It Goes Wrong in Practice

The endpoint itself rarely fails; its policy does. Endpoints are created with a default policy allowing full access to the service, and most teams never touch it. Consider the well-documented exfiltration pattern this enables: an attacker who compromises an instance in a private subnet cannot reach the internet, but the S3 gateway endpoint is right there, and its wide-open policy happily routes s3:PutObject calls to any bucket, including a bucket in the attacker's own AWS account. The private, "no internet" architecture becomes the exfiltration path.

Locking this down takes two complementary policies:

• Endpoint policy: restrict which principals, actions, and resources may be used through the endpoint, for example only buckets in your own accounts.
• Bucket policy: restrict where requests may come from, using the aws:SourceVpce condition key (which takes the endpoint ID, not an ARN) to deny access unless traffic arrives through your endpoint.

One caution from the AWS documentation itself: bucket policies that deny everything outside a specific VPC endpoint also block AWS console access to the bucket, because console requests do not originate from your endpoint. Test such policies on a non-critical bucket first, and always scope deny statements carefully.

Practical Check: Inventory Endpoints and Their Policies

List every endpoint in a VPC along with its type, service, and attached policy:

aws ec2 describe-vpc-endpoints --filters Name=vpc-id,Values=vpc-0123456789abcdef0 --query "VpcEndpoints[].[VpcEndpointId,VpcEndpointType,ServiceName,PolicyDocument]"

Review the PolicyDocument of each endpoint: a statement with "Principal": "*", "Action": "*", and "Resource": "*" is the untouched default and deserves a ticket. Filtering on Name=vpc-endpoint-type,Values=Gateway narrows the audit to S3 and DynamoDB gateway endpoints, which is where the exfiltration concern concentrates. Repeat the sweep per VPC and per region, since endpoints are regional resources and one forgotten VPC is all an audit needs to miss.

Frequently Asked Questions

Are VPC endpoints really free?

Gateway endpoints carry no additional charge, which is why enabling the S3 and DynamoDB gateway endpoints in every VPC is close to a free win: private connectivity plus reduced NAT gateway data processing costs. Interface endpoints bill per endpoint-hour and per GB processed, so for those you weigh the cost against NAT charges and the security benefit of keeping service traffic off the internet path.

Do endpoints change the DNS names my application uses?

For gateway endpoints, no: applications keep calling the standard public service endpoints, and routing sends the traffic through the endpoint for the service in the same region. Traffic to the service in another region does not match the prefix list and follows the internet route, a subtlety worth remembering when a bucket lives in a different region than the VPC. Interface endpoints work differently, publishing private DNS entries that resolve service hostnames to the endpoint's private IPs inside your VPC.

Does a security group apply to a VPC endpoint?

Interface endpoints have ENIs and therefore security groups, which must allow traffic from your workloads. Gateway endpoints have no ENI; instead, the security groups of your instances must allow outbound traffic to the service, and you can reference the service's managed prefix list ID in the outbound rule to keep it tight. This is a nice pattern for locked-down private subnets: an outbound rule allowing TCP 443 to the S3 prefix list, and nothing else, gives workloads their S3 path while keeping the security group free of broad CIDR ranges that drift out of date.