Cost-Optimized Compute: Spot vs Reserved vs Savings Plans, and Lambda vs EC2

EC2 can be paid for in four ways, and every compute cost question starts from this menu. On-Demand is the baseline: full price, per-second billing, no commitment — right for unpredictable, short-lived or unproven workloads. Everything else is a discount bought with either a commitment or a tolerance for interruption.

Reserved Instances discount a specific instance configuration for a 1- or 3-year term. Standard RIs give the deepest discount (up to 72%) but lock the instance family and cannot be exchanged for a different family or OS. They can still be modified — for example switching Availability Zone or scope, or changing size within the same family for Linux — and an unwanted Standard RI can be listed on the Reserved Instance Marketplace. Convertible RIs give a shallower discount (up to 66%) in return for the right to exchange into other families, sizes or operating systems during the term. Longer terms and more upfront payment (all, partial or no upfront) deepen the discount.

Savings Plans commit to a fixed amount of compute spend per hour for 1 or 3 years instead of to an instance configuration; eligible usage above the commitment bills On-Demand. Compute Savings Plans are the flexible variant: the discount (up to 66%) follows usage across instance family, size, Region, OS and tenancy, and it also applies to Fargate and Lambda. EC2 Instance Savings Plans commit to one instance family in one Region for a deeper discount (up to 72%, matching Standard RIs) and stay flexible across sizes, OS and tenancy within that family — but they cover EC2 only, so usage that moves to Fargate or Lambda leaves the plan.

Flexibility and depth trade against each other: the instruments that lock a family pay the most, the ones that follow you anywhere pay less. Compute databases are a separate menu — RDS and other database services have their own reserved pricing and AWS now also sells Database Savings Plans, covered in the database cost lesson.

On-Demand Capacity Reservations are not a discount. They guarantee capacity of a given type in one Availability Zone and bill at the On-Demand rate whether instances use them or not; you combine them with a Savings Plan or regional RI to get a discount on top. Buy one for guaranteed capacity (for example, a launch event or DR), never to cut cost.

One more lever sits under the menu: where you run. EC2 prices differ by Region, so workloads with no latency or residency constraint — batch, analytics, DR standby — can run in a cheaper Region, while user-facing tiers stay near their users. Placement interacts with commitments: Standard and Convertible RIs and EC2 Instance Savings Plans are bound to one Region, so moving steady work to another Region strands them, while a Compute Savings Plan follows usage into any Region. Read the usage pattern, then match commitment, flexibility need, interruption tolerance and placement freedom to the option.

The canonical Task 4.2 answer is a layered mix, because real workloads are not one shape: measure the steady 24/7 baseline and cover it with a Savings Plan or Reserved Instances; run the predictable-but-variable layer above it On-Demand behind Auto Scaling; and push interruptible work — batch, queue processing, CI, analytics — onto Spot. Each layer gets the deepest discount its reliability requirement allows, and no layer overcommits.

Sizing the commitment

A commitment is sized to the measured hourly floor, not the average or the peak, because it bills the same amount every hour of the term, used or not, and an hour's unused commitment cannot carry over. That has three consequences the exam leans on:

• It cannot follow a schedule. A Savings Plan is one hourly amount for the whole term; there is no business-hours-only or nightly-window plan (AWS no longer sells Scheduled Reserved Instances). Part-time capacity is On-Demand or Spot, not committed.
• Flexibility moves the discount, not the bill. A Compute Savings Plan's discount follows instances when you resize or re-family them, but the committed dollars per hour do not shrink. Downsize after buying and part of the commitment goes unused for the rest of the term — so right-size first. Cost Explorer's Savings Plans and RI purchase recommendations are calculated from your recent usage (a 7-, 30- or 60-day lookback), so on an over-provisioned fleet they recommend an oversized commitment.
• Existing RIs come first. AWS applies Reserved Instance discounts before Savings Plans (and EC2 Instance Savings Plans before Compute Savings Plans). A new plan should be sized to the steady usage your current RIs leave uncovered; sizing it to the whole floor pays for commitment with nothing to discount until the RIs expire.

