Establishing VPN Connections

The first option when it comes to protecting connectivity between an enterprise’s on-premises infrastructure and its AWS environment is to establish a VPN connection. AWS offers several alternatives to achieve that. The following section details each of them.

AWS Managed VPN

The first one is AWS Managed VPN, or Site-to-Site VPN. This is a fully managed service that provides an Internet Protocol Security (IPsec) VPN connection over the internet from your on-premises network equipment to AWS-managed network equipment attached to your AWS VPC.

The VPN concentrator end on the AWS side can be either a virtual private gateway (VGW) attached to a single VPC, as illustrated in the following diagram, or a transit gateway (TGW) attached to multiple VPCs (see Figure 2.2). The other end connecting to your on-premises equipment is called a customer gateway (CGW):

Figure 2.1: VPN connection between single VPC and on-premises equipment

The architecture you choose depends on your AWS environment network topology. Figure 2.2 shows the TGW option:

Figure 2.2: VPN connection between TGW and on-premises equipment

Complex organizations usually end up managing multiple VPCs that require inter-VPC communication, connectivity to the internet, and/or connectivity to your on-premises infrastructure. They then often leverage the TGW service to have a clean hub-and-spoke network model (more on this in the section dedicated to TGWs at the end of this chapter).

It is worth noting that AWS Managed VPN also provides redundancy and automatic failover, therefore it is highly recommended to connect your VGW or TGW to two separate CGWs on your end. By doing so, you establish two separate VPN connections, and if one of your on-premises devices fails, all traffic will be automatically redirected to the second VPN connection (see Figure 2.3). It allows you to nicely handle failover, as follows:

• In case of an unexpected failure of your on-premises router sitting behind your CGW
• When you need to perform maintenance on your network equipment and must take one of two VPN connections offline for the duration of the maintenance operation

This is illustrated in the following diagram:

Figure 2.3: VPN connection redundancy for failover

AWS Managed VPN offers both dynamic and static routing options. Dynamic routing leverages Border Gateway Protocol (BGP) to pass routing information between the VGW on AWS and your on-premises CGW. It allows you to specify routing priorities, policies, and weights in your BGP advertisements and to influence the network path between your networks and AWS. It is worth noting that when using BGP, both the

IPsec and BGP connections must be terminated on the same CGW device(s). Both the BGP-advertised and static route information tell gateways on each side which tunnels are available to re-route traffic in case of failure. That said, the BGP protocol brings more robustness to the table thanks to the live detection checks it performs, so using BGOP-capable devices will make your life easier when dealing with failover from the primary to the secondary VPN connection upon failure.

AWS Managed VPN is a great approach when you need to connect one on-premises location with your AWS environment, but what about situations where you need to interconnect several remote offices together and with your AWS environment?

AWS VPN CloudHub

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.

Software VPN

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.