Serverless Vs Container Cost Tradeoff — AWS Solutions Architect (SAA-C03)
Duration, invocation rate, and idle time decide
Architecture requirement: run application logic cost-effectively at variable load. Competing choices: Lambda (pay-per-invocation, 15-minute max) versus ECS/Fargate (pay for task runtime). Deciding constraint: invocation duration, request frequency, and whether the workload is bursty or sustained. Lambda wins at low-frequency or short-duration bursts; containers win at high-throughput sustained workloads where per-invocation overhead accumulates. The exam expects you to apply this tradeoff using concrete workload signals, not default to one execution model.
What This Pattern Tests
The exam presents a workload and asks you to choose between Lambda/API Gateway and ECS/Fargate or EKS. Lambda charges per invocation ($0.20/1M) plus duration ($0.0000166667/GB-second). Fargate charges per vCPU-hour ($0.04048) and GB-hour ($0.004445). At low, bursty traffic (< ~500K requests/day), Lambda wins because you pay nothing at idle. At steady high traffic (> ~1M requests/day), Fargate wins because the per-invocation overhead exceeds fixed compute cost. The crossover point depends on function duration and memory — the exam expects you to reason about it, not memorize a number.
Decision Axis
Traffic pattern determines compute model: bursty and unpredictable favors Lambda (zero idle cost), steady-state favors Fargate/ECS (lower per-request cost at volume).
Associated Traps
More Top Traps on This Exam
Decision Rules
Whether the workload's maximum per-job execution duration violates Lambda's 15-minute hard limit, and if so, which EC2 capacity model avoids idle-capacity waste given the highly variable arrival rate.
Choose EC2-based compute over Lambda when the batch job execution window exceeds Lambda's 15-minute hard timeout, because selecting Lambda forces job decomposition and orchestration retry logic that adds more operational complexity than right-sizing EC2 Spot instances with Auto Scaling.
At sustained thousands-of-requests-per-second throughput running 24 hours a day, does Lambda's per-invocation plus GB-second billing model or Fargate's vCPU and memory-hour billing model yield a lower total monthly compute cost, and which option avoids adding concurrency and timeout management complexity?
Whether sustained 24/7 high-throughput with no idle window tips the cost-optimal choice from Lambda per-invocation billing to Fargate per-vCPU/memory-hour billing, given that Lambda's cost model inverts when concurrency is perpetually high and provisioned-concurrency configuration adds operational management burden.
Whether the workload's low average invocation frequency and extended idle windows make Lambda's per-invocation model cheaper than Fargate's vCPU/memory-hour model, where idle time directly accrues cost unless scale-to-zero is configured—adding operational complexity the scenario does not justify.
Domain Coverage
Difficulty Breakdown