AWS Lambda vs AWS Fargate
Compare event-driven functions with serverless containers by runtime duration, scaling unit, packaging, startup, and traffic shape.
Open editable diagramArchitecture diagram
Edit this exact diagram
Open on the canvasAWS Lambda vs Fargate architecture diagram comparing event-driven serverless functions with long-running Amazon ECS container tasks. The image links to a fully editable BuildPlane starter.
Overview
Lambda and Fargate both remove server provisioning, but Lambda schedules function invocations while Fargate schedules complete containers. Lambda is event-driven, scales concurrency quickly, and can scale to zero. Fargate tasks have explicit CPU and memory, accept conventional container images, and can keep a process or connection alive for as long as the workload requires.
Components
- Shared decision context: Bursty events, HTTP requests, scheduled jobs, and sustained application demand.
- AWS Lambda: Runs stateless functions per event with managed concurrency and a finite invocation duration. APIs, file handlers, scheduled jobs, and stream consumers that complete per invocation.
- AWS Fargate: Runs containers without hosts and scales by starting or stopping complete tasks. Long-running HTTP services, workers, and jobs with custom runtimes or larger dependencies.
Comparison Flow
- Requests & Events can enter the AWS Lambda path and continue to Short Event-Driven Work.
- Requests & Events can instead enter the AWS Fargate path and continue to Persistent Container Service.
- Choose the path whose operating model and constraints match the workload, then delete the unused branch in the editable diagram.
Customize First
- Model request duration, memory, concurrency, and idle time before comparing price.
- Include task startup and function cold-start behavior in latency tests.
- Use both when a container service also needs bursty event handlers.
Side-by-side decision
AWS Lambda vs AWS Fargate
Use Lambda when the unit of work is a finite event-driven invocation. Use Fargate when the unit is a container process that should stay alive, run longer, or control more of its runtime.
| Decision factor | AWS Lambda | AWS Fargate |
|---|---|---|
| Execution unit | Function invocation | Container task |
| Duration | Finite invocation limit | Runs until the task exits or is stopped |
| Scaling | Concurrent executions, including scale to zero | Task count with startup and health-check time |
| Packaging | Zip or Lambda-compatible container image | Standard OCI container image |
| Runtime control | Managed function environment | Container process, ports, CPU, memory, storage |
| Traffic fit | Bursty and event-driven | Sustained services and long jobs |
Related AWS guides
Understand the decisions behind this diagram
Use these practical explanations to compare services, failure boundaries, and operating tradeoffs before adapting the architecture.
Design rationale
Decisions that shape this architecture
Choose the scaling unit the work naturally has
Lambda creates concurrent execution environments around incoming events. Fargate changes the desired number of tasks and waits for images, startup, and health checks. A burst of tiny independent jobs fits Lambda; a continuously available server or worker pool fits Fargate.
Runtime limits can decide before cost does
A task that needs a long execution, listening socket, sidecar, unusual binary, large dependency tree, or persistent connection is usually container-shaped. A handler that can receive one event, externalize state, and finish cleanly is function-shaped.
Price follows utilization
Lambda avoids compute cost while idle and charges by requests and execution resources. Fargate bills requested task resources while a task runs. Lambda tends to win for sparse demand; a well-utilized container can win for steady traffic. Model the actual duration and idle profile.
Before production
Operational checks
Measure p50 and p99 startup behavior for both deployment packages.
Set Lambda concurrency controls or Fargate task autoscaling from workload-specific signals.
Test idempotency, graceful shutdown, retries, and poison-message handling.
Include logs, networking, image storage, NAT, and idle capacity in cost estimates.
Scope and tradeoffs
What this diagram does not solve
Neither service removes application operations
AWS owns the server fleet, but the team still owns code, dependencies, permissions, observability, deployment safety, capacity signals, and recovery behavior.
The newest Lambda modes change some edges
Lambda capabilities continue to expand, including durable execution and managed-instance options. Validate current regional availability and limits when those modes affect the decision rather than applying the classic function model blindly.
Common questions
Frequently asked questions
Is Fargate serverless?
Yes in the infrastructure-management sense: AWS provisions and patches the underlying compute. You still choose task CPU, memory, networking, desired count, and autoscaling, and you pay while tasks run.
Can Lambda run container images?
Yes, but the image still runs under the Lambda invocation and runtime model. Packaging a function as an image does not turn it into a long-running Fargate service.
Which is cheaper, Lambda or Fargate?
Lambda is usually attractive for low, variable, or bursty utilization because it can reach zero compute. Fargate can be more economical for sustained, well-utilized work. The crossover depends on duration, memory, CPU, task count, and discounts.
Keep exploring
Related AWS architectures
ECS on Fargate vs Amazon EKS
Choose ECS on Fargate when the goal is to run containers with the smallest AWS operations footprint and no Kubernetes requirement. Choose EKS when Kubernetes itself is a strategic interface, the team needs its ecosystem or portability, or many product teams need a common platform abstraction. EKS can still run selected pods on Fargate, which is why separating orchestrator from capacity is essential to a correct decision.
Explore the architecture
AWS Fargate vs Amazon EC2 for ECS
Choose Fargate when removing host management and isolating capacity per task matter more than the lowest steady-state unit cost. Choose ECS on EC2 when the workload needs GPUs, privileged or daemon access, specialized instances, very high sustained utilization, or deeper control over placement and networking. Capacity providers make this a per-service or mixed-cluster decision rather than an irreversible platform choice.
Explore the architecture
AWS Lambda vs Amazon EC2
Choose Lambda when work is short, stateless, event-driven, and benefits from scaling to zero. Choose EC2 when the application needs a persistent process, custom operating system, specialized hardware, unrestricted runtime behavior, host agents, or predictable continuous capacity. The strongest architectures often use Lambda around an EC2 core for automation and events rather than forcing every component onto the same compute service.
Explore the architectureFrom reference to working draft
Adapt this architecture with your AWS AI Agent
Start from the exact diagram in this guide. Change requirements, challenge a decision, or ask what fails first, while keeping the architecture editable.