When using AWS services, it is important to access these services securely. One way to do this is by using VPC endpoints. A VPC endpoint is like a private doorway between your VPC and AWS services. This means that you can access AWS services such as S3, DynamoDB or Systems Manager within your VPC without leaving the AWS network. This improves security and ensures your data stays private.

There are two types of VPC endpoints - interface endpoints (powered by AWS PrivateLink ) and gateway endpoints. Gateway endpoints can be used to access S3 and DynamoDB services privately. There is no additional charge for using gateway endpoints. For interface endpoints, there is an hourly running cost incurred along with data processing charges.

For AWS environment with multiple VPCs, deploying separate interface endpoints in each VPC can get expensive. Each endpoint has a small cost to run per hour per Availability Zone (AZ). If your workloads span across multiple AZs, you would need an endpoint per subnet and the cost could quickly add up.

Implementing a centralised VPC endpoints architecture, as opposed to deploying endpoints in each VPC individually, has the potential to reduce your AWS bill significantly. In this blog, we will explore how the centralised VPC endpoints approach can help organisations reduce costs particularly when utilising AWS Systems Manager (SSM) service.

Overview of SSM VPC endpoints

The primary benefit of SSM VPC endpoints is that they enable secure communication between your SSM managed nodes and the Systems Manager service.

This allows you to manage EC2 instances in VPC private subnets and non-EC2 machines in hybrid and multicloud environment using features such as Session Manager, Parameter Store, Patch Manager, and Run Command, without exposing network traffic to the internet. This enhances security, reduces network latency, and avoids potential data exposure risks as you are able to place your workloads into completely private subnets without internet access.

The required interface VPC endpoints for SSM:

• com.amazonaws.<region>.ssm - The endpoint for the SSM service.
• com.amazonaws.<region>.ssmmessages - This endpoint is required for SSM Agent to communicate with the SSM service, for Run Command, and if you’re connecting to your instances through a secure data channel using Session Manager.
• com.amazonaws.<region>.ec2messages - SSM uses this endpoint to make calls from SSM Agent to the SSM service. ¹

Additional VPC endpoints utilised by SSM depending on your configurations:

• com.amazonaws.<region>.ec2 - If you are using SSM to create VSS-enabled snapshots.
• com.amazonaws.<region>.kms – If you want to use AWS Key Management Service (KMS) encryption for Session Manager or Parameter Store parameters.
• com.amazonaws.<region>.logs – If you want to use AWS CloudWatch Logs for Session Manager, Run Command, or SSM Agent logs.
• com.amazonaws.<region>.s3 – SSM uses this endpoint to update SSM Agent. ²

Interface VPC endpoints are represented as network interfaces with private IP addresses within the VPC subnets you deploy to. When you access an AWS service endpoint, eg. ssm.ap-southeast-2.amazonaws.com, the domain name resolves to a public IP address. When you create an interface VPC endpoint with the default settings, an AWS managed Private Hosted Zone (PHZ) is automatically created and associated to the VPC to override the AWS service endpoint public DNS resolution. Instead, the public service endpoint DNS resolves to the VPC endpoint private IP addresses. Hence, the network traffic routes privately within your VPC to get to the AWS service.

There are two main architectural approaches when deploying SSM VPC endpoints:

1. Distributed architecture - Deploying SSM VPC endpoints in every VPC that requires access to SSM. This is the common approach.
2. Centralised architecture - Utilising a centralised architecture where a hub VPC hosts the SSM endpoints and other spoke VPCs access them via VPC peering or, better, AWS Transit Gateway.

Let’s explore both architecture with a cost analysis.

Distributed architecture

In a distributed deployment, you create endpoints for each VPC and in every AZ to avoid cross AZ data transfer. Depending on the number of VPCs and AZs your AWS environment has, this can quickly become expensive due to the endpoint-hour costs.

Here’s a high-level diagram of what the architecture looks like:

Each VPC has its own SSM interface endpoints and Route 53 Private Hosted Zone (PHZ), which by default created and managed by AWS during the endpoints creation. The AWS managed PHZ only works within the VPC the endpoints are created. As your AWS environment scales, ie. new VPCs created, you will have to create more endpoints and rake up additional endpoint-hour charges.

Monthly cost calculation for distributed SSM VPC endpoints

For the cost calculation, I will use a scenario with 10 VPCs, each VPC using 3 AZs and 6 SSM VPC endpoints, and assume each VPC would transfer 10GB data per month (10GB is a guesstimate; the data volume depends on how heavily you utilise SSM services).

I will use the AWS Sydney region AWS PrivateLink pricing . The pricing as at the time of writing this post:

Billing item	USD
Pricing per VPC endpoint per AZ per hour	$0.013
Pricing per GB of Data Processed per month (first 1 PB)	$0.01

The monthly cost for the endpoint-hour charges is:

10 VPCs * 3 AZs * 6 ENIs * 24 hours * 30 days * $0.013/hour = $1684.80 monthly

The data processing charges for 10GB per VPC would be:

10 VPCs * 10GB * $0.01/GB = $1.00 monthly

