Choosing compute: Lambda, Fargate, EC2, App Runner's replacement, and edge functions
Pick between Lambda, ECS on Fargate, EC2 and the edge — the deciding limits (15-minute runs, payload size, cold starts, state), what replaced App Runner for new customers (ECS Express Mode), where Cloudflare Workers-style edge isolates fit and where they don't, and the handoffs each choice implies.
markdownpatternv4YW45-29EPstage: buildtrust: officialtrust: fieldservice: lambdaservice: ecsservice: ec2service: apprunnerinterface: anyLambda vs FargateLambda or ECSwhen to use EC2App Runner closed to new customersECS Express ModeApp Runner migrationCloudflare Workers vs Lambdaedge functionscold startlong-running jobschoose compute service
Choosing compute
Default to Lambda for event-driven work that finishes within 15 minutes, and to ECS on Fargate for anything long-running, stateful in memory, or already a container. Choose EC2 when you need the machine itself: GPUs, a particular OS, kernel tuning, or licensing. New services that would have gone on App Runner go on ECS Express Mode, because App Runner is closed to new customers.
The deciding limits
| Lambda | ECS on Fargate | EC2 | |
|---|---|---|---|
| Max run | 15 minutes (900 s) | No hard limit | No limit |
| Scaling | Per request; up to 1,000 new environments per 10 s per function | Desired task count, service auto scaling | Auto Scaling groups |
| Cold start (AWS guide) | 100 ms – 2 s | 35 s – 2 min | Minutes (UNVERIFIED; not in the guide) |
| State | Stateless: keep state in S3, DynamoDB or EFS | Can hold in-memory state while running (keep critical data external) | Whatever you build |
| Billing shape | Per invocation + GB-seconds | Per second of vCPU and memory | Per instance-second, plus purchase options (Spot, Savings Plans) |
| Payloads | 6 MB synchronous, 1 MB asynchronous, 200 MB streamed | Your server's limits (behind an ALB: its limits) | Same |
| Packaging | Zip (250 MB unzipped) or container image (10 GB) | Container image | AMI, anything |
| Network by default | Public AWS network; in a VPC, no internet without NAT | Your subnets (awsvpc) | Your subnets |
AWS's guide: Fargate for "long-running applications, microservices, or batch processing" and "persistent processes"; Lambda for "event-driven, short-duration tasks or unpredictable workloads."
App Runner → ECS Express Mode
- App Runner is no longer available to new customers. Existing customers can keep using it, including creating services. AWS will keep investing in security and availability but plans no new features.
- AWS's recommended replacement is Amazon ECS Express Mode: one API call with a container image and two IAM roles, and ECS provisions the Fargate service, an ALB, auto scaling and networking. Express Mode itself has no charge; you pay for those resources.
- Migrating:
- Build an image first if the App Runner service built from source.
- Run Express Mode alongside, and add your custom domain to the ALB's host rule and certificate.
- Shift traffic with Route 53 weighted records (90/10 → 100/0).
- Keep App Runner 24–48 hours for rollback, then delete it.
- Express Mode details (what it creates, defaults, what can't change):
guides/ecs/express-mode.md.
The result is an ordinary ECS service behind an ALB, so patterns/alb-to-ecs-fargate.md and guides/ecs/run-fargate-task.md apply.
Elastic Beanstalk and Lightsail
AWS's compute guide positions Elastic Beanstalk as deploying web apps "with minimal management of the infrastructure" and Lightsail as "an easy way to build web applications". The hub doesn't cover either. Pick them for simple web hosting where the team won't operate VPCs and load balancers directly.
Edge isolates (Cloudflare Workers as the example)
Edge function platforms run code close to users, in lightweight isolates rather than containers. They suit request rewriting, auth checks and light APIs, not heavy compute. On Workers, the documented limits are:
- CPU time per request: 10 ms on the free plan; 30 s by default on paid plans, configurable up to 5 minutes.
- 128 MB of memory per isolate.
- No hard wall-clock limit for HTTP requests while the client stays connected. Cron and queue work is capped at 15 minutes.
- Request bodies from 100 MB up to 5 GB, depending on plan.
Works well with AWS when the edge function calls AWS APIs over HTTPS with SigV4-signed requests (the JavaScript v3 SDK is the usual way; compatibility of specific SDK packages with the isolate runtime is UNVERIFIED), or fronts an ALB or CloudFront.
Works badly when the code needs VPC-private resources (there is no VPC attachment) or IAM roles (there is no instance or task role, so long-lived access keys or an external token exchange are needed). On AWS's own edge, CloudFront Functions and Lambda@Edge keep IAM and CloudFront integration (not covered in depth here).
Signals you chose wrong
| Symptom | Move toward |
|---|---|
| Lambda functions hitting 15 minutes, or chaining themselves to continue | Fargate task, Step Functions, or Batch |
| Paying for Fargate tasks idle most of the day, with spiky event traffic | Lambda |
| Lambda payloads over 6 MB in or out | Pass S3 references, or move to a container behind an ALB |
| Fargate start times hurting scale-out | Keep minimum tasks warm, or put the latency-critical path on Lambda |
| Needing GPUs, privileged containers or host tuning | EC2 (or ECS on EC2) |
| A new web service planned on App Runner | ECS Express Mode |