How Does Aviatrix Global Transit Solution Differ from the CSR Solution?
Aviatrix AWS Global Transit Solution has been published on AWS Answer page as a partner solution. Since then we are often asked by customers on why they should consider Aviatrix solution, and for that matter, why they should consider Aviatrix over all other virtual appliance based solution. This article tries to answer some of the questions.
- Who should use Aviatrix solution?
If you are not a CCIE with domain expertise in VRF, BGP and IPSEC, you should not consider the CSR based solution. While the CloudFormation and Lambda scripts make it easy to setup, you wouldn’t know what to do when network go down, or to prove network is not the problem when a developer complain about connectivity issue for her apps.
If you are a CCIE but have not managed large scale network with potentially hundreds of BGP sessions, you should not consider the CSR based solution. Since each spoke VPC to Transit VPC runs a independent BGP session, there could be hundreds of BGP sessions. Managing hundreds of BGP sessions is like managing a mini ISP handicapped, because the other side of every BGP session is a black box (The VGW in every Spoke VPC runs BGP that no one can see).
If you are the super star CCIE who can do everything but like to be able to take vacations and have a normal life, you should not consider the CSR based solution. Chances are you are the only person in your organization who has the capability to manage and support this solution. The entire network up time will be on you.
If you are not comfortable with programming but need customization, you should not consider the CSR based solution, because the entire solution is written in python.
By the way, this is true for all virtual appliance vendors out there that mimic the CSR solution.
If you are not a super hero, like the rest of us, you should consider the Aviatrix solution.
Using Aviatrix Transit VPC solution, you are going to have a very different experience. Aviatrix solution has a central controller with a web console that provides an easy to use and manage Transit solution. No BGP runs in any Spoke VPC gateway. In the cloud, it is all software defined networking (SDN), just like how AWS does it for intra region peering and inter region peering. If you know how to build an AWS VPC and configure AWS peering, your skill is good enough to operate the Aviatrix controller.
Here is a diagram of Global Transit Network with Aviatrix.
2. Network segmentation consideration
This is about security. Since BGP runs in every VPC in the CSR based solution, there is default connectivity established among all Spoke VPCs. These Spoke VPCs are most likely owned by different organizations and are never supposed to talk to each other. Realize you just build something with the blast radius of the entire cloud network. Note 99% of data breach come from one weakness in the datacenter design: lack of network segmentation. Why should you build something like that in the cloud?
Because Aviatrix uses SDN in the cloud, a Spoke VPC can only communicate with Transit VPC to on-prem. Spoke and Spoke have no connectivity by default, unless you specify it, at which time, you can choose to use AWS native peering or Aviatrix encrypted peering.
3. Connectivity efficiency consideration
This is about not having a performance bottleneck. With BGP running in every VPC in the CSR based solution, Spoke to Spoke traffic by default is routed through the Transit. Your Transit hub is the performance bottleneck. In addition you pay twice the egress charge. You really should distribute the traffic and leverage native AWS peering as much as possible for Spoke to Spoke traffic. Of course you can go to AWS console to build that, Aviatrix does better by integrating the native AWS peering into the controller.
4. AWS limitation consideration
AWS VPC comes with multiple limits. For example, each route table in a VPC has a maximum 100 route entries for static and dynamic routes, which implies you cannot have many VPCs, after taking into consideration the route list propagated from on-prem. Special handling on route entry limit is needed to overcome that. That special handling is not in the CSR based solution. Aviatrix’s Designated Gateway feature allows to scale beyond the AWS route limit.
5. Has Aviatrix product been proven in the field?
We are a Cisco shop, the entire engineering team came from Cisco with years of networking development experience. We abstract the complexity of networking so you don’t have to know the nuts and bolts. Aviatrix product has been in production for over 3 years in companies of all sizes. Recently at re:Invent 2017, Aviatrix was selected as one of the two inaugural partners for the newly established AWS Network Competency in the connectivity category.
I hope this covers a few bases, there are certainly other areas, such as visibility, troubleshooting, logging and monitoring, to consider. I encourage to find out more at our website and our Doc site.
