Service Mesh Traffic Shifting: VPC Lattice, Istio on EKS, and App Mesh EOL
Quick summary: App Mesh is a 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
- New meshes should start with VPC Lattice for AWS-native east-west or Istio on EKS when you need full L7 policy
- AWS App Mesh is on a maintenance/EOL trajectory
- As of June 2026, greenfield should evaluate VPC Lattice (service network across VPCs/accounts) and Istio on EKS for Kubernetes-native canary (Flagger, Argo Rollouts)
- Reach for Istio only when you need K8s-native mTLS and WASM extensibility
- Measure before meshing 200 microservices
Table of Contents
AWS App Mesh is on a maintenance/EOL trajectory. As of 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 the Lattice migration path.
Symptoms, mechanisms, and AWS controls
| 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 and plan a 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 is covered in part 4 of this track.
Frequently asked questions
Should new AWS meshes start on App Mesh in 2026?
When is Istio the wrong default versus VPC Lattice?
What could go wrong if I mesh 200 microservices on day one?
Does Cloud Map replace Lattice named services?
Enterprise AI Transformation
Enterprise AI transformation and implementation leader focused on pilot-to-production playbooks, with a background in financial services. Writes the FactualMinds guides on serverless, CI/CD, and DevOps on AWS, the delivery plumbing production AI depends on.
