Elastic Compute: Auto Scaling Policies, Lambda Tuning, and Compute Selection

Compute selection on SAA-C03 is a matching exercise along three dimensions: how long the work runs, what triggers it, and how much infrastructure you are willing to manage. Read those out of the scenario and the service names itself.

Lambda owns short, event-driven work: a request arrives, a file lands in S3, a message hits a queue, and a function runs for seconds or minutes — never more than 15 minutes — then disappears. No servers, no capacity planning, near-instant scale-out per event. The moment a scenario implies long-running processes, sustained connections, or specialized hardware, Lambda is out.

Fargate owns containers without servers: you bring a container image, define CPU and memory per task, and AWS runs it — no EC2 fleet to patch, size, or scale. It handles long-running services Lambda cannot, while keeping the no-instance-management property. "Containers" plus "least operational overhead" is the Fargate signature.

EC2 owns everything that needs control: specific instance hardware, GPUs, custom AMIs, OS-level agents, long-lived stateful processes, or licensing tied to hosts. Maximum flexibility, maximum management — which is why, under a LEAST-overhead qualifier, EC2 loses to a serverless option whenever the workload permits one.

AWS Batch owns large-scale batch jobs: it queues jobs, provisions right-sized compute (including Spot), runs work that takes hours, and tears capacity down after. EMR owns big-data frameworks: when the scenario says Spark, Hadoop, Hive, or Presto by name, EMR is the managed home for it — the next section draws that line precisely.

The exam tests this as elimination under a qualifier. A four-hour nightly job rules out Lambda on duration alone; a containerized API with "no infrastructure management" rules out EC2; a Spark migration rules in EMR. Notice that the dimensions are independent — a workload can be long-running and serverless (Fargate), or event-driven and hardware-bound (EC2 behind a queue) — so read all three before committing. Get the service right first: instance families, memory dials, and scaling policies are tuning within the choice, never a substitute for it.

Three services fight over "a lot of processing," and the exam separates them cleanly once you know each one's home ground.

Lambda wins when the units of work are small, independent, and event-shaped: resize each uploaded image, process each stream record, handle each API call. Its scale-out is per-event and effectively instant, but every invocation must finish inside 15 minutes, and you get no say in the underlying hardware. In a big-job scenario, Lambda is usually the distractor whose elimination sentence is the runtime: "each job takes several hours" ends the conversation.

AWS Batch wins when the work is jobs, plural and heavy: thousands of transcoding, simulation, genomics, or financial-modeling runs that each take minutes to hours. You submit jobs to a job queue with dependencies and priorities; a compute environment provisions appropriately sized instances — or Fargate capacity, or Spot Instances for the cost-sensitive variant — scales with the queue, and scales to zero when it drains. There is no runtime cap and no scheduler to build. The phrase "batch jobs" in a scenario is almost a service name: an answer that hand-builds the same thing from an Auto Scaling group, a custom queue poller, and cron is the LEAST-overhead elimination.

EMR wins on vocabulary: it is managed infrastructure for big-data frameworks. If the scenario's workload is already written for Spark, Hadoop, Hive, or Presto — or describes petabyte-scale analytics with those ecosystems — EMR runs it without you standing up and tuning a cluster by hand. The distinction from Batch is the framework: Batch runs your containerized or scripted jobs; EMR runs framework jobs. A team migrating on-premises Spark does not want Batch; a team rendering video frames does not want EMR.

The exam's shape here is a workload description plus all three as options. Ask two questions in order: does each unit of work fit in 15 minutes (no → Lambda out)? Is a named big-data framework involved (yes → EMR; no → Batch)? That two-step resolves nearly every variant.

When the service choice lands on EC2, the next decision is the instance family, and the rule is single: identify the resource the workload exhausts first, and buy the family built around it. The exam does not test instance-size trivia; it tests whether you can hear the bottleneck in the workload description.

General purpose (the M family) balances CPU, memory, and network — the default for web servers, application tiers, and small databases with no dominant hunger. Its sibling, the burstable T family, runs on CPU credits: a low baseline with the ability to burst, ideal for spiky, mostly-idle workloads like dev environments and low-traffic sites — and wrong for anything that needs sustained CPU, where exhausted credits become a mystery slowdown the exam likes to plant.

