Serverless compute cost: Lambda and Fargate on SAA-C03

When per-request and per-second billing beats an always-on server — and the utilization point where it stops — in the exam's own scenario style, SAA-C03, 2026 edition.

Here are 7 serverless-cost questions written in the exam's scenario style — free, with every answer explained, no sign-up.

Straight to the 7 free questions ↓

Serverless compute is sold as simpler, but on the SAA-C03 exam it is tested as a cost decision. The question is rarely “what is Lambda” — it is for which workload does paying per request and per second beat paying for a server by the hour, and where does that stop being true. Both halves are scored, and the second is the one candidates miss.

The serverless cost model: you pay for work, not for waiting

An always-on server is billed for wall-clock time — every hour it runs, busy or idle. AWS Lambda inverts that: it bills per request and per millisecond of execution, and it scales to zero between invocations, so idle time is free. AWS Fargate does the same for containers, billing per-second for the vCPU and memory a task uses while it runs, with no host to provision or patch. The unifying idea is that you pay for work performed, not for capacity held in reserve.

That model is decisive when a workload is spiky, low-volume, event-driven, or intermittent — a rarely-hit API, a nightly script, a bursty queue consumer. Wherever a traditional server would sit idle waiting for the next request, serverless charges nothing for the wait. The first thing to spot in a cost stem is whether the workload has meaningful idle time.

The break-even: where always-on wins again

The catch, and the diagram above, is that this advantage is not permanent. Per-request and per-second billing carries a small convenience premium on every unit of work. When utilization is high, steady, and round-the-clock, there is no idle for serverless to save, and that premium is paid on every busy second. Past a break-even point, a committed EC2 fleet covered by a Compute Savings Plan costs less for the same throughput.

Read the two curves as cost against utilization. The serverless line starts near zero on the left — scale to zero, no idle cost — and climbs steeply as work grows. The EC2-plus-Savings-Plans line starts higher, because a committed instance is paid for even while idle, but rises gently. They cross. Left of the crossover, serverless is cheaper; right of it, the always-on commitment is. A stem describing a continuous, always-busy, multi-year workload points to the right of that line even when it currently runs on Fargate.

Fargate versus EC2 for containers

For containerized workloads the same trade appears as a launch-type choice. Fargate removes the cluster: no hosts to size, patch, or scale, and you pay per-second for each task’s declared resources. That is cheapest — and lowest-overhead — for variable or bursty container traffic. Amazon ECS or EKS on self-managed EC2 hands the capacity problem back to you, and its idle headroom is your cost; it wins only when utilization is high and constant enough that a committed, well-packed fleet under a Savings Plan beats Fargate’s per-second rate. “No hosts to manage” points to Fargate; “steady, high, long-term utilization and willing to manage hosts” points back to EC2.

One commitment across all three

Commitment discounts are not EC2-only. A Compute Savings Plan applies automatically across EC2, Fargate, and Lambda for a one- or three-year hourly-spend commitment, without pinning to instance types. When a stem has a predictable baseline spread over serverless and instances, it is usually the intended answer — narrower EC2 Instance Savings Plans and Reserved Instances cover neither Fargate nor Lambda.

Right-sizing serverless itself

Serverless still has a size dial. Lambda bills GB-seconds — memory times duration — so an over-provisioned memory setting inflates every invocation. More memory only lowers cost when the function is CPU-bound and finishes proportionally faster, because CPU scales with memory; otherwise it is waste. Tuning memory toward real usage is the serverless equivalent of right-sizing an instance.

How to use the questions below

For each stem, name the workload’s shape first — spiky or steady, idle-heavy or always-busy, short bursts or a continuous firehose. That shape decides which side of the break-even you are on, and the deciding constraint is always in the stem. Then read each explanation past the correct answer: every wrong option saves money for a different workload, and knowing which is the skill this domain scores.

A cost-versus-utilization chart with two curves. The horizontal axis runs from low or spiky usage on the left to high steady usage on the right; the vertical axis is monthly cost. The serverless curve for AWS Lambda and Fargate starts near zero at the left because it scales to zero and carries no idle cost, then rises steeply as usage grows because every request and every running second is billed. The EC2-plus-Savings-Plans curve starts higher on the left, since a committed instance is paid for even while idle, but rises only gently. The two curves cross at a marked break-even point: to the left of it serverless is cheaper, to the right the committed always-on server is cheaper. A left-side note reads scale to zero, no idle cost, and a right-side note reads high steady use, commitment wins.

