Multi-cloud Networking and Security Challenges

Indeed, the cloud is not built with enterprise-grade networking in mind and the main focus was to host applications fast with all the required agility. In contrast, as the business deciding to adopt multiple clouds, the IT infrastructure folks in the organizations are challenged to serve the cause. let’s look at some of the key multi-cloud networking and security challenges in this blog.

Probably the last five to six years people were more and more aware of the cloud deployments, they will go into the cloud of their choice, however, there were not too many things to do. Slowly when the cloud becomes big enough, they realize that automation is a key to survival.  And also one cloud cannot meet all the requirements and may need to add or move to another cloud for various business reasons. Today companies are realizing that the public cloud is multi-cloud. Clearly, if not today, shortly, as a network architect you may need to strategies the adoption journey. It is required for getting the visibility and control over the network and security you have all across the popular clouds that you may go into.

Needless to say, the need of the hour is to have an architectural approach on extending/or interconnecting to multi-cloud offerings.   And without the architecture, it is only like a sandbox environment, and undoubtedly with multi-cloud, you require some power tools to help you with it.  To understand the need for an architectural approach let’s look into some of the current public cloud limitations/challenges below.

Inter and Intra Region Transit Networking

The biggest piece here is the global transit networking across the cloud providers and having a common networking module across all or most of the main CSP’s

• Managing and operating inter-network connectivity across the multi-cloud environment
• Cloud-native transit gateway (TGW) route scalability: E.g.: with AWS maximum 100 BGP route per routing table
• Gateway peering support between the different cloud providers cloud regions
• Lacks native transit solution to interconnect VPC’s Eg: – GCP recommend single VPC
• Max of 10 VCNs per region, Route table management (OCI)
• No route summarization support natively ( Azure)
• Automating routing between the gateways across CSPs

On-Prem Connectivity Management

This is about how we connect all of your external entities, such as extra-net, public internet, Ingress traffic, your partners, branches, data centers, this is where you will be terminating all of those connectivities.

Some of the key considerations include but not limited to the following

• Back-hauling traffic  to on-prem DC first before reaching the cloud
• Securing remote users to cloud locations
• Connect corporate resource through VPN
• Connect customers to the public cloud resources
• Low latency access to the cloud resources

Firewalling & Security Challenges

We talk a lot about zero trust when it comes to the on-prem deployments, now those applications are moved to the cloud. And we want to make sure your workloads are double-safe, regardless of whether it is hosted in CSPs of your choice. And when you insert a firewall, want to make sure it follows the best practices, great architecture, etc.

Let’s look at some of the security and firewalling challenges here

• Native cloud IPsec VPN has a maximum encryption performance of 1.25 Gbps per tunnel
• How to use IPsec, BGP, SNAT without reducing throughput ( It reduces to 500 Mbps and lack visibility)
• leveraging deep packet inspection, IPS, and IDS capabilities in the cloud?
• Avoid doing of static routes and SNAT (source IP visibility is a challenge)  when redirecting traffic to the firewall/L7 devices
• L4-L7 instance failover without using any complicated scripting
• How to re-use security group  when traffic transiting between the segments

End-to-End visibility & Troubleshooting

With multi-cloud, you are kind of managing multiple data-centers.  And just think about the operational complexities involved with this.  In this section lets pinpoint some of the operational complexities.

• Different clouds operate using different UI, CLI, and API constructs. Leveraging centralized management across the clouds is a huge challenge.
• Native cloud tools from CSPs are not helping with end to end traffic, path trace visibility across the different clouds
• Single pane of glass to manage all cloud accounts, around show-back, and chargeback details.
• Visualization of the traffic, workload connectivity, flow map, and resource usage, etc

Summary & Next Steps

Each of the CSPs such as AWS, Azure, OCI, Ali Bababa, and GCP are spread of different terminology, architectures limitations, and configuration constructs. The interesting fact is everything is kind of similar, but at the same time, it is different. It has some analogies in the on-prem world. But it’s not something that you can pick up easily.

In short, when you are getting ready to be multi-cloud, you want to make sure that all the architecture is unified. You don’t want to do different things in Azure, another many different thing in AWS and much more different networking approaches on GCP, etc that’s not scalable. That’s not how an enterprise should do networking. So it is time to have a multi-cloud networking strategy part of your enterprise architecture to have everything unified and centralized. With a common edge, transit, access, core network across all of those clouds, and on-prem with repeatable architecture model could give you better control over the network and security policy for your hosted workloads.

For more information on various architecture and related discussion please refer to the data center networking & security section. Happy Learning