Deploying FastAPI and Next.js to AWS App Runner vs. ECS Fargate: When Managed Wins

I've spent 25+ years building and shipping SaaS products, split recently between leading engineering on the AppSumo marketplace at Sumo Group — real scale, real traffic — and running my own small stack of side projects as a solopreneur ops team. Those two worlds teach you very different lessons about AWS. At scale, you can justify a platform team babysitting ECS Fargate task definitions. As a solopreneur, you cannot — and you shouldn't want to.

This article addresses a decision I see engineers agonize over far more than necessary: should you deploy your FastAPI backend and Next.js frontend to AWS App Runner or ECS Fargate? I'll give you my honest, opinionated answer, and walk through the adjacent complexity that trips people up during rollout — what "managed" actually buys you, when it stops being enough, and one piece of news that changes this decision for anyone starting fresh today.

Important update: App Runner is moving to maintenance mode

Before you commit to either path, know this: as of the AWS service availability update published March 31, 2026, App Runner stopped accepting new customers on April 30, 2026. If you already run services on App Runner, nothing breaks — AWS says existing customers can keep creating new services and resources normally, and will keep investing in security and availability. But no new features are planned, and AWS's own guidance points new workloads toward Amazon ECS Express Mode instead, a newer capability inside ECS itself that was announced at re:Invent 2025 and is explicitly positioned as App Runner's replacement.

Practically, this means:

• If you're starting a brand-new project today, App Runner is no longer an option — new accounts can't provision it. This article's comparison is still valuable for understanding why App Runner made certain trade-offs (and ECS Express Mode inherits most of them), but the actual button you'll click for a fresh FastAPI/Next.js deploy is now ECS Express Mode, not App Runner.
• If you already have App Runner services running, you're fine for now, but you're on a service AWS has signaled it will stop actively developing. Runtime versions (Python, Node) will lag, integrations with newer AWS features won't reach parity, and support headcount on the team will shrink over time. This is the "maintenance mode" pattern AWS has run before — existing workloads honored, no urgency to migrate immediately, but plan a path off within the next 6–12 months if you're running anything you care about.
• ECS Express Mode is designed to feel like App Runner — point-and-deploy simplicity — while sitting on top of full ECS/Fargate underneath, meaning you get an on-ramp to the harder ECS primitives (multi-container tasks, VPC control, service discovery) without a full re-platform later. If you're choosing between "managed simplicity" and "Fargate control" today, ECS Express Mode is very likely where AWS wants you to land regardless of which side of this argument you were on.

Everything below explains the underlying trade-offs — App Runner vs. Fargate — because the reasoning transfers directly to ECS Express Mode vs. "full" Fargate, even as the specific product name shifts.

Why "App Runner" (or its successor) at all?

App Runner was AWS's answer to "I have a container, or I have source code, please just run it." You provide a Dockerfile (or point it at a repo), and it handles the load balancer, TLS certificate, auto-scaling, health checks, and deployment pipeline. No VPC wiring required, no hand-authored task definition JSON, no cluster sizing or patching. You push, it builds, it runs, it scales — and for idle periods, it can scale down to zero compute cost depending on your configuration.

ECS Fargate pitches the same "serverless containers" story but leaves you responsible for the scaffolding: the Application Load Balancer, target groups, security groups, service discovery for cross-service calls, the cluster itself, and a task definition schema that's powerful but genuinely finicky to get right initially. Fargate excels at "I need fine-grained control over networking, sidecars, and multi-service orchestration." The managed layer — App Runner historically, ECS Express Mode going forward — excels at "I need my API and frontend running reliably without becoming an infrastructure hire."

For a FastAPI backend and Next.js frontend — one of the most common pairings I see — the managed path is frequently the correct default. Not because Fargate is bad, but because most such applications don't actually need what Fargate is good at. They need a container that runs, scales with traffic, and doesn't page you at 2 a.m. because a cluster ran out of capacity.

