Skip to content

Build1 publisher2 min readPublished

A reviewed cut plan caught the App Mesh migration's problems before deployment did

AWS ends App Mesh support in September 2026. One team scored the replacements on weighted criteria, wrote a rollback for every step, and moved about 40 services in two phases with no outage.

The Engineer · Build desk

Illustration accompanying A reviewed cut plan caught the App Mesh migration's problems before deployment did

What happened

  • AWS is retiring App Mesh with end of support in September 2026, and the team's entire platform ran on it, so the move was not optional.
  • A reviewed plan document set the order of services, the prerequisites, the exact steps for one service, the rollback at every step, and the first step that could not be undone.
  • Almost every problem described in the write-up was found during planning rather than during deployment, and the team calls the plan the project's best investment.
  • The migration of around 40 microservices across three environments and multiple regions finished with no outage and no major incident.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

  • constraint The September 2026 date sets the pace for every App Mesh user, so the work competes for the same engineers as roadmap features on a calendar nobody in the team chose.
  • capability Splitting the edge from the mesh means a gateway upgrade no longer requires touching the data plane of any service, and a mesh upgrade no longer requires touching ingress.
  • cost Moving mTLS from a per-pod sidecar to a per-node proxy shifts the overhead onto node count, so anyone budgeting the saving has to measure their own pod density first.
  • precedent Sequencing the reversible phase first, with the old gateway kept idle as the rollback target, is the transferable part of this plan for anyone running two meshes side by side.

Phase 1 moved external traffic off the App Mesh Virtual Gateway and onto a Kubernetes gateway speaking the Gateway API, and every sidecar stayed exactly as it was [9][11]. Service to service traffic did not change [11]. The step is cheap to undo because the rollback is pointing ingress back at the old gateway, and the team left that gateway running with no traffic on it for a long time [12].

External traffic used to reach a service through API Gateway, then a VPC Link, then an internal NLB, then the App Mesh Virtual Gateway [8]. Phase 1 swaps out that last hop and leaves the rest of the chain alone.

Phase 2 took services off their App Mesh sidecars in waves [13]. Under App Mesh every pod ran an Envoy sidecar injected by the controller, and mTLS used certificate files mounted into that sidecar [6][7]. Ambient mode instead runs one proxy per node, called ztunnel, which terminates mTLS for every pod on that node [14]. The team credits the change with removing duplicated CPU and memory across the fleet and with ending the sidecar lifecycle problems they had in jobs [14][15]. How much of the first gain transfers depends on how many pods share a node, and the post does not publish before-and-after CPU or memory figures.

The first blocker was trust. The old mesh authenticates with certificate files issued by its own CA [16]. For the length of phase 2 the two meshes run side by side while services move one at a time, and the post calls working that out the hard part [17].

Around 40 microservices, three environments, multiple AWS regions [5]. Forty services across three environments is 120 service-environment cutovers before regions multiply anything [20]. The team went slowly over a few months on purpose, choosing safety over speed [5].

The routing config is now in Gateway API, a Kubernetes standard instead of a cloud provider format, and it gave them traffic mirroring and A/B testing they did not have before [10]. The evaluation that got them there was written up as a decision record: candidates listed, criteria weighted by what mattered to them, every option scored, then a proof of concept for the shortlist [3]. Istio Ambient Mesh came out on top [4].

The account is self-reported and gives no count of the problems the plan caught, though it is specific about where they were caught. "Finding them on paper is much cheaper than finding them in production," the post said [18].

What to watch

  • Whether the team publishes pods-per-node and CPU or memory figures that would let others price the sidecar-to-ztunnel saving.
  • How the certificate trust gap between the App Mesh CA and ambient mesh was bridged while both meshes carried traffic.
  • Whether AWS ships a migration path or tooling for App Mesh users before the September 2026 end of support.
Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories