AWS App Mesh support ended on September 30, 2026. AWS now says that the App Mesh console and App Mesh resources are no longer accessible. This page is a post-retirement reference for teams that used the service; it is not a guide for creating a new mesh. AWS App Mesh documentation

What AWS App Mesh did

App Mesh was a managed control plane for configuring service-to-service traffic through Envoy proxies running alongside application workloads. A mesh grouped related services. Virtual services gave applications stable names, virtual nodes described the participating workloads, and virtual routers and routes directed requests between service versions. Workloads used DNS or AWS Cloud Map for service discovery. Teams configured proxy telemetry separately for their monitoring and tracing tools. AWS's App Mesh overview

App Mesh could route traffic between versions and optionally configure TLS, including mutual TLS between Envoy proxies. Those controls depended on proxy and mesh configuration; App Mesh did not automatically make every connection encrypted or provide a complete monitoring setup. For example, AWS notes that traffic between an application and its local Envoy proxy is not encrypted by App Mesh's mTLS feature. AWS App Mesh mTLS details

What retirement changes

AWS announced in September 2024 that new customers could no longer onboard to App Mesh starting September 24, 2024. Existing customers could continue using it, including creating resources through the CLI and CloudFormation, until the September 30, 2026 end-of-support date. That period has ended. AWS's current notice says that after September 30, 2026, customers can no longer access the App Mesh console or App Mesh resources. AWS's retirement and ECS migration announcement

Do not plan a migration around querying, editing, or exporting live App Mesh resources. Start with material your team retained: CloudFormation, CDK, Terraform, Kubernetes manifests and App Mesh custom resources, ECS task definitions, deployment pipelines, service-discovery configuration, and Envoy settings. AWS's notice does not say whether Envoy sidecars already running in workloads will continue to pass traffic. Do not treat an existing data plane as supported or assume it will keep working indefinitely; verify current application behavior while planning to remove the dependency.

Build a migration inventory from retained configuration

Before selecting a replacement, record what the application actually relied on. A mesh name or list of virtual nodes is not enough; the migration must preserve required application behavior.

  • Map services and callers. Record service names, ports, protocols, namespaces, DNS names, Cloud Map registrations, and which workloads initiate or receive connections.
  • Recover traffic rules. Capture version-based routing, weights, retries, timeouts, health checks, and circuit-breaking behavior from saved configuration and application deployment files.
  • List security requirements. Identify TLS termination and origination, certificate sources, any proxy-to-proxy mTLS, authorization rules, account boundaries, and network access controls.
  • Trace operations dependencies. Note which metrics, access logs, traces, dashboards, alarms, and incident procedures expect Envoy or App Mesh data.
  • Plan and test the cutover. Choose how clients will discover the replacement, how traffic will shift, and how to roll back. Verify DNS, authorization, TLS, routing, failure handling, and telemetry with representative requests.

If replacing App Mesh is part of a wider container migration, our guide to assessing and moving applications to AWS containers covers broader workload preparation.

Compare migration paths by workload

AWS points Amazon ECS App Mesh users to ECS Service Connect and EKS users to VPC Lattice migration guidance. VPC Lattice is also a candidate for service connectivity across supported AWS compute types. These services have different scopes and operating models, so choose by workload and required behavior rather than by product-name similarity.

Workload Candidate to evaluate Boundary to account for
Amazon ECS services, on EC2 or Fargate Amazon ECS Service Connect is designed for communication between ECS services. VPC Lattice's ECS integration is another candidate when services need connectivity across supported compute types, VPCs, or accounts. AWS has App Mesh migration guidance for both paths. Service Connect is scoped to ECS services. VPC Lattice uses service networks and target groups instead of App Mesh's mesh and sidecar model. Check how each candidate's discovery, routing, TLS, observability, and deployment behavior matches the controls the application actually used in App Mesh.
Amazon EKS Amazon VPC Lattice through the AWS Gateway API Controller connects Kubernetes services using Kubernetes Gateway API resources. AWS's App Mesh migration guidance for EKS uses VPC Lattice. This is an EKS integration with VPC Lattice, not an automatic conversion of App Mesh resources or proof of feature parity. Map and test the Kubernetes routes, traffic policy, identity, and telemetry the application needs.
EC2 workloads VPC Lattice target groups support EC2 instances and private IP targets. Consider this when the required service flow and network placement fit Lattice's target and service model. EC2 target support does not mean ECS Service Connect applies to standalone EC2 services. Check target registration, VPC placement, protocols, routing, and security requirements.
Hybrid services across AWS and on-premises networks VPC Lattice can expose AWS services and resources reachable through a VPC, including on-premises resources using a resource gateway and network connectivity such as Direct Connect or Site-to-Site VPN. Design the VPC endpoints, gateways, resource configurations, and network path for the actual traffic direction. This is application networking, not a promise of a transparent mesh for arbitrary external workloads.

AWS's VPC Lattice migration article focuses on EKS and compares migration patterns; AWS has also published an ECS App Mesh-to-VPC Lattice migration example. Current AWS documentation lists Lattice target types including EC2 instances, IP addresses, ECS tasks, and Kubernetes Pods; EKS Pod integration uses the Gateway API Controller. For hybrid resource access, AWS documents VPC Lattice resources and resource gateways; its hybrid connectivity guidance describes the network path using Direct Connect or Site-to-Site VPN.

Why replacements are not feature-for-feature

App Mesh used workload-side Envoy proxies and mesh resources to control service traffic. ECS Service Connect is configured through ECS and connects ECS services. VPC Lattice provides services, listeners, target groups, service networks, and policies for application networking across supported AWS resources. Those different boundaries affect where traffic flows, how configuration is applied, and what an operator owns.

Compare concrete requirements before translating configuration. For example, VPC Lattice supports weighted target groups in listener rules, but that does not by itself reproduce every App Mesh virtual-router behavior. ECS Service Connect can be a simpler fit for ECS-to-ECS communication, but it does not cover EKS or standalone EC2 services. App Mesh's optional proxy-to-proxy mTLS, certificate handling, retries, telemetry, and shared-mesh account design also deserve explicit checks against the current target service documentation. Do not infer equivalence from a similar label such as “service mesh” or “service network.” VPC Lattice listener routing rules · VPC Lattice target group types

For each candidate, test the service-to-service paths and failure cases that matter to the application. Confirm which component performs discovery, load balancing, retries, authorization, encryption, and telemetry; then document any behavior that moves into application code, a load balancer, or a separate networking component.

Summary

Use retained configuration to reconstruct the application's discovery, routing, security, and observability requirements. Evaluate ECS Service Connect for ECS-to-ECS communication, VPC Lattice for suitable cross-compute and cross-network paths, and the EKS Gateway API integration or VPC Lattice targets where they fit. Validate each option against the required behavior; none should be assumed to reproduce every App Mesh control.