Compute optimized (C family) buys the highest CPU-to-memory ratio: batch processing, media transcoding, scientific modeling, high-performance web serving. Memory optimized (R and the larger X families) buys the reverse: in-memory caches and databases, real-time analytics over large datasets, anything whose working set must live in RAM. Storage optimized (I and D families) buys enormous, fast local NVMe instance store for I/O-hungry distributed databases and search clusters. Accelerated computing (P and G families, and purpose-built ML chips) buys GPUs and accelerators for training, inference, and graphics.

Selection is not a one-time act — right-sizing is a performance activity. An undersized instance throttles the workload; an oversized one wastes money without helping it. AWS Compute Optimizer is the recognition-level answer here: it analyzes utilization history and recommends instance types and sizes (it also covers Lambda memory and EBS volumes), so "identify over-provisioned or under-provisioned instances with the least effort" resolves to Compute Optimizer, not to a hand-rolled CloudWatch spreadsheet.

Exam questions state the bottleneck in plain clothes — "in-memory analytics," "CPU-bound encoding," "millions of low-latency IOPS to local storage" — and list one family per option. Translate symptom to family, and treat a T-family instance mysteriously degrading under sustained load as the CPU-credit story until proven otherwise.

Lambda tuning questions reduce to a single fact with several consequences: memory is the only performance dial, and CPU scales with it proportionally. You do not pick vCPUs for a function; you pick a memory allocation, and more memory brings more CPU (and better network throughput) along with it.

The first consequence: a CPU-bound function gets faster by allocating more memory, even if it never touches the extra RAM. A scenario where a compute-heavy function is slow, and the answer options include "increase the function's memory allocation," is testing exactly this — raising memory is how you raise CPU. The second consequence is the cost twist the exam enjoys: Lambda bills on gigabyte-seconds, memory multiplied by duration. Doubling memory doubles the per-second rate, but if the added CPU cuts the duration enough, total cost can hold steady or even drop while latency improves. So "more memory" is not automatically "more expensive" — an elimination trap for options that reject tuning on cost grounds without doing the arithmetic.

The hard wall: 15 minutes maximum execution time, no exceptions. Any workload described in hours — or any job that cannot be decomposed into sub-15-minute units — disqualifies Lambda outright, which is the most common elimination sentence in compute-selection questions. The architectural responses to the wall are decomposition (Step Functions coordinating many short functions) or relocation (the job belongs on AWS Batch or Fargate).

Two more tuning levers at recognition level. Provisioned concurrency keeps function environments initialized so latency-sensitive APIs skip cold-start delay — the answer when a scenario complains about intermittent slow first requests. And Lambda's scaling model is per-event concurrency: it fans out horizontally without an Auto Scaling group, which is why no Lambda option ever pairs with a scaling policy.

On the exam, expect the memory-CPU link tested directly ("how do you give a function more CPU?"), the 15-minute cap as an eliminator, and cold starts answered by provisioned concurrency rather than by moving off Lambda.

Container questions are two decisions stacked: which orchestrator, then which launch type runs its tasks.

The orchestrator choice is requirement-driven, not taste-driven. Amazon ECS is the AWS-native orchestrator: simpler to operate, deeply integrated with IAM, load balancers, and CloudWatch, no cluster software of your own to run. It is the default when the scenario just says "containers" with no ecosystem constraint. Amazon EKS is managed Kubernetes, and it wins only when the scenario names its reasons: the team already runs Kubernetes and wants its manifests, tooling, and operators to carry over; the organization requires Kubernetes for portability across clouds or on-premises; or open-source Kubernetes ecosystem tools are a stated dependency. Absent a Kubernetes keyword, choosing EKS buys operational complexity for nothing — which is precisely how the exam frames the wrong answer.

