Product

Automating GCP Cost Optimization with an AI Agent

Automate GCP cost optimization with an AI agent: read-only connect, continuous scans of 7 waste sources, and approval-gated fixes across every project.

·
gcpcostoptimizationfinopscostopsaiagent
Cover Image for Automating GCP Cost Optimization with an AI Agent

Automating GCP Cost Optimization with an AI Agent

Run gcloud projects list in any organization more than two years old and count the results. Most teams stop being surprised somewhere around project forty. Google Cloud's project model is excellent for isolation and bad for cost visibility: waste does not pile up in one account you can audit on a Friday afternoon — it scatters across dozens of projects, most of which nobody has opened since the quarter they were created. That is why the practical way to automate GCP cost optimization is not a better checklist for a human. It is a system that watches every project at once and never stops.

This is part three of our GCP series. Part one mapped where GCP money leaks. Part two showed how to audit each leak with native tools — billing export to BigQuery, Recommender, gcloud sweeps. If you did that audit, you already know its two limits: the findings were stale within a week, and every fix still needed a ticket. This article covers the third step — running those checks continuously with CloudThinker's CostOps agent, and being precise about what the agent will and will not do to your projects.

Connect with a read-only service account, in about five minutes

CostOps connects to Google Cloud through a dedicated service account holding read-only roles. Nothing is installed on your VMs, and no write credentials are stored — there are none to store, because none are granted at connection time. Setup is a service account, a couple of role bindings, and pasting the credential into CloudThinker; the whole flow takes about five minutes.

Two details matter for a skeptical review:

  • The grant is inspectable before you make it. The exact roles the agent requests, and why each is needed, are documented in the connection guide. Your security team can read the list, veto it, or scope it down before anything connects.
  • Scope follows your org structure. Bind the roles at project level to start narrow, or at folder or organization level to cover everything — including the sandbox projects that never make it into a manual audit. Given the sprawl problem above, org-level read access is usually the point.

Once the credential lands, the first scan starts on its own.

What continuous coverage adds over Recommender

Google's own Recommender is good, and part two leaned on it heavily. Its limits are structural, not qualitative: it produces point-in-time suggestions, scoped per project, and it stops at the suggestion. You still have to visit each project, triage each item, and turn the ones that survive into tickets. The agent's job is to remove exactly those three frictions — it watches all projects continuously, correlates findings with your billing data, and attaches a prepared remediation to each one.

Here are the seven waste sources it scans, and what the continuous version of each check buys you:

Waste source Why a point-in-time check falls short
Orphaned persistent disks and snapshots Every deploy can orphan a disk. A disk orphaned Tuesday should be a finding Tuesday, not next quarter.
Idle or oversized Compute Engine Utilization drifts. An instance sized correctly in March is oversized by June, and no one re-audits March's list.
CUD coverage gaps Baselines shift and commitments expire. Coverage is a moving target; a quarterly snapshot is stale in weeks.
Unused static IPs and idle LBs Small per item, constant in aggregate — the kind of waste that only stays at zero if something checks daily.
Over-provisioned Cloud SQL Needs a sustained utilization window to call safely; the agent maintains that window instead of rebuilding it.
Egress and inter-zone traffic Invisible in resource lists entirely — it only appears in billing data, and only if something is watching trends.
Non-prod running 24/7 Schedules decay. Someone disables the shutdown script for a demo, and it stays disabled until something notices.

Each finding arrives with its evidence — the utilization window, the current monthly cost from billing data, the projected saving as a range. It is the same material you assembled by hand in part two, produced daily instead of quarterly.

Graduated autonomy: four levels, set per action class, per environment

Detection without remediation is just a second Recommender. But handing write access to an agent on day one is not how any sane platform team operates either. CostOps resolves this with graduated autonomy — every class of action carries a level you assign, separately for each environment:

  • Notify — the agent reports the finding and does nothing else. This is the default for every action class, everywhere.
  • Suggest — the agent attaches a specific fix: the exact change, projected impact, rollback notes.
  • Approve — the agent stages the action and executes only after a named human approves it.
  • Autonomous — the agent executes and reports afterward.

