AWS Lambda vs ECS Fargate: Serverless vs Containers Compared

Freshness Check (September 2026)

In this cycle, Lambda Managed Instances raised async and ESM function timeout from 15 to 90 minutes (9 Sep 2026). Synchronous invokes and classic on-demand Lambda stay at 15 minutes. Earlier 2026 updates still apply: LMI up to 32 GB / 16 vCPUs and durable-function expansion.

This page was refreshed against official AWS announcements and service documentation published in the last 12 months. Confirm region support, quotas, and pricing before final architecture sign-off.

• AWS What’s New
• 90-minute LMI timeout
• Lambda announcement updates

AWS Lambda and ECS Fargate are both “serverless” in the sense that you do not manage underlying EC2 instances — but they represent fundamentally different execution models. Lambda is event-driven and ephemeral; Fargate runs containerized workloads continuously. Choosing the wrong one for your workload costs money, creates architectural debt, and generates operational complexity that compounds over time.

This comparison is written for architects and CTOs who need a technically grounded decision, not a marketing summary.

Execution Model Comparison

The core difference is not just technical — it is conceptual. Lambda treats compute as a function: a unit of code that executes in response to an event, runs for up to 15 minutes on classic Lambda (90 minutes on LMI async/ESM as of 9 Sep 2026), and terminates. Fargate treats compute as a service: a container that runs continuously (or for a defined task duration) and handles requests as they arrive.

Cold Starts

Lambda cold starts are one of the most misunderstood aspects of serverless architecture. A cold start occurs when Lambda needs to provision a new execution environment — downloading your code, initializing the runtime, and running your initialization code before handling the actual request.

Typical Lambda cold start durations:

Cold starts only affect a fraction of requests under normal operation — Lambda reuses warm execution environments. However, at low traffic volumes, concurrency spikes, or after deployments, cold starts become frequent. Lambda Provisioned Concurrency eliminates cold starts but adds ~$0.015/GB-hour of reserved capacity cost.

Fargate has a different characteristic: container task startup takes 30–60 seconds for a new task, but once running, requests are handled by the already-warm container with no cold start equivalent. Fargate is not suitable for workloads that need sub-second spin-up from zero.

Timeout Limits

The 15-minute Lambda timeout is a hard cap for classic on-demand Lambda and all synchronous invokes. It is not a hard cap for async and supported ESM invokes on Lambda Managed Instances, which rose to 90 minutes on 9 Sep 2026.

When a classic Lambda function approaches the 15-minute limit, teams typically reach for one of three patterns: chunking work across multiple invocations via SQS, orchestrating multi-step pipelines via Step Functions, or migrating the entire workload to Fargate. As of 9 Sep 2026, LMI async/ESM is a fourth path for 15–90 minute jobs. All four add complexity relative to a short function. If your workload routinely needs hours, a GPU, or a persistent process, Fargate is still the cleaner architectural choice from day one. See LMI 90-minute timeout.

Cost Comparison

Lambda and Fargate use entirely different pricing models, making direct comparison require realistic traffic assumptions.

Lambda pricing (us-east-1):

• Requests: $0.20 per 1 million requests
• Compute: $0.0000166667 per GB-second (after 400,000 GB-seconds free tier)

Fargate pricing (us-east-1):

• vCPU: $0.04048 per vCPU-hour
• Memory: $0.004445 per GB-hour

Estimated monthly cost comparison — simple API backend (512 MB memory, 200ms avg duration):

At low traffic, Lambda wins decisively on cost because you pay nothing when there are no requests. At 5–10 million requests per month the crossover point is reached, and Fargate’s always-on cost becomes competitive. At 50 million+ requests per month, Fargate at appropriate task sizing is typically cheaper.

Stateless vs Stateful Workloads

Lambda’s execution environment is effectively stateless between invocations. While Lambda does reuse warm execution environments (and you can cache data in memory), this behavior is not guaranteed. You cannot maintain a persistent database connection pool, hold WebSocket connections, or rely on in-memory state across invocations in a predictable way.

Fargate containers are stateful within their lifecycle. A running Fargate task can maintain database connection pools (reducing per-request latency significantly), hold WebSocket connections, run background threads, and cache data in memory reliably.

For workloads requiring persistent TCP connections to databases or caches, Fargate with RDS Proxy provides better connection management than Lambda, which tends to exhaust database connections at scale without RDS Proxy in front of it.

Decision Framework

Choose Lambda when:

• Workload is genuinely event-driven with irregular traffic
• Execution time is reliably under 5 minutes
• Traffic is low-to-medium (under 5 million requests per month) or highly spiky
• You want zero infrastructure management and automatic scaling to zero
• Cost optimization at low traffic is the priority
• Functions integrate directly with AWS event sources (S3, SQS, DynamoDB Streams, EventBridge)

Choose Fargate when:

• Tasks run longer than 15 minutes on classic/sync Lambda, or longer than 90 minutes on LMI async
• Workload requires more than 10 GB memory or 6 vCPU
• Application maintains state, persistent connections, or in-memory caches
• Traffic is sustained and predictable (lower per-unit cost at scale)
• You have an existing containerized application to migrate
• Background workers, queues, or WebSocket servers are involved

Use both when:

• Event processing triggers long-running Fargate tasks (Lambda as orchestrator)
• API gateway routes lightweight endpoints to Lambda and heavy endpoints to Fargate
• Step Functions workflows combine Lambda for transformation with Fargate for intensive processing

Migration Path

Moving from Lambda to Fargate is typically straightforward if your Lambda functions are already container-packaged. The main work involves adding a web server layer (Express, Gin, FastAPI) to handle the persistent request model, configuring an ECS task definition, and setting up an ALB instead of API Gateway.

Moving from Fargate to Lambda requires decomposing long-running tasks, eliminating persistent state dependencies, and ensuring the execution model fits within the 15-minute classic/sync cap — or the 90-minute LMI async/ESM cap.

If you are starting a new workload and are uncertain about traffic patterns, Lambda is lower risk — you can always migrate to Fargate once traffic warrants it.

Related Comparisons

Explore other technical comparisons:

• AWS EC2 vs Lambda
• AWS ECS vs EKS

Why Work With FactualMinds

FactualMinds is an AWS Select Tier Services Partner — a verified AWS designation earned through demonstrated technical expertise and customer success. Our architects have run production workloads for companies from seed-stage startups to enterprises.

• AWS Select Tier Partner — verified by AWS Partner Network
• Architecture-first approach — we evaluate your specific workload before recommending a solution
• No lock-in consulting — we document everything so your team can operate independently
• AWS Marketplace Seller