7 free SAA-C03 practice questions

Answers and explanations — no email wall

SAA-C03 Question 1 of 7

A startup exposes an internal admin API through Amazon API Gateway. It receives a few hundred requests on a busy day, none overnight, and traffic is impossible to predict. The team wants the lowest compute cost and refuses to pay for capacity that sits idle. Which compute option fits BEST?

Answer: A — AWS Lambda

The deciding phrase is 'refuses to pay for idle': Lambda bills per request and per millisecond of execution and scales to zero between calls, so a few hundred requests a day cost a few hundred requests a day — nothing while the API is quiet. Why not the others: a continuous On-Demand instance is billed every hour of the day whether or not a request arrives, which is the definition of idle cost here. An Auto Scaling group with a minimum of one never scales below that one paid instance, so it carries the same floor. ECS on EC2 with an always-on task keeps a container host running around the clock for the same reason. All three are sized for a steady load this workload does not have.

SAA-C03 Question 2 of 7

A team is containerizing a web service with variable daytime traffic. They want to run it on AWS without managing, patching, or capacity-planning any EC2 hosts, and want to pay only for the compute each task actually uses while it runs. Which launch type meets this with the LEAST operational overhead?

Answer: A — AWS Fargate

Fargate is serverless compute for containers: you declare the vCPU and memory a task needs and pay per-second for exactly that while the task runs, with no host to provision, patch, or scale. That matches 'no EC2 hosts' and 'pay only for what each task uses' exactly. Why not the others: ECS on a self-managed Auto Scaling group and EKS with self-managed nodes both hand you the cluster capacity problem the stem is trying to avoid — you size, patch, and pay for the instances, and idle headroom on them is your cost. Starting containers from a user-data script is EC2 management with extra steps. Only Fargate removes the host entirely.

SAA-C03 Question 3 of 7

A container platform runs a steady, always-on workload that holds several instances busy at high utilization 24 hours a day, and is expected to for years. The company already runs it on AWS Fargate and finds the bill high. It can commit to consistent usage and accepts managing hosts. What most likely reduces cost?

Answer: A — Move the workload to Amazon ECS on EC2 and cover the steady usage with a Compute Savings Plan

This is the break-even the diagram shows. Serverless is cheapest when usage is spiky or low, because you pay nothing while idle — but at high, constant, round-the-clock utilization there is no idle to avoid, and the per-second convenience premium of Fargate is paid on every busy second. A committed EC2 fleet under a Compute Savings Plan wins on steady, predictable load. Why not the others: raising vCPU or adding tasks increases what you pay per second, not decreases it. Lambda is billed per request with a 15-minute ceiling and is the wrong shape for a continuous high-throughput service — it would cost more, not less, at this scale.

SAA-C03 Question 4 of 7

A company has mixed compute: some Amazon EC2 instances, several Amazon ECS on AWS Fargate services, and a large fleet of AWS Lambda functions, all with a predictable baseline of usage. It wants one commitment-based discount that applies across all three without pinning it to specific instance types. Which purchase option should it use?

Answer: A — A Compute Savings Plan

Compute Savings Plans commit you to an hourly dollar amount of compute spend for one or three years and apply automatically across EC2, Fargate, and Lambda, regardless of instance family, size, or Region — which is exactly the 'all three, no pinning' requirement. Why not the others: an EC2 Instance Savings Plan is narrower — it discounts EC2 within a chosen family and Region and does not cover Fargate or Lambda. Standard Reserved Instances apply only to EC2 and lock to instance attributes, covering neither serverless service. Spot is not a commitment discount at all; it is interruptible capacity and cannot cover a predictable baseline that must not be reclaimed.

SAA-C03 Question 5 of 7

A reporting script runs for about three minutes each night. Today it lives on a small EC2 instance that is provisioned and billed 24/7 but does real work only during those three minutes. The team wants to eliminate the idle cost while changing the billing model, not just shrinking the server. What should they do?

Answer: A — Re-implement the script as an AWS Lambda function triggered on a schedule by Amazon EventBridge

