AWS Lambda vs ECS Fargate: Serverless vs Containers Compared

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, 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 architectural constraint, not a configurable limit.

When a 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. All three options add complexity. If your workload routinely approaches 15 minutes, Fargate is the cleaner architectural choice from day one.

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 or need to run continuously
• 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 constraint.

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.

Choosing between Lambda and Fargate involves trade-offs across cost, operational complexity, and architectural fit. Contact our team to discuss which compute model best fits your specific workload requirements and traffic patterns.