Almost Every Mesh Runs the Same Engine

Istio, Kuma, Consul, App Mesh, Gloo. Five names, and under the hood the same proxy five times: Envoy.

At the end of September, AWS shuts down App Mesh for good. Anyone still running on it is migrating now, voluntarily or otherwise. A forced migration like that puts the same question to every team: how much of what you’ve learned comes with you? If all you knew was the console, you start from zero. If you knew Envoy was doing the work underneath, your knowledge simply moves with you.

The market argues about meshes as if they were fundamentally different machines. In reality, most of them differ on just two questions.

Where does the proxy live? As a sidecar next to every pod. As a shared node proxy for L4, with Envoy waypoints only where L7 is needed (ambient). Or straight in the kernel via eBPF, with Envoy handling only L7 (Cilium).

And who configures it? That’s the control plane. It’s the actual product you’re choosing.

The one real exception is Linkerd, with its own Rust proxy. That comes with a truth that rarely shows up in feature tables: since 2024, stable builds are no longer shipped as open source artifacts; they come commercially from the vendor. The edge releases remain open. That’s legitimate. But it’s a governance decision, not a proxy decision.

For decision makers, this means: you’re choosing more than software. You’re choosing what knowledge your team will have in three years, and how much of it survives the next platform change. Envoy knowledge moves with you. Console knowledge stays with the vendor.

Meshes come and go, App Mesh is demonstrating that right now. The engine stays.

Next week I’ll take the engine apart: four Envoy resources, and debugging almost any mesh becomes readable. If you’ve read report #8, you can already guess why istioctl proxy-config asks for listeners, routes, clusters, and endpoints, of all things.