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 — or running independent containerized simulations — does not want EMR in any form.

EMR itself comes in shapes that the exam separates by how much cluster you want to own:

Scheduled container jobs have their own simple answer. A containerized job that runs on a timetable — a weekly ETL export, say — runs as an Amazon ECS task on Fargate started by an Amazon EventBridge Scheduler schedule (or an EventBridge rule): the task launches, runs to completion, and stops, so nothing sits idle between runs and there is no instance to patch. Packaging the job as a Lambda container image does not escape the duration wall: a function deployed from a container image is still a Lambda function, and every invocation still ends at 15 minutes.

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 large local instance store — I for fast NVMe random IOPS (I/O-hungry distributed databases, search clusters), D for dense HDD storage and sequential throughput (data lakes, distributed file systems). 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.

Do not confuse it with AWS Trusted Advisor's low-utilization check. That check flags instances that look idle — low CPU and network over recent days — as candidates to stop or downsize. It does not model a better instance type or size, and by design it cannot notice an instance that is under-provisioned and starving for CPU or memory. When a scenario needs both directions (some instances too big, some too small) and concrete type-and-size recommendations, Compute Optimizer is the tool; Trusted Advisor answers only "which instances look idle?"

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 (128 MB to 10,240 MB), 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 uses only a fraction of its memory is testing exactly this — raising memory is how you raise CPU. The second consequence is the cost twist: 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".

The dial has a ceiling for some code. At 1,769 MB a function gets the equivalent of one full vCPU; above that, Lambda adds further vCPUs, up to six at 10,240 MB. Extra vCPUs only help code that runs work in parallel (multiple threads or processes). Single-threaded, CPU-bound code stops getting faster at about 1,769 MB — memory set above that point leaves the duration flat while the per-second price keeps rising, so cost goes up for nothing. Finding the right setting is measurement, not guesswork: test a few sizes, or use Compute Optimizer's Lambda memory recommendations.

The hard wall: 15 minutes maximum execution time, whether the function is deployed as a .zip archive or as a container image. Any workload described in hours — or any job that cannot be decomposed into sub-15-minute units — disqualifies Lambda outright. The architectural responses are decomposition (Step Functions coordinating many short functions) or relocation (the job belongs on AWS Batch or an ECS task on Fargate).

Startup latency is a separate problem from execution speed, with its own levers:

So a function that is slow on every request needs more memory; a function that is slow only on requests after a quiet period needs provisioned concurrency or SnapStart; the two causes are independent, so each symptom is diagnosed and fixed on its own — more memory never removes a cold start, and pre-initialization never speeds a warm request. SnapStart fits when paying for idle pre-initialized environments is unwelcome; provisioned concurrency fits when a fixed level of instantly ready capacity is the requirement. For SnapStart on Java there is no additional charge; for Python and .NET, snapshot caching and restoration are billed. 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.

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 capacity decision comes second. Fargate (available to both ECS and EKS) 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 — but Fargate offers no GPUs and no choice of instance type. For ECS, two EC2-backed options cover what Fargate cannot:

Read the constraint, then the table answers. GPU containers with least management and no image requirement → ECS Managed Instances. Any container fleet whose instances must boot from your own AMI → an Auto Scaling group capacity provider, because it is the only option that runs your own image. Daemons on every host, or dense reserved capacity cheaper than per-task pricing, also point to EC2-backed capacity.

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" rules out Fargate and leaves the two EC2-backed options, split by whether a custom AMI is required.

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 the policy types to traffic shapes. There are four families (target tracking, step and its older sibling simple scaling, scheduled, and predictive), and they combine.

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 creates and manages its own CloudWatch alarms, so there is no alarm arithmetic, 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 and you already know how much capacity each level of load needs. A step scaling policy is attached to one CloudWatch alarm; its step adjustments cover ranges of how far the metric is above (or below) that alarm's threshold — for example, add 1 instance when the breach is 0–10 units, add 3 when it is 10–30, add 6 beyond that. You do not create a separate alarm per step; you typically create one policy for scale-out and another for scale-in. Step scaling keeps responding to further alarm evaluations while a scaling activity is in progress.

Simple scaling is the older form: one alarm, one fixed adjustment, and then a cooldown during which the policy ignores further alarms until the activity completes and the cooldown expires. It cannot scale harder for a bigger breach and reacts slowly to sustained spikes, so AWS recommends step or target tracking instead; on the exam it is the distractor that reacts in one size only.

