AWS App Mesh Is Being Discontinued September 30, 2026: What to Migrate To (and What Breaks)

AWS App Mesh Is Being Discontinued September 30, 2026: What to Migrate To (and What Breaks)

On September 30, 2026, AWS discontinues AWS App Mesh entirely. This isn't a maintenance-mode freeze like Bedrock Agents Classic — after that date you lose console access and API access to your App Mesh resources completely. If you're running App Mesh in production, that's roughly seven weeks from this post to plan and execute a real migration, not just read about one someday.

What actually happens on September 30

AWS stopped accepting new App Mesh customers back on September 24, 2024. Existing customers have been able to keep creating meshes, virtual services, and routes normally since then, and AWS has kept shipping critical security and availability patches. That ends on September 30, 2026: no console, no API access to App Mesh resources, full stop. There's no allowlist-based exception path here the way there was for Bedrock Agents Classic — every App Mesh customer is affected on the same date.

If you're running ECS workloads through App Mesh, AWS's stated migration target is Amazon ECS Service Connect. If you're on EKS, the recommended path is Amazon VPC Lattice. Both are real, current AWS services — not community projects — but neither is a drop-in replacement, and the gaps matter more than the marketing copy suggests.

Why you can't just flip a switch

The single most important constraint: an ECS service can't be part of an App Mesh mesh and a Service Connect namespace at the same time. You're not editing a service in place — you're recreating it under the new networking model, one service at a time, while the old and new versions run side by side. AWS's own guidance recommends a blue/green cutover: stand up the Service Connect version alongside the App Mesh version, then shift traffic gradually using Route 53 weighted routing, CloudFront continuous deployment, or Application Load Balancer target group weighting, watching Service Connect's CloudWatch metrics as you go.

There's also no cross-environment networking between an App Mesh mesh and a Service Connect namespace during the transition — a service still in App Mesh can't discover a service you've already moved to Service Connect through either system's native service discovery. If your migration spans multiple services that talk to each other, sequence it so tightly coupled services move together, or expect a window where they can't reach each other through mesh-native discovery at all.

What you lose moving to ECS Service Connect

Service Connect is a real upgrade in some ways — it's a fully managed proxy (no sidecar containers to patch and redeploy yourself), CloudWatch application-level metrics are included at no extra charge, and TLS setup is simpler using AWS Private CA's shorter-lived certificates. But it's meaningfully less capable than App Mesh in a few specific areas that are easy to miss until you're mid-migration:

App Mesh capabilityService Connect equivalent
Virtual Router: granular multi-version, weighted, header-based routingNot supported — Service Connect doesn't do fine-grained traffic splitting
Configurable outlier detection and retry tuningOpinionated defaults; only timeouts are configurable
Mutual TLS (two-way peer authentication)Not yet available on Service Connect
Cross-account mesh sharing via AWS RAMNot supported — Service Connect namespaces don't span accounts

If your App Mesh setup leans on any of these — canary deployments via Virtual Router weights, custom retry budgets per route, mTLS between specific services, or a mesh shared across accounts via RAM — Service Connect doesn't have a like-for-like answer today. Plan around the gap rather than assuming it'll show up before your deadline.

EKS workloads: VPC Lattice, not Service Connect

Service Connect is ECS-specific. If your App Mesh usage is on EKS, AWS's guidance points to Amazon VPC Lattice instead — a separate service that operates at the VPC level rather than inside a single ECS cluster's task networking. Lattice supports weighted target groups across services, which recovers some of the multi-version routing App Mesh's Virtual Router gave you, but the underlying model (a Lattice service network mapped onto your VPC) is different enough from App Mesh's mesh-of-virtual-services model that this is a real re-architecture, not a config swap. Budget time to actually read VPC Lattice's routing and auth model before you start moving EKS services, rather than assuming it maps 1:1 onto what you already have.

Best practices for the migration

  • Inventory what you actually use App Mesh for before picking a target. A mesh that's just doing basic service discovery and load balancing moves to Service Connect (or Lattice, on EKS) easily. A mesh doing weighted canary routing, custom retry tuning, or mTLS needs a harder look at whether Service Connect covers your case at all right now.
  • Migrate loosely-coupled services first. Since there's no cross-environment discovery during the transition, start with services that don't have many in-mesh dependencies, and save tightly-coupled service groups for a coordinated, planned cutover window.
  • Use the blue/green pattern AWS recommends, not a big-bang cutover. Stand up Service Connect (or Lattice) versions alongside the App Mesh versions and shift traffic gradually with Route 53 weighted routing or ALB target group weights, watching CloudWatch the whole way.
  • If you rely on mTLS today, treat that as your real blocker, not September 30 itself. Service Connect doesn't have it yet — decide now whether you're waiting, building an interim solution, or accepting a temporary security-posture change, rather than discovering this gap during the week of the deadline.

Common mistakes to avoid

  • Assuming this is a maintenance-mode freeze, like Bedrock Agents Classic. It isn't — App Mesh access ends completely on September 30, for every customer, with no allowlist exception.
  • Trying to migrate a service in place. A service can't be in both an App Mesh mesh and a Service Connect namespace simultaneously — you're recreating it, not editing it.
  • Assuming Service Connect replaces every App Mesh feature. Virtual Router-style weighted/header routing, tunable outlier detection, mTLS, and cross-account mesh sharing don't have direct equivalents today.
  • Moving tightly-coupled services independently and expecting them to still discover each other. There's no cross-environment discovery between App Mesh and Service Connect during the transition window.

Troubleshooting

Services can't reach each other after partially migrating. Check whether one service is still in the App Mesh mesh while its dependency has already moved to Service Connect — that pairing has no native cross-environment discovery. Migrate them together, or add an explicit bridge (e.g., an ALB) for the transition window.

Trying to replicate weighted canary routing on Service Connect and finding no equivalent setting. There isn't one yet. Use ALB target group weighting or Route 53 weighted routing as the traffic-splitting layer instead of expecting Service Connect itself to do it.

mTLS requirement blocking your migration timeline. This is a known, current gap in Service Connect. Either scope those specific services out of this migration wave and handle them separately, or evaluate whether your compliance requirement can tolerate an interim state while you wait for the feature.

FAQ

Is this the same kind of change as the Bedrock Agents Classic maintenance mode? No. Bedrock Agents Classic keeps working forever for existing users with no forced deadline. App Mesh access ends completely for everyone on September 30, 2026.

Do I have to migrate all my services at once? No, and you shouldn't — AWS's own guidance is a gradual blue/green migration, service by service, with traffic shifted incrementally.

What if I'm on EKS, not ECS? Your migration target is Amazon VPC Lattice, not ECS Service Connect. The two AWS services solve the same problem for different container platforms.

Does Service Connect support mutual TLS? Not yet, as of this post. If mTLS between services is a hard requirement for you, that's the gap most likely to actually block your timeline — plan for it explicitly.

Can I keep using App Mesh past September 30 if I really need to? No — console and API access to App Mesh resources ends on that date for all customers. There's no extension or allowlist path like the Bedrock Agents Classic maintenance-mode allowlist.

Key takeaways

If you are...What to do
Running App Mesh on ECSMigrate to ECS Service Connect, service by service, blue/green
Running App Mesh on EKSMigrate to Amazon VPC Lattice instead — different service, different model
Using Virtual Router weighted/header routingReplace with ALB target group weights or Route 53 weighted routing
Relying on mTLS between servicesTreat this as your real blocker — not yet supported on Service Connect
Sharing a mesh across AWS accounts via RAMNo Service Connect equivalent — plan an account-level workaround

Further Reading