Decision checkpoints
| Compare | Standard Lambda | ECS on Fargate |
|---|---|---|
| Execution unit | Standard Lambda: an event-driven function invocation. | Fargate: a container task managed through a supported orchestrator, such as ECS. |
| Scaling unit | Standard Lambda: supported invocation concurrency, constrained by quotas and configuration. | ECS/Fargate: desired task count and task capacity, with task startup and service scaling behavior. |
| State | Persist durable state outside the function; a reused execution environment is not guaranteed. | Persist durable state outside the task; running-process memory is lost when the task is replaced. |
Match the process you actually have
A practice LetX handler processes independent export events and has a bounded runtime. A function can suit that unit of work. A practice QuantumSketch worker already has a container, a continuous native process and longer processing. A task-based worker can suit that process.
Packaging code as a container image does not make a Lambda invocation an unrestricted persistent container service. Conversely, using a Fargate task does not require you to manage an EC2 host. Choose from the behavior of the running work.
A 15-minute rule needs a compute-mode label
For standard Lambda functions, one invocation is limited to 900 seconds. Current Lambda includes additional compute and workflow options, so a blanket statement about every Lambda workload would be incomplete. Consult the current quota and compute-mode documentation when those options are candidates.
For a continuously running task, ask how it is replaced after failure, whether it can resume, and whether its state survives. For a multi-step waiting workflow, ask whether orchestration can suspend between steps instead of keeping compute occupied. These are different requirements.
Scaling compute can overload another service
A queue consumer, function or container has a downstream budget. If the database can sustain only a certain number of expensive jobs, adding consumers without a bound can reduce useful completion. Use queue age and dependency capacity as evidence.
In the experiment below, increase worker count and compare arrivals with completions. The arithmetic shows a workload relationship, not actual scheduling or automatic scaling in either AWS service. A production comparison needs measured startup time, concurrency, task resource allocation and job-duration distribution.
Include idle capacity and operating work in cost
For the same example workload, estimate function requests/duration or allocated task CPU/memory time, then include networking, data services and observability. Record the Region and traffic assumptions. Warm capacity, bursts and steady utilization can change the outcome.
Avoid a universal request-count break-even point. A meaningful recommendation includes latency and reliability constraints alongside cost. Follow the architecture guide for the decision, then use real service measurements before choosing a deployment.
Predict it. Test it. Change one thing.
Local educational model. No account or cloud charges. Nothing is deployed to AWS.
Constant rates; no polling, retries, batch effects or service quotas. This models work conservation.
sim.shahriarlabs.com · Free to explore
Sources and scope
Reviewed against these official references. The model’s supported scope appears alongside its controls.
- AWS: Fargate or Lambda decision guide
- AWS: Lambda compute-mode quotas
- AWS: ECS service auto scaling
- AWS: Lambda pricing
- AWS: Fargate pricing