2.1.3. VPC Endpoints (Interface & Gateway)

VPC Endpoints provide private and secure connectivity to AWS services from within your VPC, bypassing the public internet and NAT Gateways, enhancing security and potentially reducing costs.

Scenario: You need to securely access Amazon S3 and Amazon CloudWatch from EC2 instances in a private subnet. This traffic currently routes through a NAT Gateway, incurring significant costs and introducing internet exposure.

Normally, instances in a private subnet needing to access AWS services (like Amazon S3) would route traffic through a NAT Gateway or an Internet Gateway. VPC Endpoints eliminate this need, providing a more secure and often more cost-effective solution.

Key Types of VPC Endpoints:

• Gateway Endpoints:

  • What they are: A gateway that you specify as a target for a route in your route table.
  • Supported Services: Only for Amazon S3 and Amazon DynamoDB.
  • Benefits: Free of charge (no data processing fees), no need for NAT Gateway or Internet Gateway for these services.
  • Endpoint Policy: Control access to services via an endpoint policy.
  • Controls: a gateway endpoint has no security groups and no DNS name; you add it as a target (the service prefix list) to the route tables of the subnets that should use it, and restrict it with the endpoint policy (e.g., Resource limited to one bucket). One endpoint serves the VPC — it is not deployed per AZ.

• Interface Endpoints (powered by AWS PrivateLink):

  • What they are: An Elastic Network Interface (ENI) with a private IP address that serves as an entry point for traffic to a service.
  • Supported Services: A wide range of AWS services (e.g., CloudWatch, Kinesis, Systems Manager, SageMaker), as well as SaaS applications and services hosted by other AWS customers.
  • Benefits: Private connectivity, higher security, typically lower cost than NAT Gateway egress for large volumes.
  • New port on a PrivateLink service: add a listener for the port on the provider's Network Load Balancer and open the port in the security groups on both sides (including the provider's targets). The existing endpoint service and interface endpoints stay as they are, and route tables are not involved.
  • Private REST APIs: an Amazon API Gateway private API is reachable only through an execute-api interface endpoint (plus a resource policy), including from on-premises over Direct Connect or VPN, never from the internet.
  • Endpoint Policy: Control access.
  • Endpoint policy scope: an IAM resource policy on the endpoint that limits which principals, actions and resources can be used through it (e.g., only AppRole may call sqs:SendMessage on one queue). Security groups and NACLs see only IP addresses and ports, never the caller's IAM identity.
  • Private DNS: with Enable private DNS name on, the service's default public hostname (e.g., kinesis.us-east-1.amazonaws.com) resolves inside the VPC to the endpoint's private IPs — no hosted zone or CNAME to create. It applies only inside the VPC (on-premises clients need Resolver endpoints). For a custom friendly name, create a record (CNAME or alias) in a private hosted zone that points at the endpoint's DNS name.

• Endpoint services (PrivateLink provider side): a provider fronts its application with a Network Load Balancer (or Gateway Load Balancer), publishes it as a VPC endpoint service, and controls who may connect with allowed principals (optionally requiring manual acceptance). Consumers create an interface endpoint (a Gateway Load Balancer endpoint, for a GWLB-backed service) in their own VPC. Only the service is exposed — no routes join the two VPCs — so PrivateLink works even when consumer and provider CIDRs overlap, needs no peering or Transit Gateway, and scales to many customers.

• Interface Endpoint Security Groups: The endpoint's ENIs carry a security group that must allow inbound traffic from the clients on the service port (e.g., TCP 443); the client's own security group must allow outbound traffic to the endpoint's private IPs. No route table entries are needed — clients reach the endpoint through its private DNS name. The same applies to AWS PrivateLink endpoint services published by other accounts.

• Endpoint Policies as a Data Perimeter: To let instances reach only your own S3 buckets, allow S3 actions with a condition on the resource — aws:ResourceOrgID (buckets in your organization) or s3:ResourceAccount/aws:ResourceAccount (buckets in listed accounts). aws:PrincipalOrgID constrains who is calling, not which bucket. Route tables cannot tell buckets apart: the gateway endpoint route targets the whole S3 prefix list.

Practical Implementation: Creating an S3 Gateway Endpoint

# Assuming VPC_ID and PRIVATE_ROUTE_TABLE_ID are already defined
# 1. Create the S3 Gateway Endpoint
ENDPOINT_ID=$(aws ec2 create-vpc-endpoint \
  --vpc-id $VPC_ID \
  --service-name com.amazonaws.us-east-1.s3 \
  --route-table-ids $PRIVATE_ROUTE_TABLE_ID \
  --query VpcEndpoint.VpcEndpointId --output text)
echo "S3 Gateway Endpoint ID: $ENDPOINT_ID"

# Note: A route to the S3 service prefix is automatically added to the specified route table.
# You can verify this by:
aws ec2 describe-route-tables --route-table-ids $PRIVATE_ROUTE_TABLE_ID

⚠️ Common Pitfall: Using a NAT Gateway for S3 or DynamoDB access from private subnets. This is an unnecessary cost and security exposure when a free Gateway Endpoint is available.

Key Trade-Offs:

• Cost (Gateway) vs. Service Coverage (Interface): Gateway Endpoints are free but only support S3 and DynamoDB. Interface Endpoints support a wider range of services but incur hourly charges and data processing fees.

Reflection Question: How do VPC Endpoints (differentiating between Gateway Endpoints for S3 and Interface Endpoints for CloudWatch) fundamentally provide private and secure connectivity to AWS services from within your VPC, bypassing the public internet and NAT Gateways for enhanced security and cost optimization?