Unpacking Data Transfer Cost in AWS — Part 2

n this blog post, we explore how to minimize AWS data transfer costs when your VPC workload communicates with public AWS services like S3 and DynamoDB. Discover how using VPC Gateway endpoints can eliminate data transfer fees and potentially improve latency.

September 17, 2024
Share on Linkedin
n this blog post, we explore how to minimize AWS data transfer costs when your VPC workload communicates with public AWS services like S3 and DynamoDB. Discover how using VPC Gateway endpoints can eliminate data transfer fees and potentially improve latency.

Key Takeaways:

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.

In part 1 of this blog post series I focused on breaking down the Data transfer cost across from three most common outbound channels which are:

  • Directly from Internet Gateway (IGW)
  • from private subnet to NATA gateway, same Availability Zone.
  • and private subnet to NAT gateway where they subnets are in two different AZs.

In this post I would like to talk about another common Data transfer cost which is between the workload that you deployed in your VPC and public aws services such as S3, Dynamo, Kinesis, and etc.. and provide you with some tips on how we can optimize for cost efficiency in this use-case.

The two primarily most common scenario in this use-case are:

  1. workload is running on a public subnet communicating with AWS public endpoint of aws services. (example: S3)

2. workload is running on a private subnet communicating with AWS services. (example: S3)

For use-case 1 there is no additional data transfer cost, but for 2nd use-case customer has to pay for each GB of data that processes over NAT Gateway.

comparison between workload running in public subnet(1) vs private(2)
comparison between workload running in public subnet(1) vs private(2)

Tips for lower cost, and potentially improving latency

S3 and Dynamo DB supports VPC Gateway endpoint that uses AWS Backbone networking infrastructure to connect your VPC workload (no matter its on public or private subnet) to the private endpoint of these two services thus your request no longer requires to be processes using NAT gateway and travel to internet before it arrives at S3 or Dynamo endpoint. This results in reducing the data transfer cost by 100% while it can enhance the latency since it no longer go via internet, although I have never measure how much of latency difference it makes, if any.

I am not sure why AWS doesn’t want to enable VPC Gateway endpoint as the default way of connecting to S3 and Dynamo but its surprising how many teams aren’t leveraging this simple yet useful feature.

For services other than S3 and Dynamo that run outside of customer networking perimeter, such as SNS, SQS, and Kinesis, you would have to use something else called interface endpoint that is a bit more work to set and is not free of charge and I don’t intend to discuss it in this blog post. (I have actually never used it 🙂 )

For more information

We’re ready when you are. Get in touch and a friendly, Costwise knowledgeable cloud expert is prepared to discuss your cost optimization needs, ask a few questions to get the full picture, and make a plan to follow up.

THE COSTWISE.CLOUD BLOG

Stay in the know

Our experts continuously share their insights to provide meaningful perspective on the best practices in the industry -- breaking down what you need to know, opportunities, and how you should approach your cloud infrastructure settings.

Redefining the way you look at AWS Costs

CostWise is dedicated to helping businesses reduce their cloud spend without sacrificing performance. By leveraging advanced analytics, tailored recommendations, and continuous monitoring, we empower you to achieve sustainable cost efficiency.