Improve security and save money with s3 VPC endpoints

Well what is a s3 VPC endpoint?

Let’s look at what problem s3 VPC endpoints solve and how they can enhance our architectures. A typical real-world use case is accessing objects and putting objects in an s3 bucket from an EC2 instance or a container running in ECS.

This example works efficiently because the instance is in a public subnet and has direct egress to the internet. In most production architectures, we would avoid this. It’s more likely that most of your instances will be in private subnets, and you either will not have a route to the internet and the S3 API’s or will need to route through a NAT gateway.

Any call to the s3 API’s will timeout from a private subnet as there is no route to the internet.

S3 VPC endpoint to the rescue

S3 VPC endpoints are an aspect of VPC networking called gateway endpoints. AWS gateway endpoints add entries to your route tables, directing traffic to S3 through the VPC Endpoint. AWS has gateway endpoints for both s3 and DynamoDB.

For other AWS services, you would use an interface endpoint that works over AWS Private Link.

With this setup, you can keep your instances in private subnets and still communicate to the s3 API.

VPC Endpoint Setup

Looking at the route table created, we can see that traffic specified for s3 routes to the s3 API’s and everything else is local.

Why not just use NAT Gateway or NAT Instances?

It’s common in a three-tier architecture to have a NAT Gateway in your public subnets, and then all traffic in your route tables to 0.0.0.0/0 is routed to the NAT GW as opposed to your internet gateway. You can do this for s3 as well, but it is less efficient. When routing to s3 via NAT, you have to pay for all the bytes that transfer through the NAT GW. You are also leaving Amazon’s network and re-entering, which adds latency.