Extend your AWS Network with VPC Endpoints

More security and More Privacy

A central concern about cloud computing has always been security. AWS has always tightly addressed this with some of it's core services like VPC, KMS and CloudHsm. VPCs specifically, are extra amazing because it's gives a level of security by provisioning it's own network. We have seen this type of architecture before in this post. AWS is always growing and it can be difficult to keep your finger on the pulse of their priorities. It does seem clear though that security is one of their biggest concerns. In this post I'll show you one of their newest features in the VPC called an endpoint. It provides security by allowing access to AWS services without having to traverse the open internet.

Endpoint Architecture

To wrap around your mind around what endpoints do we can start with a typical architecture of a bastion host in a public subnet. That is to say that it's route table has a route to the internet gateway attached to the VPC. For security purposes, we can then launch and instances into a private subnet in the same VPC. Previously, I've shown you how you can get inbound traffic to that private instance via a NAT gateway. The only catch to that is traffic will go over the open internet. The endpoint feature of the VPC closes this security gap by allowing you to add entries into your route table that go directly to an AWS services.

A Use Case for Endpoints

In this screen shot

the supposition is that I'm on an instance in a private subnet and trying to list my buckets in S3. You can see that it is failing. It's specifically failing because I don't have a NAT gateway in the route table for the subnet that this instance is in. What I can do though is use a VPC endpoint endpoint feature and make a route directly to the S3 service so that I can call it from on an instance in a private subnet.

Making an Endpoint

In this screen shot

you can see the endpoint feature from the standard VPC menu. We can now create an endpoint directly to S3. This is pretty easy to do because the only details we need are the VPC and the affected route table. Here is a screen shot of how I set this up in my own account.

If you look at that picture carefully you can see that endpoints come in two flavors. There are gateways and instances. You can see that we are using a gateway directly to S3. This will give my instance in a private subnet access to S3. You can see here

that when I again list my buckets the api call is successful because the affected route table now has a route to S3. The important detail to not miss though is that this traffic didn't come over the internet. It was facilitated by the endpoint feature.

AWS Evolution

Time has shown that AWS changes quickly. Even if you were well versed on VPC's two years ago, many things have changed. At the time of writing this, the endpoint feature is relatively new. They have also released an egress-only internet gateway for IPv6 traffic. VPC peering can now span regions. Even S3 itself has many new storage classes. The new services released by AWS always get attention but the people forget the fact that established services also change. Changes that impact security are particularly relevant because it's a central concern of AWS customers. To alleviate some security concerns customers might think about AWS Config to check that configuration rules are followed. Other relevant services like Inspector and Trusted Advisor can lock down security and keep an eye on cost optimization.