Migration Apprunner To Ecs Express

App Runner was the “startup-friendly” compute option. It’s closing to new customers April 30, 2026. Existing services keep running, but you need a plan.

Startup Decision: What to Migrate TO

Don’t assume ECS Express Mode is the answer. Choose based on your situation:

The “Do I Even Need to Migrate?” Question

Existing App Runner services continue to work. You only MUST migrate if:

• You need to create NEW services (can’t after April 2026)
• You want to consolidate on fewer platforms
• App Runner’s scaling model (concurrent requests) doesn’t fit your workload

If your App Runner service is stable and you’re not creating new ones, deprioritize this migration. Focus on product, not infrastructure churn.

Cost Comparison for Startups

Key insight: ECS Express Mode is MORE expensive than App Runner at low traffic due to the ALB baseline. If cost matters and traffic is light, Lambda might be the better migration target.

Startup Quick Migration Path

For non-critical services (dev, staging, internal tools):

1. Extract config: aws apprunner describe-service --service-arn <arn>
2. Note: image URI, port, env vars, CPU/memory
3. Create Express Mode service with same config
4. Test the *.ecs.<region>.on.aws URL
5. Update DNS or upstream references
6. Keep App Runner as rollback for 48 hours, then delete

Total time: 2-4 hours for a simple service.

Startup-Specific Gotchas

When to NOT Use Express Mode (Startup Context)

Choose standard ECS Fargate instead if:

• You need fine-grained networking control (specific subnets, custom security groups)
• You want to share an ALB you already manage
• You need sidecar containers (observability agents, proxies)
• You’re running >5 services and want central control

Choose Lambda instead if:

• Your app fits Lambda constraints (stateless, <15 min, <10GB memory)
• Traffic is highly variable with long periods of zero requests
• You want $0 baseline cost
• You’re willing to handle cold starts (or pay for provisioned concurrency)