AWS VPN CloudHub is a hub-and-spoke VPN solution to securely connect multiple branch offices together and a VPC on AWS. It leverages the AWS Managed VPN service, but instead of creating CGWs for a single on-premises location, you create as many CGWs as you have remote branches/offices that need a VPN connection and connect all of them to the same VGW on AWS. The result is a simple low-cost hub-and-spoke VPN setup that can be used for communicating securely from one branch/office to another and between your branches/offices and your AWS environment.
The following diagram illustrates this:
Figure 2.4: Hub-and-spoke VPN
Important Note
The remote sites must not have overlapping IP ranges.
Redundancy and failover mechanisms follow the same principle as for AWS Managed VPN. For greater reliability, it is recommended to use multiple CGW devices on your on-premises locations.
It is worth noting that the AWS VPN CloudHub construct is compatible with AWS DX, which will be covered in the next section. For instance, on the hub-and-spoke model represented in the previous diagram, one of your on-premises environments could connect to AWS using an AWS DX connection while the other two on-premises locations use a VPN connection over the internet.
Now that you’ve seen which managed services AWS provides to establish a VPN connection, you can consider cases where an organization may prefer or need to bring its own VPN software solution.
An additional alternative consists of connecting your on-premises network equipment to a software VPN appliance running inside a VPC on AWS. This is the right option if, for some reason, you want or need to manage both ends of the VPN connection. You can select between several partner solutions or open-source solutions that provide VPN software appliances that can run on Amazon Elastic Compute Cloud (EC2) instances.
The major difference between this option and AWS Managed VPN is that in this case, you must manage the software appliances entirely, including updates and patching at operating system (OS) and software levels. Another essential point to note is that a software VPN appliance deployed on an Amazon EC2 instance is, per se, a single point of failure (SPOF). Thus, reliability is an extra complexity that you must deal with, whereas it is handled for you by AWS, on the AWS end of the connection, when using the Managed VPN solution.
This concludes the section on VPN connections, but as you will see now, a VPN is not the only way to establish a private connection between your on-premises infrastructure and your AWS environment.
Using a VPN connection when you get started makes a lot of sense. It can be up and running in no time and will likely cause no big change in your network topology.
However, it is not always the best option. For cases where internet connectivity unreliability becomes a business risk, AWS DX offers the right alternative by offering low latency and consistent bandwidth connectivity between your on-premises infrastructure and AWS.
In a nutshell, a DX connection ties one end of the connection to your on-premises router and the other end to a virtual interface (VIF) on AWS. There are three different types of VIFs: public VIFs, private VIFs, and transit VIFs. Public VIFs are used to connect to AWS services’ public endpoints. Private VIFs are used to connect to your own AWS environments within a VPC. Transit VIFs allow you to end the connection on a TGW.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
