What's a VPC Endpoint?

A VPC Endpoint is a private connection between services on a VPC (EC2, ECS...) and supported AWS services (S3, DynamoDB, CloudWatch, CodeBuild...). The traffic going through a VPC Endpoint doesn't leave the AWS internal network.

There are two types of VPC Endpoints:

• Interface endpoints: An Elastic Network Interface (ENI) with a private IP that serves as an entrypoint for the AWS service. You use that private IP to connect to the AWS service from EC2/ECS. Interface endpoints cost $0.01/hour and $0.01 per GB for the first 1PB. Detailed pricing: https://aws.amazon.com/privatelink/pricing/

• Gateway endpoints: A target that you specify in your route table. Currently, only S3 and DynamoDB are supported. Gateway Endpoints are free.

The differences between these two types of endpoints can be found here: https://docs.aws.amazon.com/AmazonS3/latest/userguide/privatelink-interface-endpoints.html#types-of-vpc-endpoints-for-s3

In this article, we are going to focus on Gateway endpoints, as they're free and it's (almost, find some limitations below) always a good idea to use them. In some situations, it might be worth it to use Interface endpoints as well, depending on the security concerns and costs (traffic going through an Interface endpoint is cheaper than traffic going through a NAT Gateway).

Gateway VPC Endpoints limitations

The main Gateway VPC Endpoints limitation is that the VPC endpoint and the service must be in the same region. So, if you have your S3 buckets in a different region than your instances, you can't use Gateway VPC Endpoints (you might want to consider using Interface VPC Endpoints, as they don't have this limitation).

There are some other limitations that can be found here: https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html

Why do I need a VPC Endpoint?

If you try accessing to an AWS service, like S3, from an instance in a public subnet, it will work as the subnet has an Internet Gateway attached and the traffic goes through the public Internet.

But what happens if you try this from a private subnet? It won't work, as the instance doesn't have access to the internet (unless you attach a NAT Gateway/NAT instance to the subnet).

Is there a way to have access to AWS services from instances that are on a private subnet without incurring on the data transfer costs of a NAT Gateway? The answer is yes, VPC Endpoints.

When should I use VPC Endpoints?

If you have any instances on a private subnet (a subnet that doesn't have direct access to the Internet) or any requirements to keep your traffic to AWS services internal, you should use VPC endpoints.

On a private subnet, using VPC Endpoints avoids having to pay the data transfer costs associated with a NAT Gateway.

But even on a public subnet, using VPC Endpoints will improve the transfer speed between your instance and S3 and will keep your traffic internal

Adding a VPC endpoint to your private subnet using Terraform

Adding a VPC endpoint using Terraform is pretty straightforward. The code below creates a Gateway VPC Endpoint for S3 and attaches it to the route table of a private subnet.

resource "aws_vpc_endpoint" "s3" {
  vpc_id          = aws_vpc.vpc.id
  service_name    = "com.amazonaws.${var.aws_region}.s3"
  route_table_ids = ["${aws_route_table.private_rt.id}"]

  tags = {
    Name = "my-s3-endpoint"
  }
}

After this resource is created, you should see a new route like this on the route table of your private subnet.

That's all you need to start using Gateway VPC Endpoints. After this route is created, all the traffic going to S3 will use this route, as the most specific route that matches the traffic is used (that's the reason why this new VPC Endpoint is used instead of the NAT Gateway route).

A real use case: Pawp

Pawp, the first-ever online vet clinic for pets, uses ECS Fargate and S3. Pawp's Fargate tasks are hosted on a private subnet, with outbound access to the internet via a NAT Gateway. When these tasks needed to download/upload files to S3, this NAT Gateway was being used. As the files stored on S3 increased, so did the data transfer costs.

By leveraging an S3 Gateway VPC Endpoint, Pawp was able to reduce the amount of traffic processed by the NAT Gateway by ~90%, saving ~22% of their TOTAL AWS costs. Impressive, huh?

Conclusion

VPC endpoints are (almost always) a great option to save some money on AWS and, sometimes, they're not used as architects are not aware of their existence. I hope you found this article useful and you can leverage VPC endpoints to save some money on your AWS bill!