The vGeek Blog

I came across Aviatrix for the first time a few months ago, while I was knee-deep in the preparation of AWS Associate Exams and at the same time researching for a cloud migration project. AWS networking was a major topic of the exams and also an important research area for my assignment at work. It was very clear to me from the very beginning that Cloud Networking is inherently different from traditional networking. Of course, they share the very same foundations but designing and managing networks in any Public Cloud is a very different business than doing the same in your Data Center. In the Cloud there are no routers or switches you can log into, there are no console cables nor SFP connectors, but you have VPCs that you can literally spin up with a few lines of code with all their bells and whistles (including security policies for the workloads they contain).

This implies a few considerations. First and foremost, the expectations of Cloud Engineers are very different from those of Network Engineers: Cloud Engineers can set up VPCs in minutes but they can be easily frustrated by their on-prem Network counterparts lagging weeks behind to provide VPN connectivity and BGP route distribution to the Data Center. Then there is the skills gap to be filled: Cloud Engineering Teams are usually small and manned by all-round technologists rather than specialists, very often there is no Network Guru in Cloud Teams capable of citing RFCs by memory, so there is a need to keep things simple, yet they must work “as they should”. Finally, in Public Clouds is very easy to lose control and become victims of the VPC sprawl; managing Cloud Networking at scale is probably the biggest challenges of all.

Enter Aviatrix

Aviatrix’s journey starts exactly here, aiming to resolve the three pain points I just highlighted, by making Cloud Networking fast, easy and manageable. Aviatrix achieves this goal with AVX, a solution elegantly simple and developed around a few clear and addressable use cases. What it is AVX then? Let’s answer by clarifying what is not: AVX is not a virtual cloud router, meaning that it is not just a virtualized version of your on-prem router, adapted to run in a Public Cloud. If AVX was only a virtual router it most likely wouldn’t be capable of all the features it comes with and that are provided by its control plane component, the AVX Controller. AVX is a Software Defined Cloud Router, meaning exactly this, it is a distributed set of IPSec capable appliances (AVX Gateways) deployed in each VPC and managed by the AVX Controller: Cloud Engineers can define policies on the Controller and apply them to Gateways at will by means of APIs. The beauty of AVX is that it is indeed Cloud Provider agnostic: it works with AWS (Amazon actually recommends Aviatrix as one of the preferred options to deploy Transit Networks) but also with Azure and Google Cloud, and it can interoperate with all of them at the same time. The number of providers (Public and Private) that Aviatrix might support in the future – as hinted during CFD4 – could become even bigger with Oracle Cloud, OpenStack and possibly VMware NSX next in line if enough customer interest will justify investment in research and development. One interesting tidbit about Gateways is that they run fine on T2 micro instances with just one network interface; therefore, the monthly EC2 instance cost of a Gateway (AVX costs aside) is literally peanuts.

The Use Cases

Aviatrix’s strength lies in its simple, elegant UI designed around the most common Cloud Networking Use Cases. Let’s review them quickly.

The first and most obvious is related to Transit Networks. Put simply: if you are an organization that scales beyond a couple of accounts and a few VPCs, you will definitely need a Transit Network (and most likely a Shared Services VPC too). The reason is very simple: you will need to make a choice between a meshed VPC network (working, but hard to scale and even harder to manage) and a hub-and-spoke architecture where all VPCs (the spokes) connect to a central hub which, in turn, provides simple connectivity to the on-prem network. Do you already see the advantages of setting just one VPN connection from “home” to the Cloud instead of having to touch your edge every time you need to add one VPC? There you are. Now, you could set up your Transit VPC on your own but that would be time consuming, convoluted and feature limited or you could have AVX do it for you literally in minutes and forget about it. One important consideration is that while in theory VPCs can connect to each other through the Transit Hub, this communication is disabled by default and by design, mainly for security reasons. Of course, this type of connectivity can be enabled on a VPC-to-VPC basis if required; in addition, if you really need to have two VPCs talk to each other, best practices prescribe to use traditional VPC peering to avoid engulfing the hub unnecessarily. Of course, Aviatrix helps there as well, by easily establishing encrypted communications across VPCs, something that is not exactly out-of-the-box in AWS.

