On March 31, AWS announced it is deprecating AWS App Runner. New customers were cut off on April 30, and while AWS has not yet published a final sunset date, the direction is clear: teams running on App Runner need a migration plan.
AWS’s official migration guide [1] points at Amazon Elastic Container Service (Amazon ECS) Express Mode. Express Mode is a reasonable starting point for prototyping, but for production workloads we recommend going straight to ECS on AWS Fargate. That way your lower environments and production use the same runtime, and you inherit the security controls App Runner abstracted away.
Below: what changes when App Runner disappears, why we skip Express Mode for production, and the security and networking details AWS’s migration guide leaves out.
What’s in this post
- What AWS actually announced
- App Runner vs ECS at a glance
- What AWS’s migration guide leaves out
- The upside: ECS unlocks Compute Savings Plans
- Our recommendation
- Skip the headache with the FivexL ECS Blueprint
What AWS actually announced
App Runner was AWS’s fully managed container service — link a repo or push an image, and AWS handled the build, deploy, and hosting. The trade-off was always the same: fast setup in exchange for limited control over networking, observability, and CI/CD. With App Runner going away, teams have to make choices they never had to make before.
The migration paths on the table:
- ECS Express Mode: created as the default replacement, fast to set up, closer to the App Runner experience.
- ECS on EC2: you’ll have to set up EC2 instances and maintain them (headache).
- ECS on Fargate (standard): more configuration up front, full control, easier to run under HIPAA or SOC 2 expectations.
- Other platforms: AWS Lambda for event-driven workloads (up to 15 minutes), or third-party PaaS options.
For anyone running a production workload that will still be around in a year, we think ECS on Fargate is the option that saves you a second migration later.
App Runner vs ECS at a glance
| Feature | App Runner | ECS on Fargate |
|---|---|---|
| VPC / networking | Fully managed, no VPC required; optional VPC Connectors for egress and VPC Ingress Connections for private endpoints | Runs in your own VPC (recommended for security and compliance) |
| CI/CD pipeline | Built-in, link a GitHub repo and AWS auto-builds and deploys | Bring your own using GitHub Actions, AWS CodePipeline, or similar |
| Container image build | Handled automatically from source (optional) | You build and push images to Amazon ECR |
| Load balancer | Managed Network Load Balancer plus a hidden L7 request router | Application Load Balancer (Express Mode) or ALB/NLB (standard ECS) |
| Custom domain and TLS | One-click domain and auto-provisioned certificate | Manual AWS Certificate Manager setup and ALB listener configuration |
| Observability and tracing | AWS X-Ray integrated out of the box | Sidecar required (X-Ray daemon or OpenTelemetry collector) |
| Auto scaling | Built-in, concurrency-based | Application Auto Scaling with target tracking or step scaling |
| Pricing model | Idle instances charged for memory only, no vCPU; can pause to zero cost but lose state | Pay per vCPU and memory-second; eligible for Compute Savings Plans (up to 52% on Fargate); can set desired count to 0, but this requires external automation and is not built in. |
| Configuration complexity | Minimal, a handful of settings | Task definitions, services, target groups, security groups, IAM roles |
| Security posture | Abstracted, limited control | Full control over IAM, security groups, NACLs, private subnets |
| Multi-environment parity | Harder to replicate (prod vs dev) | Easy with infrastructure as code, same Terraform for every environment |
| Launch types | Serverless only | Fargate (serverless), EC2, External (ECS Anywhere) |
What AWS’s migration guide leaves out
Reading AWS’s migration guide, we noticed several things that matter in production but do not get called out.
Express Mode ignores AWS’s own security baseline
By default, ECS Express Mode creates the new cluster inside the default VPC. That goes against the AWS Startup Security Baseline [2], which recommends avoiding the default VPC for production workloads. If you use Express Mode, explicitly configure the cluster to use a VPC you control. If you can build a custom VPC anyway, most of Express Mode’s convenience advantage disappears.
You now own the CI/CD pipeline
App Runner offered a “code-based” service that linked a GitHub repo and provided a hidden CI/CD pipeline. That is gone. You are now responsible for building your own images and deploying them.
AWS’s migration guide includes a GitHub Actions example, but it assumes:
- You use GitHub as your git host.
- You are willing to pay for GitHub Actions minutes at scale.
- You can create the IAM role, permissions, and OIDC trust configuration to push to ECR and update task definitions.
There is a helper in the Actions marketplace [3] and a companion GitHub repo [4], but the setup is still on you. Teams on GitLab, Bitbucket, or self-hosted git will need to build the equivalent themselves.
The load balancer story is more complicated
App Runner gave you a ready URL and a one-click way to attach a domain and certificate. With ECS you get an Application Load Balancer (ALB), which you configure through the EC2 console rather than the ECS console. That is a common source of confusion for teams new to ECS.
There is also a networking difference worth understanding. App Runner used a public-facing Network Load Balancer (NLB) at Layer 4 paired with an internal Layer 7 request router [9]. ECS Express Mode only supports ALB [5], which operates at Layer 7. If you need NLB behavior (TCP-level routing, static IP addresses, ultra-low latency), you have to move to standard ECS.
With both ALB and NLB, you can attach multiple SSL certificates to a single listener (a default certificate plus additional ones via SNI), and with ALB specifically you can define listener rules that route traffic based on host header, URL path, query string, or HTTP method — something App Runner never offered.
That means you can run multiple domains or microservices behind a single ALB, each with its own certificate and routing logic — giving you far more flexibility over how traffic reaches your containers.
Observability requires a real plan now
Credit where it’s due: while researching this post, we came across another writeup [13] that called out the same gap. App Runner shipped with AWS X-Ray integration out of the box; with ECS, tracing requires a sidecar container running the X-Ray daemon or an OpenTelemetry collector.
Worth knowing: the X-Ray SDKs and daemon entered maintenance mode on February 25, 2026 and reach end-of-support on February 25, 2027 [6]. AWS recommends transitioning to OpenTelemetry [7] and replacing the X-Ray daemon with either the CloudWatch Agent or the OpenTelemetry Collector with the X-Ray Exporter. If you are setting this up fresh, go straight to the AWS Distro for OpenTelemetry rather than deploying the X-Ray daemon and migrating twice.
The upside: ECS unlocks Compute Savings Plans
Once you are on ECS with Fargate, you qualify for AWS Compute Savings Plans [8], which offer meaningful discounts on your compute bill in exchange for a one- or three-year commitment. App Runner had no equivalent program.
Our recommendation
If you are already on App Runner in production, get the VPC right first — private subnets, VPC endpoints, flow logs — before you touch compute. From there, move to standard ECS on Fargate rather than Express Mode, so dev, staging, and production all run the same way. Build the CI/CD pipeline once, in code, wire up observability with OpenTelemetry from day one, and only look at Compute Savings Plans once the workload has settled.
Express Mode is fine if you are exploring ECS for the first time, but every team we have worked with that started there ended up rebuilding on standard ECS within a few months. Two migrations is one more than most startups can afford.
Skip the headache with the FivexL ECS Blueprint
If you would rather not build all of this from scratch, our ECS Blueprint is a production-ready application platform for teams that need to run containers reliably on ECS and Fargate, ship features quickly, scale automatically, and stay aligned with HIPAA or SOC 2.
It gives you:
- Private networking and least-privilege IAM as defaults.
- Centralized logging and observability.
- Automated CI/CD that works across environments.
- A repeatable Terraform setup so every environment looks the same.
Built specifically for regulated SaaS startups, the Blueprint replaces the fragile quick fixes (single environment, ad-hoc deploys) that fail under real usage — broken releases, spike-driven outages, stalled security reviews — with a proven, repeatable setup that stays up under load as you grow.
Read more at ECS Blueprint , or see how we have implemented it for other teams in our case studies .
Sources
- AWS App Runner availability change and migration guide
- AWS Startup Security Baseline — acct-09: Avoid using the default VPC
- Amazon ECS Deploy Express Service — GitHub Actions marketplace
- amazon-ecs-deploy-express-service — GitHub
- ECS Express Mode overview — load balancer support
- Announcing AWS X-Ray SDKs and daemon end of support and OpenTelemetry migration
- Migrating from X-Ray SDKs to OpenTelemetry
- AWS Compute Savings Plans pricing
- Serverless Web Hosting on AWS App Runner — reference architecture
- Amazon ECS Managed Instances
- AWS Fargate documentation
- ECS External Launch Type (ECS Anywhere)
- A practical guide to moving from App Runner to ECS Express Mode (dev.to)