Turn Rightsizing Recommendations into a Reviewed, Safe Change Plan

Tier: Core · Hands-on time: ~45 minutes

This playbook uses AI to convert recommender output into a risk-ranked change plan with per-change rollback notes, while the decision to resize anything stays with the human who owns the workload's performance.

When to use

• •
  Quarterly cost pushes: you have 50–500 rightsizing recommendations and need to turn them into an actionable, prioritized batch.
• •
  Before renewing commitments (RIs/Savings Plans/CUDs) — rightsize first, commit second.
• •
  K8s requests/limits cleanup where VPA suggestions exist but nobody trusts them enough to apply.

Skip AI for a handful of recommendations on services you know well — your own judgment plus a load graph is faster and better.

Prerequisites

• •
  Exported recommender output (CSV/JSON) including current size, recommended size, utilization stats, and lookback window.
• •
  Utilization context the recommender does not see: burst patterns, batch jobs, seasonal peaks, failover headroom requirements.
• •
  A way to stage changes gradually: one instance group at a time, canary node pool, or non-prod first.
• •
  Acceptance that the gate is a load test or gradual rollout — never a bulk apply.

The workflow

1. 1.

   Export and annotate. Dump recommendations to CSV. Add two columns yourself before any prompting: owner and known-constraints (e.g., "month-end batch spike", "DR capacity, must stay warm", "licensed per-core"). This context is the difference between a plan and a spreadsheet.

2. 2.

   Ask for risk-ranked triage, not approval.

   Copy

   Attached: rightsizing recommendations with owner and known-constraints
   columns. For each row produce:
   - savings/month (from the data; do not estimate prices yourself)
   - risk class: LOW (stateless, autoscaled, low variance), MEDIUM (stateful
     or bursty), HIGH (constraint listed, DR/failover, or utilization
     lookback shorter than the workload's known cycle)
   - why: one line citing the utilization stats or constraint
   - verification step required before and after the change (load test,
     canary %, watch metric + threshold)
   Sort into three batches: apply-soon, needs-owner-review, do-not-touch.
   If lookback window < 31 days for anything flagged as cyclical, put it in
   do-not-touch and say why.
   

3. 3.

   Audit the HIGH/do-not-touch reasoning first. The model's most valuable output is what it refuses to batch. Check that everything with a known-constraints entry landed outside apply-soon. If any constrained row leaked into apply-soon, tighten the prompt and rerun — this is your safety regression test.

4. 4.

   Spot-check five apply-soon rows manually. Open real utilization graphs (not the recommender's summary stats) for five sampled rows: check p99 not just average, check the full business cycle, check burst credits on burstable families. If ≥1 of 5 fails your check, the batch is not trustworthy — re-triage with stricter rules.

5. 5.

   Generate the change plan artifacts. For the surviving apply-soon batch, have the AI draft: the IaC diff per change (instance type / requests-limits edits), a rollout order (lowest blast radius first), and a per-change rollback one-liner. All of it ships as a PR — reviewed by the workload owner, applied gradually.

6. 6.

   Close the loop with measurements. After each tranche, feed post-change utilization and any alert/latency deltas back in and ask for a one-paragraph tranche report: realized savings, incidents caused (target: zero), rows promoted from needs-review.

Tool variants

• Cloud-native recommenders + chat assistant: the default path; works identically for Compute Optimizer, Azure Advisor, GCP Recommender exports.
• K8s: VPA/Karpenter + AI review: feed VPA recommendations and kubectl top/Prometheus percentiles; the AI drafts requests/limits PRs per namespace with the same three-batch triage. Karpenter consolidation handles node-level sizing automatically — point the AI at workload-level requests instead.
• Autonomous rightsizing platforms (Cast.ai-class): if one is approved, use this playbook to define its guardrails (which namespaces, max change %, exclusion labels) rather than to duplicate its job.

Verification

• •
  Zero rows with known constraints in the apply-soon batch (checked mechanically, not by trust).
• •
  5-row manual spot-check passed against real p99 graphs across a full business cycle.
• •
  Every applied change went through PR review by the workload owner and a staged rollout with a named watch metric.
• •
  Post-change: no new saturation alerts or latency SLO burn attributable to the batch after one full cycle.

Pitfalls

• Average-utilization traps. Recommenders and LLMs both over-trust averages; the incident lives in p99 and in the monthly batch job the 14-day lookback never saw.
• Letting the AI invent prices. Savings figures must come from the recommender/billing data in the file; model-recalled instance pricing is stale and region-wrong.
• Bulk apply because the triage looked smart. The three-batch structure exists to slow you down exactly where slowness is cheap insurance.
• Ignoring licensing and reservation interactions. Downsizing licensed-per-core software or breaking RI coverage can cost more than it saves — that belongs in known-constraints.
• One-shot cleanup. Rightsizing untended regresses in a quarter; keep the prompt and re-run monthly.

Restricted-environment variant

• •
  Recommender exports from client accounts are client data: redact account IDs and workload names (SVC_A), or normalize sizes to relative classes before using a public assistant.
• •
  Client-safe path: run triage with a local model via Ollama — the reasoning is table-over-rows and works on 8B-class models — or the client's approved Bedrock/Azure OpenAI tenancy.
• •
  In managed-services contracts, resizing may require a client change request: have the AI draft the change-request text (change, reason, risk class, rollback) as part of step 5.

Success criteria

• •
  A recommendation pile that sat unactioned for months becomes a reviewed change plan in under an hour.
• •
  First tranche applied with zero performance incidents and measured realized savings.
• •
  Constrained/DR/cyclical workloads provably excluded — you can show the triage rule that caught them.
• •
  The team repeats this monthly with the saved prompt, and commitment purchases now happen after rightsizing.