I recently wrote about how we leverage AWS CloudFormation to automate the deployment of full-mesh IPsec VPN tunnels on AWS. This is part of our managed VPN solution. The managed VPN solution is an alternative VPN connectivity solution to AWS Transit VPC.
In our conversations with customers we are frequently asked to compare our solution to the Transit VPC. There are a number of important differences in terms of the VPN architectures and the VPN appliances that are spun up.
Datapath.io’s solution easily scales from simple one-to-one cross region VPC VPN connectivity scenarios to more complex full-mesh plus transit VPC setups.
And it costs less!
In this blog post i’m going to make both the pricing comparison as well as look at other architecture differences.
But before we start, what exactly is a transit VPC?
AWS transit VPC is a networking solution that allows AWS users to connect geographically distributed VPCs and remote networks. As the name suggests transit VPC works by deploying a central hub VPC which is in turn connected to spoke VPCs distributed across regions.
In comparison, Datapath.io’s IPsec VPN is a fully managed and highly available solution for deploying full-mesh IPsec VPN tunnels across AWS regions and/or VPCs. It also supports VPN connectivity inside the same region by provisioning local transit VPCs, which in turn are connected to individual leaf VPCs (our term for VPCs inside the same region as the transit VPC).
The operative word here is full-mesh. Full-mesh connectivity in contrast to transit connectivity, refers to direct one-to one connections between VPCs/nodes, without having to go through a central hub VPC.
What is the architecture like? Hub and spoke vs full-mesh
The conversation about architecture goes back to the discussion in the previous section about transit VPC as compared to full-mesh connectivity.
One major advantage Datapath.io’s IPsec VPN solution has over the transit VPC is the full-mesh core of the network. Transit VPC provisions a single hub VPC which every other VPC is connected to. VPN traffic between any two spoke VPCs has to go through the transit or hub VPC.
Datapath.io on the other hand provisions multiple local transit VPCs. Each transit VPC is placed in a separate AWS region. Inter-region VPN connections are arranged in a full-mesh where every transit VPC is directly connected to every other transit VPC. VPCs inside the same region at then connected to the local transit VPC.
The hub and spoke architecture leads to a higher bandwidth requirement at the Transit VPC.
Transit VPC also results in double the number of network hops required to get from one spoke VPC to another. This is bad news in two ways: an increase in latency due to the increased number of hops as well as higher egress traffic costs.
Since AWS charges for egress traffic going out of a VPC, traffic that would go directly from one VPC to another in a full-mesh has to go through the CSR instances which results in double the cost.
How do the setups compare?
Setup for both the transit VPC and Datapath.io’s managed IPsec VPN solution is automated using a CloudFormation stack. The AWS CloudFormation template launches, configures and runs the AWS services required to provision IPsec VPN connectivity on AWS. Let’s go into some more detail on what happens once the CloudFormation stack is triggered.
– Number of IPsec VPN appliances:
There are a couple of differences in the number and type of AWS services that are provisioned.
The CloudFormation stack for the transit VPC solution deploys two VPN appliances (Cisco CSR 1000v instances) into separate Availability Zones of a dedicated transit VPC. Users can choose to automatically create a new VPC or to use an existing VPC as the transit hub.
Datapath.io managed IPsec VPN solution also deploys two VPN appliances running as AWS instances in separate availability zones. Instances are deployed in primary and secondary roles to ensure a highly available and resilient setup.
Users tag the VPCs that they want to connect via IPsec VPN tunnels. Each tagged VPC serves as a local transit VPC which can in turn be connected to local VPCs inside the same AWS region.
Users can also opt to create up-to 5 instances (VPN appliances) per region depending on the availability and disaster recovery requirements.
– Spot Instances:
To reduce instance costs, the managed VPN solution also supports the use of spot instances as VPN appliances. This is also supported by the Transit VPC solution. Users can choose to run all VPN appliances as either on demand or spot instances.
– Spot / on-demand instance mix:
Running the solution exclusively on spot instances however, does lead to concerns about losing connectivity. Spot instances can be terminated when spot instance price goes above the bid price.
Datapath.io addresses this by offering our users a hybrid on-demand/spot instance setup. This ensures that even if the spot instances are terminated on-demand instances can take over with out effecting connectivity.
AWS transit VPC has two pricing models, BYOL (bring your own license) and license included. The pricing model with included license charges for the Transit VPC setup on an hourly basis. For the purposes of this comparison, we will be using the hourly subscription model.
Datapath.io’s pricing structure is based on the number of AWS regions connected to the VPN network. The first two regions that are connected are charged at EUR 450/month. Every additional region added is charged at a further EUR 450/month.
– How does the pricing change with instance size?
One difference in the pricing structure of transit VPC and Datapath.io’s managed VPN is the fact that the AWS transit VPC’s pricing increases with the instance type chosen.
Choosing a t2.medium or a c4.2xlarge instance to run as VPN appliances has zero effect on Datapath.io’s pricing. This can come in handy for applications requiring higher bandwidth levels.
The transit VPC solution charges $0.541/hour for the software license when it is running on a t2.medium instance. In comparison when running on a c4.2xlarge instance users have to cough up almost three times more: $1.616/hour.
Datapath.io’s pricing remains the same irrespective of the instance type chosen.
– How does the pricing change with the number of VPCs?
AWS transit VPC’s pricing also increases with the number of spoke VPCs added to the VPN network.
Every spoke VPC added to the VPN network adds an additional $0.10/hour. This might seem pretty harmless at first, but when scaling to hundreds of VPCs and 24/7 workloads the costs can quickly get out of hand.
Datapath.io’s pricing increases only when an additional AWS region is added to the VPN network. Adding VPCs to the VPN connectivity does not add any additional costs as long as they are in the same AWS region.
AWS Transit VPC charges every additional spoke VPC at $ 0.10/hour. Datapath.io’s pricing remains the same irrespective of the number of spoke VPCs, as long as they are in the same AWS region.
Datapath.io aggregates all local VPCs, inside the same AWS region, by connecting them to a local hub VPC, which is then charged as one region. This makes a significant dent in the pricing as compared to the Transit VPC solution.
Sign-up today and deploy a full-mesh VPN network in minutes!