PCG logo
Article

VPC Endpoints: Explanation and Cost Comparison

In this blog post, I will explain what VPC Endpoints actually are. What are the differences between VPC Gateway and Interface Endpoints? What benefits do VPC Endpoints offer? Also, a cost breakdown of how much the VPC Endpoints cost, as well as a comparison of the costs to a NAT Gateway.

What are VPC Endpoints?

Initially, it should be understood that within AWS, a Virtual Private Cloud (VPC) is an isolated network segment where I can utilize my desired CIDR IP range. Without an internet and NAT gateway, this VPC is completely isolated.

On the other hand, all AWS services that are not directly deployed into a VPC, such as S3, Systems Manager, SQS, Secrets Manager, etc., are accessible via a public address. This results in the fact that a VPC with EC2 instances in a private subnet must communicate with these AWS services via the NAT gateway. If no NAT gateway is available, there is also no possibility of communication and utilization of AWS services from the private subnet.

Traffic Diagram without a VPC Interface Endpoint:

Traffic Diagram without a VPC Interface Endpoint

To address this issue, VPC Endpoints are available. They allow me to establish communication from a VPC to a desired AWS service without the need for an internet or NAT gateway. Additionally, the traffic remains within the AWS network, further enhancing security and efficiency.

There are two types of VPC endpoints:

  • interface endpoints
  • gateway endpoints

What are VPC Interface Endpoints?

An Interface Endpoint utilizes AWS PrivateLink technology to create an Elastic Network Interface (ENI) within a private subnet of your VPC. Subsequently, traffic is redirected using a Route 53 DNS entry, so that, for instance, the FQDN logs.eu-central-1.amazonaws.com for CloudWatch is no longer resolved to its public IPs but to the IP address of the Elastic Network Interface of the VPC Endpoint. 

Traffic Diagram with a VPC Interface Endpoint:

Traffic Diagram with a VPC Interface Endpoint

To ensure high availability, it is advisable to create an endpoint network interface for each Availability Zone (AZ). Should there be only one endpoint network interface, communication with the corresponding AWS service could be disrupted in the event of an AZ or network interface failure.

Traffic Diagram with a VPC Interface Endpoint in one AZ:

image-664f98f75840

The following traffic diagram illustrates two endpoint network interfaces across two Availability Zones. When the public FQDN, for example, logs.eu-central-1.amazonaws.com, is used, traffic is distributed between the healthy endpoint network interfaces using round-robin.

Traffic Diagram with a VPC Interface Endpoint in multiple AZ

Should it suit your needs more effectively, you have the option to route traffic from your resources directly to the AWS service by leveraging the endpoint network interface situated within the same Availability Zone. To achieve this, simply utilize the corresponding private zonal endpoint or the IP address associated with that particular network interface.

AWS will give you a list of DNS names that you can use. The main one lets you connect to interfaces in all Availability Zones in a rotating fashion. The rest are for connecting to a specific Availability Zone—like if you want to connect only to eu-central-1a.

Here's what the DNS names from AWS look like for a VPC Interface Endpoint:

To connect to any Availability Zone: vpce-0ad175bd696304b1f-lk6xuedu.logs.eu-central-1.vpce.amazonaws.com

And if you want to connect to a specific zone, like eu-central-1a, eu-central-1b, or eu-central-1c, you would use one of these:

For eu-central-1a: vpce-0ad175bd696304b1f-lk6xuedu-eu-central-1a.logs.eu-central-1.vpce.amazonaws.com

For eu-central-1b: vpce-0ad175bd696304b1f-lk6xuedu-eu-central-1b.logs.eu-central-1.vpce.amazonaws.com

For eu-central-1c: vpce-0ad175bd696304b1f-lk6xuedu-eu-central-1c.logs.eu-central-1.vpce.amazonaws.com

Here is an example of how to use the AWS CLI to describe log groups utilizing the eu-central-1a VPC Endpoint:
aws logs describe-log-groups --endpoint-url https://vpce-0ad175bd696304b1f-lk6xuedu-eu-central-1a.logs.eu-central-1.vpce.amazonaws.com

image-8a2b7bba8dc3

What are VPC Gateway Endpoints?

A Gateway Endpoint is available exclusively for Amazon S3 and DynamoDB. When you create an S3 gateway endpoint, for instance, a prefix list containing all the public IP addresses of S3 is added to your VPC's route table, with the gateway endpoint specified as the target. As a result, traffic to S3 is directed to this gateway endpoint instead of going directly to the public IP addresses of S3. This ensures that the traffic flows through the AWS network, enhancing security and potentially reducing data transfer costs.

