# Cilium vs Istio: eBPF Service Mesh Compared (2026) URL: https://www.devopsness.com/blog/cilium-vs-istio Author: Kiril Urbonas Published: 2026-07-29 Updated: 2026-10-03 Categories: DevOps Tags: Kubernetes, Ebpf, Cilium, Istio, Service Mesh Summary: A practitioner's comparison of Cilium's eBPF, sidecar-less dataplane against Istio's Envoy sidecar and ambient mesh models. --- # Cilium vs Istio: eBPF Service Mesh Compared (2026) If Cilium is already your CNI, start with its mesh features and add Istio only when you need deep L7 traffic management. Cilium does L3/L4 forwarding and policy in the kernel with eBPF; Istio runs Envoy, either per pod or, in ambient mode, as a per-node ztunnel plus optional waypoints. They also compose well. For the wider picture, see our [service mesh guide](/blog/service-mesh-guide). If your shortlist also includes Linkerd, the [Istio vs Linkerd](/blog/istio-vs-linkerd) comparison is the companion read. ## The core architectural split Istio's classic model puts an Envoy sidecar in every pod. All traffic in and out is intercepted by that proxy, which gives Istio a very rich L7 story: fine-grained routing, retries, fault injection, header manipulation, and per-request telemetry. The cost is one proxy process per pod plus the redirect plumbing. Ambient mode, generally available since Istio 1.24 in November 2024, changes the shape. A per-node proxy written in Rust, ztunnel, handles mTLS, L4 authorization, and telemetry, and tunnels traffic over HBONE. Envoy-based waypoint proxies run outside application pods only for workloads that need L7 features, so you pay for L7 only where you use it. Cilium comes from the opposite direction. It started as an eBPF-based CNI and network-policy engine and grew mesh features on top. eBPF programs in the kernel handle IP, TCP, and UDP; when you need HTTP, gRPC, or DNS awareness, Cilium hands that traffic to a per-node Envoy it manages. Both projects converged on per-node proxies for L7, but Cilium never had a sidecar to shed. | (as of October 2026) | Cilium | Istio sidecar | Istio ambient | |---|---|---|---| | L3/L4 dataplane | eBPF in the kernel | Envoy per pod | ztunnel per node | | L7 proxy | Per-node Envoy | The sidecar | Optional waypoint Envoy | | Encryption / identity | IPsec or WireGuard; SPIFFE mutual auth in beta | mTLS with SPIFFE identities | mTLS in ztunnel over HBONE | | Policy object | `CiliumNetworkPolicy`, L3 to L7 | `AuthorizationPolicy` | `AuthorizationPolicy` | | Observability | Hubble flow logs | Envoy metrics and tracing | ztunnel and waypoint telemetry | | CNCF status | Graduated, October 2023 | Graduated, July 2023 | Graduated, July 2023 | ## mTLS and encryption Istio's mTLS is the most battle-tested part of the project: SPIFFE identities, certificates distributed to sidecars or ztunnel, and mutual TLS between workloads as a policy toggle. Cilium's transparent encryption works at the node level with IPsec or WireGuard, plus a ztunnel mode that is in beta. Its SPIFFE-based mutual authentication is also still beta per the Cilium docs. If a regulator cares about the exact encryption boundary, read those pages rather than assuming parity with per-connection mTLS. ## Network policy vs mesh policy Because Cilium began as a CNI, `CiliumNetworkPolicy` is mature and can express L3/L4 and L7 rules in one object: ```yaml # cilium/allow-api-get.yaml apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: allow-api-get spec: endpointSelector: matchLabels: app: backend ingress: - fromEndpoints: - matchLabels: app: frontend toPorts: - ports: - port: "8080" protocol: TCP rules: http: - method: "GET" path: "/api/.*" ``` That policy lets the frontend reach the backend only for `GET` requests under `/api/`. If identity-aware segmentation is the goal, Cilium delivers it without a full mesh. Istio's `AuthorizationPolicy` is equally expressive but lives in the mesh layer. For the policy side alone, see [Kubernetes network policies](/blog/kubernetes-network-policies-in-practice). ## Observability Cilium ships Hubble, which taps the same eBPF layer for flow-level visibility with no app instrumentation: ```bash $ hubble observe --namespace payments --protocol http --verdict DROPPED ``` That surfaces dropped flows, DNS lookups, and L7 requests with identities attached, which is the fastest way we know to debug a policy. Istio's Envoy telemetry feeds Prometheus, Grafana, and tracing through Jaeger or Tempo, and is richer for application-behavior questions. Hubble is stronger for network-level truth about what actually flowed. ## Performance: read the benchmark's byline The most cited numbers come from Istio's own blog (Mitch Connors, October 21, 2024), so treat them as vendor-authored. On a 1,000-node cluster with 50,000 pods and constant churn, Istio ambient served 2,178 queries per core against Cilium's 1,815, which the post summarizes as "56% more queries at 20% lower tail latency." Cilium used about 30% less measured CPU, but the post notes that Prometheus only counts user-space resources, so Cilium's in-kernel work and encryption were not measured. Benchmark with your own traffic; connection churn and payload size move the result. ## Can you run both? Yes, and it is often the right answer. Cilium's docs describe integration with Istio in both sidecar and ambient modes: Cilium stays the CNI, handling pod networking, L3/L4 policy, and Hubble, while Istio owns mTLS and L7 routing. You get kernel-level networking without giving up Istio's traffic management. The cost is two control planes to upgrade and understand. ## Questions people ask ### Cilium vs Istio: which is faster? It depends on what you measure. Istio's October 2024 benchmark at 1,000 nodes found ambient mode handled 56% more queries at 20% lower tail latency than Cilium, while Cilium used about 30% less user-space CPU; kernel-side costs were not counted. Istio wrote that benchmark, so rerun it on your workload. For pure L3/L4 forwarding, an in-kernel path avoids proxy hops entirely. ### Do I need Istio if I already run Cilium? Often not. If your needs are segmentation, encryption between nodes, ingress through Gateway API, and flow visibility, Cilium covers them with `CiliumNetworkPolicy`, WireGuard or IPsec, and Hubble. Add Istio when you need progressive delivery, traffic mirroring, fault injection, or per-request mTLS everywhere, and run it in ambient mode on top of Cilium. ### Is Istio ambient mode production ready? Istio declared ambient mode generally available in release 1.24 on November 7, 2024. Its core, ztunnel for L4 mTLS and authorization plus waypoint proxies for L7, is stable; some individual features in the docs are still marked alpha. Check the status of any feature you depend on, such as multi-cluster, before migrating sidecar workloads. ## The decision, concretely - Already run Cilium as your CNI? Turn on its mesh features first; a second system may never be needed. - Need identity-aware segmentation more than L7 shaping? Cilium plus Hubble, with less overhead. - Need canaries, weighted routing, and a broad extension ecosystem? Istio in ambient mode. - Multi-cluster? Cilium Cluster Mesh for connectivity and policy; Istio multi-primary for consistent L7 policy. ## The call we'd make Greenfield, we'd run Cilium as CNI with its mesh features, and layer Istio ambient on top only when the L7 gap actually bites. Hubble alone often justifies Cilium. If your requirements are L7-heavy from day one, go straight to Cilium plus Istio ambient. Either way, prototype against your own traffic and recheck release notes, because the feature line between the two keeps moving. ## Sources - [Istio blog: Istio ambient vs. Cilium benchmark (October 21, 2024)](https://istio.io/latest/blog/2024/ambient-vs-cilium/) - [Istio 1.24 release announcement, ambient mode GA](https://istio.io/latest/news/releases/1.24.x/announcing-1.24/) - [Cilium service mesh documentation](https://docs.cilium.io/en/stable/network/servicemesh/) - [Cilium transparent encryption documentation](https://docs.cilium.io/en/stable/security/network/encryption/)