Overview of AWS VPN CloudHub
AWS VPN CloudHub is a hub-and-spoke VPN technology offered by AWS. CloudHub allows your remote sites to communicate with one another over VPN tunnels that are created between your AWS Virtual Private Gateway (VPG) and your remote sites. You can use just the VPG to interconnect remote sites, or you can connect your VPG with your AWS VPC to allow for communication between remote sites and your applications that are hosted within AWS. You can read move about the VPN components here. You can use CloudHub to securely communicate to applications not publicly accessible from outside your VPC or you can use it to interconnect remote sites only. For example, a customer might use CloudHub for remote site VPN connections only if all of their applications are publicly available and use other methods to provide secure access.
AWS VPN CloudHub has a several requirements to start functioning:
- You create a VPG and attach it to your VPC.
- You create a VPN connection for each remote site. To save a step in the process, you can create the Customer Gateway (CG) at the same time. See Figure 1 below.
- You associate multiple CGs with the same VPG.
- The remote sites must be using statically assigned public IP addresses.
Figure 1: VPN Connection Dialog Example
For the Border Gateway Protocol (BGP) configuration, you assign a unique BGP Autonomous System Number (ASN) to each one of your CGs. When you create your VPN connections, you will tie together using a single VPG and multiple CGs running BGP. AWS will automatically exchange routes learned from your remote sites via BGP to the other remote sites. This will allow spoke-to-spoke traffic to be routed via your VPG.
Pricing for AWS VPN CloudHub is the same as the standard AWS VPN. In most U.S.-based regions, you will pay $0.05 per VPN connection (remote site) per hour. For example, if you have 10 remote sites, you will pay $0.50 per hour or around $360 per month. You will also pay the standard AWS data transfer rates for the VPN connections you need. For each customer, your mileage will vary depending on the amount of traffic sent between remote sites and between your remote sites and your VPC.
In figure 2, you can see an example AWS VPN CloudHub topology attached to a VPC with several subnets.
Figure 2: Sample AWS VPN CloudHub Topology
Overview of Cisco DMVPN on AWS
The Cisco Dynamic Multipoint VPN (DMVPN) is a Cisco IOS software solution for building multipoint GRE IPsec encrypted tunnels. It’s a centralized VPN hub-and-spoke topology typically created between Cisco hardware routers in the past. These are the main differences between DMVPN and typical VPN technologies:
- DMVPN allows for dynamic public IP addresses on spoke routers (remote sites).
- DMVPN allows for the dynamic creation of spoke-to-spoke tunnels without human intervention.
DMVPN uses several technologies to provide the features above:
- Next Hop Resolution Protocol (NHRP) – This is how the spokes can obtain the public IP address of remote site networks that it may want to build a tunnel and route traffic to.
- Multipoint GRE Tunnel Interfaces – This is a single GRE interface that can support multiple GRE and IPsec tunnels.
For AWS, the DMVPN technology runs on a virtualized Cisco IOS XE router called the Cloud Services Router 1000V (CSR) that is available in the AWS Marketplace. The CSR runs as an EC2 instance within your VPC to provide the hub router functionality. The hub router sits in your VPC with an Elastic IP address (a public IP address assigned by AWS) to one of it’s interfaces that resides in a public subnet. This EIP is configured as the tunnel destination between the spoke routers running in your remote locations and your AWS VPC. The tunnel between the hub and the spoke is always up but the tunnels between the spokes are created dynamically only when needed. Figure 3 below shows at a high level what this looks like.
Figure 3: Cisco DMVPN on AWS High Level Architecture
A big feature for running the Cisco CSR in AWS for DMVPN is that you can run Interior Gateway Protocols (IGPs) like EIGRP or OSPF to exchange reachability information between your VPC and your remote sites.
For pricing with DMVPN in AWS, mileage will vary greatly depending on how you architect your DMVPN infrastructure and also how much network throughput you have. Since the CSR is an EC2 instance, you are billed hourly depending on the instance type you select for your CSR and you are charged standard Internet transfer rates for the VPN traffic traversing your VPC. You also need to license the CSR router from Cisco. At this time, the available instance types for the Cisco CSR are m3.medium/large/xlarge for the general purpose instance types or c3.large/xlarge/2xlarge for the compute optimized instance types.
As for licensing the Cisco CSR, you can do it in two ways:
- Bring Your Own License (BYOL). Licenses can be purchased from AHEAD.
- Pay for the license as part of your AWS usage fees. Hourly pricing for software will vary depending what licensing package you select.
To get DMVPN working, you must, at a minimum, license the CSR IOS XE Security package as well as license the desired throughput rates on the CSR. See Table 1 for available throughput licenses supported by Cisco for AWS. Keep in mind the actual throughput is going to depend on the instance type selected and other conditions within the AWS infrastructure.
Table 1: Supported AWS Throughput Licenses
If you are going to run CSRs in a highly available manner for your EC2 instances, then you will need the Application Experience (AX) which includes support for DMVPN as well as a protocol called Bidirectional Forwarding Detection (BFD). You can read more details on how this works in Part 2 of this post series.
One way to keep your costs to a minimum using this solution is to combine AWS reserved instances and BYOL licensing. A reserved instance is a billing feature in AWS that allows you to pay for a certain percentage of the EC2 costs up front in order to reduce expenses. Reserve instances also reserves capacity for that instance in the region you use. If you combine this with purchasing CSR licenses up front from AHEAD, you can save money if you are planning on running the CSR instances 24/7 compared to using the on-demand model. AHEAD recommends this model for production deployments.
Use Cases / Comparison
“So, should I use AWS VPN CloudHub or Cisco DMVPN?” This is a common question I am often asked to which my response is usually, “it depends.” That answer also applies to hub-and-spoke VPN designs in AWS. What you build is going to vary depending on your adoption of AWS technology, location of remote sites, and other factors. Here are some questions and other items to think about as you are looking at these two solutions.
- Do your remote sites have statically assigned IP addresses or dynamically assigned IP addresses for the Internet connection? Cisco DMVPN will work with either, but AWS currently requires static IP addresses.
- Do you have any latency sensitive applications (like video, VoIP, etc.) that need to send network packets directly between remote sites? If you do, DMVPN might be a good solution as it allows the spokes to talk directly to one another without requiring an IPsec tunnel to be built manually between each site.
- Do you have Cisco routers in all of your remote sites? DMVPN is a Cisco IOS solution, so if you are running Cisco ASAs, Palo Alto firewalls, Jupiter routers, etc., in your remote sites, then you will need to stick with CloudHub or purchase additional hardware to support a DMVPN solution.
- Is your staff comfortable with BGP, or do you prefer to run EIGRP or OSPF between your hub-and-spoke routers? Since CloudHub uses BGP, some customers may be a little hesitant to take on running BGP. The great thing about CloudHub is AWS will provide a BGP configuration for each remote site that requires minimal editing, so you can get the solution up and running. To be fair, you can run BGP across DMVPN as well, but most deployments use EIGRP.
- CloudHub integrates natively with routing in your VPC and that makes routing from your EC2 instances to your remote sites very easy as the network addresses can be propagated from your VPG to your VPC routing table(s). On the other hand, since Cisco DMVPN runs on EC2 instances, there is no native integration with your VPC environment. The lack of native integrations makes DMVPN more challenging to implement into a AWS environment, especially for failover.
- Note: VPC limits the number of BGP propagated routes to 100 per routing table, so if you have 100 or more remote sites, then you are going to need to create a static route in your VPC routing table(s) summarizing the DMVPN networks and pointing that to your VPG.
- How much throughput do you expect between your remote sites and your EC2 instances? Do you plan to use AWS Direct Connect? For DMVPN, the EC2 instance type you select for your CSR, the throughput licence, and other EC2 environmental elements within an a physical EC2 host (remember, AWS is a shared tenancy environment), can affect network performance for the CSR. For the best performance, select the instances with the most Elastic Compute Units (ECUs) and run them on dedicated hosts for more predictable performance. As of now, the largest instance supported for the CSR is C2.2xlarge, which has 28 ECUs. Direct Connect with VPN encryption also provides better bandwidth consistency rather than just using VPN over the Internet alone.
A great hub-and-spoke solution can be implemented using AWS with a little bit of planning. Ultimately, what you build for networking in AWS needs to be a part of a larger AWS adoption plan for your enterprise. AHEAD offers consulting services to help enterprise organizations build a strategy and a roadmap, as well as a design and plan with this roadmap in mind. Networking connectivity to your AWS VPC and remote sites is important for your users that are consuming applications running in AWS. For more information on AHEAD’s expertise with AWS or how you can get started on your journey toward AWS adoption, contact AHEAD today, and stay tuned for a deeper dive into AWS CloudHub vs. Cisco DMVPN in Part Two of this series!