The launch decision applies to both orchestrators. The Fargate launch type is serverless: each task gets its requested CPU and memory, and there are no EC2 instances to provision, patch, right-size, or scale underneath. Under a LEAST-operational-overhead qualifier, Fargate wins whenever nothing in the scenario demands host control. The EC2 launch type earns its keep when something does: GPU tasks, workloads needing specific instance types or custom AMIs, daemons that must run on every host, or a cost profile where sustained, dense workloads on reserved capacity beat per-task pricing.

Keep the layers straight, because distractors blur them: ECS and EKS decide how containers are orchestrated; Fargate and EC2 decide where they run. "EKS on Fargate" is a coherent architecture; "Fargate versus EKS" is a category error the answer options sometimes bait. Elasticity carries into this layer too: a containerized service scales by adjusting its running task count against load, the same policy logic as an Auto Scaling group — target tracking on utilization or request count per target — applied to tasks instead of instances.

The exam's container questions almost always carry a qualifier. "Migrate containerized microservices with the least infrastructure management" is ECS or EKS on Fargate — pick the orchestrator by whether Kubernetes is named. "Standardize on Kubernetes across environments" is EKS. "GPU-accelerated inference in containers" pushes the launch type to EC2.

An Auto Scaling group needs a policy that answers one question — when does capacity change, and by how much? — and SAA-C03 tests whether you can match four answers to four traffic shapes.

Target tracking is the default and the AWS recommendation: pick a metric and a value — keep average CPU utilization at 50%, keep request count per target at a set level — and the group adds and removes instances automatically to hold the target, like a thermostat. It requires no alarm arithmetic and self-adjusts to demand in either direction, which is why "simplest way to keep the fleet at a healthy utilization" resolves here.

Step scaling exists for when one target is not expressive enough: you define CloudWatch alarm thresholds with different adjustment magnitudes per breach severity — add a little capacity when the metric is slightly high, add a lot when it spikes hard. Choose it when the scenario demands custom thresholds or graduated responses; recognize that for ordinary "keep utilization reasonable" goals it is the higher-maintenance distractor next to target tracking.

Scheduled scaling handles known clocks: capacity raised at fixed times for predictable events — business hours, a nightly batch window, a planned marketing launch. It scales on the calendar, not on load, so it is wrong when the pattern is real but its magnitude varies.

Predictive scaling is the machine-learning answer: it studies historical load, forecasts recurring patterns, and provisions capacity ahead of the predicted demand. It fits cyclical traffic — weekday morning ramps, regular weekly rhythms — especially when instances take minutes to initialize, so purely reactive policies always lag the ramp. It pairs with target tracking, which corrects the forecast's errors in real time.

Two supporting concepts carry questions. Warm-up tells the group how long a new instance needs before it pulls its weight, so metrics do not trigger over-scaling while instances boot. Cooldown spaces scaling activities so the group sees the effect of one action before taking another. Both answer "the group keeps overshooting" scenarios: capacity added, metrics still hot because the new instances aren't serving yet, more capacity added, then a lurch past the need. The exam gives you a traffic story and four policies; the story's shape — steady target, custom severity tiers, fixed calendar, recurring forecastable cycle — is the answer, and policies can combine (scheduled or predictive setting the floor, target tracking handling the noise).

CPU is a proxy, and sometimes a bad one. The canonical case is the queue-driven worker fleet: producers drop jobs on an SQS queue, an Auto Scaling group of consumers processes them. Worker CPU tells you the workers are busy; it does not tell you the queue is ten minutes deep. The scaling signal that matters is backlog per instance — the number of visible messages in the queue divided by the number of running instances. You publish that as a custom CloudWatch metric and run a target tracking policy against the backlog each worker can clear within your latency target. Queue grows, fleet grows; queue drains, fleet shrinks — capacity follows work, not a proxy for work. The exam tells this story explicitly ("scale consumers based on the number of messages in the queue") and expects the custom-metric target-tracking answer over any CPU-based policy.

The pattern generalizes into the design principle behind it: decouple workloads so each tier scales independently. When a web tier calls a processing tier synchronously, the two must scale in lockstep, and a burst that outruns the processing tier turns into user-facing errors. Put a queue between them and the dynamics change: the web tier acknowledges quickly and scales on request load; the queue absorbs the burst as buffered depth; the worker tier scales on backlog at its own pace. Nothing is dropped, and each tier's Auto Scaling policy watches a signal native to that tier. Pub/sub topics (SNS, often fanned out to multiple queues) apply the same decoupling when several consumers need the same events.

