Aviatrix Cloud Network Building Blocks
As companies move applications to the public cloud from the traditional data centre or building new applications in the cloud. These applications are deployed in the cloud providers virtual networks such as VPCs, VNETs or VCNs, i.e., the data centres of the cloud. The challenge is to securely deliver these applications, allowing users, customer and developers with connectivity that protects the user accessing the application or service and the company providing the application. These applications will typically integrate with and talk to other applications. This communication can be over many connecting paths such as ingress or egress within the same cloud or to other clouds. The application may be presented by SaaS or PaaS providers or consumed by users using the public internet or over private networks.
As companies start to develop these applications/services and networking teams start to develop cloud networking solutions, it becomes clear the cloud providers networking constructs are unique to the cloud provider and only deliver basic network connectivity. This makes it difficult for the operations teams to get more visibility, more control and advanced networking and security features that are still as important to the cloud as they were in the enterprise data centre.
By working with the Aviatrix Multi-cloud Network Architecture an organisation can arrange the building blocks of cloud networking to deliver on their business requirements (see https://www.cloudsilverlining.net/post/single-and-multi-cloud-network-architecture ). The Aviatrix platform and building blocks provided by Aviatrix allow companies to implement consistent, repeatable secure networks with operational simplicity and efficiency.
To implement and deliver a cloud network, Aviatrix software leverages AWS, Azure, GCP and Oracle Cloud APIs to interact with and directly program native cloud networking constructs. Aviatrix abstracts the unique complexities of each cloud to form one network data plane, and adds advanced networking, security and operational features enterprises require.
This post walks through the building blocks of a multi-cloud network, starting with a single cloud single region through to a multi-cloud multi-region network. I then extend the building blocks to external locations such as on-premise data centres and user remote access.
Single Cloud Single Region
The Single Cloud Single Region is the foundation of the building blocks. The network build in this case starts with AWS and symbols 1 and 2 on the diagram above represent Aviatrix Gateways. An Aviatrix gateway can be a spoke gateway (1) that is deployed as part of the MCNA Application Layer Networking and is a gateway that provides a VPC connectivity to the core network or Transit Layer Networking for VPC to VPC communication. The Aviatrix Transit gateway (2) provides the connectivity for inter-VPC communication and the Spoke to Transit gateway connectivity is established over a high performance encrypted (HPE) backbone (3). A key benefit of Aviatrix gateway connectivity is that HPE is implemented as standard so all cloud connectivity is encrypted by default.
Single Cloud Multi Region
Expanding the cloud network from a single region to a second region in a single cloud with Aviatrix, is as simple as implementing the same spoke and transit design in Region 2 and providing HPE connectivity from Aviatrix Transit (4) to Region 1.
Deploying in another cloud has never been easier and with the same spoke and transit design the second cloud, in this instance, the cloud network in Azure is connected to AWS with HPE from the Aviatrix Transit (5).
Using the repeatable pattern, Google GCP and Oracle OCI are connected to AWS and Azure using HPE from the Aviatrix Transits (6, 7). Aviatrix will provide multi-cloud connectivity to all cloud providers including AliCloud (not included in the diagram). The Aviatrix platform will build a full mesh of encrypted connections across between the Aviatrix Transits providing direct access from one cloud provider network to the other thereby minimising any transit latency between clouds.
Cloud Access Networking - Data Centre
Connectivity from the on-premise data centre (8) to the cloud can be implemented over the public Internet or using a private underlay from network providers such as Megaport and Equinix. Both approaches are implemented using HPE (9) and extending the encryption from the cloud to the data centre providing the confidence that secure network connectivity is available regardless of the approach. For HPE an Aviatrix appliance (virtual or physical) will provide the high performance encryption and for data centres connecting to the cloud, using 3rd party routers or firewalls, standard IPSec or GRE is used.
Cloud Access Networking - Remote Site and Remote User
Remote sites (10) can represent a branch office, a partner site/data centre or SD-WAN access to the cloud network. Branch office and partner connections can be established using Aviatrix HPE from an Aviatrix appliance (virtual or physical) or standard IPSec from any 3rd party firewall, router. SD-WAN access to the Aviatrix Multi-Cloud Network can be IPSec or the SD-WAN appliance can also be deployed directly in the transit networking layer with BGPoLAN connectivity for high bandwidth access requirements. Secure access connection policies can be defined for each parter or site access requirement. Policy will determine network segmentation and whether further inspection is required via a Next Generation Firewall (NGFW).
Aviatrix provides an advanced remote user SSL VPN solution (11) that connects remote users on individual or group based secure policies to access resources in the cloud network. This is a OpenVPN and SAML based solution with advanced policy control when implemented with the Aviatrix Client App.
Aviatrix provides tools for businesses to implement segmentation across the multi-cloud with segmentation policy extended across all cloud provider networks. Aviatrix has 2 approaches to cloud network segmentation that can be combined to meet business security requirements. These are network domain and micro segmentation and they provide a simple, intuitive and efficient method of applying segmentation policy. The example above uses coloured circles to illustrate the point. Segments of the same colour can communicate by default. For one coloured segment to communicate with another, a connection policy is defined. The example connection policy (12) allows blue, green and orange to communicate with each other, but the purple is only allowed to communicate with orange.
Aviatrix Multi-Cloud Service Insertion
Inserting NGFW into a cloud network is simplified with the service insertion capability of the Aviatrix Multi-Cloud Networking platform (13). Organisations are able to select their standard firewall such as Palo Alto VMSeries, Checkpoint Cloud Guard and Fortinet Fortigate and the Aviatrix platform will manage the insertion of the firewall into the cloud transit layer. Security policy will determine if inspection is required by the firewall and where the policy requires inspection of a certain traffic flow, then Aviatrix Transit gateways will route the traffic to the firewalls in the cloud transit layer for policy enforcement. Traffic that does not require inspection will be routed based on it the network segmentation policy.
Secure Ingress and Egress
The Aviatrix building blocks considers secure ingress and egress to the cloud network. Organisation preference or requirements may stipulate centralised versus distributed ingress and egress.
For ingress Aviatrix can, in conjunction with cloud provider load balancers or proxy services, support a dedicated centralised point of access to the cloud network. Aviatrix will, based on policy, route the traffic through a NGFW for inspection before forwarding to the target application or service in the multi-cloud network. The ingress point can be a dedicated VPC or VNET alternatively it could be ingress directly to the core transport networking layer routed directly to a NGFW. solutions (14).
For egress Aviatrix provide both centralised and distributed solutions full qualified domain filtering (FQDN) for filtered access to the Internet. Distributed egress provides direct access from a VPC or VNET to the internet with the appropriate filtering applied. This can be used in conjunction with Aviatrix L4 firewall filtering capabilities. A centralised egress is provided at the core transit networking layer and Aviatrix will steer traffic to the central egress point with same filtering capabilities as the distributed solution.
It should not be complex to design and build a cloud network. Aviatrix provides all the building blocks for an organisation to implement a cloud network solution from a single cloud single region solution to a multi-cloud multi-region solution with cloud access to data centre, remote sites and remote user VPN. Aviatrix can simplify and provide a consistent implementation of cloud network security with Aviatrix segmentation and firewall service insertion automation and control.
Aviatrix provide customers with a framework, reference architectures and tools that simplifies the design and build to improve the efficiency of cloud network deployments.
Refer to the Aviatrix website to get more information how the Aviatrix MCNA is used to solve business outcomes for customers and the solutions to meet Enterprise networking, security and visibility.
https://aviatrix.com https://aviatrix.com/multi-cloud-solutions/ https://aviatrix.com/cloud-network-platform/ https://aviatrix.com/aviatrix-transit/