Purpose
Turn a cloud bill into a prioritized, dollar-quantified optimization plan — identifying where spend is wasted, which commitments to buy, what to shut off, and how to govern cost so it stops creeping back. Solves the problem of cloud spend growing faster than usage without a systematic way to attack it.
When to Use
Invoke this skill when the user asks to:
- Reduce or optimize a monthly cloud bill (AWS, Azure, GCP, or multi-cloud)
- Diagnose why cloud spend is growing faster than headcount or revenue
- Decide between reserved instances, savings plans, and spot capacity
- Find and eliminate idle, orphaned, or overprovisioned resources
- Compare cost of running the same workload across cloud providers
- Stand up FinOps governance, tagging discipline, or cost accountability
Inputs Required
Before starting, collect:
- Cloud provider(s): AWS / Azure / GCP / multi-cloud, and primary regions
- Monthly spend: Total, and rough breakdown if known (compute / storage / data transfer / managed services / other)
- Top cost drivers: The 3–5 largest line items or services by spend
- Workload profile: Steady-state vs. spiky, production vs. non-prod split, batch/interruptible workloads present?
- Existing commitments: Current reserved instances, savings plans, or committed-use discounts and their coverage/utilization
- Growth trajectory: Is spend flat, growing, or shrinking, and by how much month-over-month
- Governance maturity: Current tagging discipline, cost allocation, and who owns cost decisions
If a spend breakdown or commitment coverage is unknown, use provider-typical distributions and note the assumption; flag data gaps as the first governance action.
Instructions
Step 1: Spend Baseline & Waste Signal Scan
Establish where the money goes and where the waste signals are.
- Break spend into compute / storage / data transfer / managed services / other as percentages of total
- Apply typical distribution sanity checks: compute usually 40–60%, data transfer >10% is a red flag, storage growing faster than compute suggests snapshot/log accumulation
- Flag the classic waste signals: low commitment coverage on steady workloads, on-demand pricing for predictable capacity, oversized instances, unattached storage volumes, idle load balancers/NAT gateways, cross-AZ/cross-region transfer, and untagged spend
- Name the single largest optimization lever before going deeper
Step 2: Rightsizing Analysis
Find overprovisioned compute and storage.
- CPU/memory utilization thresholds: instances sustaining <40% CPU and <50% memory are rightsizing candidates; recommend dropping one instance size and measuring
- Burstable opportunities: steady low-utilization workloads on fixed instances should move to burstable families (T-series/B-series/E2)
- Storage tiering: infrequently accessed data on hot/standard storage → move to infrequent-access or archive tiers; set lifecycle policies
- Overprovisioned managed services: oversized managed databases, over-allocated Kubernetes node pools, provisioned-throughput settings above actual usage
- Quantify: estimate % savings per rightsizing action and rank by dollar impact
Step 3: Commitment Strategy (Reserved vs. Savings Plans vs. Spot)
Match pricing model to workload predictability.
- Steady, predictable, 24/7 workloads: commit — Savings Plans (compute or instance) or Reserved Instances / Committed Use Discounts. Target commitment coverage of ~70–80% of steady baseline, never 100% (leaves room for change)
- 1-year vs. 3-year: 3-year for stable infra you're confident about; 1-year for anything uncertain — the discount delta rarely justifies locking in unstable workloads
- Savings Plans vs. RIs: Savings Plans for flexibility across instance families/regions; RIs when you need capacity reservation guarantees
- Interruptible/batch/stateless workloads: use Spot / preemptible — target 60–90% savings, with checkpointing and graceful interruption handling
- Non-prod: schedule shutdown outside business hours (nights/weekends) — often 65% reduction on dev/test compute
- Recommend a specific coverage target and estimated blended savings
Step 4: Idle & Orphaned Resource Elimination
Kill spend that produces no value.
- Unattached storage volumes and old snapshots: identify and set retention/deletion policies
- Idle load balancers, NAT gateways, elastic IPs: charged hourly regardless of traffic
- Zombie instances: running compute with no network traffic or attached workload
- Over-retained logs and backups: apply lifecycle expiration
- Abandoned dev/test environments and orphaned managed service instances
- Estimate the monthly recurring savings from cleanup and note that this is a one-time sweep requiring ongoing governance (Step 6)
Step 5: Multi-Cloud & Data Transfer Cost Comparison
Compare where relevant and attack egress.
- Data transfer is the silent killer: map cross-AZ, cross-region, and internet egress costs; co-locate chatty services, use private endpoints/VPC endpoints, add CDN caching to cut egress
- Multi-cloud comparison (only if genuinely portable): compare compute, egress, and managed-service equivalents for the specific workload — but weigh migration cost, egress-out fees, and operational overhead against the delta. Do not recommend migration for marginal savings
- Managed vs. self-hosted tradeoff: flag where a managed service premium is or isn't worth the operational savings at this team's scale
Step 6: FinOps Governance Recommendations
Prevent waste from returning.
- Tagging & allocation: enforce mandatory tags (owner, environment, cost-center, project); block or flag untagged resources; target >95% tagged spend
- Accountability model: showback (visibility) → chargeback (teams own their bill) as maturity increases
- Budgets & anomaly alerts: per-team budgets with automated alerts on spend spikes and forecast overruns
- Commitment lifecycle: quarterly review of commitment utilization/coverage; renewal cadence
- Guardrails: instance-size limits, auto-shutdown policies for non-prod, approval gates for high-cost resource types
- Cadence: define who reviews cost, how often, and what triggers action
Step 7: Ranked Optimization Plan & 90-Day Roadmap
Consolidate into an action plan.
- List optimization actions ranked by estimated monthly savings ÷ implementation effort
- Group into a 90-day roadmap: Days 0–30 (quick wins — idle cleanup, non-prod scheduling, obvious rightsizing), Days 31–60 (commitment purchases, storage tiering, egress fixes), Days 61–90 (governance rollout, tagging enforcement, review cadence)
- State total projected monthly and annualized savings, and the confidence level of the estimate
Output Format
- Structure: 7 sections; optimization actions as a ranked table (action / category / estimated monthly savings / effort / risk); roadmap as a 30/60/90-day phased plan
- Length: 1,000–1,400 words
- Format: Structured document with a savings-by-category summary table and a ranked action table
- Sections: Spend baseline & waste scan → Rightsizing → Commitment strategy → Idle resource elimination → Multi-cloud & data transfer → FinOps governance → Ranked plan & 90-day roadmap
- Tone: Cloud economics director — quantitative, decisive, tradeoff-aware; every recommendation tied to dollars and risk, no generic "monitor your usage" advice
Quality Checklist
Before delivering output, verify:
- [ ] Spend baseline is broken into the five categories with percentages that sum to 100%
- [ ] Every optimization action has an estimated dollar or percentage savings — not "could save money"
- [ ] Commitment strategy specifies a coverage target and distinguishes steady vs. interruptible workloads
- [ ] The ranked action table is ordered by savings-to-effort, not arbitrarily
- [ ] The 90-day roadmap places quick wins in days 0–30 and commitments/governance later
- [ ] A total projected monthly and annualized savings figure is stated with a confidence caveat
- [ ] Multi-cloud migration is only recommended when the delta clearly exceeds migration and egress cost
Notes
- The largest savings usually come from commitment coverage and idle elimination, not micro-rightsizing — attack those first
- Never recommend 100% commitment coverage; workloads change and stranded commitments become their own waste
- Data transfer costs are chronically underestimated — always inspect egress before concluding a workload is optimized
- Rightsizing and cleanup are one-time gains; without Step 6 governance, spend reliably creeps back within two quarters
- If provided data is incomplete, the first roadmap action should be instrumenting cost visibility and tagging, since you cannot govern what you cannot see
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills