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 doesn't 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's why the practical way to automate GCP cost optimization isn't a better checklist for a person. It's something 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 audited each leak with native tools: Billing reports, Recommender, Cloud Monitoring, the BigQuery billing export and gcloud sweeps.

If you ran that audit, you already know its limits: the findings were stale within a week, and every fix still needed a ticket. This part covers the step after: running those checks continuously with CloudThinker Optimize, what its first analysis looks like, and exactly what it will and won't do to your projects.

---

Why Recommender isn't the whole answer

Google's Recommender is good, and part two leaned on it heavily. Its limits are structural. It produces point-in-time suggestions, scoped per project and location, and it stops at the suggestion. Someone still has to visit each project, verify each item against a longer window, and turn the survivors into tickets.

The verification step is the one that matters. Part two's worked example had the machine-type recommender proposing a resize that would have pushed a month-end batch into swap. The recommendation wasn't wrong about 28 days of the month. Catching the other two took a person reading 35 days of metrics. Across forty projects, that judgment is what gets skipped when the audit runs long, and skipping it is how a rightsizing ticket turns into an incident.

01Detect

Cost moves

A SKU, a project or a coverage ratio changes in the daily billing data.

02Explain

Trace it

Down to the resources, the metrics and the change that started it.

03Judge

Verify

Rule out the readings that would make the fix wrong: spikes, dependencies, owners.

04Output

Proposal

One fix, its saving as a range, how to roll it back, and who must approve.

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

01Your organization

Google Cloud

• Billing export and CUD analysisSpend by SKU, project, label and coverage
• RecommenderIdle, machine type, Cloud SQL findings
• Compute, Cloud SQL, GKE, MonitoringInventory and the metrics behind it

Read-only service account

02Optimize

CloudThinker

• Scan every project dailyAll seven leaks from part one
• Verify before reportingSpikes, memory, owners, dependencies
• Propose the fixSaving as a range, with rollback notes

Nothing installed on VMs

03Where the team works

Chat and tickets

• Slack or TeamsFindings and approvals in the thread
• JiraOwned follow-ups with the evidence linked
• Audit trailWho approved what, and what changed

Nothing new to watch

Optimize 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, because none are granted at connection time. Setup is a service account, a couple of role bindings and pasting the credential into CloudThinker.

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

The agent 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:

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

---

One finding, investigated

Here's an inter-zone traffic finding the way CloudThinker works it. The details are illustrative.

On a Tuesday, the daily billing export shows Network Inter Zone Data Transfer Out in project prod-apps running about 40% above its 30-day average, and the trend started nine days ago. Three readings fit, and each predicts different evidence:

• Chatty services spread across zones. Predicts the cost sitting on the nodes of a regional GKE cluster, with traffic between two workloads.
• Clients reaching a zonal resource in another zone. Predicts traffic converging on one database, cache or VM in a single zone.
• Replication or backup traffic. Predicts a scheduled pattern tied to a storage or database job.

Which resources carry the cost? From the detailed billing export:

SELECT
  resource.name AS resource,
  ROUND(SUM(cost), 2) AS cost
FROM `project.dataset.gcp_billing_export_resource_v1_XXXXXX`
WHERE project.id = 'prod-apps'
  AND LOWER(sku.description) LIKE '%inter zone%'
  AND usage_start_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 14 DAY)
GROUP BY resource
ORDER BY cost DESC
LIMIT 10;

Almost all of it sits on the node VMs of GKE cluster prod-east, spread evenly across three zones. No single zonal resource stands out, which makes the second reading unlikely, and the pattern runs around the clock rather than on a schedule, which rules out the third.

Which workloads are talking? VPC Flow Logs are on for the node subnet. Grouping flows by source and destination workload and zone shows orders-api calling inventory-api for most of the cross-zone bytes. Nine days ago inventory-api went from 3 replicas to 9 after a release, and kube-proxy spreads requests across all endpoints regardless of zone. Roughly two-thirds of calls now cross a zone boundary.

