Rightsizing Compute

Why this matters

You've entered the Optimize phase (module 00), and for most organizations the biggest single lever is embarrassingly simple: they're paying for compute they don't use. Over-provisioned VM SKUs, AKS node pools sized for a load that never came, Container Apps with 4x the CPU they touch — this is the most common and most recoverable waste in any cloud bill. Rightsizing is the discipline of matching provisioned capacity to actual demand. But it has a sharp edge that separates real FinOps from naive cost-cutting: a rightsizing recommendation that's correct on average can be catastrophically wrong for a bursty or spiky workload — and blindly applying Advisor's suggestions is how a $50/month saving becomes a $50,000 outage. This module teaches both the mechanics and the judgment.

Concepts

Azure Advisor is your automated Optimize backlog

Azure Advisor is a free, built-in service that continuously analyzes your resources and emits recommendations across five categories; the Cost category is a ready-made Optimize backlog. Its cost recommendations typically include: rightsize or shut down underutilized VMs (based on observed CPU/network over a lookback window, usually ~7-14 days), buy reserved instances/savings plans for steady workloads (module 05), delete unattached public IPs and idle resources (module 04 territory), and more. Each recommendation carries an estimated monthly/annual savings and an impact rating. Advisor is where the Optimize phase gets concrete — instead of "we should be more efficient," it's a scored list of specific actions with dollar figures. But — and this is the whole judgment lesson — Advisor's savings estimate assumes its recommendation is safe to apply, and it doesn't know your workload's shape or its SLOs (track 20). It sees average utilization; it can't see the 9am spike or the month-end batch. Treat Advisor as a backlog to triage, not a set of commands to run.

Rightsizing a VM: SKU families, and why "smaller" isn't one axis

Rightsizing a VM means changing its SKU to better fit observed usage. Azure VM SKUs come in families tuned for different ratios: general-purpose (D-series, balanced CPU:memory), compute-optimized (F-series, high CPU:memory), memory-optimized (E-series, high memory:CPU), burstable (B-series, cheap baseline with burst credits — key below), and more. Rightsizing isn't only "go smaller within a family" (e.g. D4s_v5 → D2s_v5, halving vCPU/RAM/cost); it's often "move to the right family" — a VM using 80% memory but 10% CPU is wasting money on a balanced D-series and belongs on a memory-optimized E-series, possibly cheaper while better fit. The mechanics are easy (az vm resize); the skill is reading utilization to pick the right family and size. Two cautions: resizing usually requires a reboot/deallocate (brief downtime — plan it), and not every SKU is available in every region/zone, so a resize can fail on capacity.

Rightsizing AKS node pools (track 07 callback)

On AKS (track 07), rightsizing operates at two levels, and conflating them is a classic error. Node-level: the VM SKU of the node pool — the same SKU judgment as above, applied to worker nodes. You can't resize nodes in place; you add a new node pool with the right SKU, cordon/drain the old one, and delete it (the safe migration pattern from track 07). Cluster-level: the Cluster Autoscaler (track 07 module 05) sizes the number of nodes to pending pods — so rightsizing here means setting sensible --min-count/--max-count and, above all, setting pod resource requests correctly, because the autoscaler and the scheduler bin-pack on requests, not actual usage. The subtle, expensive AKS waste: pods with inflated CPU/memory requests reserve capacity they never use, forcing the autoscaler to add nodes you're paying for to satisfy phantom demand. So AKS rightsizing is often not "smaller nodes" but "honest pod requests," after which the autoscaler naturally runs fewer nodes. Tools like the Vertical Pod Autoscaler (VPA) in recommendation mode surface right-sized requests from observed usage — the Kubernetes-native analog of Advisor.

Rightsizing Container Apps allocations (track 06 callback)

On Azure Container Apps (track 06), you don't manage VMs at all — you set a CPU/memory allocation per replica (e.g. 0.5 vCPU / 1 GiB), in fixed valid combinations, and you pay per the vCPU-seconds and GiB-seconds your replicas consume while running. Rightsizing here is lowering the per-replica allocation to fit actual usage and, just as importantly, tuning the KEDA scale rules (track 06 module 03) — especially scale-to-zero (minReplicas: 0), the single biggest Container Apps cost lever, so an idle app costs nothing instead of holding warm replicas. The interplay matters: an over-generous per-replica allocation multiplied across maxReplicas under load is where Container Apps bills add up. Because Container Apps abstracts the node (track 06 vs track 07's hand-managed nodes), rightsizing is simpler here — allocation + scale rules — but the same principle holds: match provisioned capacity to real demand, and let it scale to zero when there's no demand at all.

The bursty-workload trap: when the recommendation is wrong

