AWS App Runner Availability Change: How to Migrate to ECS Express Mode Before April 30, 2026

On March 31, 2026, AWS said App Runner will stop accepting new customers on April 30, 2026. Existing App Runner customers can keep using the service, create new App Runner services, and keep running what they already have. The bigger change is strategic: AWS also said it does not plan to introduce new features, and it now points teams to ECS Express Mode as the recommended migration path.

That is not the same thing as an immediate shutdown. Your current App Runner services do not disappear on May 1. But if you are still standardizing on App Runner for new projects, the message is pretty clear. The simple-path container platform on AWS is shifting toward ECS Express Mode.

What actually changed on April 30, 2026

The confusing part is that three different groups are affected differently.

That last row is the one that matters most. If you are a platform team, you should stop treating App Runner as the long-term default. If you are a small team with one or two stable services already running there, you probably do not need a panic migration this week.

If you want the detailed App Runner operating model before deciding, the existing AWS App Runner guide still holds up. The availability change is about new customer access and roadmap direction, not about the runtime failing tomorrow.

Why AWS is pushing ECS Express Mode

AWS is making the same recommendation in more than one place now. It did it in the App Runner availability guidance, and it did it again in the AWS Copilot CLI migration guide. That tells you a lot.

ECS Express Mode keeps the “give AWS a container and a couple of roles” experience that made App Runner attractive, but it does it on top of ECS primitives that AWS is actively investing in. You still get the managed load balancer, HTTPS endpoint, auto scaling, and simplified deployment path. The difference is that you land on a platform that fits the rest of the ECS ecosystem instead of a narrowing side branch.

Here is the short version.

That does not mean ECS Express Mode replaces every App Runner use case perfectly on day one. It means AWS has chosen where future simplicity work will accumulate.

When you should migrate now

You should move sooner rather than later if any of these apply:

• You are onboarding new AWS accounts after April 30, 2026.
• You are standardizing deployment patterns across several teams.
• You need closer alignment with ECS capabilities like Service Connect or deeper container networking control.
• You already have App Runner services, but you know more services are coming and you do not want two separate operating models.

You can slow down if the workload is low-risk, stable, and already paid for in operational simplicity. I would still set a migration target, though. “We will decide later” usually turns into “we forgot this existed.”

A clean migration path to ECS Express Mode

The App Runner migration docs recommend a blue/green cutover using DNS weighting. That is the right approach. It keeps rollback simple and avoids turning a platform migration into an outage story.

1. Inventory what App Runner is doing for you

Before touching anything, capture:

• container image and tag strategy
• CPU and memory sizing
• environment variables and secrets
• custom domain setup
• VPC connector usage
• scaling configuration

This sounds obvious, but migration projects get messy when teams discover half the runtime settings only after the first cutover test.

2. Recreate the service in ECS Express Mode

ECS Express Mode is good precisely because it does the boring parts for you. It provisions the ECS service, load balancer, networking, and scaling path in your own account. If your team already uses AWS CodePipeline and CodeBuild or GitHub Actions for delivery, this usually fits cleanly into the existing release flow.

3. Reconnect the domain

This is where many migrations go wrong. Custom domains are often treated as a last step, but they are part of the rollback plan. Create the new service, validate the domain path, and only then start traffic shifting.

4. Shift traffic gradually

Weighted DNS is slower than flipping one record, but it gives you something more valuable: time to notice a bad assumption. Start small. Watch health checks, latency, and logs. Increase traffic only after the new service behaves like the old one.

5. Retire App Runner only after rollback confidence is real

Keep the old service around through at least one normal traffic cycle. A migration that looks good at noon can still fail at the nightly batch window.

Where teams usually get surprised

The first surprise is cost shape. App Runner felt simple because AWS hid a lot of infrastructure detail. ECS Express Mode is still simple, but it makes the ECS foundation a more explicit part of your world. That is good for portability and future features, but it also means teams should understand where the service boundaries actually sit.

The second surprise is that “existing customers can continue as normal” is not a reason to avoid planning. It just means AWS gave you breathing room. Use it.

The third surprise is process drift. If one group keeps deploying to App Runner while another starts new services on ECS Express Mode, you end up with duplicated docs, duplicated templates, and duplicated operational habits. That is exactly the kind of slow mess platform teams should eliminate.

My recommendation

If you are choosing a platform for new request-driven container services on AWS in late April 2026, pick ECS Express Mode. If you already have App Runner in production, migrate deliberately instead of urgently, but do not pretend the direction is ambiguous.

App Runner is still a running service. It is just no longer the place AWS seems interested in expanding. That distinction matters.

For the deeper container path after migration, read Amazon ECS Service Connect and the Copilot migration guide. If you are evaluating the operating model from scratch, keep the older AWS App Runner guide in view as the baseline you are moving away from.