The exam presents the mix as a multi-part workload description; the correct option layers all three, and distractors commit to the peak, run everything On-Demand, put the un-interruptible tier on Spot, or size a new commitment over usage that is already reserved.

Spot's discount is only usable if the architecture absorbs interruptions, and the exam expects you to know the machinery, not just the caveat. Spot fits work that is stateless, fault-tolerant, or checkpointable: batch and big-data processing, containerized workers, CI/CD builds, rendering, queue-driven jobs where a killed task simply returns to the queue. It never fits databases, stateful sessions, or anything a two-minute notice would corrupt — an option putting the web tier's only capacity or an RDS workload on Spot is self-eliminating.

The safe pattern is an Auto Scaling group with a mixed instances policy, which blends purchase options and instance types in one group. You set an On-Demand base — a fixed number of instances that are always On-Demand — and an On-Demand percentage above base, with the remainder Spot. A queue-processing fleet might run a small On-Demand base so work never fully stalls, with the bulk on Spot for the discount.

The second half of the policy is diversification. Each combination of instance type and Availability Zone is a separate Spot capacity pool, and pools run dry independently. Specifying multiple instance types (and sizes and generations) across multiple AZs gives the group many pools to draw from, so one pool's reclamation doesn't drain the fleet; the price-capacity-optimized allocation strategy then launches Spot from the pools with the best balance of low price and low interruption likelihood. A single-type, single-AZ Spot request is the fragile distractor. Complementary tactics: handle the two-minute interruption notice to checkpoint or drain, keep work idempotent and queue-driven so retries are free, and let capacity rebalancing proactively replace at-risk instances.

One mechanical note: modern Spot has no bidding. You pay the current Spot price, which AWS adjusts gradually on long-term supply and demand, and interruptions are driven by capacity, not by being outbid — so answer options built around "bidding strategies" are dated distractors.

Exam questions describe a fault-tolerant processing fleet and ask for MOST cost-effective yet resilient: the answer combines a mixed instances policy, a modest On-Demand base, Spot for the rest, and diversified types across AZs. Options are graded on exactly those pieces — all-Spot with one instance type fails resilience; all-On-Demand fails cost.

Purchase options discount the meter rate; right-sizing shrinks the meter itself, and the exam treats an oversized instance as waste no discount excuses. Right-sizing means matching the instance family to the workload's bottleneck and the size to its measured utilization. Families at Associate level are recognition work: general purpose (m) for balanced web and application tiers, compute optimized (c) for CPU-bound batch, encoding, and high-performance web serving, memory optimized (r, x) for in-memory caches and databases, storage optimized (i, d) for high local-disk I/O, and accelerated (g, p) for GPU work. A memory-bound workload on compute-optimized instances is mis-sized in kind, not just in size — the fix is the right family, sometimes at a smaller size and lower price.

The evidence comes from monitoring, and the recommendation engine is AWS Compute Optimizer: it analyzes CloudWatch utilization history and recommends specific instance-type changes, flagging over-provisioned and under-provisioned resources across EC2, Auto Scaling groups, EBS, and Lambda. When a scenario asks how to "identify underutilized instances" or "get right-sizing recommendations," Compute Optimizer is the purpose-built answer; the other cost tools (Cost Explorer, Budgets, the CUR, cost allocation tags) answer different questions, compared in the next section.

Two evergreen rules finish the section. Newer generations deliver better price-performance — a current-generation instance typically does the same work cheaper than its predecessor, so "upgrade the instance generation" is a legitimate cost answer, not just a performance one. And Graviton (AWS-designed Arm processors) offers better price-performance again for compatible workloads — Linux, open-source stacks, containers, and managed services; Compute Optimizer even flags Graviton candidates. On the exam, right-sizing answers beat "negotiate a bigger discount on the oversized fleet": fix the size, then discount what remains — a commitment bought on an over-provisioned fleet locks in the waste for one to three years, because its hourly amount stays the same after you downsize. Expect questions that show low CPU utilization on a large instance and grade you on downsizing (or re-family-ing) before any purchase-option change, and tool-swap distractors that offer Budgets to "identify underutilized instances" or Compute Optimizer to "alert on overspend."

