For a few years, AWS App Runner was the answer I gave to anyone who asked how to run a container on AWS without learning half of the platform first. You pointed it at an image or a repository, it gave you a URL with TLS, and it even scaled to zero-ish levels of cost when nobody was visiting. It was the closest thing AWS had to the developer experience of Cloud Run or Fly.io.
That chapter is closing. AWS announced that App Runner will no longer accept new customers after April 30, 2026. Existing customers can keep using it, and AWS says it will continue investing in security and availability, but there will be no new features. Several managed runtime versions already reached end of support in December 2025. In practice this is the long goodbye that AWS gives services it has decided against, the same pattern we saw with CodeCommit and Cloud9. If you are starting something new in 2026, App Runner is off the menu, and AWS itself points you toward a newer capability called Amazon ECS Express Mode.
So the question I want to work through in this post is a practical one. When you sit down to build a new serverless application on AWS in mid-2026, what do you actually reach for? The landscape shifted more in the past year than in the previous three, and the honest answer is more interesting than "just use Lambda."
What the end of App Runner tells us
Before the decision guide, it is worth pausing on why this happened, because it changes how I evaluate the alternatives.
App Runner was a black box by design. The load balancer, the VPC, the scaling policy, the deployment pipeline were all hidden inside the service. That opacity was the selling point and also the trap. The moment your requirements grew past what the box exposed, say a WebSocket workload, a custom health check pattern, or a specific networking setup, you had to migrate off entirely, because there was no escape hatch into the underlying resources.
ECS Express Mode, announced at re:Invent 2025, takes the opposite approach. You make a single call with a container image and two IAM roles, and ECS provisions a complete stack in your own account: a Fargate service, an Application Load Balancer, auto scaling, security groups, HTTPS, and CloudWatch wiring. The resources are real and visible. When you outgrow the defaults, you edit the resources rather than abandon the service. AWS shares one ALB across up to 25 Express services to keep the fixed cost sane, and Express Mode itself adds no charge on top of the resources it creates.
The lesson I take from this pair of decisions is that AWS has concluded opaque PaaS abstractions do not survive on their platform, while transparent ones might. That is a useful filter for everything else in this post.
The 2026 Lambda is not the Lambda you remember
The bigger story of the past year is how much ground Lambda itself has covered. Three announcements from re:Invent 2025 matter for architecture decisions, not just for release-notes trivia.
The first is durable functions. Lambda can now run multi-step workflows that survive interruptions and pause for up to a year, using a checkpoint and replay mechanism exposed through an SDK for Python, TypeScript, JavaScript, and Java. You write ordinary sequential code, wrap side effects in steps, and suspend on waits or callbacks. While the function is suspended you pay nothing for compute. This dissolves a whole category of architectures where we previously glued Lambda to Step Functions purely to get waiting and retry semantics. I go deep on one use of this, human approval gates for AI agents, in a companion post.
The second is managed instances. You can now tell Lambda to run your function on EC2 instances in your account, choosing the instance types and fleet bounds, while Lambda keeps handling patching, load balancing, scaling, and the runtime. This exists for workloads that never fit the 15-minute, per-request model: steady high-throughput services where EC2 pricing beats per-invocation pricing, or code that needs specific hardware. Rust support arrived in March 2026 and can process requests concurrently within one instance, which changes the economics again for CPU-bound work.
The third group is quieter but useful. Async invocation payloads went from 256 KB to 1 MB, SQS event source mappings gained a provisioned mode for predictable latency at high throughput, and the runtime lineup moved forward to Python 3.14, Node.js 24, and Java 25. None of these change your architecture on their own, but each one removes a workaround you may still be carrying.
How I actually decide now
With App Runner out and Lambda enlarged, my decision process in 2026 comes down to a handful of questions asked in order.
The first question is whether the unit of work is a request that finishes in seconds. If yes, Lambda remains the default, and the case for it is stronger than ever. Scale to zero, per-request billing, and now the option to keep long business processes inside the same programming model through durable functions. Most APIs, event handlers, and glue code land here and never need to leave.
The second question is whether you have a containerized web application that wants to stay a container. A Rails or Django app, a Next.js server, anything that assumes a long-lived process and does not decompose naturally into functions. This is where App Runner used to live, and ECS Express Mode is now the honest successor. Two caveats deserve attention before you commit. Express Mode deploys pre-built images only, so you need a build-and-push pipeline, typically GitHub Actions into ECR, where App Runner could build straight from source. And Fargate does not scale to zero, so a hobby project that App Runner ran for pocket change will have a real monthly floor on Express Mode. For genuinely idle side projects, a Lambda function with a web adapter or a different platform entirely may serve you better.
The third question is whether the workload is a long-running process rather than a workflow. Something that streams, holds connections open, or churns through a queue continuously. That was never App Runner territory anyway; plain ECS on Fargate handles it, and Lambda managed instances are now a legitimate alternative when you want Lambda's operational model with server-shaped economics.
The last question is about orchestration, and here the line has genuinely moved. Step Functions still earns its place when the workflow spans many AWS services, when you want the visual state machine as living documentation, or when non-developers need to reason about the flow. But when the workflow is really just your application logic with retries and waits, durable functions let you keep it in code, in one place, in a language your team already writes. My rule of thumb after a few months: if I would have drawn the state machine mostly as a straight line with one or two branches, it becomes a durable function now.
A worked example
To make this concrete, consider a fairly typical product: a web frontend, an API, an occasional heavy job, and a payment flow that needs a human in the loop for large amounts.
In 2024 I would have put the frontend on App Runner or Amplify, the API on Lambda behind API Gateway, the heavy job on Fargate, and modeled the payment flow as a Step Functions state machine with a task token wait. In 2026 the frontend container goes to ECS Express Mode, the API stays on Lambda, the heavy job stays on Fargate or moves to a managed-instances Lambda if it is bursty, and the payment flow collapses into a single durable function that suspends on a callback until a human approves. One fewer service to operate, one fewer DSL to maintain, and the waiting costs nothing while it waits.
Closing thoughts
The uncomfortable part of writing a guide like this is knowing that App Runner had guides like this written about it too. Services end; the skill is in noticing which properties of a service are durable and which are fashion. Resources you can see and take over, as with ECS Express Mode, age better than boxes you cannot open. Programming models that absorb complexity into ordinary code, as durable functions do, age better than external orchestrators for logic that was always yours. Those two bets feel safe for 2026. Ask me again in three years.
Sources: the App Runner availability change notice, the Lambda durable functions documentation, and the re:Invent 2025 serverless announcements.
Top comments (0)