This is also a performance answer, not just a resilience one: buffering converts an unabsorbable spike into a manageable queue depth, and independent scaling means you size each tier for its load instead of the worst tier's load. Choosing the signal is itself a tested skill: web fleets behind a load balancer scale well on request count per target, worker fleets on queue backlog, CPU-bound processors on utilization — the correct metric is whichever one moves first when the workload's real demand moves. On the exam, "traffic spikes cause lost requests" or "the processing tier cannot keep up during bursts" points at the queue-plus-independent-scaling redesign, with the SQS backlog metric driving the worker fleet.

Two levers improve compute performance without touching a scaling policy. Edge offload: putting CloudFront in front of an application caches static and cacheable dynamic responses at edge locations, so a large share of requests never reaches the origin at all — the origin fleet shrinks, latency drops for global users, and traffic spikes hit the CDN's capacity instead of yours. When a scenario describes origin servers strained by global read-heavy traffic, "add CloudFront" can outrank "add instances" — it removes the demand rather than absorbing it. At recognition level, know that light request-manipulation logic can run at the edge itself (CloudFront Functions and Lambda@Edge), moving small pieces of compute next to the user so the origin fleet is not scaled for work the edge can do. Hibernation, at recognition level: a hibernated EC2 instance saves its RAM to its EBS root volume and, on start, resumes with memory, caches, and long-lived processes intact — the fast-resume answer when boot-time initialization (warming large in-memory state) makes cold launches too slow for pre-provisioned standby capacity.

The two lookups that resolve most Task 3.2 questions:

Exam questions hide these rows inside operational stories; extraction is the skill. When two rows fit, the qualifier arbitrates — LEAST overhead favors the serverless row, MOST cost-effective favors Spot-friendly Batch or right-sized families.

Scenario 1. A ticketing platform's traffic climbs steeply every weekday from early morning to a midday peak, in a pattern that recurs week after week but whose height varies with the events on sale. Application instances take several minutes after launch to warm their caches before serving efficiently. Users report slow responses during the morning ramp. Which scaling approach fixes this with the LEAST ongoing effort?

Reasoning: The complaint is lag: by the time reactive policies see the metric move, demand has outrun capacity, and the minutes-long warm-up widens the gap. That eliminates target tracking and step scaling alone — both are reactive; step scaling just reacts in fancier increments. Scheduled scaling tempts because the clock recurs, but the magnitude varies with the sales calendar: a fixed schedule either over-provisions quiet days or under-provisions big ones, and someone has to keep editing it — failing LEAST ongoing effort. The pattern is recurring and learnable, and capacity must exist before demand: that is predictive scaling, forecasting from history and launching instances ahead of the ramp, paired with target tracking to correct forecast error in real time. Configure the instance warm-up time so new capacity is counted honestly. Recurring shape, variable magnitude, slow-to-ready instances — those three clues together are the predictive-scaling signature.

Scenario 2. A research company runs nightly genomics analyses: thousands of independent containerized jobs, each running two to six hours, submitted in a burst and processed under a strict budget. What compute architecture fits with the least management?

Reasoning: Run the two-step. Duration first: two to six hours obliterates Lambda — the 15-minute cap is absolute, and no decomposition story is offered. Framework second: nothing says Spark or Hadoop, so EMR is solving a problem this workload doesn't have. A self-managed Auto Scaling group with a hand-built job queue could work, but it recreates scheduling, prioritization, and scale-to-zero by hand — the classic LEAST-management elimination. AWS Batch is purpose-built for exactly this shape: submit the burst to a job queue, let a managed compute environment provision capacity, run the containers, and scale to zero at dawn. The strict budget adds the finisher: configure the compute environment to use Spot Instances — interruption-tolerant, retryable batch jobs are Spot's ideal tenant. Batch on Spot answers both the qualifier and the budget in one move.