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

Every EC2 cost question starts from the same menu. On-Demand is the baseline: full price, per-second billing, no commitment — right for unpredictable, short-lived, or first-time workloads where you cannot yet promise usage. Everything else is a discount bought with either a commitment or a tolerance for interruption.

Reserved Instances discount a specific instance configuration in exchange for a 1- or 3-year commitment, saving up to 72% versus On-Demand. Standard RIs give the deepest discount but lock the instance family — you can adjust some attributes, but you cannot swap a general-purpose reservation for a memory-optimized one. Convertible RIs trade a shallower discount for the right to exchange into different families, sizes, or operating systems during the term — the pick when a scenario commits to three years but expects its instance needs to change. Longer terms and more upfront payment (all, partial, or no upfront) deepen the discount.

Savings Plans commit to an amount of compute spend per hour for 1 or 3 years instead of to an instance configuration, and any eligible usage above the commitment simply bills On-Demand. Compute Savings Plans are the flexible variant: the discount follows your usage across instance family, size, Region, OS, and tenancy — and 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 — while staying flexible across sizes and OS within that family. The modern default for steady compute is a Savings Plan; RIs remain in scenarios needing their specific mechanics (and the RI concept extends to RDS and other services, where Savings Plans do not reach).

Spot Instances sell spare AWS capacity at up to 90% off, with the catch that AWS can reclaim them with a two-minute interruption notice. That single fact does all the exam work: Spot is only ever correct for interruption-tolerant work.

One more lever sits underneath the menu: where you run. EC2 prices differ by Region, so workloads with no latency or residency constraint — batch processing, analytics, disaster-recovery standby — can run in a lower-priced Region, while user-facing tiers stay near their users. The exam tests this menu by workload description: read the usage pattern, then match commitment, flexibility need, interruption tolerance, and placement freedom to the option.

Real workloads are not one shape, and the canonical Task 4.2 answer is a composite: 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 any interruptible work — batch jobs, queue processing, analytics — onto Spot. Each layer gets the deepest discount its reliability requirement allows, and no layer overcommits: a commitment sized to peak demand would pay for idle reserved capacity all night, while an all-On-Demand fleet pays full price for a baseline that never goes away.

Two supporting facts sharpen the mix. Commitments are Region-scoped or Region-flexible by type, so consolidate steady workloads where your commitments live. And under Organizations consolidated billing, unused RI and Savings Plan discounts share across member accounts, so one account's idle commitment covers another's matching usage — the answer to "reduce cost across many accounts without changing workloads." The exam presents the mix as a multi-part workload description; the correct option layers all three, and distractors either commit to the peak, run everything On-Demand, or put the un-interruptible tier on Spot.

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 — Cost Explorer also surfaces basic right-sizing suggestions and is the tool for spend analysis, while cost allocation tags, AWS Budgets alerts, and the Cost and Usage Report provide attribution, thresholds, and line-item detail. Tag by team, alert on forecasted overruns, analyze in Cost Explorer, drill into the CUR: the compute-cost feedback loop.

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. 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."

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; Spot does not apply to Lambda.

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 is a cost feature: capacity you release is capacity you stop paying for, and Task 4.2 tests scaling decisions with a cost lens. Horizontal scaling (more/fewer instances behind a load balancer) beats vertical scaling (a bigger instance) for cost as well as availability — small instances added and removed track demand closely, while a vertically sized instance must be big enough for peak all the time and requires downtime to resize. The half of Auto Scaling that saves money is scale-in: target tracking that removes instances as demand falls, so nights and weekends are not billed at daytime scale. For demand that is predictable by clock — business-hours traffic, month-end processing — scheduled scaling adds capacity just before the wave and, just as importantly, removes it after; it also pairs with the blunter version of the same idea, stopping non-production environments outside working hours, since dev and test fleets rarely need nights and weekends. Stopped instances stop billing for compute (EBS storage keeps billing).

That points at a broader principle the guide calls out: 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, and batch tiers can run single-AZ, on Spot, smaller, and only when in use. A scenario asking to cut costs on a dev/test environment resolves to some mix of off-hours stopping, Spot, and single-AZ — options that add Reserved capacity to a part-time environment are the trap, because commitments only pay off on high utilization.

Hibernation is the specialist lever: instead of stopping cold, a hibernated instance saves its RAM contents to its encrypted EBS root volume, so on start it resumes with memory state, caches, and long-boot applications already warm. While hibernated you pay for storage (including the RAM dump), not compute. It fits workloads with expensive warm-up — large in-memory caches, long-initializing processes — that are used intermittently: pre-warmed capacity without paying for idle instances. The exam cue is "resume quickly without rebuilding in-memory state"; plain stop/start loses the memory, and staying running costs full price.

Some compute savings come from not doing the work in your fleet at all. 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 — fewer instances, plus reduced origin data-transfer charges (transfer from origin to CloudFront costs nothing, and serving from cache spares origin egress). A scenario where "most requests fetch the same content and the EC2 fleet keeps scaling" is a CloudFront answer wearing a compute costume: cache the content, shrink the fleet. Lightweight request logic can additionally run in CloudFront's edge functions instead of on origin instances — recognition-level, same offload principle.

Hybrid options appear at recognition level, and the tell is a constraint that makes in-Region compute the wrong buy. AWS Outposts brings AWS-managed infrastructure into your data center — the answer when data gravity, local processing, or residency requirements would otherwise force expensive round-trips or a parallel on-premises stack. AWS Local Zones place compute near a metro for single-digit-millisecond latency to local users without building a self-managed site. Snowball Edge provides compute in disconnected or remote environments — ships, mines, field sites — where processing data where it is generated beats hauling raw data over a link that is slow, expensive, or absent. In each case the "cost optimization" is avoiding either massive data transfer or duplicate infrastructure; match the constraint, not the price tag.

Load balancers carry their own cost angle. An Application Load Balancer routes at layer 7 by host and path, so one ALB can front many services — consolidating services onto a single ALB with routing rules replaces a per-service fleet of load balancers and their hourly charges. A Network Load Balancer operates at layer 4 with very high throughput and lower per-unit processing cost at extreme volume — the pick when the workload is raw TCP/UDP at scale, needs static IPs, or demands ultra-low latency, not when HTTP routing is required. A Gateway Load Balancer exists for inline third-party appliance fleets — recognition only. The exam's shape: "a company runs one load balancer per microservice" resolves to ALB consolidation via path-based routing.

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 keeps up-to-72%-class savings while 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, 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.