Cost Optimization Strategies for AWS and GCP Workloads That Actually Work

Most cloud cost-optimization advice stops at "turn off what you're not using," which is true, easy, and rarely worth more than a few percent once a team has been running for more than a year (the obviously-idle resources tend to get cleaned up early). The strategies that produce real, sustained savings — the kind that show up as a meaningfully different number on next quarter's bill — take more deliberate work. Here's what's actually moved the needle on client infrastructure audits, with real ranges, not marketing numbers.

Right-sizing: the audit that pays for itself first

Before any purchasing decision, right-sizing existing compute is almost always the highest-leverage first step, because most fleets are meaningfully over-provisioned — in our audits, it's common to find 30–40% of instances running at under 20% average CPU utilization, sized for a peak load that either never materialized or only happens for a few hours a month. AWS Compute Optimizer and GCP's Recommender both surface this automatically from actual usage data, for free, and the fix is usually just picking a smaller instance size — no architecture change required.

The trap here is optimizing for average utilization and getting bitten by the tail: an instance sized for 95th-percentile load with headroom for genuine spikes is safer than one sized tightly to the average, which will page someone the first time traffic has a bad day. Right-size against p95 or p99 usage over a meaningful window (30+ days, including any seasonal peak), not the mean.

Reserved capacity and committed use: real, but require confidence

AWS Reserved Instances (or the more flexible Savings Plans) and GCP Committed Use Discounts both trade a 1- or 3-year commitment for a real discount — typically 30–40% for a 1-year commitment and up to 60–72% for a 3-year commitment paid upfront, depending on the instance family and payment option. That's not a rounding error; on a baseline compute spend of $50,000/month, a well-targeted 3-year commitment on the stable, always-on portion of that fleet can save $15,000–20,000/month.

The discipline this requires: commit against your floor, not your average. Look at the last 12 months of usage and commit reserved/committed capacity to the level that's been running continuously the entire time — the part of your fleet that's never scaled below. Leave everything above that floor on-demand or spot. Committing against average usage means you're paying for reserved capacity you don't use during troughs, which erases a meaningful chunk of the savings.

Spot instances (AWS) / preemptible VMs (GCP): 60–90% off, for the right workloads

Spot capacity is priced at a steep discount — commonly 60–90% off on-demand — in exchange for the provider being able to reclaim it with short notice (a two-minute warning on AWS, similar on GCP). That makes it a poor fit for anything stateful or user-facing that can't tolerate interruption, and an excellent fit for batch processing, CI/CD runners, data pipeline workers, and any horizontally-scaled stateless service designed to handle instance loss gracefully (which, done right, most services in a well-architected system should be able to do anyway).

A pattern that's worked well for several clients: run the baseline, always-needed capacity on reserved instances, run the elastic portion that scales with load on a mix of on-demand and spot (spot for the bulk, with on-demand as a fallback when spot capacity isn't available, via AWS's capacity-optimized allocation strategy or GCP's automatic fallback), and never put anything on pure spot that a 2-minute-notice termination would actually hurt. For CI/CD runners specifically, we've seen teams cut that specific line item by 70%+ moving to spot, since a CI job that gets interrupted just retries.

Spot instances aren't cheaper compute — they're the same compute, sold at a discount, in exchange for accepting that the provider can take it back. Only put things there that can afford to lose the argument.

Autoscaling: the difference between "configured" and "actually tuned"

Nearly every client we audit has autoscaling configured. Far fewer have it tuned — the default scale-up/scale-down thresholds and cooldown periods that get set once during initial setup and never revisited. A scale-down cooldown that's too conservative (common default: 10–15 minutes) means the fleet stays oversized for a while after every traffic spike, quietly paying for capacity nobody's using anymore. A scale-up threshold that's too conservative means the opposite problem — degraded performance for real users while waiting to provision more capacity.

Scale-to-zero for non-production environments is the single most underused version of this: dev, staging, and QA environments that run 24/7 but are only actually used during business hours are, for most teams, paying for roughly 21 idle hours a day. A scheduled scale-down outside business hours (or a genuine scale-to-zero for environments that support it, like serverless-first staging setups) is close to free savings — no risk to production, immediate impact on the bill.

Storage tiering and egress: smaller line items, still real money

Object storage lifecycle policies that automatically transition infrequently-accessed data to cheaper storage classes (S3 Infrequent Access or Glacier, GCP's Nearline/Coldline) after a defined age are easy to set up and easy to forget once set — but on a large enough data lake, the difference between "everything in standard storage forever" and a properly tiered lifecycle policy is a meaningful recurring saving, often 40–60% on the storage line item for data older than a few months. Combine this with reducing unnecessary egress (caching aggressively at the CDN layer, and being deliberate about which services genuinely need to call out across regions or clouds — see our piece on multi-cloud architecture for how quickly that specific cost compounds) and the storage-and-transfer line items usually have as much headroom as compute does.

A realistic before/after

For illustration — a composite, representative profile drawn from patterns across several client engagements, not one specific client's real numbers: a mid-size SaaS company spending roughly $80,000/month across AWS compute, storage, and transfer, after a full pass of right-sizing (−12%), committed-use discounts on baseline capacity (−18%), spot for CI and batch workloads (−6%), tuned autoscaling and non-prod scale-down (−7%), and storage lifecycle policies (−4%), landed at a combined reduction in the 35–40% range — without removing any actual capacity the business needed, just paying the right price for the capacity it was already using.

None of these strategies are individually exotic. The reason they're consistently underused isn't lack of awareness — it's that they each require someone to own the ongoing tuning, not just the initial setup, and that ownership is exactly the kind of cross-cutting work that's easy to deprioritize until a bill gets uncomfortable enough to force the conversation.