Multi-cloud architectures have evolved from being “nice to have” to an absolute necessity for more and more enterprises. One of the core components of any network design is the elimination of single points of failure. In 2025 alone, AWS, GCP and Azure (among other cloud vendors) all had outages that caused severe business impacts to their customers. Implementing a multi-cloud strategy for resilience and disaster recovery greatly reduces the impact that one of these outages can have. Why Multi-Cloud? As mentioned previously, multi-cloud deployments create resiliency which not only eliminates single points of failure but also reduces dependency on a single vendor. In addition, there are other benefits to multi-cloud architectures. One is cost efficiency, since now enterprises can shop around for the best fit for their needs. Multi-cloud also allows for best-of-breed designs, as one cloud provider may have features or capabilities that either perform better or don’t exist in other clouds. Geographic constraints can also be mitigated. All clouds may not have a presence in a certain location, and regulatory and/or data sovereignty requirements may be easier to satisfy in a multi-cloud deployment. Flexibility is also increased in a scenario where an enterprise acquires a company that deploys in a different cloud. Once the decision is made to move to a hybrid or multi-cloud architecture, execution becomes subject to certain challenges. What Multi-Cloud Means Multi-cloud is a strategy where enterprises use multiple environments, from on-premise datacenters or colocations to one or multiple public cloud providers like Amazon Web Services (AWS), Google Cloud Platform (GCP) and Microsoft Azure, or neo clouds like CoreWeave to host workloads which increases flexibility and resilience while reducing vendor lock-in. In this article we will cover not only what multi-cloud is and why multi-cloud is important. We will also discuss the benefits, use cases and how a common platform like Isovalent’s Cilium based networking simplifies managing multi-cloud environments. Common Multi-Cloud Use Cases Disaster recovery and failover – Deploying an application or service in multiple cloud environments increases resiliency, protecting against an outage in the primary provider’s infrastructure. In this case, traffic is redirected to a secondary provider until the primary provider’s outage is resolved. Geographical coverage and data residency/sovereignty (compliance) – Some cloud providers have presences in regions where others do not. This provides flexibility for enterprises to keep cloud resources geographically close to end users, or to keep data in country when required by regulatory rules. Mergers and acquisitions with mixed cloud deployments – Even when enterprises have made the business decision to stick to a single cloud provider, they may acquire a company that has deployed in a different cloud, leading to a situation where a multi-cloud architecture is created regardless of the original intent. AI and data-intensive workloads deployed across distributed infrastructure – AI models are growing increasingly complex, requiring increasing amounts of compute and power to support them. Relying on a single cloud may not provide adequate resources to run these models, forcing the models to be deployed across or expanded to additional cloud environments. For additional details regarding how Cilium can be used with AI workloads, check out the blog Securing AI/ML Workloads with Isovalent. Multi-Cloud Kubernetes The first question that might arise is “what is the difference between hybrid cloud and multi-cloud?” A hybrid cloud environment includes a certain number of on-premise datacenters combined with an additional deployment in a public or neo cloud provider. A multi-cloud environment includes multiple public or neo cloud providers. The key elements of each are: Whether an enterprise chooses a hybrid or multi-cloud design for their infrastructure, modern application development has increasingly moved to the Kubernetes model where applications are developed as a series of microservices, or at least that the applications leverage the orchestration advantages of Kubernetes to handle deployment, life-cycle management and scaling. With the added complexity of having these business critical applications deployed and managed on different infrastructures in different clouds, the need for a common Kubernetes platform like Isovalent Cilium becomes that much more critical in order to enable seamless operations. Challenges with managing Kubernetes in multiple public cloud environments Fragmented operational model – Modern application development is increasingly cloud-native, focused on microservices and deployed in containers. Kubernetes has become the standard platform for this deployment model, but vendors have their own product to support Kubernetes. AWS has Elastic Kubernetes Service (EKS), Microsoft has Azure Kubernetes Service (AKS) and Google has Google Kubernetes Engine (GKE), and each have their own implementations. On-premise vendors like Red Hat (OpenShift) and VMware (VMware Kubernetes Service – VKS) also have platforms designed to host and orchestrate containerized workloads, many times deployed on top of Cisco equipment and managed through Cisco Application Centric Infrastructure (ACI). Tool sprawl – These vendors have their own set of constructs and tools, including container network interfaces (CNIs). This creates complexity for network and platform teams who need to install, configure, manage and troubleshoot Kubernetes environments spread across multiple public cloud providers, or even in a hybrid cloud environment. Learning new terminology, tools and even a different UI can increase operational overhead, costing time and money for businesses attempting to modernize their infrastructure and benefit from leveraging the capabilities of different public and private cloud providers. Inconsistent security posture – Security becomes a particular challenge when deploying in multiple environments. Each vendor has different constructs or mechanisms for enforcing security policy which makes it difficult to maintain a consistent security posture across the entire enterprise infrastructure. Complex or incomplete visibility – Understanding what is happening in the enterprise infrastructure is critically important for teams responsible for managing and maintaining this infrastructure. Fragmented observability resulting from different tools being supported by different cloud providers makes it difficult not only to understand what is going on in the multi-cloud environment, but also to troubleshoot issues when something goes wrong. Benefits of Building a Consistent Multi-Cloud Orchestration layer with Isovalent Cilium Simplification and flexibility – Cilium eliminates the complexity of multi-cloud Kubernetes management by providing a provider-agnostic, consistent cloud-native operating model. The Cilium CNI has already become the preferred CNI for multiple public cloud providers including Microsoft Azure AKS, Google Cloud GKE, AWS EKS Anywhere and Alibaba Cloud, and is certified by Red Hat for use in hybrid cloud deployments on OpenShift. Standardizing on a common orchestration layer using Cilium helps abstract cloud provider-specific infrastructure. Security – Identity-aware Cilium network policies provide a consistent, fine-grained security posture across a multi-cloud environment, fusing security into the fabric of the network. Built on Isovalent’s eBPF technology, Cilium network policies are implemented without the need for sidecars and avoid the performance issues associated with large iptables rulesets. Most importantly, this allows network and security operations teams to maintain a consistent security posture regardless of the underlying infrastructure. Observability – Isovalent Hubble Timescape provides a unified way to gain deep, near real-time visibility into traffic flows across a multi-cloud deployment, also displaying a live service map so that network and platform teams can better understand what is happening in their infrastructure. Historical flow data storage is also available to allow investigation into changes or incidents that have happened in the past. Having a holistic view into an organization’s entire infrastructure reduces visibility gaps, closes security holes and makes troubleshooting faster and easier. High-performance and scalability – Cilium’s cloud-native control and data planes have been designed for scale and performance, using eBPF for efficient load balancing and data forwarding. This design supports highly dynamic cloud-native environments where hundreds to thousands of containers can be created and destroyed within seconds with minimal impact to throughput and CPU usage. Multi-cluster connectivity – Cilium ClusterMesh creates a unified network fabric that connects workloads across a multi-cloud environment. The ClusterMesh API server for each cluster communicates with the other ClusterMesh API servers to determine which clusters are available and should have traffic directed to. This creates resiliency as application access be shifted from one cloud provider to another when the primary cloud has an outage. This works seamlessly when private circuit connectivity (such as AWS Direct or Azure ExpressRoute), but Cilium can also integrate with other connectivity solutions like VPN or SD-WAN solutions when needed. To learn more about how Cilium is becoming the defacto standard container network interface (CNI) in the cloud, see the blog From Hyperscalers to Neoclouds. Multi-Cloud FAQ What are the biggest operational challenges in a multi-cloud environment and how can they be reduced? The biggest challenges are lack of visibility, inconsistent policies due to fragmented vendor-specific tooling. These challenges can be mitigated by standardizing on Isovalent Cilium, providing a unified platform and operating model across any public or private cloud. How can enterprises enforce consistent security policies across multi-cloud deployments? Using Isovalent Cilium, organizations can create consistent, identity-based policies that maintain a consistent, zero trust enforcement model so that policies are always applied to workloads as desired even if the workload moves from one provider to another. How is visibility maintained for distributed multi-cloud applications and workloads? Isovalent Hubble Timescape provides near real-time insight into traffic flows and security policies regardless of where the workloads are deployed. Having a single pane of glass look into telemetry at the network layer allows enterprise teams to identify potential performance or security issues and reduce the time to resolve these issues. Conclusion Simplification is critical in order to allow businesses to modernize their network infrastructure efficiently. However, simplification and speed cannot come at the cost of security. Deploying Cilium across a multi-cloud environment provides the simplicity of a single operational model while maintaining the security posture that enterprises demand.