Skip to content

SYSTEM Cited by 1 source

AWS App Mesh

AWS App Mesh is AWS's first-generation, Envoy-based service mesh for ECS, EKS, Fargate, and EC2 workloads. It exposes a four-tier abstraction stack on top of ECS services (Mesh → Virtual Service → Virtual Router → Virtual Node) with a self-managed Envoy sidecar container deployed inside every Task, and an AWS Cloud Map namespace for service discovery. AWS announced App Mesh's discontinuation: closed to new customers 2024-09-24, full EOL 2026-09-30. Existing customers are directed to Amazon ECS Service Connect (ECS) or Amazon VPC Lattice (EKS).

Abstraction model

  • Mesh — logical boundary; the set of resources that share routing + policy.
  • Virtual Service — one per application microservice; the name other services connect to.
  • Virtual Router — routing rules between versions of a Virtual Service.
  • Virtual Node — a specific backend version (e.g. a particular ECS Service or Deployment); Virtual Routers distribute traffic across Virtual Nodes, enabling version-weighted canary routing.

Plus a separate Cloud Map namespace for service discovery.

Data plane: self-managed Envoy

App Mesh ships systems/envoy as a container image you run inside your Task as a sidecar. Envoy handles routing, outlier detection, health checks, retries, observability. The customer owns the sidecar lifecycle — image updates, resource limits, crash recovery — under the patterns/sidecar-agent shape.

Feature strengths (vs. post-EOL Service Connect)

  • Full Envoy configurability. Retry policies, outlier-detection thresholds, health-check intervals — all exposed.
  • Advanced traffic routing. Virtual Router + multi-Virtual-Node shape supports weighted routing between versions, the precondition for in-mesh canary deployments.
  • Mutual TLS. Two-way peer authentication between services — zero-trust primitive for regulated workloads.
  • Cross-account mesh sharing via AWS RAM. Multi-account applications can share one logical Mesh boundary.
  • AWS Private CA general-purpose certificates (vs. Service Connect's short-lived certificates).

EOL timeline

  • 2019-03: GA announcement.
  • 2024-09-24: Closed to new customer onboarding.
  • 2026-09-30: Full discontinuation. Critical security + availability updates provided through this date; existing customers can still create resources via CLI/CloudFormation until then.

Why the sunset

The 2025-01-18 migration-guide post doesn't state a rationale explicitly, but the structural read is:

  • Managed-service consolidation. App Mesh required customers to operate Envoy themselves. AWS's new offerings (Service Connect and VPC Lattice) ship Envoy (or equivalent) as a fully-managed data plane — less customer friction, more AWS operational surface.
  • Fragmented adoption across ECS + EKS. App Mesh tried to be one mesh across compute substrates; the replacement story splits ECS (Service Connect) from EKS (VPC Lattice), each optimized for its substrate's discovery + scheduling model.
  • Concurrent open-source evolution. Istio Ambient Mesh, gRPC xDS, proxyless meshes, and Cilium Service Mesh emerged during App Mesh's lifetime — alternative points in the design space that AWS customers could pick without vendor lock-in.

Migration mechanics

An ECS Service cannot simultaneously be in an App Mesh Mesh and a Service Connect Namespace — services must be recreated. The canonical migration is patterns/blue-green-service-mesh-migration: parallel blue (App Mesh) + green (Service Connect) environments, edge traffic shifting (Route 53 weighted records, CloudFront continuous deployment, or ALB multi-target-group), no cross-environment networking during the cutover.

Seen in

Last updated · 200 distilled / 1,178 read