The cost tools each answer one question, and Task 4.2 tests whether you pick the right one. Compute Optimizer recommends; Cost Explorer analyzes; AWS Budgets alerts; the Cost and Usage Report itemizes; cost allocation tags attribute.

Cost allocation tags must be activated. Tagging resources is not enough: a user-defined tag key appears in Cost Explorer and the CUR only after it is activated as a cost allocation tag in the Billing console — in an organization, by the management account — and by default only for costs incurred from activation onward. The management account can request a cost allocation tag backfill of up to 12 months to apply an activated tag to earlier costs, for resources that carried the tag at the time.

Consolidated billing in AWS Organizations combines member accounts into one bill. Usage is pooled for volume pricing, and Reserved Instance and Savings Plans discount sharing is on by default: a plan applies first to the account that bought it, then to matching usage in other accounts, so one account's idle commitment covers another's steady usage without buying more. The management account can turn sharing off for individual accounts — then their commitments apply only inside the purchasing account. That is the answer to "reduce cost across many accounts without changing workloads": join the accounts to an organization and keep sharing on, rather than buying a new commitment in every account.

Choosing the compute service is itself a cost decision, and the axis is utilization. Lambda bills per request and per GB-second of execution — you pay exactly for work performed, and idle costs zero. EC2 bills per second the instance runs, busy or not. Fargate sits between: serverless containers billed per vCPU-second and GB-second while the task runs, with no instances to manage but no per-request granularity either.

The decision list the exam rewards:

• Low, spiky, or unpredictable volume → Lambda. An API called a few thousand times a day, a nightly trigger, an event handler: per-request billing crushes an always-on instance that idles between calls. Constraints to respect: a 15-minute execution ceiling and an event-driven model — work that exceeds them disqualifies Lambda regardless of cost.
• Sustained, high-utilization workloads → EC2. When compute runs hot around the clock, always-on capacity is cheaper per unit of work than paying serverless premiums per invocation — and EC2 stacks with Savings Plans, RIs, and Spot for further discounts.
• Containers without cluster management → Fargate. Fargate removes the instance fleet (and the cost of managing and patching it) and never leaves you paying for unused instance headroom; it wins for intermittent or modest container workloads. At high sustained scale, EC2-backed containers become cheaper: you can bin-pack many tasks per instance — container density is precisely the utilization-optimization the guide names — and run the fleet on Spot or commitments. Compute Savings Plans discount Fargate and Lambda; EC2 Instance Savings Plans and RIs do not; there is no Spot for Lambda.

Fargate has three cost levers of its own. First, it bills the vCPU and memory a task requests in its task definition, not what the containers use — a task averaging 20% of its requested CPU is mostly paid-for headroom, so right-size the task definition. Second, steady Fargate usage takes a Compute Savings Plan. Third, Fargate Spot (the FARGATE_SPOT capacity provider) runs interruption-tolerant tasks at a discount on spare capacity, with a two-minute warning (a SIGTERM to the task and an EventBridge event) before a task is stopped; it never falls back to regular Fargate on its own, so a customer-facing service should not run on Fargate Spot alone.

An ECS capacity provider strategy mixes the two. Base is the minimum number of tasks placed on one provider before anything else (only one provider in a strategy can have a base); weight is the ratio in which the tasks above the base are split. Put the base on FARGATE for an uninterruptible floor and the larger weight on FARGATE_SPOT so most burst tasks run discounted — for example, FARGATE base 4 weight 1 with FARGATE_SPOT weight 4 keeps 4 regular tasks, then places four of every five additional tasks on Spot and one on regular Fargate. Swapping the weights would keep the same floor but send most burst tasks to full-price Fargate. Weights without a base give only a ratio, never a guaranteed floor.

Lambda has its own right-sizing lever: memory. The memory setting also scales CPU proportionally, and cost is memory × duration — so more memory that finishes a CPU-bound function proportionally faster can cost the same or less while running quicker, and an oversized allocation on an I/O-bound function is pure waste. Compute Optimizer recommends Lambda memory settings.

Exam scenarios state a traffic pattern and often an operational constraint ("no servers to manage"). Read utilization first — "a few requests per minute" points at Lambda, "consistently 70% busy" points at EC2 with commitments — then let the constraints eliminate what remains.

