Right-sizing, autoscaling and getting performance per pound

Why this matters

Optimisation is the objective where cloud work differs most from traditional infrastructure work. On owned hardware, an over-specified server is a one-off purchase you stop thinking about. In a cloud it is a recurring charge that continues every hour, forever, and nobody notices because nothing is broken.

CompTIA pairs performance and cost in the same bullet deliberately. They are the same lever pulled in opposite directions, and the skill being tested is finding the point where a workload meets its requirement without paying for capacity it never uses.

The habits here also feed objective 1.8 directly: optimisation is what you do after the bill tells you where the money went.

The lesson

Measuring before resizing, and the utilisation figure that argues for a smaller instance

Never resize on intuition. Measure first, over a window long enough to contain the workload's actual peak — a week at minimum, a month if there is a monthly cycle, and longer if the business has a season.

What to look at, and the trap in each:

• CPU utilisation. The easiest metric and the most misleading on its own. Average utilisation of 8% with a daily peak of 85% is not an over-sized instance; it is a peaky workload. Look at the percentiles, not the mean.
• Memory utilisation. Usually not visible to the provider — the hypervisor sees memory allocated to the guest, not used inside it. You need an in-guest agent. A right-sizing exercise that ignores memory because the console did not show it is how a database gets moved onto an instance that cannot hold its working set.
• Storage IOPS and throughput, separately, per objective 1.2.
• Network throughput, which is capped by instance size.

The figure that genuinely argues for a smaller instance is a sustained peak well below the instance's capability — for example a 95th-percentile CPU under about 40% with memory and network comfortably clear, across a full cycle. The figure that argues for a different family rather than a smaller one is an imbalance: CPU at 10% while memory sits at 90% says memory-optimised, not smaller.

Change one dimension at a time and re-measure. And right-size down in steps — halving an instance and discovering the peak was real is a worse outcome than two conservative reductions.

Vertical and horizontal scaling, and the workloads that can only take one of them

Vertical scaling (scale up) means a bigger instance. Simple, works for anything including software that cannot be clustered, and requires no application change. Its limits are real: there is a largest instance, it usually needs a restart, and it leaves a single point of failure.

Horizontal scaling (scale out) means more instances behind a load balancer. Effectively unbounded, improves availability, and allows fine-grained scaling. It requires the application to tolerate it.

The precondition is statelessness, and this is the heart of the objective:

• Session state held in an instance's memory means a user's next request must reach the same instance. Sticky sessions make that work and undermine the benefit — load becomes uneven and losing an instance logs its users out.
• The right answer is to move state out: a shared cache or datastore for sessions, object storage for uploaded files, a database for everything durable.

Workloads that can only scale vertically: traditional relational database primaries, licensed software bound to one machine, and anything with an unavoidable in-memory working set. Workloads that should scale horizontally: web and API tiers, queue consumers, stateless processing, containers.

The practical pattern is both — scale the stateless tiers out, and scale the stateful ones up until a genuine sharding or managed-service answer is justified.

Autoscaling on the right signal, and the metric that scales you into a bigger bill

Autoscaling adjusts instance count automatically. Its quality depends almost entirely on the signal it watches.

Three approaches, for three demand shapes:

• Scheduled. Demand is predictable by clock or calendar — office hours, a nightly batch, a known campaign. Cheapest and most reliable when it applies.
• Reactive (metric-based). Scale on an observed measure crossing a threshold. The general case.
• Predictive. Forecast from history and scale ahead of demand. Useful where instances take a long time to become useful.

Choosing the metric is where it goes right or wrong:

• CPU is the default and is often wrong. A web tier bound by a downstream database shows high CPU only rarely; scaling on CPU adds instances that make the database contention worse.
• Request rate or concurrency is usually better for a front end.
• Queue depth is the best signal for worker fleets: it directly measures unserved work, and it degrades gracefully.
• Application latency matches the user's experience but reacts late.

The failure the heading refers to is the scaling loop that spends money without fixing anything: the real constraint is a shared dependency — a database, a third-party API, a lock — and adding instances increases pressure on it, which worsens the metric, which adds more instances. The bill rises and latency does not improve. Always ask what the actual bottleneck is before attaching a scaling policy to it.

Two practical settings: cooldown periods, to stop the group reacting to its own last action and flapping; and sensible minimums and maximums, because a maximum is the only thing standing between a traffic anomaly and an unbounded bill.

Storage tiers and lifecycle rules that move cold data without anyone deciding to

Storage is where optimisation is most nearly free, because it requires no application change.

Object storage is offered in tiers that trade retrieval cost and speed against storage price: a standard tier for frequent access, an infrequent-access tier that is cheaper to store and more expensive to read, and archive tiers that are very cheap and take minutes to hours to retrieve.

The mechanism that matters is the lifecycle rule: a policy that moves objects between tiers by age, or deletes them, automatically. Set it once and the savings accrue without anyone making a decision.

Watch for three things the exam likes:

• Minimum storage durations. Cheaper tiers often bill a minimum period, so moving short-lived data into them costs more, not less.
• Retrieval charges and times. An archive tier is wrong for anything that might be needed quickly, and restore time is a real constraint on using archives as backups.
• Per-object overheads, which make archiving millions of tiny objects inefficient. Aggregate first.

Also automate deletion: old snapshots, previous object versions, detached volumes and stale logs accumulate silently, and a lifecycle rule is the only thing that reliably removes them.

Compute purchasing models as an optimisation lever that changes no architecture

The purchasing decisions from objective 1.2 are the fastest optimisation available, because they change the bill without changing anything technical.

The sequence that actually works, in order:

1. Turn off what is not needed. Non-production environments outside working hours are typically two-thirds of their hours wasted. Scheduled start/stop is the single highest-return change in most estates.
2. Right-size what remains, using the measurements above.
3. Then commit. Reserved or committed-use discounts apply to the workload as it now is. Committing first and right-sizing afterwards leaves you paying for a commitment to capacity you no longer use — the standard mistake, and a likely exam distractor.
4. Use spot for interruptible work — batch, CI, rendering, anything that can be killed and retried.

The order matters, and it is the examinable part. Optimise, then commit.

What to take into the exam

• Measure before resizing, over a full cycle, and use percentiles rather than averages. Memory usually needs an in-guest agent.
• Vertical = simple, capped, needs a restart. Horizontal = unbounded, needs statelessness. Sticky sessions are a workaround that costs the benefit.
• Pick the autoscaling signal that measures unserved work — queue depth, concurrency — not CPU by reflex. Scaling against a shared bottleneck spends money without helping.
• Cooldowns prevent flapping; a maximum is the only guard against an unbounded bill.
• Lifecycle rules move and delete cold data automatically; beware minimum durations, retrieval costs and retrieval times.
• Turn off, right-size, then commit. Committing before right-sizing locks in the waste.