Your Resource for All Things Apps, Ops, and Infrastructure

What I Learned at AWS re:Invent 2016: Hybrid Cloud Connectivity

This year at AWS re:Invent, one area of focus for me was network connectivity, especially between client data centers and AWS. Many organizations are seeing AWS as an extension of their data centers, and how they connect is a common discussion topic. To hinge on this topic, in this post, I will compare and contrast the different options for connecting your data center to AWS.

For more information, you can watch sessions from re:invent 2016. I suggest the following:  

Use Cases

There are a number of common use cases that necessitate the need for extending network connectivity to AWS from your on-premises data center.  These include:

  • Stretch application components across both on-prem and AWS
  • Front-end services in AWS connecting to a back-end database
  • Data archival and tiering to S3 and/or Glacier
  • WorkSpaces desktops but applications and data on-prem
  • Disaster recovery to AWS
  • Or, any combination of these use cases. 

Often organizations start with one use case and then it expands out to include several others.  This may lead them down a path where they start with simple connectivity via VPN but then their requirements dictate that they move to Direct Connect. There are many things to consider when deciding which connection option to use and how to implement it.

Entry Point – VPN

The first type of connection that most organizations stand up is VPN (Virtual Private Network).  This allows you to get connected with AWS quickly and easily, without the commitment needed for Direct Connect. One important caveat when talking about VPN connections is that you only have access to private resources with this type of connection. You do not have access to public endpoints, such as DynamoDB.

AWS offers two VPN options:

  • Software VPN – EC2 instance running the VPN software system of your choice
  • Hardware/Managed VPN – Service provided by AWS where they manage a VPN endpoint in AWS for you

Software VPN

Software VPN is simply using your own chosen VPN solution, such as Openswan or Cisco CSR, in an EC2 instance. It is not managed or supported by Amazon in any way. There are many prebuilt options in the AWS Marketplace that can save you time and simplify the deployment of the VPN solution. The benefit of this is that you can easily spin these up for test purposes and use any software VPN package that you’re already comfortable using. It’s also a good way to use whatever corporate standard you already have for VPN connectivity.

The downside of Software VPN is that configuring routing within your VPC, as well as HA (High Availability), is left to you. If you want redundant VPN connections, you’ll need to script the failover and handle all of the routing yourself. Some software packages have these capabilities built in, but those obviously vary depending on what you use.

Pricing for Software VPN is strictly based on the normal EC2 charges for the type of instance you run along with the standard network traffic charges. Therefore, if your throughput needs are small, you can run an instance that costs less than one that gives you higher throughput. It is key to size these instances correctly and balance cost with throughput. If you underestimate or overestimate, you can redeploy, but it may not be a simple process depending on your software selection. Of course, if you use a commercial VPN solution, there may be extra licensing costs to consider.

A good use case for Software VPN is the ability to create a mesh between regions over the VPN. This allows for communication between regions as well as office connectivity to a local region over the software VPN. For more information on this type of architecture using Transit VPCs look here.

Managed VPN (Hardware)

Managed VPN, also known as Hardware VPN in some AWS documentation, is an AWS managed service providing IPsec VPN connectivity to a VPC. A key thing to remember is that as you scale and have multiple VPCs, you will have multiple managed VPNs. Each of these VPN endpoints is referred to as a Virtual Private Gateway (VGW). You will need your own Customer Gateway (CGW) at your data center(s). These are not provided by Amazon but can be physical or virtual systems that connect to the VGW via IPsec. An interesting feature with the managed service is that when you configure it, the AWS console will give you suggested configurations for many VPN systems such as Juniper, Cisco, Palo Alto, and more. Even if your chosen VPN device or software isn’t available, these configurations will give you a good starting point.

The managed service has the following features:

  • AES256
  • SHA-2
  • NAT-T (NAT Transversal)
  • Phase 1 DH Groups – 2, 14-18, 22, 23, and 24
  • Phase 2 DH Groups – 1, 2, 5, 14-18, 22, 23, and 24

The benefit of the managed service is that it is completely handled by Amazon with no configuration, monitoring, or management required by you. It is also natively resilient so there is no scripting or manual failover required. You simply create two tunnels to two different IP addresses. Of course, this assumes that you are redundant on the data center side as well.  Normally, you would have two devices on your end connecting to each VGW in each VPC.

There is very little downside to using the managed VPN option. It does cost more than most EC2 instances, though not as much as you would think when you factor in two EC2 instances for HA. The cost of the managed service is $0.05/hr that it is connected plus the usual data transfer fees. But again, it’s per connected hour so if you do not need it up all of the time, you could create some easy automation to tear down and build up the VPN during certain parts of the day.

Direct Connect (DX)

