Hi, folks! The leaves are starting to change color and Halloween is almost here!  This installment of our AWS Blog series can help you avoid an AWS architecture pieced together a lot like Frankenstein’s monster!  Today we will take a quick look at how you can keep traffic to and from your AWS storage private. 

How to keep AWS S3 Traffic Private

Amazon’s Simple Storage Service (AKA – AWS S3) is a highly scalable and resilient object storage platform in the cloud.  It is a central component of any AWS deployment, and is therefore ubiquitous.  S3 storage is built for the Internet and accessed using web-based protocols such as HTTP(S) or the RESTful S3 API.  Put another way, S3 is accessed by default over the public Internet, even if you configure your Bucket to block public access. 

This isn’t desirable or even permissible for many people, even though S3 traffic is encrypted.  You may have sensitive data that cannot be allowed to travel over the public Internet, for internal or even regulatory compliance reasons.  So the quick answer is usually “Well, I’ll just put in an AWS Direct Connect to keep my S3 traffic on a private connection.”  Not so fast!  That can definitely work, but the full answer is more involved.   

This blog post will go over the two types of Direct Connects available and the different virtual interfaces you can attach to them.  You need to understand these options before you settle on your final architecture for access to S3 and your other AWS resources. 

DIRECT CONNECT COMES IN TWO BASIC FLAVORS 

AWS’s Direct Connect cloud service enables you to create a dedicated connection from your data centers into your AWS environment.  That means that you can create a “private” network path for your AWS traffic.  This creates a secure, low-latency connection to your private IaaS resources such as VPCs and their EC2 instances and workloads, or to public AWS resources such as S3 Buckets or Glacier archives.  The classes of resources you can connect to over the Direct Connect depends on the type of virtual interface (VIF) you attach to it. 

You’re probably thinking “I already knew that!”  Yes, but here’s the rub. There are two basic types of Direct Connect available – Dedicated and Hosted – and they provide different support for attachment of VIFs.  Since this blog post is not meant to be a deep-dive into all of the differences between Dedicated and Hosted Direct Connects, let me sum up my point this way: 

• A Dedicated Direct Connect supports up to 50 VIF attachments, in any combination of public or private (but only one transit).  But a Hosted Direct Connect only supports attachment of a SINGLE VIF. 

Refer to this link for more details about Direct Connect quotas. 

THE THREE TYPES OF VIRTUAL INTERFACES 

Put simply, virtual interfaces enable access to AWS services from your Direct Connect.  There are three types of VIFs that you can attach to your Direct Connect: public, private and transit.  This is laid out nicely in the AWS console when you go to create a VIF, but it can still be confusing. 

A public VIF enables access to public AWS services (such as S3); a private VIF enables access to private AWS services (IaaS components like your VPC or EC2 instances); and, a transit VIF attaches to an AWS Transit Gateway.  We’ll only deal with the first two here to understand how to access S3 over your Direct Connect.  Just note that a Transit Gateway is a type of network hub in AWS that interconnects and routes traffic between VPCs and on-premises networks.   

You with me so far?  Okay, let’s pull it all together. 

If you want to access S3 over a Direct Connect to keep that traffic off of public Internet, you have to attach a public VIF to it.  For traffic to and from a VPC and its EC2 instances and workloads, you have to attach a private VIF (one per VPC).  This diagram shows that clearly: 

Source: https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html 

Now, here is the most important part!  If you need both a public and private VIF (or multiple public and private VIFs), you must have either a single Dedicated Direct Connect, or multiple Hosted Direct Connects. If you put in just a single Hosted Direct Connect, you will be limited to just one VIF (and note that you cannot pass S3 traffic over a transit VIF, but nice try!).  If you provision your Hosted Direct Connect with a private VIF but later want to change it to a public one, you can but you’ll have to rebuild it.  That can be a hassle and cause down-time and service interruptions. 

THE LONG AND THE SHORT OF IT (PROBABLY COST) 

You’ll need to plan ahead for how you intend to use Direct Connect in your AWS deployment.  If you have a requirement to keep S3 traffic private, be careful to consider the limitations I’ve discussed here.  Since other aspects of this type of hybrid connection come into play, such as bandwidth requirements, you may have to pull a few quotes from a Direct Connect provider to see what is the most economical yet efficient option for you.  Keep in mind that there are other functions and benefits of deploying a Direct Connect, such as reducing latency and AWS data transfer costs.   

Freeit Data Solutions cloud architects are experienced with these deployments and can help you navigate the not-so-scary world of AWS S3 and Direct Connect tricks and treats! Email our team today for expert help with AWS S3 and Direct Connect. 

Happy Halloween!