by Valts Ausmanis · September 4, 2024
AWS VPC endpoints enable you to connect privately to AWS managed services and VPC endpoint services. There are two types of VPC endpoints: Interface Endpoints and Gateway Endpoints. Both allow you to use private IP addresses to connect with the service's resources, ensuring that traffic between the Amazon VPC and the service doesn’t leave the AWS network. To understand when to use an interface endpoint versus a gateway endpoint, let’s take a closer look at the differences between the two.
A VPC interface endpoint enables you to connect privately to services over AWS PrivateLink. These services can include:
AWS PrivateLink is essentially the backbone of the interface endpoint, providing highly available and scalable technology to privately connect your VPCs to the services described above.
A VPC gateway endpoint enables your instances in a VPC to connect to Amazon S3 and DynamoDB without requiring public IP addresses. This connectivity doesn’t require an internet gateway or NAT gateway, which would otherwise be needed if the VPC gateway endpoint were not attached to the specific VPC (see diagram below).
While the traffic between instances in the VPC and S3/DynamoDB doesn’t leave the AWS network, it’s good to note that gateway endpoints, unlike interface endpoints, do not rely on AWS PrivateLink.
As you may already know from the previous sections' descriptions and diagrams, there are differences between VPC interface endpoints and gateway endpoints. Now, let’s take a closer look at these in more detail.
A VPC interface endpoint is created at the subnet level. When you create a new VPC interface endpoint, you can choose one or more subnets (one from each availability zone) where the interface endpoint will be created.
One interface endpoint can represent one or more network interfaces that have private IP addresses, serving as the entry point for traffic to the selected service.
In the diagram above, you can see that we have created a VPC interface endpoint to access our private API gateway endpoints in two private subnets (each in a different availability zone), where each subnet has one network interface with a specific private IP address as the traffic entry point. By creating a VPC interface endpoint in multiple availability zones, you ensure high availability for your application; if one of the availability zones goes down, the other endpoint remains available.
At the same time, a VPC gateway endpoint is created at the VPC level. Compared to an interface endpoint, you don't have to specify specific subnets; instead, you just choose a VPC.
For example, in the diagram below, you can see that we have created a VPC gateway endpoint for specific VPC to privately access our S3 buckets (via the S3 service: com.amazonaws.eu-west-1.s3).
The difference compared to an interface endpoint is that a gateway endpoint provides high availability by default, with AWS managing all the underlying infrastructure, such as providing an internal failover mechanism if one availability zone goes down.
When you create a VPC interface endpoint, public DNS names are created by default (e.g., vpce-0c11f0aa40d2ff5ad-l1xf6pcv.kendra-ranking.eu-west-1.vpce.amazonaws.com) that can be used to access a specific endpoint service (e.g., Amazon Kendra Intelligent Ranking).
A regional DNS name will be created along with a DNS name for each availability zone where you have created the specific VPC interface endpoint. These DNS names point to private IP addresses that represent the network interfaces of the VPC interface endpoint:
You can enable private DNS for your VPC interface endpoint if “Enable DNS hostnames” and “Enable DNS Support” are enabled for your VPC. This will create an AWS-managed (hidden) private hosted zone with a record set for the default service public DNS name (e.g., kendra-ranking.eu-west-1.api.aws) that resolves to the interface endpoint's private IP addresses. This allows you to continue using the public endpoint of the specific service (e.g., kendra-ranking.eu-west-1.api.aws) for your application, while the traffic is routed through the VPC interface endpoint instead.
While an interface endpoint doesn’t require additional routes to be added in VPC route tables for traffic to be routed to the interface endpoint network interfaces, this is not the case with a gateway endpoint. To route traffic to a gateway endpoint, which is attached to the VPC, a specific route must be added to the route table:
As you can see above, a new route was added to the route table with the target set to the gateway endpoint ID and the destination set to the AWS-managed prefix list ID (in this example, for the S3 service). This prefix list defines the IP address ranges for the S3 service in a specific region. Whenever your application uses the S3 public DNS name (e.g., s3.eu-west-1.amazonaws.com) and if the underlying IP address falls within one of these IP ranges, the traffic will be routed to the gateway endpoint.
It’s important to note that these prefix lists are region-specific. So, if you try to access, for example, the S3 service from another region, let’s say the us-east-1
region (via s3.us-east-1.amazonaws.com endpoint), the traffic will be routed to the internet gateway and will leave the AWS network.
As mentioned before VPC interface endpoint supports many different services:
However, gateway endpoint supports only DynamoDB and S3 services.
This means that whenever you need a private connection with service which is not DynamoDB or S3 – VPC interface endpoint is the way to go.
A VPC interface endpoint supports security groups that control the traffic allowed to flow into the endpoint network interfaces.
A VPC gateway endpoint doesn’t support security groups.
However, both gateway and interface endpoints support setting an endpoint policy (not all AWS services support endpoint policies), which essentially acts as an additional layer of control by specifying what actions on which resources are allowed through the specific VPC endpoint.
VPC gateway endpoint is designed to be used within the VPC in which it is created.
However, an interface endpoint is designed to be additionally used from other VPCs, across regions, and on-premises.
As you can see in the above diagram, we have created a shared services VPC with an interface endpoint (with private DNS disabled) to the API Gateway service. We established VPC peering connections between the shared services VPC and three consumer VPCs to access the VPC endpoint. To correctly route requests from the consumer VPCs to the shared services VPC endpoint, we created a private hosted zone (apigateway.eu-west-1.amazonaws.com) that points to the interface endpoint's regional DNS name. This resolves to the VPC interface endpoint's private IP addresses and is properly routed via the VPC peering connections.
To access this interface endpoint from on-premises, we created a site-to-site VPN connection and a Route 53 Resolver inbound endpoint. This ensures proper DNS resolution between on-premises and AWS services. Additionally on-premises DNS resolver needs to be updated with forwarding rules that points queries to service to the Route 53 Resolver inbound endpoint.
For a VPC gateway endpoint, there are no additional usage or data processing costs. However, all standard S3 or DynamoDB pricing still applies.
However interface endpoint usage is not for free and it's pricing consists of:
Use a VPC gateway endpoint whenever you have to privately access S3 or DynamoDB within the same region and from the same VPC where the gateway endpoint is attached. This approach is cost-effective and ensures that data transferred between the VPC and S3 or DynamoDB doesn’t leave the AWS network.
Use a VPC interface endpoint whenever:
Keep in mind that when using VPC peering or transit gateway connections to access VPC interface endpoints in other VPCs, there are additional data transfer and usage costs. These costs are on top of the standard interface endpoint costs. Therefore, I suggest designing your AWS network architecture wisely.
Looking for a tool to automatically visualize your VPC Interface Endpoints and Gateway Endpoints?
Try out Cloudviz.io and visualize your AWS cloud environment in seconds
As experienced AWS architects and developers, our goal is to provide users an easy way to create stunning AWS architecture diagrams and detailed technical documentation. Join us to simplify your diagramming process and unleash the beauty of your cloud infrastructure
Support
Contact
Copyright © 2019 - 2024 Cloudviz Solutions SIA