Skip to content

AWS 2025-01-18 Tier 1

Read original ↗

AWS — Migrating from AWS App Mesh to Amazon ECS Service Connect (App Mesh discontinuation announcement)

Summary

AWS announces the end-of-life of AWS App Mesh (discontinued 2026-09-30; no new customers as of 2024-09-24; existing customers can still use the service until EOL, including new resources via CLI/CloudFormation; critical security + availability updates continue during the sunset window). The bulk of the post is a migration guide from App Mesh to Amazon ECS Service Connect (introduced at re:Invent 2022) for ECS workloads, with a sidebar redirecting EKS-on-App-Mesh users to Amazon VPC Lattice. The piece has three architecturally interesting threads: (1) an abstraction comparison between App Mesh's Envoy-based sidecar mesh and Service Connect's AWS-managed Service Connect Proxy; (2) a feature delta showing what you give up by moving off the full Envoy-configurable mesh (fine-grained retry/outlier tuning, virtual routing between service versions, mTLS, cross-account mesh sharing via AWS RAM) in exchange for a simpler operational model and free CloudWatch application-level metrics; (3) a blue/green migration pattern (patterns/blue-green-service-mesh-migration) because a single ECS Service cannot simultaneously be part of both an App Mesh Mesh and a Service Connect Namespace — you must recreate services, stand up a parallel environment, and gradually shift traffic via Route 53 weighted routing, CloudFront continuous deployment, or ALB multi-target-group routing, with no cross-environment networking between the two meshes during the cutover.

Key takeaways

  1. App Mesh is being retired after ~5 years. Launched GA 2019-03, no new customer onboarding from 2024-09-24, full discontinuation 2026-09-30. AWS guides existing ECS customers to Service Connect and EKS customers to VPC Lattice. The direct read is that AWS is consolidating its service-mesh story around managed, service- specific offerings rather than a universal Envoy control plane. (Source: raw article top-matter.)
  2. Service Connect collapses App Mesh's abstraction stack. App Mesh requires four nested abstractions on top of ECS services: Mesh (logical boundary) → Virtual Service (one per microservice) → Virtual Router (routing rules) → Virtual Nodes (versioned backends), plus a separate AWS Cloud Map namespace for service discovery, plus a self-managed Envoy sidecar per Task. Service Connect replaces all of this with a flat Client / Server / Client-Server role on an ECS Service, attached to a single Cloud Map namespace, with the Envoy sidecar (the Service Connect Proxy) fully managed by AWS. Fewer dials, fewer things to break. (Source: "Comparing App Mesh to Service Connect" section.)
  3. The load-bearing architectural primitive that changed is managed data plane, not the mesh model. Both products use Envoy for L7 routing, outlier detection, health checking, and retries. The difference is who operates the sidecar: App Mesh ships Envoy as a container image you run inside your Task; Service Connect runs Envoy for you. The article frames this explicitly: "Service Connect eliminates the undifferentiated heavy lifting associated with managing sidecar proxies." Same systems/envoy data plane, different operational contract. (Source: sections 1 + "Increased Network Reliability.")
  4. You give up configurability in exchange for the managed tier. The article enumerates five explicit feature deltas:
  5. Retry / outlier detection / health-check tuning — App Mesh exposes the full Envoy knobs; Service Connect ships opinionated defaults and only timeouts are configurable.
  6. Advanced traffic routing — App Mesh's Virtual Router + Virtual Node combination supports version-weighted routing for canary deployments; Service Connect does not.
  7. Observability — inverted: App Mesh requires you to ship Envoy metrics yourself; Service Connect publishes application-level traffic metrics to CloudWatch for free, visible in both the CloudWatch and ECS consoles.
  8. Security / mTLS — both support TLS encryption; App Mesh supports two-way peer authentication via mutual TLS, Service Connect does not yet. Service Connect also uses AWS Private CA short-lived certificates (cheaper) vs. App Mesh's general-purpose certificates.
  9. Cross-account sharing — App Mesh Meshes can be shared across AWS accounts via AWS RAM; Service Connect's Cloud Map namespace cannot be shared across accounts, so all tiers of an application must live in one account. (Source: "Feature comparison" section.)
  10. EKS-on-App-Mesh customers get routed to VPC Lattice, not Service Connect. Service Connect is ECS-native. The EKS replacement story is Amazon VPC Lattice, with its own dedicated migration post. Read: AWS is not offering a single unified post-App-Mesh destination; it's splitting the population by compute substrate and shipping service-specific managed alternatives. (Source: EKS sidebar link.)
  11. Migration is blue/green because an ECS Service cannot participate in both meshes simultaneously. The constraint is load-bearing: you cannot in-place swap one sidecar for another — you must recreate the ECS Service in the new mesh. That forces the patterns/blue-green-service-mesh-migration pattern: stand up a parallel Service Connect environment next to the App Mesh environment, and gradually shift production traffic by adjusting weights on:
  12. Amazon Route 53 weighted routing records (DNS-level)
  13. CloudFront continuous deployment (edge-level)
  14. ALB multi-target-group routing (load-balancer-level)

