The decision has been made. You’re moving to the cloud. Now, you need to decide how to do it. You’ve got two options.
In the first scenario, you lift and shift virtual machines, send all the data to the cloud storage, adapt or rewrite applications to be serverless, leverage PaaS services and so on. This is the optimal solution, but unfortunately, in many cases impossible to realize. And that’s due to a number of reasons.
First of all, it’s not feasible to move all systems at once. You often need to migrate them one at a time. Another issue may be your corporate applications – some of them may be not ready for the cloud. There may also exist certain legal regulations that won’t allow you to keep your data outside of the data center.
Whatever the reason, in some cases you may not be able to perform a complete migration. This means that the only remaining option will be to implement scenario number two – a hybrid cloud environment.
Why go hybrid?
In a hybrid solution, your on-premises data center is connected to the cloud environment, and while some systems work in the cloud, others remain in your data center.
Companies use hybrid connectivity for many reasons apart from the situations as mentioned earlier.
Here are some more examples of hybrid cloud strategies:
- Running some parts of your application, like front-end and application core, in the cloud, and keeping the database in your DC.
- Feeding your cloud application with data from your on-premises database.
- Leveraging a cloud storage for backup or archive.
- Running workspaces as VDIs using your back-office applications.
- Using a cloud disaster recovery solution.
- Leveraging the cloud for all of the above cases, and much more.
Regardless of the motivation behind the hybrid cloud strategy, the final result is that you store data or run compute workloads in the cloud and connect them with resources or services hosted elsewhere, which is usually your data center.
What options are there to connect?
There are two main options you can leverage to connect your data center with the AWS cloud, or being more precise, with the VPC in the AWS. These are VPN and Direct Connect.
Generally speaking, VPN uses the Internet for connectivity, while Direct Connect uses a dedicated, private connection leading straight to the AWS region.
Option 1: VPN
In VPN, you can choose between two solutions. You can use the VPN gateway managed by AWS (on AWS’s end), or software VPN running on an EC2 instance.
AWS managed VPN
In this case, AWS manages the Virtual Private Gateway and takes care of the underlying VPN architecture and high-availability. The Virtual Private Gateway can sustain a single Availability Zone failure.
Connecting the Virtual Gateway (VGW) to your on-premises VPN gateway is pretty straightforward. First, you need to create a Customer Gateway, which is your local gateway, then create the Virtual Private Gateway (on Amazon’s end), and finally set up a VPN connection.
To facilitate the process, the management console can generate configurations for different devices from various vendors. If your vendor is not on the list, you can choose the generic settings.
Every VPC requires its gateway. To achieve high-availability, each VGW is represented by two public IP addresses. It is recommended (however not required) that you use both, and connect a single physical device on your end to both public IPs of VGW. If you have a primary and a secondary data center, you should establish two VPN tunnels per each of them, which amounts to four VPN tunnels in total.
If you want to connect to more than one VPC, you’ll need to design each instance separately.
Once you set up the VPNs, traffic per given network will be flowing through one tunnel only in both directions in the active/standby mode. You can use BGP to determine the tunnel for the traffic flow.
Virtual Gateway Requirements
The customer gateway that you want to connect to the VGW has to support:
- IKE SA using pre-shared keys
- IPsec SA in Tunnel mode
- AES-128 or AES-256 encryption
- SHA-1 or SHA-2 hashing
- Phase 1 DH groups 2, 14-18, 22, 23 and 24
- Phase 2 DH groups 1, 2, 5, 14-18, 22, 23 and 24
- DH Perfect Forward Secrecy
For dynamic routing it also has to be able to:
- Establish BGP peering
- Utilize IPsec Dead Peer Detection
- Create route-based VPNs
When using AWS managed VPNs, you pay per VPN connection-hour (even if there’s no traffic flow) and data transfer.
Software VPN (EC2)
Another option to connect to the cloud with VPN is to use a software VPN gateway. Such gateway leverages virtual appliances running on EC2, and you’re free to use your own software or a marketplace solution. You may want to use software VPN gateway to remain consistent with your other locations or to leverage some proprietary features like Cisco DMVPN.
Software gateways are regular EC2 instances, so you’ll also pay as for such. Needless to say, this may be expensive. You’ll also have to assign an Elastic IP for every software gateway, and the gateway has to be installed in a subnet with Internet Gateway access.
When using software VPN gateway, you have the full responsibility for scaling and for the high-availability, so it’s a good idea to create at least two gateway instances per VPC. The advantage of such approach is that with software gateway you can create a global backbone and connect VPCs in different regions and your data center. You can also use multiple instances for the same VPC.
The cost of Software VPN includes the cost of instances and data transfer and vendor licensing in most of the cases.
Hub-and-spoke communication with VPN CloudHub
If you have multiple VPN connections, they can provide secure communication between sites via VPN CloudHub. This architecture enables your remote sites to communicate with one another, as it acts as a hub operating in the hub-and-spoke model. You can use VPN CloudHub with or without a VPC.
Option 2: Direct Connect
AWS Direct Connect service enables you to establish a dedicated network connection to AWS. This option offers privacy and usually higher bandwidth than VPN connections. It works with all AWS services, including S3, EC2, and VPC.
AWS Direct Connect routers are AWS-owned routers installed in a colocation, outside of regions or Availability Zones, from where you can peer with AWS.
There are more than 40 locations around the world to where you can connect. In each of them, you can use 1 Gbps or 10 Gbps connectivity. Smaller capacities of 100, 200, 300, 400 and 500 Mbps are available through AWS partners.
You will be able to use Direct Connect if:
- Your equipment is in the same location as Direct Connect.
- You have a circuit from your data center to the Direct Connect location.
- Your service provider network (i.e., MPLS cloud) extends to the Direct Connect location.
When requesting a Direct Connect, you need to choose which colocation you belong to and request a 1 Gbps or 10 Gbps port. That triggers a process (which may take up to 72 hours), at the end of which you’ll receive a Letter of Authorization (LoA). Once you get the LoA, it means that a port on AWS routers has been allocated for you. Now you can connect to the port whenever you’re ready.
The next step is to deliver the LoA to the colocation provider and request a cross connect between your router and the AWS port. When the provider completes that task, you’re all set! You can now create virtual interfaces on your connection.
When you have no presence in the Direct Connect location, the procedure is still similar. You will receive the same LoA, but now you need to involve your service provider to provide a circuit from your data center to the colocation with the Direct Connect.
When connecting with Direct Connect, high-availability is your responsibility. It’s worth considering setting up an additional VPN connection as a backup for the Direct Connect one.
Another option would be to order an extra Direct Connect connection for the same VPC. In such a case, when you order a second port in the same colocation through the same AWS account, you will be automatically placed on two different pieces of hardware to provide device redundancy. Of course, to achieve full redundancy, you need to ensure device redundancy on your end as well.
Colocation – checked, what’s next?
Once the connection is up and running, you need to create a Virtual Private Interface and connect it to the Virtual Private Gateway, same as for the VPN connection. All the traffic flowing between that particular VPC and your router is tagged with 802.1q VLAN tag. Within the VLAN, a BGP session is set up between your router and the VGW, and the entire VPC subnet range is advertised to you. For prefixes advertised from your router to VGW, there is a limit of 100 entries.
You need to repeat the same steps for every VPC to which you want to connect. Connecting through a VPC to another VPC is impossible.
Public Virtual Interface
You can use Direct Connect to reach AWS services directly from your data center, without using public IPs. To do so, create a Public Virtual Interface.
The process is similar to the one above. You map the VLAN and establish BGP. The only difference is that you require a pair of publicly routable IP addresses on your router. After that, AWS will advertise the entire region IP space towards you so you will be able to reach those IPs through the Direct Connect.
Not bad, right? And what about the costs? Well, except service provider circuit, MPLS or colocation cage costs, you’re paying for the port hours and the data transfer out. And that’s about it.
Ready to move to hybrid?
Of course, there are some more ways to connect your data center to the cloud. Many architectures you can use, leveraging multiple VPNs, multiple Direct Connect links, or a mixture of both.
The above guidelines should help you sail through this process. In the end, it’s about choosing the approach that will work best for you.
If you need more information about connecting your data center to the AWS cloud, check out the official AWS documentation.