--- cuppy_hub: aws cuppy_path: patterns/alternatives/choosing-compute.md cuppy_section: docs cuppy_doc: YW45-29EP cuppy_doc_uuid: 75de2146-dd44-4b8f-9cc2-03209feb9f1a cuppy_permalink: https://cuppy.io/aws/d/YW45-29EP cuppy_version: 4 cuppy_updated: 2026-10-23T16:16:52.575Z cuppy_canonical: https://cuppy.io/aws/docs/patterns/alternatives/choosing-compute cuppy_mcp: https://cuppy.io/mcp cuppy_body_sha256: e07f2a4f86e5592c1f8aad8ec8c8c29bb64399202a2ddff9ac23b9748a57441b # cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks. --- # 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: 1. Build an image first if the App Runner service built from source. 2. Run Express Mode alongside, and add your custom domain to the ALB's host rule and certificate. 3. Shift traffic with Route 53 weighted records (90/10 → 100/0). 4. 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 | --- You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 131 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/aws/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.