Here is the judgment that separates FinOps from cost-cutting. Advisor (and any average-utilization tool) computes recommendations from average or percentile CPU over a lookback window. A workload with a low average but sharp bursts — a payment service quiet all day that spikes at checkout, a batch job that pegs the CPU for 20 minutes at 2am, a Black-Friday retailer — has a low average and so gets a "rightsize down" recommendation. Applying it removes exactly the headroom the burst needs, causing throttling, latency-SLO breaches (track 20), or an outage precisely when the workload matters most. The saving ($X/month) is real; the risk (a checkout outage) dwarfs it. The correct FinOps move is not "obey Advisor" and not "ignore Advisor" — it's look at the utilization distribution, not just the average: the p95/p99 and the peak, the shape over a representative window (including your known peak events). For a genuinely bursty workload, the right answer might be a burstable B-series (cheap baseline, bursts on credits) rather than a smaller fixed SKU, or keeping the size but adding autoscaling so capacity follows demand — not a static downsize. This is exactly module 00's "value, not just savings," made concrete, and it's this module's diagnose-and-fix.

Command reference

Advisor and utilization metrics are free to read. az vm resize and node-pool changes affect real (billable) resources — the exercises keep them tiny and clean them up.

Flag breakdown — az vm resize --resource-group rg-app --name vm-web --size Standard_B2s:

• --name vm-web — the VM to rightsize.
• --size Standard_B2s — the target SKU. Here a burstable B-series — chosen deliberately for a low-average/bursty workload so it keeps a cheap baseline but can burst on credits, instead of a fixed smaller SKU that would starve the burst. Verify availability with az vm list-skus -l <region> first.
• (implicit) resizing across some SKU families forces a deallocate/reboot — plan the brief downtime; the command may stop/start the VM.

Flag breakdown — read the utilization distribution before trusting a recommendation:

az monitor metrics list \
  --resource $(az vm show -g rg-app -n vm-web --query id -o tsv) \
  --metric "Percentage CPU" \
  --start-time 2026-07-10T00:00:00Z --end-time 2026-07-24T00:00:00Z \
  --interval PT1H \
  --aggregation Average Maximum \
  -o table

• --metric "Percentage CPU" — the utilization signal Advisor also uses.
• --start-time/--end-time — a representative window (here ~2 weeks); include a known peak event if you have one, or Advisor's blind spot becomes yours.
• --interval PT1H — hourly buckets; fine-grained enough to reveal spikes an average would hide.
• --aggregation Average Maximum — the whole point: pull Maximum alongside Average so you can see the peaks. A 12% average with a 95% max is a bursty workload Advisor will wrongly tell you to shrink.

Hands-on exercises

Advisor and metrics are free. The VM/Container App exercises create small, short-lived billable resources — clean them up. Advisor's lookback means brand-new resources won't have recommendations yet; use existing resources where you can.

1. Pull your cost recommendation backlog. Run az advisor recommendation list --category Cost -o table (add the extension if prompted). Read the estimated savings and impact. This is your Optimize to-do list — but a backlog to triage, not a script to run.

2. Inspect one recommendation in detail. Pick the highest-savings rightsizing recommendation and az advisor recommendation list --category Cost --query "[?contains(shortDescription.solution,'right')]" -o json. Note the target resource and the assumed saving. Write down: what does Advisor not know about this workload?

3. Read a VM's utilization distribution. For a real VM (or a small one you create), run the az monitor metrics list query from the command reference with --aggregation Average Maximum. Compare the average CPU to the maximum. Write both down — the gap between them is the whole rightsizing judgment.

4. Rightsize a VM down within a family. Create a small VM, then resize it:

   az group create -n rg-rightsize -l eastus
   az vm create -g rg-rightsize -n vm-demo --image Ubuntu2204 --size Standard_D2s_v5 \
     --admin-username azureuser --generate-ssh-keys --no-wait
   # ...wait for it, then rightsize down:
   az vm resize -g rg-rightsize -n vm-demo --size Standard_B1s
   

   Note the resize triggered a deallocate/reboot, and compare the two SKUs' hourly prices (portal or az vm list-skus). This is the mechanic; the judgment is next.

5. Choose a family, not just a size. Using az vm list-skus -l eastus --resource-type virtualMachines --query "[?contains(name,'B2')||contains(name,'D2')||contains(name,'E2')]" -o table, compare a general-purpose D2s_v5, a burstable B2s, and a memory-optimized E2s_v5 on vCPU/RAM. Write down which you'd pick for: a steady 80%-CPU service, a low-average bursty web app, and a memory-hungry cache. The answer is rarely "the smallest."

