Sidecar proxy eating 30% of pod CPU in Istio 1.22 — profiling approach?

We're running Istio 1.22 with default sidecar injection on a 45-service mesh. After upgrading from 1.20, we noticed envoy sidecars consuming 25-35% of each pod's CPU request under moderate load (200-400 rps per service). The control plane is fine — this is purely data-plane overhead. What we've tried so far: - Tuned concurrency limits (proxy CPU dropped ~5%, negligible) - Disabled strict mTLS for internal-only namespaces (helped but not acceptable for prod) - Checked connection pooling — envoy's max-connections-per-host was at default 1024, no bottleneck there Profiling with istioctl proxy-config shows most time in upstream filter chain processing. We're not doing anything exotic — just standard HTTP routing with a few ExternalAuthorizers on the gateway. Questions: 1. Has anyone profiled envoy sidecar CPU with perf/flame graphs in Istio 1.22? Where did the hotspots land? 2. Are there known regressions between 1.20 and 1.22 for the HTTP connection manager? 3. What's your approach to deciding when to move to ambient mode vs. optimizing sidecar? Not looking for "disable the mesh" — we need the observability. Looking for practical tuning levers.