So, the total cost for the distributed SSM endpoint architecture is $1685.80 per month.

Centralised architecture

Instead of creating many interface endpoints across all VPCs, you could centralise the endpoints in one VPC and allow the other VPCs to access the shared endpoints. This way you reduce the number of endpoints and therefore the associated costs.

AWS provides a reference architecture for this design - Centralizing VPC endpoints with AWS Transit Gateway. In this architecture, all your VPCs connect to the shared services VPC via AWS Transit Gateway to access the interface endpoints.

A simple diagram of this architecture in SSM context:

The SSM VPC endpoints are deployed in a shared services (hub) VPC and access by other VPCs (spoke) through the Transit Gateway. The Route 53 PHZ is manually created and associated to the spoke VPCs to enable the other VPCs to resolve the SSM public service endpoint DNS to the shared interface endpoint private IP addresses.

Note that the private DNS option needs to be disabled when the interface endpoints are created. A Route 53 PHZ matching the service endpoint name and an Alias record with the full AWS service endpoint name pointing to the interface endpoint needs to be created and added manually.

Monthly cost calculation for centralised SSM VPC endpoints

I will use the same scenario as distributed architecture for the cost calculation and AWS Sydney region AWS Transit Gateway pricing . The pricing as at the time of writing this post:

Billing item	USD
Price per AWS Transit Gateway attachment per hour	$0.07
Price per GB of Data Processed per month	$0.02

The monthly charges of the 6 interface endpoints in the hub VPC is:

3 AZs * 6 ENIs * 24 hours * 30 days * $0.013/hour = $168.48 monthly

For Transit Gateway attachments, we have 11 VPC attachments (10 spoke VPCs and 1 hub VPC), so the cost is:

11 VPC attachments * 24 hours * 30 days * $0.07/hour = $554.40 monthly

The same 10GB data from each VPC is routed across the Transit Gateway to reach the hub VPC endpoints, thus the Transit Gateway data processing cost is:

10 VPCs * 10GB * $0.02/GB = $2.00 monthly

Plus, the hub VPC endpoints data processing charges:

10 VPCs * 10GB * $0.01/GB = $1.00 monthly

Therefore, the total cost for the centralised architecture using Transit Gateway is $725.88.

From the cost analysis, using a centralised architecture results in a cost of $725.88/month as compared to $1685.80/month for the distributed approach - a savings of $959.92.

Which architecture best suits your AWS environment

The monthly cost of the architecture design varies based on these factors - the number of VPCs, AZs, endpoints, and the volume of data processed.

I created several datasets to determine the break-even point. Here’s a sample dataset showing the monthly cost for transferring 10GB of data per VPC:

# of VPC	# of AZ	# of Endpoints	Data transfer (GB)	Distributed cost	Centralised cost
1	3	6	10	$168.58	$269.58
2	3	6	10	$337.16	$320.28
3	3	6	10	$505.74	$370.98
4	3	6	10	$674.32	$421.68
5	3	6	10	$842.90	$472.38
6	3	6	10	$1,011.48	$523.08
7	3	6	10	$1,180.06	$573.78
8	3	6	10	$1,348.64	$624.48
9	3	6	10	$1,517.22	$675.18
10	3	6	10	$1,685.80	$725.88
11	3	6	10	$1,854.38	$776.58
12	3	6	10	$2,022.96	$827.28
13	3	6	10	$2,191.54	$877.98
14	3	6	10	$2,360.12	$928.68
15	3	6	10	$2,528.70	$979.38
16	3	6	10	$2,697.28	$1,030.08
17	3	6	10	$2,865.86	$1,080.78
18	3	6	10	$3,034.44	$1,131.48
19	3	6	10	$3,203.02	$1,182.18
20	3	6	10	$3,371.60	$1,232.88

The chart below illustrates the break-even point between the centralised (green line) and distributed (purple line) architecture occurs at approximately 2 VPCs mark.

After 2 VPCs, the cost of the distributed architecture increases exponentially.

However, as the volume of data increases, the higher cost of data processing via Transit Gateway offsets the endpoint-hour savings.

The following chart shows the costs of both architecture for 10TB data transfer per VPC.

Disclaimer: I don’t know if 10TB data transfer per VPC for SSM even makes sense, but for comparison’s sake, let’s assume it does.

For organisations with many VPCs, multiple AZs and low data transfer, the centralised model offers significant cost savings. Conversely, if a large volumes of data are processed, the distributed architecture may be more cost-effective.

Summary

By considering the factors - number of VPCs, AZs and endpoints, and data volumes - you can determine the most cost-effective approach for deploying SSM VPC endpoints in your AWS environment.

• Centralised SSM VPC endpoints: Ideal for environments with many VPCs and minimal data transfer. This setup not only reduces the endpoint-hour charges but also simplifies management therefore making it suitable for organisations with a high number of VPCs and low to moderate data processing needs.

• Distributed SSM VPC endpoints: More appropriate for environments with a few VPCs, a small number of endpoints, or where data processing is high, as the higher Transit Gateway data processing costs could outweigh the savings from reduced endpoints.