Cutting Cloud Costs 30-40% Without a Full Re-Architecture

Cloud cost reviews tend to jump straight to "we should re-architect for serverless" or "we need to move to Kubernetes properly." Those conversations are usually a distraction from cheaper, faster wins sitting in the existing bill. On a typical mid-size enterprise AWS or Azure account we audit, 30-40% of spend can be recovered through rightsizing, commitment planning, and closing a handful of well-known egress traps — none of which require touching application code.

Rightsizing catches waste that accumulates silently

Instances and databases get sized for a peak load estimate made at launch, and nobody revisits it once the workload stabilizes. On a recent audit for a logistics client, we found production RDS instances provisioned at 3x the CPU and memory the actual query load ever used, based on 90 days of CloudWatch metrics — a sizing decision made 18 months earlier and never revisited.

The process that catches this reliably:

• Pull utilization metrics (CPU, memory, IOPS, network) over a full business cycle — 30 days minimum, 90 preferred to catch monthly or quarterly peaks like billing runs or reporting cycles.
• Flag anything running under 40% average utilization on its primary constrained resource as a rightsizing candidate, and confirm against peak (not just average) before downsizing.
• Rightsize compute before storage — compute waste is usually the larger dollar amount, and downsizing storage frequently requires downtime or migration that compute resizing doesn't.

Kubernetes clusters have their own version of this problem: pods requesting far more CPU/memory than they use, because a developer set requests conservatively once and nobody tuned them since. Tools like the Vertical Pod Autoscaler in recommendation mode, run for a few weeks before anyone changes anything, give you real usage data instead of guesses.

Reserved capacity and commitment discounts are left on the table constantly

This is the least technically interesting lever and often the largest single dollar impact. Enterprises running steady-state workloads on pure on-demand pricing are routinely paying 40-60% more than they need to for identical compute.

• Reserved Instances or Savings Plans (AWS) / Reserved VM Instances (Azure) should cover baseline steady-state load — the compute you're confident you'll be running in 12 months regardless. We typically recommend covering 60-70% of baseline with 1-year commitments initially, leaving room to true-up as usage patterns are better understood, rather than over-committing on day one.
• Spot/preemptible instances for anything fault-tolerant — batch jobs, CI runners, non-critical background processing — routinely cut compute cost 60-90% for that workload segment. The engineering cost is building tolerance for interruption, which is a one-time investment, not ongoing spend.
• Committed use discounts on managed services (RDS, ElastiCache, managed Kubernetes control planes) are frequently missed because teams commit on compute but forget the managed database layer carries its own commitment discount structure.

None of this requires an architecture change. It requires someone owning the commitment planning as an ongoing function, not a one-time purchase made during initial cloud setup and never revisited as usage grows.

Data egress is the trap that surprises finance teams every time

Egress charges — data leaving the cloud provider's network — are the line item most likely to blindside a client because they don't map intuitively to "using more compute." A few patterns we see repeatedly:

1. Cross-region replication set up for disaster recovery, running constantly, when the actual requirement was a nightly snapshot, not continuous replication. The egress cost of continuous cross-region sync can dwarf the storage cost it's protecting.
2. CDN misconfiguration sending origin-fetch traffic through the most expensive path because cache hit rates are lower than assumed — worth auditing cache-hit percentage directly rather than assuming a CDN is doing its job.
3. Multi-cloud data pipelines where an analytics pipeline pulls raw data out of one cloud provider into another for processing, paying egress on the way out, when the same processing could run in the source cloud provider's own analytics services.

The audit habit that catches this early

Set a monthly cost-anomaly alert specifically scoped to data transfer line items, separate from general spend alerts. Egress costs creep gradually as data volume grows, so they rarely trigger a sudden spike alert — they show up as "huh, this line item has doubled over six months" only if someone is actually looking at the trend.

Making savings durable, not one-time

The mistake that undoes all of this within a year is treating a cost optimization pass as a project instead of a function. Rightsizing recommendations go stale as workloads change; reserved capacity needs true-up as usage grows; a new team spinning up a new service can reintroduce the same egress patterns that were just fixed elsewhere. We push clients toward a lightweight monthly cost review — even 30 minutes with the top 10 line items and month-over-month deltas — rather than a big annual audit, because the compounding savings come from catching drift early, not from a bigger one-time cleanup.

For clients who want this done rigorously without pulling a platform team off feature work for a quarter, this is exactly the kind of focused engagement we run as a fixed-scope cloud cost audit rather than an open-ended re-architecture project.