Elasticity saves money because capacity you release stops billing; the scaling questions in Task 4.2 are about matching the scaling method to the demand pattern. Horizontal scaling (more or fewer instances behind a load balancer) beats vertical scaling (a bigger instance) for both cost and availability: small instances added and removed in small steps track demand closely and can span Availability Zones, while a single vertically sized instance must be big enough for the peak all day, needs a stop/start to resize, and is one AZ's worth of availability. Horizontal scaling needs a stateless tier (sessions in ElastiCache or DynamoDB, not on the instance).

The half of Auto Scaling that saves money is scale-in. Which policy drives it depends on whether demand follows the clock:

Keeping a group fixed at peak size around the clock "to be safe" is the waste the exam wants removed — removing overnight capacity saves more than discounting it with a commitment.

Required availability differs by workload class, and paying production prices for non-production reliability is a design error. Production earns multi-AZ, redundant capacity; development, test, QA and batch tiers can run single-AZ, smaller, on Spot where work can be rerun, and only when in use. Commitments fit neither: a Savings Plan or RI bills every hour, so reserving an environment that runs a few hours a day pays for the idle hours.

Hibernation is the specialist lever: a hibernated instance saves its RAM contents to its encrypted EBS root volume, so on start it resumes with in-memory data and long-initializing processes already warm. While hibernated you pay for storage (including the RAM image), not compute. It fits intermittently used instances with expensive warm-up; a plain stop loses the memory, and staying running costs full price. Its prerequisites decide whether it is even possible:

• Hibernation must be enabled when the instance is launched; it cannot be turned on for an existing instance, running or stopped.
• Instance RAM must be less than 150 GiB on Linux (16 GiB or less on Windows), on a supported instance family and AMI (bare metal is not supported).
• The root volume must be an encrypted EBS volume (gp2/gp3/io1/io2), large enough to hold the RAM image plus the OS and applications — space for the RAM is allocated at launch.
• Spot Instances can hibernate only from a persistent Spot request.

A workload whose in-memory dataset needs more RAM than those limits allow cannot use hibernation; the design has to reduce warm-up another way (for example, loading from a faster store) or accept running time.

Some compute savings come from not doing the work in your fleet at all, and CloudFront is the main edge offload. Caching static and cacheable dynamic content at edge locations means those requests never reach the origin, so the origin fleet is sized for cache misses rather than total traffic, and data transfer from AWS origins to CloudFront is free. A scenario where "most requests fetch the same content and the EC2 fleet keeps scaling" is a CloudFront answer wearing a compute costume.

Request logic can also run at the edge, and the two options differ sharply in cost and capability:

Where a function runs decides how often it runs. Viewer events fire on every request, including cache hits, so a longer cache TTL reduces origin fetches but not viewer-function invocations. Origin events fire only on cache misses, after the cache lookup — cheaper, but logic that must run on every request (an auth check) or must shape the cache key (query-string normalization) cannot move there. High-volume, simple, no-network logic on viewer events is the CloudFront Functions case.

Hybrid and edge compute options are chosen by where the compute must physically sit and who operates the facility; the cost question is whether a constraint makes in-Region compute the wrong buy.

When both a Local Zone and Outposts would meet a latency goal, the deciding facts are residency and who houses the hardware: no residency need and no wish to buy, house or power equipment points to a Local Zone; a requirement that data stays on premises points to Outposts.

AWS Snowball Edge, still named in the exam guide as a hybrid compute option for disconnected or remote sites, is no longer available to new customers (since 7 November 2025); existing customers can keep using it. For a new account it is not a current choice — AWS points new customers to AWS DataSync for data transfer, and Outposts remains the on-premises compute option.

The load balancer is chosen by protocol and job first, cost second — the wrong type either cannot carry the traffic or needs extra services around it.

The cost patterns: "one load balancer per microservice" resolves to one ALB with host- or path-based routing rules, removing a fleet of hourly charges. "UDP plus a short list of fixed IPs" is a single NLB — an ALB cannot carry UDP, and adding Global Accelerator for fixed IPs is an extra service the NLB makes unnecessary. "Inspect all traffic with third-party appliances without changing application load balancers" is a Gateway Load Balancer, which keeps each flow on the same appliance and replaces failed ones; ALB and NLB treat targets as destinations, not inline hops.