One more check before proposing. Topology-aware routing keeps traffic in-zone only when each zone has enough endpoints to take its share. CloudThinker checks the deployment: 9 replicas, 3 per zone, with a topology spread constraint keeping them balanced. Safe to propose.

The finding, posted in the platform team's channel:

Inter-zone traffic in prod-apps: orders-api to inventory-api. Since the inventory-api scale-up nine days ago, about two-thirds of calls between the two services cross zones, roughly $4,100 a month in inter-zone SKUs at the current rate. Replicas are balanced 3 per zone. Proposed: enable topology-aware routing on the inventory-api Service. Rollback: remove the annotation. Needs approval from: the platform team, which owns prod-east.

The command it would run, once approved:

kubectl annotate service inventory-api -n prod \
  service.kubernetes.io/topology-mode=Auto

Whether to go further (zone affinity for the whole call path, or fewer replicas) is an architecture decision. The agent surfaces it, quantifies it and tracks whether the fix worked. It doesn't make that call.

---

You decide what the agent may touch

Deleting an already-snapshotted orphaned disk in a sandbox project and buying a three-year committed use discount aren't the same kind of decision. CloudThinker acts within Auto Mode, so you decide what runs on its own and what waits for approval.

Every action lands in an audit trail: what was found, what was proposed, who approved, what changed and when.

A first analysis, worked through

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

Call it $18,000 a month identified on day one, roughly a fifth of the bill. Look at the shape. 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. The mix is also estate-specific: a compute-heavy estate leads with idle instances and scheduling, this one leads with traffic. Ranking findings against your actual billing data, rather than walking a generic checklist, is what makes the table worth reading.

The traffic rows are the highest-value findings and the least automatable. The agent can show that 140 TB crosses zones each month and trace it to two services, as above. Adding zone affinity or putting a CDN in front of the media path is still your team's decision.

Why this beats the traditional approach

The deeper difference is where the hours go. In the audit, most of the time goes to collecting evidence across projects and too little to judging it. With the agent collecting, your time goes to the decision.

---

Prompts to try in your first session

Optimize is conversational. Ask in plain language, and each answer cites the underlying billing and monitoring data (the same evidence trail you built in part two), so you can verify it rather than trust it:

"Find unattached persistent disks across all projects, with their size, age and monthly cost. Propose only, change nothing."

"Analyze our committed use discount coverage against the stable baseline, list anything expiring in the next 90 days, and recommend commitments with the break-even point."

"Show egress and inter-zone traffic cost trends by project this quarter, and trace the biggest increase down to the services involved."

"Which non-production projects ran VMs over the weekend, and what would a business-hours instance schedule save?"

"Check the machine-type recommendations in prod against 35 days of CPU and memory, and tell me which ones are safe to apply."

The first one is a good start: the answer is immediate, easy to check against gcloud, and usually a little embarrassing.

---

What the agent won't do

An AI agent connected to your GCP organization should trigger hard questions. Here are the answers:

• Read-only by default. The connection roles grant no write access. Remediation needs scoped write permissions you grant explicitly, and still goes through Auto Mode.
• No silent deletes, resizes, schedules or purchases. Every change shows up with its evidence, whether it ran on its own or waited for approval.
• Nothing off the record. The audit trail holds every finding, proposal, approver and execution, with the evidence attached.
• No architecture decisions. It will tell you two services are moving 140 TB a month across zones. How to redesign the call path stays yours.

If you did the part-two audit yourself, the right mental model is that audit running daily across every project, with an approval-gated remediation queue attached. It's 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 to 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 decides yours. If you run multi-cloud, the same agent and the same Manual and Auto model cover the other providers: see the parallel guides for AWS and Azure.

Related reading

• Auto Mode: decide what runs on its own
• Optimize: continuous cloud cost optimization
• Introducing CloudThinker Optimize
• Automating Kubernetes cost optimization with an AI agent

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