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:
![image-5cda51048867](https://cdn.sanity.io/images/jl67zxfh/production/4f3907b4a5546c3cb4c81f2129e2756cb9490913-521x493.png)
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:
![image-52db2fec421b](https://cdn.sanity.io/images/jl67zxfh/production/0fc9e593e7e5c003e25f3c8799eddbfee13216f9-521x331.png)
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](https://cdn.sanity.io/images/jl67zxfh/production/2a884b9db03cfd03de85fb97aa89210481acb7d0-501x561.png)
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.
![image-1b7142f7eeff](https://cdn.sanity.io/images/jl67zxfh/production/2e61b9d2051d0619fdc73edd9e1df3e86bd092f4-501x561.png)
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](https://cdn.sanity.io/images/jl67zxfh/production/a2a035849f5f725b4d50c466bdc1021b2e67d011-501x561.png)
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:
![image-f97fb133e9d0](https://cdn.sanity.io/images/jl67zxfh/production/e6b28a970c4dc4b4a22c902681138e35305965c7-491x311.png)
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](https://cdn.sanity.io/images/jl67zxfh/production/e3735775bc4a148b5ab3fc5b9e071fefba1e2104-805x210.png)
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](https://cdn.sanity.io/images/jl67zxfh/production/7bc7820e94435a211d0422cb7b4bb9b9d0278fbf-742x568.png)
*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.