Aviatrix has pioneered Secure Cloud Network Architecture through the Multi-Cloud Network Architecture reference model.
In order to be effective, network architecture needs to be repeatable, scalable, predictable in behavior, and meet the application requirements.
To this end, the Aviatrix “transit-spoke” architecture allows customers to scale advanced network connectivity in any cloud, across regions, and across multiple clouds, all whilst maintaining full ownership of the control, management and data plane.
Let’s review quickly the role of these tiers:
Transit – provides high-speed, encrypted connectivity between the different spokes, transit gateways in other regions or CSPs as well as on-premise and third-party locations. Supports advanced service chaining and service insertion.
Spoke – Provides services to application VPCs containing VMs, containerized workloads, connectivity to cloud services, etc. Supports advanced routing and NAT services.
The benefits of the Aviatrix platform include a fully encrypted, high-speed data plane, fully orchestrated deployment using Infrastructure as Code, enterprise-level visibility, and management as well as advanced security capabilities such as Firenet, ThreatIQ/ThreatGuard, and advanced network segmentation.
When two tiers are no longer enough
All architectures need to be flexible in order to let the business do what the business needs to do.
For most cloud designs, the transit-spoke architecture meets customer requirements, but there are times when business requirements demand a different approach.
These requirements may be any of the following:
- a design where a customer is present in a large number of regions globally (in one or multiple CSPs) requiring a large number of Aviatrix transit peerings. In this case, we may add another layer of transit to simplify the global peering design.
- a requirement to centralize the Firenet and advanced security functions in 2-3 regions. In this case we may use another transit layer to provide these security services.
- a need to satisfy application owners requiring their own dedicated Firenet designs but leveraging the Cloud Networking backbone for inter-region, inter-cloud connectivity. In short, a more complex Cloud design. More on this challenge below.
We will have a deeper look at this last use case.
Example Design Requirements
Let’s have a look at the design requirements for a fictitious customer:
ACME Holdings is a conglomerate with diverse Business Units and Entities. The CCoE team is mandated with providing a scalable Multi-Cloud Network Architecture to the various stakeholders.
The design review has identified 2 main application architectures:
Application Architecture 1 (App1) – Complex application architecture requiring multiple VPCs, ingress controls, advanced security service insertion, interconnectivity with other CSP regions, on-prem DCs, and corporate shared services. This division will be using Fortinet firewalls.
Application Architecture 2 (App2) – Application owner requires VPC assignment only and will leverage the CCoE and corporate security services for FW policy and connectivity requirements as well as for operations and management.
The CCoE team will provide the following:
- A common, high-speed encrypted transit network between all CSP regions and the on-premises data centers and sites
- A managed Palo Alto NGFW service enforcing the corporate security inspection policy in conjunction with the CISO office
- Advanced network segmentation to ensure network-level segregation of applications and Business Units
- Advanced IP routing control, NAT management, and shared services access
- Enterprise level Day 2 Operations and Management
Therefore, we can identify 3 main architectural building blocks:
- App1
- App2
- CCoE
All 3 building blocks need to be deployed across any region in any cloud.
Design Overview
The below design includes an Azure region and a GCP region. This network design can be replicated quickly to any new region via Terraform in less than 1 hour including firewall builds.
As you can see, we are leveraging the Aviatrix Multi-Tier Transit capability to satisfy the design requirements.
For the CCoE building block design, we find the familiar Aviatrix MCNA 2-Tier architecture, which also serves the application owners and provides shared services:
As you can see the CCoE team provide the following:
- high-speed encrypted multi-cloud transit
- corporate firewall insertion and inspection
- network segmentation, keeping the App1 separate from App2
- connectivity to the on-premises sites
- inter-spoke connectivity for the App2 business unit
- providing access to the corporate shared services VPCs for both App1 and App2
In the below, you will also see that the App1 Architecture is more complex than the App 2 architecture as per the analysis during the design review:
App1, thanks to the Aviatrix Multi-Tier Transit, can provide the following services to its clients:
- dedicated firewall service with application-specific policy enforcement
- dedicated high-speed encrypted transit for the workload spokes
- network segmentation where required
- advanced ingress services for the application
- high-speed connectivity back to the CCoE-managed Multi-Cloud transit
The App1 architecture is connected to the CCoE block via the Aviatrix Multi-Tier Transit (MTT) capability:
This flexibility enables more advanced design scenarios depending on customer requirements.
On top of that, there is very little extra configuration required in the Aviatrix controller:
One command – that’s it.
Or if doing Terraform:
One line of config.
Once again, whilst this design may appear complex at first sight, we are adhering to architectural best practices:
- building blocks are scalable and repeatable
- we architect for high availability
- traffic flows are predictable and there are clear administrative boundaries
- there is a single data plane, high-speed and encrypted
- we have enterprise-level visibility and control end-to-end
- everything can be deployed via code
Conclusion
The Aviatrix platform offers enormous flexibility whilst retaining repeatable and scalable features critical to the success of any Cloud project.
Reach out to us for any further details or design questions.