Scenario. A retail company runs its e-commerce platform on EC2. Analysis shows a steady floor of 20 instances running 24/7 all year; daytime traffic adds up to 25 more instances that scale away overnight; and a nightly 3-hour analytics job runs on a separate fleet that can tolerate restarts, since it reprocesses from checkpoints in S3. The platform team also expects to move the web tier to a newer instance family within the year. What is the MOST cost-effective purchasing design?

Reasoning: Decompose by layer and match each to the cheapest option its requirements allow. The 20-instance floor is guaranteed usage — full-price On-Demand for it burns money, and Spot is disqualified because the floor must never disappear. A commitment is right; the planned family change decides which kind. Standard RIs and EC2 Instance Savings Plans lock the instance family, so the expected migration would strand their discount. A Compute Savings Plan gives up a little depth (up to 66% against 72% for the family-locked options) in exchange for following usage across families, sizes, and even to Fargate if the tier is containerized later — with Convertible RIs as the second-best commitment thanks to exchanges. The daytime layer is variable: On-Demand behind Auto Scaling, with target tracking (or scheduled scaling, since the pattern is daily) adding and, crucially, removing capacity — committing to this layer would pay for reserved capacity that idles most of the day. The analytics fleet announces its own answer: checkpointed, restartable, batch — Spot, at up to 90% off, diversified across instance pools so a reclaim delays rather than derails the job.

Eliminating the distractors: "Buy 45 Standard RIs" commits to peak — 25 of them idle overnight, and the family lock fights the migration plan. "Run everything On-Demand for flexibility" pays full price for a floor that has not varied all year. "Use Spot for the entire platform" puts the un-interruptible baseline on reclaimable capacity — a requirement violation, not a saving. "Compute Savings Plan for all 45 instances plus the batch fleet" over-commits: the commitment is billed hourly whether used or not, and it cannot be scheduled for daytime only, so sizing it beyond the steady baseline recreates the idle-reservation problem the layering exists to avoid.

Scenario. A media company transcodes uploaded videos. Jobs arrive on an SQS queue; each takes 5–20 minutes; a failed job is simply retried, and results land in S3. The current design is an Auto Scaling group of one large On-Demand instance type scaling on queue depth. Finance wants the cost cut substantially; engineering insists the queue must keep draining even during capacity disruptions. What should the architect propose?

Reasoning: Check Spot's admission test first: queue-driven, idempotent, checkpoint-free-but-retryable work with results in S3 is the textbook interruption-tolerant workload, so the up-to-90% discount is available if the design absorbs reclaims. The naive proposal — switch the ASG to Spot with the same single instance type — fails engineering's constraint: one instance type in each AZ is one capacity pool, and when that pool is reclaimed or unavailable, the whole fleet stalls at once. The robust answer is a mixed instances policy: keep a small On-Demand base so the queue always drains even in a Spot drought, set a high Spot percentage above base, and diversify across several instance types, sizes, and generations in multiple AZs — many pools, so reclamations hit a slice of capacity, not all of it. Use the price-capacity-optimized allocation strategy to favor deep, cheap pools, enable capacity rebalancing, and handle the two-minute interruption notice to stop pulling new messages and let in-flight work finish or return to the queue (SQS visibility timeout makes the retry automatic). Since transcoding is CPU-bound, the same review should right-size the "one large" type — a modern compute-optimized generation, with Graviton evaluated for the codec stack.

Eliminating the distractors: "Reserved Instances for the transcoding fleet" mismatches shape — the fleet scales with queue depth, and commitments only pay on steady utilization. "All Spot, single type, no base" is the fragility trap engineering vetoed. "Move transcoding to Lambda" hits the 15-minute execution ceiling for the longest jobs and mispays for sustained CPU-heavy work. The mixed-instances design is the only option that is simultaneously the cheapest and still meets the always-draining requirement — which is the entire skill Domain 4 measures.