6. Rightsize a Container App allocation and enable scale-to-zero (track 06). If you have a Container App from track 06 (or make a trivial one), lower its allocation and let it scale to zero:

   az containerapp update -n <app> -g <rg> --cpu 0.25 --memory 0.5Gi
   az containerapp update -n <app> -g <rg> --min-replicas 0 --max-replicas 5
   

   Note that --min-replicas 0 means an idle app bills nothing — the single biggest lever on Container Apps (track 06 module 03's KEDA scaling, now framed as cost).

7. (AKS, design or real) Rightsize via honest pod requests. Reason through (or, if you have a cluster up, demonstrate) the AKS lever: a Deployment with requests: cpu: 1000m that actually uses 50m forces the autoscaler to reserve 20x the CPU it needs, adding nodes you pay for. Lower the request to a realistic value and observe (or explain) the autoscaler consolidating onto fewer nodes. Write the one-sentence rule: the autoscaler bin-packs on requests, not usage.

8. Measure impact before/after (the capstone skill). For the VM you resized in exercise 4, capture its daily cost before (module 01 Cost Analysis on that resource/RG over the prior week) and its daily cost after (over the following days — remember the 8-24h lag, so this spans two sessions). Write down the measured delta. "We rightsized" is a claim; "we cut this VM from $X to $Y/day, measured" is FinOps. The capstone requires exactly this before/after.

9. Diagnose and fix: the wrong recommendation for a bursty workload. The judgment exercise. Take a VM (real or hypothetical) that Advisor says to downsize from D2s_v5 to B1s for a $Z/month saving. Pull its CPU with --aggregation Average Maximum over a window including a peak: suppose the average is 9% but the maximum is 96% (a spike at checkout / a nightly batch). Diagnose: the recommendation is computed from the average and is wrong — B1s would throttle during the spike, breaching a latency SLO (track 20) and risking an outage worth far more than $Z. Fix, three correct options: (a) keep the size and add autoscaling so capacity follows the burst; (b) move to a burstable B-series sized for the burst (B2s+), whose credit model is built for low-average/spiky loads, rather than a fixed tiny SKU; (c) accept the recommendation only after confirming the peak is genuinely gone. The wrong fix is applying Advisor's number blindly. Lesson: rightsize on the utilization distribution (p95/max/peak events), never the average — a saving that risks an outage is a FinOps failure (module 00).

10. Clean up.

    az group delete -n rg-rightsize --yes --no-wait
    

    Delete any Container App/AKS resources you spun up unless a later module needs them. Confirm with az group show -n rg-rightsize -o table (gone).

Independent challenge

No commands given. Drawing on this module, Azure Advisor, the metric-reading from track 12 (observability), your AKS knowledge from track 07 (node pools, autoscaler) and Container Apps from track 06 (allocations, KEDA), and the before/after measurement discipline from module 01, produce a rightsizing proposal for three real (or realistic) workloads on your subscription: one VM, one AKS node pool or pod-request fix, and one Container App. For each, state the observed utilization distribution (average and peak/p95, not just average), the recommended change (target SKU/family, node count, allocation, or request value — with justification), the estimated saving, and — mandatory — the risk and how you'd de-risk it (SLO check, autoscaling, burstable SKU, staged rollout). Include at least one workload where the naive recommendation is wrong and you override it, explaining why in business terms. The deliverable is the written proposal with the exact metric queries backing each utilization claim.

Common mistakes & troubleshooting

• Applying Advisor recommendations blindly. Advisor sees average utilization, not your workload's shape or SLOs. Its estimate assumes the change is safe. Triage the backlog against the utilization distribution — never auto-apply.
• Reading the average and ignoring the peak. A 10% average with a 95% max is a bursty workload a downsize would break. Always pull Maximum/p95 alongside Average over a window that includes known peaks.
• Thinking rightsizing means "one size smaller." Often the win is a different family (memory-optimized for a memory-heavy VM, burstable for a spiky one) — sometimes cheaper and better-fitting than a smaller same-family SKU.
• Trying to resize AKS nodes in place. You can't — add a new right-SKU node pool, cordon/drain, and delete the old one (track 07's safe migration).
• Chasing node count instead of fixing pod requests. The autoscaler bin-packs on requests, not usage. Inflated requests reserve phantom capacity and add nodes you pay for; honest requests are the real AKS lever.
• Forgetting scale-to-zero on Container Apps. minReplicas: 0 makes an idle app free (track 06). Leaving a warm replica running 24/7 for a rarely-used app is pure waste.
• Claiming savings without measuring them. "We rightsized" is not a result. Capture before/after daily cost (module 01) across the data lag — the measured delta is the deliverable (and a capstone requirement).
• Ignoring the reboot/capacity cost of a resize. az vm resize can force a deallocate/reboot and can fail if the target SKU is unavailable in the region/zone. Plan the downtime and check availability first.

Checkpoint quiz

Write down your answer to each question before expanding it — checking without attempting first is the single easiest way to fool yourself into thinking you've learned this.

Next

Continue to 04-storage-and-data-cost-optimization — compute is usually the biggest lever, but storage and data are the quietest waste: orphaned disks billing for weeks (the exact track-14 trap), un-tiered blobs, and Log Analytics retention (track 12) silently accumulating. Next you'll sweep and tier the storage side of the bill.