According to Jeremy Wright, a global black belt in Azure at Microsoft, “In the Azure marketplace, there are a large number of virtual appliances and third-party devices. Unfortunately, some of them either don’t work at all, or don’t work as advertised.”
Wright found Aviatrix, in the marketplace and tested it. Aviatrix stood out, because it effectively and reliably works with Azure to provide centralized control of services for single-cloud deployments AND multi-cloud deployments. Wright said, “Aviatrix is good for my role, it is good for customers, because it supports all the advanced things that customers want to do, like a centralized point, and it addresses a lot of the designs I work with.”
Following are Azure and Aviatrix use cases discussed by Jeremy Wright and Bryan Ashley, a former Azure global black belt, in a recent webinar, along with an overview of how Aviatrix complements Azure’s hub-and-spoke architecture.
Azure Hub & Spoke
Azure’s hub-and-spoke designs are its most popular. The hubs usually access the central point of connectivity to on-prem networks and traditionally have shared services such as active directory, DNS, and security devices (e.g., firewalls). Typically, there is an ExpressRoute gateway or VPN gateway in the hub, which provides on-prem connectivity for the hub and spokes.
There is nothing that differentiates the hub VNet from the spoke VNet as far as the configuration goes. It is a matter of how the shared services are set up in peering. The spokes are essentially VNets that peer with the hub. Peering means the hub can exchange routes with and communicate with spokes. The spokes are typically deployed to isolated workloads.
For example, in this diagram, each spoke could be aligned to a business unit, prod/test, or blue-green types of deployments. Hub and spoke is a common pattern for workloads that do not require connectivity to each other. If each spoke has a requirement to access the shared services but not each other, this is a perfect design for it.
A common challenge when designing VNets, specifically with ExpressRoute or VPN in Azure, is spoke or on-prem overlapping address space. This could be due to acquisitions, address management, B2B connectivity, etc.
Aviatrix with Azure Hub and Spoke
Aviatrix is built on the hub-and-spoke architecture; however, a key differentiator is that it is a controller driven platform. Aviatrix has a common control plane, but it is implemented on a distributed data plane, which gives it some unique capabilities.
In a common Azure deployment, with some on-prem connectivity, Aviatrix can be deployed in two regions with a standard hub-and-spoke environment. This architecture allows Aviatrix to deploy in a repeatable fashion across regions as well as within a single region. For instance, rather than having a single hub with multiple spokes that are designated per BU or per development environment, Aviatrix makes it possible to stamp out multiple hub-and-spoke environments within the same region for a modified design approach.
With this repeatable design, when the need arises to be able to expand into another cloud (e.g., OCI, GCP, AWS), the exact same workflows with the exact same footprint can be stamped out. And, all that is happening underneath the components is completely orchestrated by Aviatrix. The platform handles the complexity leaving users to focus on defining intent in the controller.
Go Native with Aviatrix Multilingual Controller
Another unique feature in the Aviatrix solution is that the controller, the brains of the entire platform, is multilingual. The controller can talk not only to the Aviatrix gateways and some third-party devices, but also to Azure native constructs, such as VNet peering, VNets, UDRs, and route tables. So, rather than deploying Aviatrix spoke gateways in the respective spokes, native VNet peering can be leveraged. Because of this, expansion into multiple regions can continue with the stamp process and interconnect using the Aviatrix Transit. Also, because the Aviatrix controller is multilingual, it can talk to the Azure API and integrate native constructs to enhance those services where they are needed.
Aviatrix Supports Azure at Scale
One of the big challenges within Azure, especially at scale, is UDR management. There are a couple of ways to allow transitive connectivity. With VNet peering, UDRs can be used to bounce off a third party NVAs, or in some cases, leverage ExpressRoute.
The Aviatrix controller has visibility into the entire cloud environment. Because of this, it can orchestrate those UDRs. And more than that, it can provide end-to-end network correctness. The Aviatrix controller allows users to define intent within the controller. Then, the controller makes sure that UDRs always stay up to date and traffic flows stay consistent—whether that is purely transitive or using more advanced security services, such as next-gen firewalls, insertion, or cloud segmentation.
Workload Architectures
Azure Private Link
Azure provides hosted services over a private IP address or private endpoint in the VNet. Traditionally, these services are provided only via a public IP address over the Internet, Microsoft peering for ExpressRoute, or via proxy. As shown in the diagram below, when a VM in a hub VNet, or that single centralized VNet, needs to talk to a PaaS resource, a private IP address can be assigned to that service. Azure and Aviatrix created architectures to address challenges associated with this. With the Aviatrix multi-cloud private link, regardless of where that customers or applications reside (e.g., a remote VPN user, an on-prem user or application, or applications in another cloud), private connectivity can be provided.
Azure WVD
In the architecture below, Azure WVD is used along with Active Directory for domain services, which is yet another PaaS for domain authentication or domain joints. Aviatrix has the capability to orchestrate the native constructs, like VNEt peering, to enable the ADDs shared services VNET.
When setting this up for a customer, a requirement was figuring out how to leverage Active Directory domain services, which are unique because they are in the delegated subnet. Using Aviatrix, a native VNet peering from a desktop goes back to the AADDS VNet without having to provide any UDRs or frustrate any UDRs. A native connection is facilitated, and overlays are leveraged.
The Aviatrix platform provides advanced services that ensure all of the traffic that is destined to the control plane goes out through the FireNet, which is centrally deployed and managed. The transit connectivity leverages multi-cloud security. The VNets and the VPCs are defined as prod, and the VNets and VPCs are defined as Dev. Using Aviatrix, a policy is built that says, “Okay prod is allowed to talk to prod. Dev is allowed to talk to Dev, but the two cannot cross and cannot talk to each other.”
Why Aviatrix with Azure
The Aviatrix platform is much more than an overlay. It can orchestrate native constructs either in Azure or even in other clouds. Repeating what Microsoft Azure Black Belt Jeremy Wright said, “Aviatrix is good for my role, it is good for customers, because it supports all the advanced things that customers want to, like a centralized point, and it addresses a lot of the designs I work with.”
