Considerations when building a multi-cloud network architecture
Enterprises that move from on-prem or a single cloud to a multi-cloud environment will face several challenges. Some of these include lack of visibility, architecture gap, and difficulty to scale to meet new business needs. More often than not, connectivity between clouds can also become a serious performance bottleneck for multi-cloud architectures.
While a multi-cloud transit can provide robust networking between the clouds, it is important to look at the total architectural requirement. A good multi-cloud network architecture should allow enterprises to control not only the native cloud constructs, but also advanced features beyond what the cloud service providers (CSP) offer. It needs a balanced approach where all dimensions are combined to produce a well-rounded architecture.
When building a multi-cloud network architecture, there are several aspects you need to consider:
1. Robust Connectivity
The transit must have awareness of not only the transit routing but also of the VPC/VNET routing. It should be able to adapt to changes in the architecture without the need for manual intervention. When adding or removing new VPCs/VNETs, the transit network should be auto-aware of the change and ensure transit routes reflect the change.
Transit network architecture should not assume that the security posture of all VPCs and VNETs is going to be same, since they always have varying requirements. Some environments will have public IP based subnets, some will need local egress to internet, some may have direct peering in addition to the transit connection. A well-designed transit network should be able to adapt to the routes.
2. Pod-like characteristics
One transit network is going to connect several parts of the architecture, but it is not going to be the entire infrastructure. A public cloud architecture will need multiple transit networks, be it a single cloud or multiple cloud. Even for a single cloud in a single region, you will still need to provide isolation, control, security and operational visibility between the applications, users and business units.
The transit network architecture should allow you to scale out and have multiple transits even within a single region. Each transit network can provide the isolation and control based on the usage requirements, such as individual users or departments. This also applies to multiple regions or multiple clouds. A scale-out characteristic enables you to create multiple pods and provide connectivity between them as needed.
3. End-to-end network state awareness
The true architecture will allow transit networks to be aware of each other and to adjust their connected networks based on what may be happening in another part of the network, be it in same or different region/cloud.
If you have two transits in same region for different workloads, they should be able to talk to each other natively. For multiple transit networks in multiple regions, the right architecture will ensure the entire network has the reachability when you add a new VPC/VNET to one of the transits. All of these should be fully automated.
4. Service chaining
Transit should support a robust and modular services architecture where additional services like security can be inserted without re-architecting the deployment. Public cloud transits like AWS Transit Gateway provides the connectivity, but do not easily allow the insertion of security services like Next-Gen Fire Wall (NGFW). It is usually not possible to do so or the deployment will reduce the performance and add complexities. Scaling out to multiple parallel active/active firewalls can also be challenging.
A good transit architecture should allow you to insert NGFW without needing to manipulation the routes manually. It should also have the ability to orchestrate traffic patterns to the NGFW with maximise throughput performance and visibility into packet flow.
5. Operational visibility and troubleshooting
These are the most important aspects when choose a transit architecture. Tools like ping, traceroute, packet capture can save both time and money. Without visibility into routing, state, packets, connectivity and dynamic network maps, the mean-time-to-resolution for every issue you encounter can increase significantly. This can bring up the overall maintenance cost and the ROI will not be as expected.
By providing familiar tools, support teams can have abstracted visibility into the cloud constructs and a simpler way to troubleshoot any level 1 issues. This frees up the time and resources of your engineers and architectures to attend to the more demanding issues.
Future-proofing your cloud environment
The network architecture should be the most important part of your multi-cloud strategy. Our solution powered by Aviatrix ensures that your transit network design is future-proof for any cloud environment. Unlike other offerings in the market, we enable a repeatable multi-cloud architecture with operational visibility, control and troubleshooting capabilities.
Best of all, you rely on us to provide the expertise without needing deep cloud knowledge.