The change, and the date that matters
AWS will discontinue AWS App Mesh on September 30, 2026. After that date you will no longer be able to open the App Mesh console or access any App Mesh resource, and the Envoy data plane that App Mesh manages on your behalf stops being a managed service. This is not a price change or a feature deprecation that you can defer with a support ticket. It is a hard end of support for a control plane that sits directly in the request path of every service that depends on it.
The clock has actually been running for a while. AWS blocked new customer onboarding to App Mesh on September 24, 2024, and has been directing existing customers to migrate off ever since. So the population affected is bounded by definition: nobody new has joined in roughly two years, and adoption was already limited and shrinking before that. If you are reading this and you do not run App Mesh, you can stop here. If you do, the next several months are a real forced migration with a data-plane cutover, not a paperwork exercise.
Who is hit hardest, and why
The teams most exposed are the ones running App Mesh in production today on Amazon ECS or Amazon EKS with meshed virtual nodes, virtual routers, and routes wired into live traffic. The pain is proportional to how much of your routing logic lives in the mesh rather than in your application or your load balancer.
If you adopted App Mesh mainly for service discovery and simple east-west routing, your exit is comparatively shallow. If you leaned on it for weighted traffic shifting, retries, timeouts, header- and path-based routing, and mTLS between services, then that behavior has to be reproduced somewhere else before the cutover, and it has to be reproduced exactly, because subtle differences in retry or timeout semantics surface as production incidents under load, not in a smoke test.
The second group hit hardest is anyone treating this as a quiet background chore. App Mesh is in the data path. A migration that goes wrong does not degrade gracefully: it drops or misroutes live requests. That is what makes the date load-bearing.
The failure mode, in plain terms
There are two ways this bites a team. The first is the obvious one: do nothing, and on September 30, 2026 the managed control plane goes away. Existing Envoy proxies may keep running on last-known configuration for some time, but you can no longer change anything through App Mesh, you have no console, and you have no managed updates. You are now operating an unmanaged, frozen, unsupported data plane in production with no supported path to fix it.
The second failure mode is subtler and more common: a rushed migration. On ECS specifically, a service cannot be part of an App Mesh mesh and an ECS Service Connect namespace at the same time, so the service has to be recreated to move it. That recreation is the risky moment. If you try to flip everything at once near the deadline, you convert a planned change into an unplanned outage. The safe shape is a blue/green migration: stand up the new, unmeshed (or Service-Connect-enabled) version alongside the old one and shift traffic gradually, with a fast path back.
What to do before September 30, 2026
The goal for the remaining months is simple: get every App Mesh dependency off the mesh, with each cutover rehearsed and reversible. A senior approach treats this as a migration program, not a single change window. Mapping the mesh to your real traffic dependencies is exactly the kind of work that fits an AWS cloud management engagement, where the inventory and the cutover plan get owned end to end.
- Inventory every mesh resource: meshes, virtual nodes, virtual services, virtual routers, and routes, and map each one to the live services and traffic it actually carries today.
- Write down the behavior you are relying on per route: weighted splits, retries, timeouts, header and path matching, and any mTLS between services. This list is your acceptance criteria for the replacement.
- For ECS workloads, evaluate Amazon ECS Service Connect, which AWS names as the recommended replacement in the App Mesh end-of-support notice. Note that Service Connect reduces App Mesh's four abstractions to a simpler client/server model over a Cloud Map namespace, and manages the Envoy proxy for you.
- For EKS workloads, evaluate the targets that fit your routing needs. AWS's migration blog explicitly points EKS users toward Amazon VPC Lattice; a self-managed Envoy or Istio mesh is a common community path when you need full mesh features, but treat that as your own architectural choice rather than an AWS recommendation. Pick based on the behavior list above, not on what is trendy.
- Sequence the cutover service by service using blue/green: duplicate the service, shift a small percentage of traffic, watch error rates and latency, then ramp. Keep a one-step rollback for each service until it is fully drained from the old path.
- Set an internal deadline well before September 30, 2026 so the buffer absorbs the inevitable per-service debugging, and do the lowest-risk service first to calibrate effort.
One honest caveat, so we do not cry wolf
Two things keep this from being a five-alarm fire for the industry. First, the affected population is genuinely narrow: App Mesh onboarding has been closed since September 2024 and adoption was modest, so most AWS shops are simply not exposed. Second, AWS has stated it will continue to provide critical security and availability updates to App Mesh during this period up to the end-of-support date, so you are not unsupported tomorrow; you are unsupported after September 30, 2026.
One more nuance worth stating plainly: AWS's own documentation names Amazon ECS Service Connect as the recommended path, and its migration blog separately points EKS users toward Amazon VPC Lattice. A self-managed Istio or Envoy mesh is a legitimate destination, but treat that as your architectural choice, not an AWS recommendation. The fixed fact is only that App Mesh ends; where you land is your call, and it should follow the behavior you actually need.
How a senior team de-risks the cutover
The difference between a calm migration and a deadline scramble is almost entirely front-loaded work. A senior DevOps team starts from the dependency map, not the tooling, so the replacement is chosen against documented routing behavior rather than guessed at. It migrates the least-risky service first to measure true effort per service, then schedules the rest with margin against the September 30, 2026 date. Every cutover is blue/green with a tested rollback, and traffic moves in small increments while error rate and latency are watched in real time. This is the same disciplined-cutover posture we described for the EKS lifecycle in the analysis of EKS 1.33 extended-support cost: know the date, do the boring inventory early, and never let a managed-service end-of-life turn into an unplanned production event.
Sources
Talk to the engineer who will own your stack.
No account managers, no offshore handoff. Senior DevOps, direct. Tell us what you are dealing with and you get a straight answer.
Related News
Azure Returns 410 Gone for GPT-4o on October 1 and Auto-Upgrade Skips the Deployments That Matter
On October 1, 2026, Azure OpenAI in Microsoft Foundry retires the GA gpt-4o (2024-11-20) and gpt-4o-mini (2024-07-18) versions, after which calls to a retired deployment return HTTP 410 Gone. Standard-family deployments are auto-upgraded region by region, but Provisioned (PTU) deployments and anything set to NoAutoUpgrade are not, and Microsoft says the date is not extendable.
CloudStay on EKS 1.33 and AWS Starts Billing You 6x From August
Amazon EKS Kubernetes 1.33 leaves standard support on July 29, 2026, and any cluster still on it is enrolled in extended support by default at six times the standard control-plane rate. The hourly charge rises from 0.10 to 0.60 US dollars per cluster, and the standard patch cadence narrows. Fleets with many clusters feel it first.
CloudRDS MySQL 8.0 Leaves Standard Support in July and AWS Auto-Enrolls You Into a Paid Bill
Amazon RDS for MySQL 8.0 reaches end of standard support on July 31, 2026. The next day, AWS automatically enrolls any instance still on 8.0 into paid Extended Support, billed per vCPU-hour, unless you set the disabled lifecycle flag at creation or restore. The fix is an in-place upgrade to MySQL 8.4 before the date.