If I had to pinpoint the defining milestones in Cilium's history, the ones that turned it from a promising networking project into today's standard, I'd point to the 2020–2022 years. During that stretch, Google, Amazon and Microsoft announced in consecutive years that Cilium would be included in their Kubernetes offerings. Adoption of Cilium exploded. If the largest cloud providers in the world, including Kubernetes' creators, all select it, it must be for a good reason. The Rise of Neoclouds and Sovereign Clouds A similar phenomenon is happening in the second half of the 2020s. Regulation, geopolitical circumstances and technology have driven the emergence of new forms of clouds. Sovereign clouds are designed to meet data privacy, residency and security requirements of a specific region or country. Neoclouds are AI-specific cloud providers - without the wealth of features of the traditional (I call them "OGs" of the cloud) hyperscaler clouds and the sophisticated user interfaces. They provide GPU-as-a-service and simply aim at catering to AI and LLM requirements. What all these clouds have in common is that they all provide Kubernetes managed services. And they need a CNI. And they're all picking Cilium. Who's Using Cilium - and More Importantly - Why? CoreWeave, arguably the most prominent neocloud, uses Cilium as the default CNI for its Kubernetes Service. Crusoe Cloud (a neocloud with a commendable renewable energy approach) also uses Cilium as the default CNI for Crusoe Managed Kubernetes. Nebius (the AI cloud spun out of Yandex) deploys Cilium as a default add-on on all its managed Kubernetes clusters. It doesn't stop at AI neoclouds either. European and alternative cloud providers like OVHcloud, Scaleway, Hetzner, Gcore and DigitalOcean are all using Cilium too. Koyeb rebuilt its entire networking stack on it. And as a Frenchman, I can't help but note that two of France's homegrown clouds, OVHcloud and Outscale (owned by Dassault Systemes), both use Cilium as their default CNI. The list of clouds that leverage Cilium by default or support them as a built-in option is impressive: So the obvious question is: why? Enhanced Performance and Scalability Cilium is built on eBPF, which means networking happens directly inside the Linux kernel. No iptables chains, no kube-proxy overhead. For cloud providers running thousands of clusters, that difference compounds fast. Scale was one of the reasons Google (“the Cilium-based GKEv2 removed some iptables related bottlenecks, such as the number of Services”) and Microsoft adopted Cilium in the first place: When scaling up to 16,000 pods, the Azure CNI powered by Cilium cluster demonstrates a significant improvement with a 30 percent reduction in service routing latency compared to the kube-proxy cluster. These results reconfirm that eBPF based service routing performs better at scale compared to IPTables based service routing used by kube-proxy. The requirement for high throughput and low latency also apply to GPU workloads. As I wrote in a previous post, that's true for both the hardware networking layer and the software networking layer. You're not going to build an AI cloud and then leave performance on the table either. CoreWeave runs CKS on bare-metal nodes with NVIDIA BlueField-3 DPUs and leverages Cilium for "high-performance, eBPF-powered policy enforcement". Gcore found they could support "three times the number of pods per node compared to Calico" on their bare metal worker nodes. Likewise, by adopting Cilium, Hetzner saw a 105% increase in requests per second and a 45% throughput improvement, while cutting CPU usage by roughly half. The story from every provider that's published benchmark data is the same: the performance gap only grows at scale. Integrated Security and Multi-Tenant Isolation Cloud providers are multi-tenant by definition. For neoclouds, the stakes are even higher: GPUs are expensive, and idle GPUs are wasted money. Maximising GPU utilisation across the fleet means packing more tenants onto shared infrastructure, which makes strong, scalable network isolation essential. Cilium's approach to tenant segmentation is fundamentally different from traditional CNIs. Instead of IP-based network policies (which are fragile and hard to scale), Cilium uses identity-based policies. Nebius uses Cilium to ensure "only specific services and traffic can access certain pods" across all their managed clusters. OVHcloud highlighted how Cilium's advanced network policies provide "fine-grained control that strengthens tenant isolation and security". Scaleway chose Cilium specifically for its "advanced networking and security features, including fine-grained network policies and efficient load balancing". Both Google and Microsoft have gone further with Cilium's policy capabilities than standard Kubernetes NetworkPolicy allows. GKE now supports Cilium-powered Cluster Wide Network Policies, letting platform teams enforce security baselines across entire clusters rather than namespace by namespace. Through its Cilium support, Azure has made L7 network policies generally available for AKS, giving operators the ability to filter traffic based on HTTP methods, paths, and headers, not just IPs and ports. Additionally, data confidentiality and integrity requirements across shared infrastructures require encryption of data in transit, which often comes with a performance penalty. When Koyeb redesigned their networking platform, they replaced their Kuma/Envoy sidecar mesh with Cilium's WireGuard integration and got full in-kernel encryption across their private network, with 70% faster deployments and up to 10 Gb/s bandwidth. Enhanced Network Observability Network observability is a win for both cloud providers and their clients. Customers get visibility into their traffic and do some level of troubleshooting, which means fewer support tickets for the provider to handle. Nebius highlights that Cilium provides "observability into traffic between pods and nodes, to optimize network paths and enforce network security policies." Cilium ships with Hubble, which delivers exactly that: real-time traffic monitoring, service maps and network policy debugging out of the box. “Hubble has been particularly impactful, giving internal teams visibility into network behavior without requiring additional tooling or instrumentation.", Joël Le Corre, OVHcloud Microsoft describes this as “observability you can trust”. Cilium and Hubble metrics can be exported to Grafana, which makes “security incidents auditable and easy to diagnose, enabling operations teams to detect misconfigurations or threats in real time”. A Virtuous Circle Google, Amazon, Microsoft, Alibaba all chose Cilium. That drove community engagement, matured the project and led to CNCF Graduation. Which made it the safe choice for neoclouds building their platform from scratch. Which drives more adoption, more contribution and more maturity. As Google's Gobind Johar put it: "The Cilium community has put in a tremendous amount of effort to bootstrap the Cilium project, which is the most mature eBPF implementation for Kubernetes out there. We at Google actively contribute to the Cilium project, so that the entire Kubernetes community can leverage the advances we are making with eBPF." Google and Microsoft engineers have historically contributed a lot back to Cilium, and CoreWeave & co are now doing the same. "Cilium is the clear leader in this space.", Joël Le Corre, OVHcloud A Platform, Not Just a CNI The final reason is perhaps the most forward-looking. Cilium is more than a CNI: it's a very versatile networking platform, with so many features that our Cilium Up and Running book is perhaps the largest in the entire O'Reilly "Up and Running" series. Providers adopt it knowing they also get observability, multi-clustering, Gateway API and kube-proxy replacement built-in. Crusoe Cloud is already using Cilium's built-in Envoy integration for L7 proxy load balancing. OVHcloud is exploring Cluster Mesh for cross-cluster multi-region connectivity. Outscale runs the full Cilium stack on their managed Kubernetes service: Hubble for observability, CiliumNetworkPolicy for security, and kube-proxy replacement for performance. And it goes beyond networking. CoreWeave supports Cilium Tetragon for eBPF-based runtime security observability, taking security down to what I've called the nano-segmentation layer. What This Means for You If this post reads as self-congratulatory, let me balance it. This is a genuinely positive outcome for users. Look at the table above. Seventeen cloud providers, each with different consumption models, different architectures, different APIs. Using them in conjunction or migrating from one to another is never going to be straightforward. The fact that one networking platform now runs consistently across all of them changes that equation. Your network policies, your configuration settings and - perhaps more importantly - your skillset: they all transfer. Cilium is now so broadly adopted you could compare it to the Ethernet standard: a networking layer so universal it became invisible, the thing everyone just uses without thinking about it. And there's truth in that: Cilium is becoming the default that cloud providers simply ship, the way Ethernet became the default that hardware vendors simply built in. But Ethernet is a fixed standard. Cilium isn't. Cilium is open source, community-driven, and constantly evolving. A better analogy: Cilium is becoming the Linux of cloud networking. That might sound like a grand statement, but the parallels are hard to ignore. Linux became the universal foundation that abstracted away hardware differences and let developers focus on what they were actually building. Cilium is doing the same thing for cloud networking: abstracting away the differences between providers so platform teams can focus on their applications, not on re-learning networking primitives every time they onboard a new cloud. What this means for you, our reader: If you're a network engineer, a platform engineer, or anyone working with Kubernetes networking, investing in Cilium is one of the safest bets you can make for your career. Just as learning Linux or the OSI model became transferable skills that applied regardless of which platform or network you worked on, Cilium knowledge now carries across every major cloud provider. In a landscape where the technology you learn today can feel obsolete in two years (that Cilium book I mention earlier will need a second edition sooner rather than later), that kind of staying power is worth something. What this means for your organization: A common networking layer across clouds means better portability. If you need to exit a cloud, or split workloads across multiple providers for resilience or load-balancing, the networking layer is no longer the bottleneck. That’s not to say multi-cloud suddenly becomes easy overnight but at least having a networking configuration valid across clouds regardless of the provider makes it a possibility. Final words From the team at Isovalent, the creators of Cilium: thank you to every cloud provider that has chosen Cilium as their networking foundation. The neocloud era is only getting started, GPU clusters are scaling to sizes we haven't seen before, and the networking challenges that come with them are only going to get more interesting. We can't wait to see what comes next.