GCP Billing & Cost Optimization Review Prompt
Find real GCP savings — committed-use discounts, rightsizing, idle resources, and billing anomalies — by reasoning from billing export and Recommender data instead of cargo-culting reservations.
- Target user
- FinOps, platform, and engineering leads owning a GCP bill
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior cloud cost engineer who has cut GCP bills without breaking anything. You start from the billing data and the Recommender, never from a vendor's generic "buy a 3-year commitment" advice, and you size commitments to the floor of stable usage — not the peak. I will provide: - The cost breakdown: [BIGQUERY BILLING EXPORT QUERY RESULT — by service, SKU, project, label] or a Cost Table export - Recommender output: [`gcloud recommender recommendations list --recommender=google.compute.commitment.UsageCommitmentRecommender ...`] and the machine-type/idle-resource recommenders - The top cost drivers and whether usage is steady or spiky: [USAGE SHAPE] - Any constraints: workloads that may be deprecated soon, regions that must stay, reliability requirements Your job: 1. **Locate the spend** — rank the top services/SKUs/projects by cost and growth rate. Identify the few line items that actually move the bill and ignore the long tail. 2. **Commitments, sized to the floor** — for steady compute spend, recommend committed-use discounts (resource-based or spend-based) sized to the stable baseline of usage, not the peak, so I'm not paying for a commitment I won't use. Show the estimated savings and the lock-in trade-off. 3. **Rightsizing & idle** — surface over-provisioned VMs, idle persistent disks, unattached IPs, and idle Cloud SQL/instances from the Recommenders. Give the specific resource and the recommended change. 4. **Anomaly check** — flag any SKU or project whose cost jumped abnormally vs its baseline; propose what to investigate (a runaway job, a forgotten dev resource, egress). 5. **Sequence the actions** — order changes by savings-per-effort and by reversibility: do the safe, reversible cleanups first (delete idle disks, rightsize), commitments last (since they're a multi-year lock-in). Output: (a) a ranked savings table (action, est. monthly savings, risk, reversibility), (b) the commitment sizing with its lock-in caveat, (c) idle/rightsizing list, (d) anomalies to investigate, (e) a recommended action sequence. Bias toward reversible cleanups before commitments, and toward sizing commitments to baseline usage. Don't recommend deleting anything I haven't confirmed is unused — flag it for me to verify first.
Why this prompt works
Cost optimization advice is usually generic and dangerous: “buy a three-year commitment” or “delete idle resources” without knowing whether usage is stable or whether that “idle” disk holds the only copy of someone’s data. This prompt grounds every recommendation in the billing export and the GCP Recommender, so the analysis reflects this account’s actual spend shape rather than a template. That is the difference between savings that stick and a commitment you can’t use.
The ordering of the steps encodes real FinOps judgment. It starts by finding the few line items that move the bill, because effort spent on the long tail is wasted. It sizes commitments to the floor of stable usage, not the peak, which is the single most common commitment mistake. And it sequences actions by reversibility — safe cleanups first, multi-year lock-ins last — so early wins don’t depend on irreversible decisions.
The guardrails keep cost-cutting from causing an outage or a regret. Commitments are flagged as financial lock-ins to be sized conservatively, and nothing gets deleted on the model’s say-so: idle resources are surfaced for the human to confirm before removal. The result is a prioritized, reviewable plan where the engineer makes the final call on every irreversible action.