The per-class, per-environment split is what makes the model usable in practice. Deleting an already-snapshotted orphaned disk in a sandbox project and purchasing a three-year committed use discount are not the same kind of decision, and they should not share an autonomy level. Most teams promote a single narrow action class in non-prod to Autonomous only after weeks of watching the agent be right at Approve — and leave anything touching production or money at Notify or Suggest indefinitely. Every finding, proposal, approval, and execution is recorded in a full audit trail.

A first analysis, worked through

The numbers below are illustrative — a composite drawn from first scans of larger GCP estates, here around $95K/month across roughly forty projects, with a traffic-heavy workload profile. Your estate will differ in both size and mix.

Finding What the first analysis showed Est. monthly waste
CUD coverage gap Coverage at 18% of a stable n2 baseline that supports roughly 60% ~$6,300
Inter-zone GKE traffic Two chatty services in one cluster spread across three zones; ~140 TB/month crossing zones ~$4,100
Internet egress Uncached media responses served straight from us-central1; CDN candidate ~$2,900
Idle Compute Engine 9 instances under 5% average CPU for 30+ days, scattered across 6 projects ~$1,800
Non-prod running 24/7 5 sandbox projects with VMs running through weekends ~$1,600
Over-provisioned Cloud SQL One HA instance at 16 vCPUs with p99 CPU around 11% ~$1,150
Orphaned disks and snapshots 44 unattached disks across 17 projects, plus snapshot chains for long-deleted VMs ~$520
Unused static IPs and idle LBs 9 reserved external addresses, 2 forwarding rules with near-zero traffic ~$80

Call it $18,000/month identified on day one — roughly a fifth of the bill. Two things about the shape are worth noticing. First, commitment coverage and traffic — CUD gap, inter-zone, egress — account for about 70% of the total, and none of the three shows up in a resource inventory; they only exist in billing data over time. Second, the mix is estate-specific. A compute-heavy estate leads with idle instances and scheduling; this one leads with traffic. A gcp cost optimization tool that ranks findings against your actual billing data, rather than walking a generic checklist, is what makes the first table worth reading.

One honest caveat on the traffic rows: they are the highest-value findings and the least automatable. The agent can show you that 140 TB crosses zones monthly and trace it to two services; deciding whether to add zone affinity or put a CDN in front of the media path is an architecture decision. The agent surfaces it, quantifies it, and tracks whether your fix worked. It does not make the call.

Prompts to try in your first session

CostOps is conversational. Alex is CloudThinker's cost engineering agent — you mention @alex in chat and ask in plain language:

  • @alex find orphaned persistent disks across all projects — the classic first prompt, because the answer is immediate, verifiable against gcloud, and usually mildly embarrassing.
  • @alex analyze CUD coverage and recommend commitments — returns current coverage against your stable baseline, with break-even math on the recommended purchases.
  • @alex show egress cost trends by service this quarter — the check almost nobody runs manually, because doing it by hand means writing BigQuery SQL against the billing export.

Every answer cites the underlying billing and monitoring data — the same evidence trail you built in part two — so you can verify each claim rather than take it on trust.

What has to be true before anything changes

An AI agent for cloud cost work connected to your GCP organization should trigger hard questions. The short answers:

  • Read-only by default. The connection roles grant no write access. Changing anything requires you to grant scoped write permissions and raise the autonomy level above Notify — two separate, deliberate steps.
  • Nothing changes without approval. No deletion, resize, schedule, or commitment purchase happens unless a human approves it — or you have explicitly set that exact action class to Autonomous for that exact environment.
  • Nothing happens off the record. The audit trail holds every finding, proposal, approver, and execution, with the evidence attached.

If you did the part-two audit yourself, the accurate mental model is: this is that audit running daily across every project, with an approval-gated remediation queue bolted on. It is continuous FinOps, not an autopilot.

From quarterly audit to standing habit

Parts one and two gave you the map and the manual method. What neither can give you is cadence — and on an estate of forty projects, cadence is the whole problem. Teams that move from periodic manual reviews to continuous, approval-gated optimization typically see a 30–50% reduction in cloud spend over the following months; treat that as a typical range, not a promise, since the mix in your first findings table determines yours. If you run multi-cloud, the same agent and the same autonomy model cover the other providers — see the parallel guides for AWS and Azure.

Try CloudThinker free — the free tier includes 100 premium credits, no card required — and follow the connection guide to see your own first findings table within the hour.