AWS VPC Endpoint is NOT a security topic!?

This article demystifies the security and performance implications of using AWS VPC Endpoints.

Spoiler: This is not about security for me.

Indeed, many companies have compliance constraints that mandate the implementation of an air-gapped environment.

Let's take a closer look at how VPC endpoints work.

Start with official AWS documentation

VPC Endpoint definition from AWS
VPC Endpoint doc

Takeaways from the docs:

• Traffic stays on the AWS Network
• Prevent availability risks or bandwidth constraints
• Use AWS PrivateLink

AWS PrivateLink
If you're looking for VPC endpoints, you quickly come across the concept of AWS PrivateLink.
PrivateLink doc

Do we exit the AWS network without an endpoint?

AWS PrivateLink supports many AWS services. For this test, we will use SSM (System Manager).

Below are two diagrams showing the difference between having an endpoint and not having one.

Let's test it with the traceroute command!

Below are the results indicating the hops traversed from an EC2 instance to the SSM endpoint.

If we analyze the IP addresses of each hop. There is no IP outside of the AWS network. This is why we can conclude that we stay on the AWS network.

You can check below the reference of the RFC mentioned:

• Network class E: RFC1112
• CGNAT Shared Space: RFC6598

This last one is pretty interesting because AWS recommends using it in case of IP exhaustion for EKS.

What is intriguing here is the use of unusual CIDR blocks internally by AWS.

Are we experiencing better latency with the endpoint?

How to test this?

With a bash script of course :)

The following script measures the average latency of HTTP requests to the SSM endpoint over 30 minutes. It records timing metrics for each request and calculates the average latency from the results. Thanks to ChatGPT for the curl options.

end_time=$((SECONDS+1800)) 
while [ $SECONDS -lt $end_time ]; do
   curl -o /dev/null -s -w 'Connect: %{time_connect} TTFB: %{time_starttransfer} Total time: %{time_total}\n' https://ssm.eu-west-1.amazonaws.com;
   sleep 2; 
done >> output.log
count_lines=$(awk '{print $NF}' output.log | wc -l)
sum_lines=$(awk '{print $NF}' output.log | paste -sd+ - | bc)
average=$(echo "scale=4; $sum_lines / $count_lines" | bc)
echo "Average Latency: $average"

Result

• WITHOUT endpoint --> ~55ms
• WITH endpoint --> ~55ms

About bandwidth, based on a real-world use case using Athena with and without an endpoint, the performance remained the same.

Observation

Based on these tests we can conclude that network security and performance are the same with and without an endpoint.

AWS constructed its infrastructure using public DNS, but resolving a public IP doesn't necessarily mean traversing the internet to access it.

Example:
If you create a private load balancer on AWS, its DNS name is publicly resolvable.

Take Aways

Now, if using an endpoint is not focused on security or performance, which criteria can we rely on?

Let's delve into this topic in the next article of this series.