Google Cloud / Engineering case study
Optimizing Microsoft licensing on Google Cloud.
Connecting cloud inventory, licensing costs, and workload dependencies to recommendations engineers can review and apply.
The work, at a glance
I built an AI-assisted License Cost Optimization agent, or LCOp, for Microsoft workloads on Google Cloud. The framework combines an asynchronous data pipeline, resource topology, state drift checks, recommendation agents, and reviewed execution plans. In a sandbox benchmark, it identified about 2.7 times the estimated monthly savings of the baseline Gemini CLI.
Understand the environment
Reconcile resource inventory and billing data, map dependencies, and keep analysis aligned with live infrastructure.
Evaluate and apply changes
Compare optimization paths and generate Terraform or CLI plans with human review, health checks, and rollback instructions.
- Estimated savings vs. baseline in the sandbox benchmark
- 2.7×
- Mean time to a generated deliverable in the benchmark
- 3.01s
- Higher total token usage, a deliberate tradeoff
- 48%
01 / Context
The bill only tells part of the story.
For enterprise Microsoft workloads, infrastructure sizing and software licensing are tightly connected. An oversized virtual machine can carry unnecessary compute and licensing costs, while a database edition change can affect features that the application depends on.
The project began with a visibility problem: pay-as-you-go licensing appears in cloud billing, but bring-your-own-license agreements require additional context. Billing data alone could not explain the full environment or which changes made sense for a workload.
My goal was to give an agent enough structured evidence to explain those costs, compare optimization strategies, and produce an implementation plan an engineer could evaluate.
02 / Inventory & topology
Build the evidence before the conversation.
I built an asynchronous extraction, transformation, and loading pipeline using Python, Cloud Run, and BigQuery. It brought together live resource inventory, billing exports, and utilization data so each conversation could work from a prepared view of the project.
The understanding phase mapped relationships between virtual machines, disks, databases, networks, and identity services. Time-series utilization added context about how those resources behaved. That made it possible to reason about a proposed change in terms of both its cost and its dependencies.
I exposed the workflow through Model Context Protocol (MCP) tools for Gemini CLI, with an additional interface using Google’s Agent Development Kit and Vertex AI. Separating data collection from analysis reduced repeated discovery work and kept the interactive workflow focused.
Agent architecture
03 / State drift
Keep recommendations tied to the current environment.
A prepared inventory becomes stale when someone resizes an instance, changes a configuration, or removes a resource. I built a state comparator to detect those differences before downstream agents continued using an outdated view.
The comparator canonicalized resource records, filtered fields that changed without a meaningful configuration change, and compared state hashes. When it detected drift, it recorded the differences, refreshed the inventory, and invalidated dependent analysis and recommendations.
This became a central design constraint: a recommendation needed a traceable relationship to the infrastructure state that produced it. Rechecking that state was part of the workflow, including the path back to understanding when assumptions changed.
04 / Recommendation tradeoffs
A lower cost still needs a workable plan.
The recommendation phase combined deterministic licensing and resource checks with an LLM-as-a-judge review. Financial, reliability, and cloud architecture perspectives evaluated candidates against a shared rubric covering savings, feasibility, operational risk, and the ability to reverse a change.
The resulting recommendations ranged from idle-resource cleanup and rightsizing to SQL Server edition changes and more involved licensing or database migrations. Organizing these paths by effort and risk helped make the tradeoffs visible to the engineer reviewing them.
I also separated mutually exclusive strategies in the savings calculation. Resizing a database host and migrating that same database to another platform represent alternative plans; adding their full projected savings together would overstate the opportunity.
05 / Reviewed change plans
Make the proposed change inspectable.
The application phase generated Terraform or CLI artifacts alongside a seven-phase plan: safety verification, invariant verification, human review, implementation, health probing, rollback instructions, and observability.
Feedback during the design and progress reviews sharpened the human approval requirement, especially for actions such as deleting a disk or virtual machine. The workflow made the proposed commands and their consequences available for review before execution.
This also shaped what the agent had to return. A useful deliverable included the intended change, its prerequisites, a way to check workload health, and a recovery path if the outcome differed from the plan.
06 / Evaluation
More savings identified, with a larger token footprint.
I compared LCOp with the vanilla Gemini CLI in an internship sandbox. The evaluation used the same underlying telemetry, resource specifications, and pricing inputs, and compared estimated savings, time to a generated deliverable, and token usage.
| Metric | Gemini CLI baseline | LCOp agent |
|---|---|---|
| Estimated monthly savings | $1,514 | $4,114 |
| Mean time to deliverable | 7.45 seconds | 3.01 seconds |
| Input tokens | 7,500 | 8,880 |
| Output tokens | 1,900 | 5,000 |
| Total tokens | 9,400 | 13,880 |
The agent identified about 2.7× the estimated monthly savings and reduced mean time to a deliverable by approximately 60%. Total token usage increased by about 48%, reflecting the additional tool context and more detailed change artifacts.
The strongest gains were on SQL Server virtual machines and Cloud SQL instances. Results were comparable on Windows GKE nodes, storage, and Linux virtual machines, where the specialized licensing analysis added less.
These measurements describe the sandbox evaluation and projected opportunities. They do not establish realized customer savings, fleet-wide performance, or the time required to execute an infrastructure change.
07 / Handoff & reflection
The system around the agent matters.
I brought the framework through design review, implementation, a working dashboard, benchmarking, and handoff documentation. The production transition still required team-owned service accounts and permissions, pipeline health monitoring, and automated deployment.
The hardest problems included permissions, changing infrastructure state, and nondeterministic model behavior. They pushed me to make the data pipeline, validation boundaries, and evaluation criteria explicit.
Working with Pri, Luqi, Sampath, and Steve also changed how I communicated the project. I learned to lead with the customer’s problem, use a concrete workload to explain the system, and present the business impact alongside the engineering tradeoffs.
Outside work, the summer meant hikes at Rainier, Hoh, and Rattlesnake, plenty of racket sports, and time with the team around Seattle.