App Runner is Dead, but all is not lost

The End of AWS App Runner: Losing the “App Service” of the AWS World

For years, developers moving from Azure to AWS asked one specific question: “Where is the App Service?” Azure App Service is legendary for its simplicity. You point it at a repository, and within minutes, you have a scaled, HTTPS-secured web application or API without ever looking at a virtual network or a load balancer. For a long time, AWS didn’t have a direct answer. Then came AWS App Runner.

App Runner was the closest thing we had to that “magic” experience. It was the go-to for Web APIs and Blazor apps, providing a high-level abstraction that felt human-centric rather than infrastructure-centric. But as of April 30, 2026, AWS has officially stopped accepting new customers for App Runner, moving it into “maintenance mode.” This news has sparked significant discussion across the developer landscape, notably in articles like AWS App Runner Is Dead — Here’s What You Should Use Instead (2026) on the DEV Community.

Why App Runner was the “Missing Link”

For many of us, App Runner was the sweet spot.

Blazor & Web APIs: It handled stateful-feeling connections and long-lived requests beautifully, making it perfect for .NET developers.
Zero-Config Scaling: You didn’t need to define scaling policies in CloudWatch; it just worked based on request concurrency.
Managed TLS: No messing around with Certificate Manager and Load Balancer listeners.

The Elephant in the Room: Networking & Internal IPs

One of the most frequent criticisms of App Runner (and a likely reason for its lack of dominance) was its networking model. In its early days, App Runner was essentially “public by default.”

If you had a private microservice or a database with an internal AWS IP, App Runner struggled to “see” it without a complex VPC Connector. For many developers, the friction of setting up these connectors was so high that they often resorted to making their internal APIs public (secured by tokens) just to get them to talk to App Runner. Compared to Azure’s seamless VNet integration, this was a major disappointment and a security headache that arguably stunted App Runner’s growth.

The Future: Amazon ECS Express Mode

AWS is now pointing everyone toward Amazon ECS Express Mode. This is essentially AWS’s “Easy Button” for the Elastic Container Service.

How it compares to App Runner:

Feature	App Runner	ECS Express Mode
Simplicity	High (Managed Service)	High (Automated Setup)
Control	Limited	Full (It’s still just ECS)
Networking	Rigid/Complex	Native VPC Integration
Costs	vCPU/RAM active billing	Standard Fargate + ALB costs

Why Express Mode wins: Unlike App Runner, which was a “black box,” Express Mode simply automates the creation of standard ECS resources (Fargate, ALBs, Security Groups) in your account. If you ever outgrow the “Express” settings, you don’t have to migrate; you just start editing the ECS service directly. It also solves the networking issue from day one because it lives natively inside your VPC.

Final Thoughts

It’s disappointing to see App Runner go. It represented a shift toward developer experience that AWS often lacks. However, if ECS Express Mode can truly deliver that “one-click” experience while maintaining the power of ECS, it might finally be the App Service competitor we’ve been waiting for.

If you’re looking for a deep dive into how to make this transition, check out this overview of ECS Express Mode on YouTube which breaks down the architectural shift.

If you’re running App Runner today, don’t panic—your services will stay up. But for your next project, it’s time to look at the Express lane.