AWS VPC Interface Endpoint vs Gateway Endpoint

AWS VPC Interface Endpoint vs Gateway Endpoint
author valts

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.

In This Article

What is AWS VPC Interface Endpoint?

vpc interface endpoint overview

A VPC interface endpoint enables you to connect privately to services over AWS PrivateLink. These services can include:

  • AWS managed services (e.g., API Gateway, CloudWatch, SQS, SNS, etc.).
  • Provider services hosted by another AWS account as a VPC endpoint service.
  • Third-party services from AWS Marketplace partners.

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.

What is AWS VPC Gateway Endpoint?

vpc gateway endpoint overview

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).

s3 dynamodb access via internet gateway

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.

What are the Differences Between VPC Interface Endpoint and Gateway Endpoint?

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.

Subnet Level vs VPC level

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.interface endpoint subnet select

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.

s3 dynamodb access via internet gatewayvpc interface endpoint

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.

create gateway endpoint

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).

vpc gateway endpoint

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.

Traffic Flow: DNS Resolution vs Route Table

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).

interface endpoint dns names

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:

interface endpoint dns name nslookupinterface endpoint private ip

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:

endpoint gateway route

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.

s3 prefix list

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.

Support for Many AWS Managed and Third-Party Services vs S3 and DynamoDB Only

vpc endpoint interface managed aws services

As mentioned before VPC interface endpoint supports many different services:

  • AWS managed services (e.g., API Gateway, CloudWatch, SQS, SNS, etc.).
  • Provider services hosted by another AWS account as a VPC endpoint service.
  • Third-party services from AWS Marketplace partners.

However, gateway endpoint supports only DynamoDB and S3 services.

vpc endpoint gateway supported 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.

Security Group Support vs No Security Group Support

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.

Cross-Region and On-Premises Access vs VPC Access Only

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.

cross region interface endpoint access

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.

private hosted zone

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.

route53 reslover inbound endpoint

Additional Charges vs No Cost

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:

  • Price per interface endpoint per availability zone: $0.01 per hour.
  • Data processing charge: $0.01 per GB.

When to Use Each?

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:

  • You have to privately access AWS managed services (except S3 or DynamoDB), VPC endpoint services from another AWS account, or services from AWS Marketplace partners.
  • You have to make a VPC interface endpoint (including for S3 and DynamoDB) available for use from other VPCs, different regions, or on-premises.

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

Start your free trial

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


Copyright © 2019 - 2024 Cloudviz Solutions SIA