The article recommends monitoring the ramp using Service Connect's free CloudWatch metrics to catch misconfigurations as load increases. (Source: "Migrating from App Mesh to Service Connect.") 7. There is NO cross-environment networking during migration. Each mesh has its own service-discovery implementation (App Mesh uses its own Virtual Service abstraction + Cloud Map namespace; Service Connect uses a separate Cloud Map namespace). A user session entering the App Mesh Frontend reaches only App Mesh backends; a session entering the Service Connect Frontend reaches only Service Connect backends. The two environments are disjoint all the way down. This is the load-bearing reason the blue/green pattern uses an edge traffic shifter (DNS / CDN / ALB) rather than an in-mesh traffic splitter: once a request enters a mesh, it cannot escape. (Source: "no cross-environment networking between the environments" paragraph.)

Operational numbers disclosed

  • Migration deadline: 2026-09-30 (App Mesh fully discontinued).
  • Closed-to-new-customers: 2024-09-24.
  • No throughput / latency / cost numbers disclosed — this is an architecture + migration-pattern post, not a production retrospective.

Architectural diagrams (described)

The post walks through four architectures on the same sample app (Frontend + User API + Stock API, all on ECS):

  1. Baseline (no mesh) — three ECS Services, each behind its own Elastic Load Balancer for resilience and traffic distribution.
  2. App Mesh — three ECS Services, each Task now contains a self-managed Envoy sidecar implementing routing / reliability / observability. Client-side routing between services reduces the number of ELBs needed. A Cloud Map namespace provides service discovery; everything is attached to an App Mesh Mesh boundary.
  3. Service Connect — three ECS Services, each Task has a fully-managed Service Connect Proxy (Envoy under the hood). Frontend is a "Client" service (doesn't expose endpoints); User and Stock are "Server" services (expose endpoints). Single Cloud Map namespace provides service discovery and the logical mesh boundary.
  4. Parallel (migration in progress) — App Mesh environment ("blue") and Service Connect environment ("green") running in parallel. Route 53 weighted records shift end-user traffic from blue to green by adjusting weights. The two environments are disjoint — no cross-mesh traffic.

Caveats

  • Vendor-blog-on-vendor-product framing. The article is AWS advocating its own replacement service; feature deltas are framed to make Service Connect look favorable (e.g. the free CloudWatch metrics are foregrounded; the lack of mTLS and advanced traffic routing is deeper in the page). The architectural facts are still clean, but the "Service Connect wins" narrative is a marketing overlay.
  • No scaling numbers. The post does not discuss fleet sizes, proxy overhead, cold-start cost of the managed sidecar, or metric cardinality limits — all of which matter at real deployment scale.
  • Service Connect feature gap is a point-in-time snapshot. "Not yet available" for mTLS + advanced traffic routing suggests they're on the roadmap; readers landing here post-GA should re-check.
  • The EKS migration path (VPC Lattice) has distinct architecture. VPC Lattice is not a sidecar mesh — it's a service-networking managed control + data plane with a per-VPC data path and no customer-run proxies. Conflating "post-App-Mesh on AWS" into a single story misreads the split. (Linked but not covered in depth here.)
  • mTLS gap matters for regulated workloads. Teams that picked App Mesh specifically for in-mesh mutual authentication of peers (zero-trust / PCI / HIPAA perimeters) will need to either wait for Service Connect mTLS, stay on App Mesh until EOL, or exit to a self-managed Envoy/Istio stack.

Source

Last updated · 200 distilled / 1,178 read