AWS App Mesh support ends on 30 September
AWS App Mesh reaches end of support on 30 September 2026. Applications still depending on its routing, discovery and Envoy configuration need a replacement architecture, a migration route and clear operational ownership now.
- Author
- Intercube
- Published
- Reading time
- 8 min read
01
The support deadline is 30 September
AWS will discontinue App Mesh on 30 September 2026. Until that date, existing users can operate the service and receive critical security and availability updates. After the deadline, teams should not expect the managed control plane or its support path to remain available for production operation.
App Mesh sits between application services and the network paths they use. It can carry service discovery, traffic routing, retries, health checks, encryption and observability through Envoy sidecars. Replacing it is therefore not a resource rename. The migration changes how services find one another and how operators see and control traffic.
A late inventory is the first risk. Teams need to identify meshes, virtual services, nodes, routers, routes, Cloud Map namespaces, certificates, Envoy settings and dashboards, then map each dependency to the target platform. Undocumented traffic rules become migration blockers when the deadline is already close.
02
Choose the destination from the workload
AWS recommends ECS Service Connect for services running on Amazon ECS and points EKS users towards Amazon VPC Lattice. The target should follow the application and its operating model. Moving an ECS estate to Service Connect can reduce proxy management, while a multi-account or Kubernetes architecture may need different boundaries and capabilities.
Service Connect provides managed service discovery, traffic health, retries and CloudWatch metrics. It does not reproduce every App Mesh capability. App Mesh allows finer routing between virtual nodes, more configurable Envoy behaviour, mutual TLS patterns and cross-account mesh sharing that may not map directly to Service Connect.
List the behaviours the application actually uses before selecting the replacement. A platform that is simpler to operate can be a strong improvement, but only when missing features are either unnecessary or deliberately redesigned. A feature checklist without traffic and failure scenarios hides the most important differences.
- Map every App Mesh resource to the application service and owner that depends on it.
- Record routing, retry, timeout, certificate and observability behaviour before redesigning it.
- Compare account boundaries and service discovery requirements with the target platform.
- Remove unused mesh complexity instead of recreating every historical setting automatically.
03
Plan a parallel migration
An ECS service cannot participate in App Mesh and a Service Connect namespace at the same time. AWS therefore recommends a blue-green approach that creates the target services separately and shifts traffic after validation. The old and new environments coexist at the edge while each request remains inside one service-discovery boundary.
Build the target from infrastructure code, deploy the application and dependencies, then verify service discovery, health checks, certificates, timeouts, retry behaviour and telemetry before increasing production traffic. Route 53 weighted records, CloudFront continuous deployment or Application Load Balancer target groups can support a gradual shift where the architecture permits it.
A rollback must reverse traffic without depending on the new mesh. Define the signal that stops the migration, preserve logs and metrics from both environments and test the route before customer traffic moves. The support deadline should create urgency, not remove the controls that make a production migration safe.
- Create the replacement environment independently from the existing mesh.
- Rehearse service-to-service calls and failure behaviour before external traffic moves.
- Shift traffic in measured steps with comparable health and application metrics.
- Keep a tested rollback route until the new environment has passed an agreed observation period.
04
Use the deadline to fix ownership
App Mesh end of support exposes more than a technical dependency. It shows whether anyone owns the service lifecycle, reads deprecation notices, can reproduce the environment and has authority to coordinate application and infrastructure changes. Without that ownership, the next AWS retirement will create the same emergency.
Managed AWS should include this lifecycle work. A responsible partner inventories the affected services, designs the target, codifies the infrastructure, coordinates deployment, watches the migration and operates the result. Merely reselling AWS capacity leaves the difficult and time-sensitive work with the application team.
Intercube can take on that engineering and operating responsibility for managed AWS environments. If the present architecture no longer justifies its complexity, we can also assess a simpler Intercube hosting target and perform the migration without a separate migration fee. The right destination is the one that preserves application requirements with the least unnecessary operational burden.
App Mesh migration priorities
- Treat 30 September 2026 as an operational deadline, not the start of discovery.
- Inventory routing, discovery, certificates, observability and account boundaries before choosing a target.
- Use ECS Service Connect or VPC Lattice only after checking the capabilities the workload actually needs.
- Create a parallel target and shift traffic gradually with a tested rollback path.
- Assign long-term ownership for AWS service lifecycles after the migration completes.