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
- Service discovery Cloud Map + DNS for ECS; CoreDNS for EKS; Lattice provides named services without Consul cluster ops
- What to do this week 1
- 2
- Pilot 5% canary with weighted targets on non-critical API
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).
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.
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.
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.