VPN technologies are mature and well tested, but there are times where you want, or require, a private connection that is more consistent than having your data go across the Internet. That is the purpose of Direct Connect (DX). There are several different ways to take advantage of DX and they can be a bit confusing at times.  

There are three main deployment models for DX:

  • Scenario 1 – You already have equipment in a DX location
  • Scenario 2 – Order a circuit from your data center to a DX location
  • Scenario 3 – Extend existing service provider network to a DX location

As of now, Amazon has 42 locations around the world that provide access to DX. Each region has at least two DX locations. These are not the AWS data centers, as the location of those is not known. These 42 DX locations are housed within data centers that many people use for colocation services, such as Equinix. A DX connects you to a single region. But note that DX connections to regions in the US do allow you to access public endpoints of other regions.

Scenario 1

This is the simplest way to take advantage of DX. If you have equipment in one of the DX location data centers, you can order a simple cross-connect from your router to a 1Gb or 10Gb port on the DX equipment.  That will provide physical connectivity and from there you can start building the needed routing and IP connectivity needed. The ordering process is done through your AWS console.

Pricing for the DX port is based on the location by hour. You also pay for data transferred out of AWS and that cost can vary by location. DX ports are available in 1Gb and 10Gb. Some partners provide sub-Gb speeds, but you must go through them. Current DX pricing information is available here.

Scenario 2

This scenario is similar to the first, but instead of extending connectivity from equipment already in the DX location data center, you would order a circuit from your data center to the DX location. The provider of that circuit would then cross-connect you to the AWS DX port. This is often what people think of when they hear Direct Connect, but it’s simply one of several options.  Pricing for this would include the standard DX port and transfer charges plus the cost of the circuit.

Scenario 3

If you already use a service provider for network services, such as MPLS, they can often add DX as another access point on the network. This also works for some managed networks with colocation providers. One example we are working with is Equinix and its Cloud Exchange service, which lets you easily access AWS, Azure, SoftLayer, and others. AT&T and Verizon both offer services to extend existing MPLS networks to AWS. These are their NetBond and Secure Cloud, respectively. Pricing for this varies greatly by provider and offering.

One benefit of using service providers for your DX connection is that you can get sub-Gb connections. Many offer the ability to get incremental 50Mb to 500Mb connections, if you do not need a full 1Gb link.

Comparing DX Pricing to VPN

Pricing for DX can be simple, but varies greatly by location and scenario since often they involve colocation centers and/or telco carriers. Therefore, it is harder to do a straight comparison to VPN. But there are some things to keep in mind. With VPN, you pay for Internet transfer out of AWS plus if you are in a colocation center, you often pay for traffic egressing there as well. The price for data transfer via DX is less than the price for Internet traffic, which does help to offset circuit costs. DX transfer pricing depends on the location, but can be a fraction of what Internet transfers costs are.

Resiliency Considerations

There is no inherent resiliency with a DX connection. The circuits and ports are singular, therefore you must build out some high availability yourself. The recommended build out options are:

  • DX + VPN – Create a VPN as a backup connection. Performance will be impacted during failover.
  • 2 x DX in 1 Location – If you order two DX connections to the same location you will automatically have the ports put on different equipment.
  • 2 x DX in 2 Locations – Have the second DX go to a second data center providing site resiliency.
  • 2 x DX in 2 Locations + VPN – Go all in!  

Obviously the recurring pricing will vary depending on which of these you choose. You also need to really look at your availability and performance requirements as you decide which option to build out.

DX Security

One thing to note is that traffic over a Direct Connect link is not encrypted. It works like any other WAN or network connection. If you have the need to encrypt traffic between your data center and AWS a common solution is to create a VPN between the sites over the DX link.  This gives you predictable performance along with data security.

Final Thoughts

As you can see, there are several good options for extending on-premises data centers to AWS.  What you choose will depend on your connectivity and performance requirements, as well as location and cost considerations. Many organizations start with a simple VPN deployment and move up to DX as their needs grow. Often we see VPNs being used while circuits are being built out for DX connectivity. Once you decide on the physical connectivity, you then have to architect the network and routing. That is where the complexity really occurs when working out your hybrid cloud connectivity strategy.  

AHEAD is very excited to continue to help our customers with holistic cloud adoption and acceleration strategies, and to incorporate these technologies into their environments as it makes sense. As an organization that deeply understands these technologies and the details behind using them, we expect to spend a significant amount of time in 2017 working on projects in this arena. To learn more about AHEAD’s capabilities or offerings with AWS, contact us today to meet with our experts.

You can experience (or relive!) the excitement of AHEAD’s re:Invent sponsorship when you check out our demos from the event of ServiceNow, DevOps, or Amazon WorkSpaces, or sign up for a personalized demonstration of your own! 

Subscribe to the AHEAD i/o Newsletter