The stem asks to change the billing model, not trim the server, and Lambda changes it completely: with an EventBridge schedule the function runs for roughly three minutes a night and is billed only for those minutes' requests and duration — the other 23 hours 57 minutes cost nothing because there is nothing running. Why not the others: a Reserved Instance discounts idle hours but still pays for all of them, so idle cost is reduced, not eliminated. Downsizing shrinks the same 24/7 bill without removing the idle. A stop/start schedule keeps you on the instance-hour model and adds moving parts; the point of the question is that per-invocation billing removes the idle entirely.

SAA-C03 Question 6 of 7

A team notices two AWS Lambda functions cost far more than expected. Both were configured with 3008 MB of memory as a precaution, but monitoring shows they use under 300 MB and are not CPU-bound. Duration has not improved from the extra memory. What is the MOST cost-effective fix?

Answer: A — Lower each function's memory setting toward its actual usage after checking duration

Lambda bills GB-seconds — allocated memory multiplied by execution time — so paying for 3008 MB while using under 300 MB inflates every invocation for capacity the code never touches. Lowering memory toward real usage cuts the GB-second rate directly. Why not the others: raising memory only helps cost when the function is CPU-bound and finishes proportionally faster, since CPU scales with memory; the stem states duration did not improve, so more memory is pure waste. Timeout is a ceiling, not a billing driver — it changes nothing while runs succeed. Moving to EC2 reintroduces the idle-hour cost that made serverless attractive for a bursty function in the first place.

SAA-C03 Question 7 of 7

A data pipeline processes a continuous, high-volume event stream 24/7. Each event is quick, but volume is so high and constant that per-request AWS Lambda billing has grown very large, and the workload comfortably fits inside long-lived containers. The team wants lower cost for the same steady throughput. What should they evaluate?

Answer: A — Run the processing as long-lived Amazon ECS on AWS Fargate tasks sized to the steady throughput

Lambda's per-request model is cheapest for spiky or low-volume work, but a constant firehose of invocations turns 'pay per request' into a very large number of requests billed continuously — past a break-even, a few always-busy Fargate tasks processing the stream cost less for the same throughput while staying serverless in operations. Why not the others: raising reserved concurrency reserves capacity and can add cost, it does not lower the per-request price. More memory raises the GB-second rate. An SQS queue smooths bursts and improves resilience but the total number of billed invocations, and therefore the cost driver, is unchanged.

That is exactly how every question in the course works — answer, explanation, why-not. The real set continues in the practice player: 10 free questions, no sign-up.

Continue with the 10 free questions →

Those 7 questions were the start.

The exam does not test whether you recognise a term — it tests whether you can rule out three plausible answers under time pressure. That is what the explanations above are for, and there are 780 more questions built exactly like them.

Collecting questions yourself

Scattered across forums, of unknown age
Answer keys without reasoning
No idea which domain you are weak in

Practising with a system

780 questions in 12 full tests, SAA-C03 (2026)
Every option explained — including the wrong ones
Readiness per exam domain, and drills for your weakest

Start free — 10 questions

Straight into the player. No account, no email.

Frequently asked questions

When is AWS Lambda cheaper than an EC2 instance?

When usage is spiky, low-volume, event-driven, or intermittent — anywhere a server would sit idle. Lambda scales to zero and bills per request and per millisecond, so idle time costs nothing, while an On-Demand instance is billed for every hour it runs. As utilization climbs toward steady, round-the-clock load the advantage narrows and eventually reverses: past a break-even point a committed EC2 fleet under a Savings Plan is cheaper, because there is no idle for serverless to save. The diagram on this page shows exactly that crossover.

Do Compute Savings Plans cover AWS Fargate and Lambda?

Yes. A Compute Savings Plan commits you to an hourly amount of compute spend for one or three years and applies automatically across Amazon EC2, AWS Fargate, and AWS Lambda, regardless of instance family, size, or Region. That breadth is what separates it from an EC2 Instance Savings Plan or Reserved Instances, which discount EC2 only. If a stem mentions a predictable baseline spanning serverless and EC2, the Compute Savings Plan is usually the answer the exam wants.

Are these real SAA-C03 exam questions?

No. They are original questions written in the style and difficulty of the exam. Sharing real exam items violates the AWS certification agreement and can cost a candidate their certification. What actually prepares you is the reasoning attached to every answer here — the method of finding the deciding constraint in the stem — which real items never come with anyway.

Updated for SAA-C03 (July 2026). The sample questions above are our own work in the style of the exam — not real exam items. The exam itself is set and marked by the certification body.