Next Use Case is Egress Security: while your on-prem Internet consumers are a mix of surfing humans and servers fetching OS updates etc., egress traffic originating from the Cloud has a totally different utilization profile. Your Cloud Workloads should be able to access public services only for reasons strictly related to their functions and you should not be forced to route all the outbound traffic through your DC (where your Firewalls are) to control this type of connections. At the same time, if you are sending your egress traffic through your VPC Internet Gateway then you should definitely enforce some sort of control on it. Here is where AVX helps, allowing to filter HTTP/S, S/FTP and SSH traffic originating from your instances and directed to the Internet; AVX can dynamically learn from recorded egress traffic patterns so that Cloud Engineers can easily enforce lists of permitted/denied destinations.

Third case is related to Multi-Cloud Peering. The beauty of this case is that what could potentially be a very complex task (interconnecting VPCs in different Cloud Providers) is indeed one of those challenges Aviatrix possibly solves in the most simple and elegant way! Just deploy a new Gateway in a VPC/VNET in Provider B from the Controller in Provider A, set up the connection and it’s done. Really, it is that simple. A side note on Controllers: you can decide to deploy your AVX Controller in any VPC/VNET, regardless of the supported Provider of choice and then deploy/interconnect Gateways wherever you like, no matter how complex your resulting architecture will be (Aviatrix UI has very nice map and mesh visual representations for this). Also, you can deploy a standby Controller anywhere you like and quickly bring it up using a backup of the configuration extracted from your primary one, or you could just migrate a Controller to another location using the same technique.

The last two use cases are very similar and they are related to remote VPN access, specifically Remote User VPN Access and Site to Cloud VPN Access. In the first case AVX simplifies access of developers and admins to cloud resources, so their VPN connections won’t have to be necessarily routed through the company’s internal network to reach cloud instances; similarly, Remote and Branch Offices can be connected to the Cloud and directly access resources without complex redirections through the corporate VPN concentrators. All of this, needless to say, is achieved enforcing security policies defined on the Controller, to ensure that users can connect only to resources they are entitled to.

One last word on Use Cases is that even the AVX pricing model is based on this approach: customers pay for what case they use, when they use it. This makes very appealing to start with Aviatrix, maybe just from the Transit Hub case and then extending as needed, while at the same time controlling costs.

What is around the corner

Aviatrix has hinted at some game-changing feature that will be announced in Autumn 2018, called Insane Mode Encryption. The idea is to overcome the current bandwidth limitations of IPSec encrypted transmissions, that typically cannot exceed 1.25 Gbps because of the inability of IPSec to leverage the computational capabilities of multi-core instances. In their CFD4 session Aviatrix did not go into details about how they are going to overcome this limitation, but they mentioned that they will be soon capable to deliver line-speed encrypted transmissions, therefore unleashing full bandwidth for secure connections, without compromises.

Final considerations

Cloud Networking is simple if your Cloud size and architecture is also simple, but you cannot expect to stay small forever. Chances are that your Cloud will scale out considerably and, in that case, you will need some tool to help you manage your Cloud Networks. Aviatrix is already out there, available and easy to test and implement; for sure there are competitors in the market, but not all of them are at this very moment capable to address all Cloud Networking pain points as Aviatrix does. Aviatrix is definitely ahead in this game and any organization planning to go massively to Public Cloud cannot afford to ignore AVX.

References:

Aviatrix achieves AWS Networking Competency status – https://www.aviatrix.com/news/2017/aviatrix-systems-achieves-aws-networking-competency-status.php

AWS recommends Aviatrix to build Global Transit Networks – https://aws.amazon.com/answers/networking/aws-global-transit-network/

Aviatrix Tech Field Day videos: http://techfieldday.com/companies/aviatrix-systems/

Disclaimer: travel, hotel and meal expenses for my participation to Cloud Field Day 4 have been kindly paid for by Gestalt IT, who invited me as a delegate. I am not under any obligation by neither Gestalt IT nor any of the vendors who participated to CFD4 to write any review or recommend any of the products and solutions presented at the event. I have not received any compensation for writing the above post and its content only represent my personal opinions.

If you like this post, please share it!