Traffic Diagram with a VPC Gateway Endpoint:

Traffic Diagram with a VPC Gateway Endpoint

Sounds good, so why not create a VPC Endpoint for every AWS service?


For VPC Gateway Endpoints, this is fundamentally a good idea because they do not incur additional costs. In particular, I would create an S3 and DynamoDB Gateway Endpoint by default in every VPC. The AWS wizard for creating VPCs now also offers the option to include the creation of the S3 Gateway Endpoint directly.

image-ccc2bad6f616

In contrast, VPC Interface Endpoints do come with associated costs. Each VPC Interface Endpoint costs just under $9 in the eu-central-1 region per availability zone. If a VPC Interface Endpoint is created in all 3 availability zones for high availability reasons, the cost for a single VPC Interface Endpoint would be just under $27—and this is for one service. There are currently 211 different AWS services for which a VPC Interface Endpoint can be created. Creating VPC Interface Endpoints for every AWS service indiscriminately would amount to approximately $5700 in monthly costs.

It's also possible to centralize VPC Interface Endpoints, which makes sense especially if there is already a network account with a Transit Gateway, and all the VPCs from different accounts are attached to it. In this scenario, no additional VPC attachment fees would be incurred. The existing Transit Gateway attachment could then be leveraged to create centralized VPC Endpoints for certain AWS services.

Cost Comparison.

There are four options to make the AWS services accessible from private subnets:

  • A Gateway Endpoint is free of charge but is only available for S3 and DynamoDB.
  • An Interface Endpoint costs approximately $8.76 per month per AZ plus about $0.01 per GB and is available for most AWS services.
  • A NAT Gateway can be used to access AWS services or any other services with a public API. The cost is $37.96 per month per AZ plus $0.052 per GB.
  • A transit gateway attachment costs approximately $43.80 per month per AZ plus about $0.02 per GB. Additionally, if you use an Interface Endpoint, the cost is approximately $8.76 per month per AZ plus about $0.01 per GB.
image-193b98c86cf5

*The prices are based on the eu-central-1 (Frankfurt) region as of May 10, 2024.

It should be noted that traffic routed through a VPC Interface Endpoint is less expensive than traffic passing through a NAT Gateway. For traffic going through a centralized VPC Interface Endpoint, the traffic costs of the Transit Gateway and the VPC Interface Endpoint must be added together. However, the combined cost is still lower than that of traffic through a NAT Gateway.

When designing your network architecture, consider these guidelines:

  • Always create VPC Gateway Endpoints for S3 and DynamoDB – they're essentially cost-free and highly beneficial.
  • If you need to access non-AWS resources over the internet, include a NAT Gateway. Evaluate whether the volume of traffic to AWS services warrants the additional expense of Interface Endpoints.
  • When only accessing AWS services from private subnets and if dealing with no more than four different services, use Interface Endpoints. For broader needs, compare the costs between Interface Endpoints and a NAT Gateway to find the most cost-effective approach.
  • If there's a Transit Gateway already implemented, with all VPCs attached to it, it may be wise to create centralized VPC Interface Endpoints for the frequently used AWS services.

Conclusion.

I hope to have provided you with a comprehensive overview of VPC Endpoints and the various ways they can be utilized. I trust this information has been helpful in guiding your decisions on how to implement VPC Endpoints in your network architecture.


Services Used

Continue Reading

Article
Automation
Automated Control Rollout in AWS Control Tower

Control Tower Controls help you to set up guardrails making your environment more secure and helping you ensuring governance across all OUs and accounts.

Learn more
News
Above the Clouds: PCG's Stellar Performance at the AWS LeadMaster Challenge 2024

Wow, what a triumph! Public Cloud Group has just swept the AWS Summit 2024 Lead Master Challenge.

Learn more
Article
AWS Events 2025: The Future is Cloud

As a leading AWS Premier Partner, we're thrilled to present the exciting lineup of AWS events for 2025.

Learn more
Article
Protecting Lambda URLs with Cognito, IAM, Lambda@Edge and CDK

In this article, we’ll look at how to secure Lambda URLs using IAM access control. With complete code to try yourself!

Learn more
See all

Let's work together

United Kingdom
Arrow Down