Scheduled scaling handles known clocks. A scheduled action sets the group's minimum, maximum, and/or desired capacity at a date and time (once, or on a recurring cron schedule) — business hours, a nightly batch window, a one-off launch. It scales on the calendar, not on load. Two traps: raising only the maximum launches nothing, because max is a ceiling and the group only grows when desired capacity rises; and a fixed schedule is wrong when the pattern recurs but its size varies, because someone has to keep editing the numbers.

Predictive scaling is the machine-learning answer: it analyses recent load history (it needs at least 24 hours, and learns daily and weekly patterns from up to the last 14 days), forecasts the coming days, and launches 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 runs in one of two modes: forecast only (the default) produces forecasts you can evaluate but changes no capacity, and forecast and scale actually provisions to the forecast. Predictive scaling pairs with target tracking, which corrects forecast error in real time. What it cannot do is anticipate a one-off event — a quarterly filing deadline, a single product launch — because nothing in the history repeats it. A known one-off spike is a scheduled action that raises minimum (and desired) capacity before the event and lowers it afterwards, with target tracking still handling the noise.

The exam gives you a traffic story and several policies; the story's shape — steady target, graduated severity tiers, fixed calendar or one-off date, recurring forecastable cycle — is the answer, and policies can combine (scheduled or predictive setting the floor, target tracking following the actual load). Whatever the policy, a group whose new instances take minutes to become useful also needs the warmup settings in the next section, or it will overshoot.

A group overshoots when it counts new instances as capacity but keeps judging load by metrics that don't yet include their help — so it adds more instances, then more, then lurches past the need. Four settings sound alike and do different jobs:

The warmup fixes the measurement; it does not make instances ready faster. When initialization itself is the problem — a slow bootstrap that installs and configures software, or an application that loads a large dataset into memory — a warm pool moves that work ahead of demand. Instances run their initialization once (lifecycle hooks can hold them until it finishes), then wait in the pool in one of three states:

Hibernation is the same mechanism you can use on a standalone instance: RAM saved to the EBS root volume, then resumed with memory, caches, and processes intact instead of a fresh boot. Inside a warm pool it becomes standby capacity that resumes with its working set already loaded. Combine the pieces rather than choosing between them: a warm pool shortens time-to-serve, and the default instance warmup keeps the policy from over-reacting during whatever startup time remains.

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 (or let target tracking compute it with metric math from the queue's ApproximateNumberOfMessagesVisible and the group's in-service instance count) and run a target tracking policy against it. Queue grows, fleet grows; queue drains, fleet shrinks — capacity follows work, not a proxy for work.

Why divide by instances at all? Because target tracking assumes the metric moves in proportion to capacity: add instances and the metric should fall. Raw ApproximateNumberOfMessagesVisible doesn't behave that way — the same 600 messages mean very different things to 2 workers and to 20, and adding workers does not change the queue length in the moment — so a target on raw queue length scales erratically. Backlog per instance does fall as workers are added, so the policy converges. The target value comes from your latency goal: acceptable latency ÷ average processing time per message. If a message takes 2 seconds and no message should wait more than 100 seconds, each instance can carry a backlog of 50, so the target is 50. 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.

Queues and topics solve different decoupling problems. An SQS queue delivers each message to one consumer: consumers polling the same queue compete, and whichever receives a message hides it from the others while it is processed. That is right for spreading work across identical workers, and wrong when several different services must each see every event — an audit log, a search indexer, and a notification service all needing each new document. That is publish/subscribe: the producer publishes once to an SNS topic, and the topic delivers a copy to every subscriber. The fan-out pattern subscribes one SQS queue per consuming service to the topic, so each service gets every message and its own buffer: a slow or offline consumer builds up its own backlog without delaying the others or the producer, and each consumer fleet scales on its own queue's backlog. (EventBridge offers the same publish-once, deliver-to-many model with content-based routing rules.)

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. Contrast AWS Global Accelerator: it gives an application static anycast IP addresses and carries users' TCP or UDP traffic over the AWS global network to the nearest healthy Regional endpoint, improving the network path and failover — but it caches nothing, so every request still reaches the origin. For read-heavy repeat content, CloudFront reduces origin load; Global Accelerator does not. Hibernation is the third lever: in a warm pool's Hibernated state (previous section), standby instances resume with memory, caches, and long-lived processes intact, so scale-out skips slow in-memory initialization.

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. Two details complete it: the policy must be in forecast and scale mode (forecast only changes nothing), and the group's default instance warmup should match the cache-warming time so new capacity is measured 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.