One of the foundational pillars of any cloud strategy is connectivity. How are you going to securely access services running in your cloud, and how are they going to connect back to you and to other networks?
AWS facilitate a number of options, ranging from simple encrypted internet connections to enterprise grade BGP routing hubs running over dedicated private links. In this post, we will explore a number of these solutions and hopefully provide some insight no matter what stage of the cloud journey you are on.
The Bastion Host
If you’re just setting up a test network, or have very simple requirements with no externally hosted interfaces, a simple bastion host may be an acceptable solution.
Often referred to as a “jump server”, a bastion host simply provides an intermediate access point between your network and your AWS estate. The connection is performed over the internet and ideally uses an encrypted protocol such as SSH or HTTPS. It’s also essential that you restrict access to your bastion host to only allow those internet addresses that are trusted (eg. the external IP address of your office network or client). This would typically be done with a dedicated AWS security group.
As security groups can have trust associations (i.e one security group can allow access from another security group) we can then designate which AWS resources can be administered from the bastion host.
In the example diagram below, we can see a bastion host with a security group attached. This security group will have a list of rules allowing only trusted IP addresses or ranges to access the remote administration port. In turn, the instances running in the “private” subnet are associated with a different security group. This second group will have a rule which explicitly allows the first security group to access it on the administration port.
Figure 1. The Bastion Host.
Linux environments will generally use SSH as the bastion service. For Windows environments, it’s a good idea to use something like a Remote Desktop Gateway that tunnels RDP over an encrypted HTTPS session.
The (Third Party) VPN
A VPN creates a private encrypted tunnel over an untrusted network (eg. The Internet)
There are a number of different types of VPNs but at a high level, they fall into two basic categories:
- Site-to-Site :- Securely connects two remote networks such that they can route privately between each other.
- Client-to-Site :- Securely connects a single client to a remote network.
For the purposes of this post, we will only talk about Site-to-Site VPNs. These have been around for decades and have traditionally been associated with firewall appliances (eg. Sophos, Fortinet, Cisco, PaloAlto etc) or software solutions (eg. OpenVPN, Windows RRAS etc).
These options continue to exist in the cloud with a host of vendors offering the virtualized equivalents of their products in the AWS Marketplace. These typically have on-demand and/or BYOL (Bring Your Own License) pricing plans.
In the example diagram below, we show a corporate network securely connected to an AWS VPC utilizing a third party virtual appliance. This link is established over the open internet and all traffic traverses the AWS IGW (Internet Gateway) to access resources in the AWS VPC. It is important to note that in the scenario depicted below, traffic from the corporate DC on the left will only have direct access to resources in the Internet. Due to transitive peering restrictions, AWS prevents direct routing between the corporate DC and the Protected VPC. In order to access resources in this VPC, clients on the corporate network would have to use the bastion service in the Internet VPC.
Figure 2. Third Party VPN connecting corporate DC and AWS
The AWS Managed VPN
A slight, but very significant, variation on the third party VPN is the AWS VPN. This is an on-demand managed service that allows you to connect a VPC to a number of common VPN endpoints. Whilst it is not always possible to use it, it does have a number of advantages for certain use cases:
- No need to manage your own VPN
- It’s already redundant as multiple AWS endpoints are configured
- It doesn’t require an IGW (Internet Gateway) to be attached to the VPC.
It’s this last point that I’d like to spend a bit more time on. The obvious benefit to not needing an internet gateway is security. If the workloads you are running in AWS don’t need any access to or from the internet, then removing the IGW altogether is a valid option. There is no chance of accidentally opening up security rules, public IP addresses can’t be attached to instances etc. If outbound internet access is an absolute requirement, then this can be done via a proxy server and a dedicated peered VPC, thus preserving the isolation of your protected resources in the main VPC.
In contrast, third party VPN solutions will always require an internet gateway unless there is a dedicated private link between the two networks (see next section on Direct Connect).
The AWS VPN attaches directly to a VPG (Virtual Private Gateway) instead of an IGW. We’ll further explore the significance of this in the Cloud Hub section of this post.
Figure 3. Corporate network connected to AWS via a VPG (also called VGW) and AWS Managed VPN.
For customers with high bandwidth connectivity requirements, AWS provide their Direct Connect (DX) service. Direct Connect establishes a dedicated private (non-internet) link between a designated hosted network facility and an AWS VPC. In the, very likely, scenario that a customer does not already have a presence in the designated facilities then the “last mile” connection needs to be established by an AWS network partner.
There are arguably two types of DX connections:
- The “pure” connection supplied by AWS that has bandwidth options of 1GBps and 10GBps
- Partner connections which are available with lower bandwidth options ranging from 50-500 MBps. These are typically subdivided “pure” connections.
Aside from the obvious speed benefits, one of the biggest advantages of the pure connections is that a single Direct Connect link can create multiple Virtual Interfaces (VIFs). It is the Virtual Interface that is used to ultimately connect the two endpoint networks. Therefore, one Direct Connect link can be associated with multiple AWS VPCs across a number of different AWS accounts (in the same region).
The Direct Connect interface attaches to the VPG inside a designated AWS VPC. On the client side of the VPG, routing is normally performed dynamically over BGP (Border Gateway Protocol). This is also true of the AWS Managed VPN we discussed in the previous section.
In the diagram below we show a Direct Connect linking a corporate datacenter with an AWS VPC.
Figure 4. Direct Connect
The Cloud Hub
We finally reach the pointy end of the post where we tie it all together. The topics covered in the previous sections show individual methods for connecting remote networks in AWS. Now we will attempt to combine a number of these methods into a more complicated real world use case.
In large complex environments there will be a myriad of connectivity requirements that may benefit greatly from what AWS refers to as the Cloud Hub. To better demonstrate how a Cloud Hub works let’s use the following fictitious scenario for a company called Cloudzen:
- Cloudzen has a core AWS VPC with a defined CIDR range of 10.200.0.0/16
- Their main corporate datacenter has an internal CIDR range of 172.16.0.0/16. It is connected to the AWS VPC via a Direct Connect virtual interface and the VPG (VGW)
- Their office locations consist of four geographically separate sites connected over an MPLS network that shares the CIDR range 192.168.0.0/16. A separate Direct Connect link joins the MPLS network to the same AWS VGW.
- Cloudzen has partnered with another organization that requires access to services running in both the Cloudzen datacenter and the AWS core network. They have also provisioned a Direct Connect link via an AWS partner into the same AWS VGW. The partner’s internal CIDR range is 10.10.0.0/16.
- In the true spirit of cloud, a SaaS (Software as a Service) provider has been enlisted to provide marketing data to services running inside the AWS core network. Consequently, an AWS Managed VPN is used to connect with the SaaS partner’s cloud network. They have an addressable CIDR range of 10.33.20.0/24.
- There is a need for Cloudzen’s AWS core VPC to communicate with another partner organisation’s AWS environment. The partner VPC has a CIDR range of 10.99.0.0/16 and resides in the same AWS region. Therefore, a decision is made to create a VPC Peering connection between the 2 networks. A peering connection uses neither an IGW or VGW but rather a peering gateway (PCX)
- Finally, a third party vendor needs temporary access to the Cloudzen AWS VPC to work on an internal application. An IPSec VPN is used to connect their 172.20.20.0/24 CIDR range to the core Cloudzen VPC via the Internet Gateway.
To make all that a little easier to digest, here’s a picture with the core AWS VPC contained within the blue bubble.
Figure 5. The Cloud Hub
In this diagram, we have Direct Connect links marked with an “A”, and the AWS VPN connection from the SaaS partner marked with a “B”. Both these connection types are terminated at the AWS VGW and use BGP for route propagation. They are contained within the translucent orange highlighted area and make up the Cloud Hub.
The Cloud Hub essentially allows open routing between the associated networks with no need for traffic to enter the core AWS VPC. As a tangible example, the partner network (10.10.0.0/16) now has a direct route to the main corporate DC (172.16.0.0/16). Similarly, the MPLS network (192.168.0.0/16) can directly address the SaaS network (10.33.20.0/24) without having to traverse the core AWS network (10.200.0.0/16).
In a scenario like this, where we have multiple connections coming into a single VGW, we need to ensure that both the BGP ASN and VLAN ID associated with each connection is unique within the Cloud Hub.
From a networking perspective, the Cloud Hub has some clear advantages. However, there are a number of security implications that also need to be taken into account.