Service Mesh Traffic Shifting: VPC Lattice, Istio on EKS, and App Mesh EOL
Quick summary: App Mesh is legacy path—new meshes should start with VPC Lattice for AWS-native east-west or Istio on EKS when you need full L7 policy. Traffic shifting without duplicating load balancers per service.
Key Takeaways
- App Mesh is legacy path—new meshes should start with VPC Lattice for AWS-native east-west or Istio on EKS when you need full L7 policy
- Benchmark pattern (hypothetical workload) — VPC Lattice weighted routing 90/10 canary across ECS services, no sidecar, p99 overhead 1
- 2ms; Istio on EKS mTLS + traffic split adds 3
- 8ms p99 sidecar tax; App Mesh EOL drives Lattice migration path
- Service discovery Cloud Map + DNS for ECS; CoreDNS for EKS; Lattice provides named services without Consul cluster ops
Table of Contents
AWS App Mesh is in maintenance/EOL trajectory—June 2026 greenfield should evaluate VPC Lattice (service network across VPCs/accounts) and Istio on EKS for Kubernetes-native canary (flagger, Argo Rollouts).
Benchmark pattern (hypothetical workload) — VPC Lattice weighted routing 90/10 canary across ECS services, no sidecar, p99 overhead 1.2ms; Istio on EKS mTLS + traffic split adds 3.8ms p99 sidecar tax; App Mesh EOL drives Lattice migration path.
Symptom → mechanism → AWS control
| Production symptom | Mechanism | AWS control |
|---|---|---|
| Canary requires DNS hack | No L7 traffic splitting | VPC Lattice weighted target groups |
| Sidecar resource overhead | Envoy per pod on Istio | VPC Lattice (no sidecar) or ECS Service Connect |
| App Mesh deprecation risk | AWS App Mesh EOL trajectory | Migrate to VPC Lattice or Istio on EKS |
Opinionated take: Default to VPC Lattice for AWS cross-service routing in 2026—reach for Istio only when you need K8s-native mTLS and WASM extensibility.
Traffic shifting patterns
| Tool | Shift mechanism |
|---|---|
| ECS/CodeDeploy | Target group weights |
| EKS + Istio | VirtualService weights |
| VPC Lattice | Listener rules + target groups |
| ECS Service Connect | Simpler east-west for ECS-only |
Sidecar limitations: CPU/memory tax per pod—measure before meshing 200 microservices.
Service discovery
Cloud Map + DNS for ECS; CoreDNS for EKS; Lattice provides named services without Consul cluster ops.
AWS services map
| Need | Service | Skip when |
|---|---|---|
| AWS-native service mesh | VPC Lattice | Need K8s-only ingress without cross-VPC |
| K8s mTLS + advanced routing | Istio on EKS | Two services, ALB path routing suffices |
| ECS service discovery + mesh | ECS Service Connect | Monolith with no east-west traffic |
What to do this week
- Inventory App Mesh usage—plan Lattice or Istio migration.
- Pilot 5% canary with weighted targets on non-critical API.
- Compare p99 latency with/without sidecar on same node pool.
More in This Track
Part of the Engineering Guides library (June 2026).
- Previous: Part 2
- Next: Part 4
- Browse tracks: Engineering Guides hub
What this guide doesn’t cover
Container seccomp—part 4 of track.
AWS Cloud Architect & AI Expert
AWS-certified cloud architect and AI expert with deep expertise in cloud migrations, cost optimization, and generative AI on AWS.
