Cutting a legacy cloud environment's spend by a third

The situation

The client was spending about $14,700 a month across seven GCP projects, and nobody could say whether that number was right. Three problems stacked on top of each other: no trended view of spend (the billing console groups on one dimension at a time, and CSVs were pulled by hand), no anomaly detection (one production cost line had grown 16,128% quarter over quarter without anyone noticing), and no stable baseline, which meant every previous savings claim was a list-price estimate that couldn't be defended with numbers.

The single largest line item was SQL Server Enterprise licensing, including a $2,671-a-month Enterprise instance sitting on a development project that nobody could justify.

Audit before action

The obvious first move was a stop/start schedule: "QA is idle outside business hours, shut it down nights and weekends." Before touching anything, we ran a 14-day monitoring audit (hourly CPU and network across every candidate VM). It overturned the assumption:

• One VM ran a real overnight batch at 41.8% CPU at 1am on weeknights.
• Another fired a scheduled reporting job on Sunday mornings.

We shipped a weekends-only shutdown policy on eight VMs instead, with the batch and reporting machines excluded, and a one-command manual restart so a stopped box never blocks a developer.

The interventions

• SQL Server Enterprise to Standard on both the dev and prod databases, using a build-ahead runbook: the target instance is provisioned and parked before cutover, so the migration window is minutes, not hours.
• Right-sizing the QA database (8 vCPU to 4) with about five minutes of downtime, and post-change health verification (buffer-pool life, cache hit ratio) before calling it done.
• Decommissioning orphaned infrastructure: a legacy backup appliance and its 1TB storage volume, about $815 a month of hardware backing up a test environment, parked reversibly first, then retired.

Measure it or it didn't happen

Estimates lie. Midway through, we discovered the running change log was undercounting realized savings by 6 to 9x, because Cloud SQL for SQL Server splits its billing: compute goes under one service line, but the license fee bills under Compute Engine. Only a real measurement system catches that.

So we built one, entirely inside the client's own cloud account: GCP's billing export feeding BigQuery, a daily scheduled rollup, and five reusable SQL reports covering month-to-date versus baseline, per-project run-rate, a savings tracker, top movers, and an anomaly catcher that flags anything spiking past twice its 14-day median. The whole system costs about two cents a year in query fees and is reversible with one delete.

The result

The target environment's run-rate fell from $552.62 to $351.57 per day, a 36.4% reduction measured against billing actuals, with further savings banked and pending settlement. The measurement system now drives a monthly cost analysis delivered as a recurring service: every savings change is logged with its pre-change baseline and post-change reading, so the client never has to take our word for anything.