Benefits of the managed model (App Runner's, inherited by ECS Express Mode)

Deployment simplicity. You connect a repository or push to ECR, the platform builds and deploys, and you get a URL with HTTPS already configured. Your Dockerfile — uvicorn behind a production ASGI setup, gunicorn worker config, whatever you prefer — is genuinely the only artifact you need to think about. For Next.js, you're not hand-rolling a CDN + Lambda@Edge + S3 origin setup unless you specifically want that control level.

Auto-scaling without configuration spelunking. App Runner scaled on concurrent request count out of the box — set a max and min, done. Fargate can do this too, but you're wiring it through Application Auto Scaling policies tied to CloudWatch metrics — CPU, memory, or custom metrics — which is more powerful but also more surface area for misconfiguration. I've watched teams over-provision (paying for unused headroom) or under-provision (dropping requests during spikes because the scaling policy's cooldown was tuned for a different workload).

No cluster to operate. With Fargate you're still nominally "serverless," but you own the ECS cluster construct, the service definition, and the interplay between desired count, deployment circuit breakers, and rolling update percentages. App Runner removed that layer entirely — there was no cluster, just a service that either had traffic going to healthy instances or didn't. ECS Express Mode's whole pitch is preserving that same "no cluster to think about" feel while running on real ECS underneath.

Built-in observability basics. App Runner shipped with default CloudWatch integration for logs and metrics without you wiring a log driver into a task definition. It's not a replacement for real observability tooling, but it removes day-one friction around seeing your application's output.

Cost model matching small-to-mid workloads. Because the managed tier scales down aggressively and prices by provisioned compute, it tends to be cheaper for spiky or low-traffic workloads than running a Fargate service with a minimum task count of two sitting mostly idle.

None of this means the managed path is strictly better. It wins for a specific, very common shape of application: a couple of services, standard HTTP traffic patterns, no exotic networking requirements, and a team preferring to spend engineering hours on the product rather than the platform.

Where ECS Fargate (the full, unmanaged kind) still wins

You want full Fargate control over App Runner or ECS Express Mode when:

• You need multiple containers cooperating in a single task (sidecars for logging agents, service meshes, co-located caches).
• You need fine-grained VPC networking control — multiple subnets, custom routing, peering, or strict security group topology that the managed model's networking doesn't expose.
• You're running background workers, queue consumers, or scheduled jobs alongside your web service and want them orchestrated as part of the same platform.
• You have compliance or architectural requirements mandating specific control over task placement, and "trust the platform" isn't an acceptable audit answer.

If none of those apply to your FastAPI/Next.js pair, you're very likely over-engineering by reaching for hand-authored Fargate task definitions first.

Deploying FastAPI to a managed container service

Containerize FastAPI with a slim Python base image, install dependencies from a lockfile (not a loose requirements.txt resolved at build time), and run behind uvicorn with a worker count tuned to your chosen vCPU allocation — over-provisioning workers relative to available CPU degrades throughput. Expose a single port, add a lightweight /health endpoint that checks your database connection so health checks reflect actual service readiness, and keep startup fast — App Runner's (and ECS Express Mode's) deployment health checks roll back if the service doesn't become healthy in time.

For configuration — database URLs, API keys, secrets — use the platform's built-in environment variable and secrets integration (pulling from Secrets Manager or SSM Parameter Store) rather than baking secrets into the image. This is easy to get sloppy about early and expensive to unwind later.

Deploying Next.js to a managed container service

Decide up front whether you're deploying the Node server (SSR, API routes, ISR) or a fully static export. If you need server-side rendering or API routes, containerize the Node server and let the platform run it like any other web service — this is the straightforward path and my default unless you have a strong reason for a static/CDN-first setup. If your app is fully static, you're often better served by S3 plus a CDN than by a container runtime at all — don't force one onto an app that doesn't need it.

Support lifecycle: base image deprecation

AWS and upstream vendors periodically issue end of support notices for specific runtime versions, base image tags, or platform versions. App Runner's managed runtimes followed deprecation cycles, and if you pinned your Dockerfile to a Python or Node version hitting end-of-life, you wouldn't get security patches even though your deployment kept "working." This matters more, not less, now that App Runner itself is in maintenance mode — a service that isn't actively developed is a service where you should assume runtime-version parity will lag further behind upstream over time. Build a habit of checking your base image's support timeline during routine maintenance, not after a CVE forces the issue.

When to pick managed (and when not to)

• Solopreneurs and small teams shipping a FastAPI + Next.js product: managed (App Runner if you're already there, ECS Express Mode if you're starting fresh), almost every time.
• Growing startups with a handful of services and no exotic networking needs: managed, until you hit a wall it doesn't solve.
• Platform teams running dozens of interdependent services, background workers, and strict network segmentation: full Fargate (or EKS, but that's a different article).
• Anyone starting a brand-new project today: you don't get to choose App Runner anymore — go straight to ECS Express Mode and skip the migration conversation entirely.

Final take

I've built products at both ends of this spectrum — as part of a team maintaining serious infrastructure, and alone, where every hour wrestling a task definition is an hour not spent on the product. App Runner existed because most workloads don't need Fargate's power, and paying for that power in engineering time is a worse trade than most teams realize. That reasoning didn't die when AWS put App Runner into maintenance mode — it just moved house, to ECS Express Mode. Start managed. Move to full Fargate control only when its constraints actually block you — not because it feels more "real" to hand-write your own load balancer config.

FAQ

Is AWS App Runner still available for new projects? No. As of April 30, 2026, App Runner stopped accepting new customers, per AWS's own service availability update. Existing App Runner services keep running normally, but AWS is directing new workloads to Amazon ECS Express Mode instead.

What is Amazon ECS Express Mode, and is it the same as App Runner? It's a newer, simplified deployment experience built directly into ECS, announced at re:Invent 2025 and positioned by AWS as App Runner's successor. It aims for the same "point at a container, get a running service" simplicity, but it runs on top of full ECS/Fargate, so you have a smoother upgrade path into Fargate's advanced features if you eventually need them — something App Runner never offered.

Is AWS App Runner more expensive than ECS Fargate? It depends on traffic shape. For spiky or low-traffic services, the managed tier is often cheaper because of aggressive scale-down behavior. For steady, high-throughput workloads running at consistent capacity, the cost difference narrows and can favor hand-tuned Fargate.

Can I run background jobs or a task queue with App Runner or ECS Express Mode? Not natively as a first-class concept the way you can within an ECS cluster running multiple task definitions. You can run a worker as its own service, but if you need tight orchestration between web and worker processes, full Fargate gives you more native tooling.

Does App Runner support custom domains and HTTPS? Yes — you can attach a custom domain and App Runner provisions and manages the TLS certificate for you, which is one less thing to wire up compared to a Fargate + ALB + ACM setup. ECS Express Mode offers the same.

Will my Next.js app work on a managed container service if I use server actions or ISR? Yes, provided you're running the Node server in the container rather than doing a static export — these platforms just run your container, so anything that works in a standard Node server environment works here too.

What happens if my container fails the health check during deploy? The platform rolls back to the previous healthy deployment automatically, which is one of the quieter but genuinely valuable benefits of the managed model — you don't have to hand-build that safety net yourself.

Should I migrate an existing App Runner service to ECS Express Mode right now? Not urgently, unless you're on a compliance timeline that penalizes running services on a de-prioritized product. AWS says existing App Runner workloads are honored indefinitely, so treat this like any other maintenance-mode dependency: plan the migration, don't panic about it, and prioritize it if you rely on App Runner-specific features like source-based builds that a maintenance-mode team is less likely to keep improving.