Cutting cloud spend 60% without cutting corners

Most cloud bills are not expensive because the workload is expensive. They are expensive because the architecture was optimized for shipping quickly, and nobody has revisited the defaults since. Over the last three years we have run cost-reduction engagements across banking, healthcare, and SaaS platforms, and the pattern is remarkably consistent: 55–65% of spend can be recovered without degrading a single SLO, if you attack the problem in the right order.

The wrong order is to start with reserved instances and savings plans. Commitments lock in whatever inefficiency you already have. The right order is to fix the shape of the workload first, then commit to the smaller, correct footprint.

Step one: measure before you touch anything

You cannot optimize what you cannot attribute. The first two weeks of every engagement are spent making spend legible. That means tagging every resource by team, service, and environment, then reconciling those tags against the actual bill. It is tedious, and it is the highest-leverage work in the entire project.

• Enforce a tagging policy at provisioning time, not retroactively — untagged resources should fail the pipeline.
• Split shared costs (data transfer, NAT gateways, observability) with a documented allocation model so teams see their true cost.
• Build a per-environment breakdown early; non-production is frequently 40% of spend and the easiest place to start.

Step two: right-size and reshape

With attribution in place, the reshaping work becomes obvious. Development and staging environments rarely need to run overnight or on weekends. A simple scheduler that scales those environments to zero outside working hours typically removes 15–20% of total spend in the first month, with zero architectural risk.

For production, the wins come from matching instance families to actual utilization. We routinely find fleets provisioned for peak load that sits idle 90% of the time. Moving stateless services to autoscaling groups with sensible floors, and migrating bursty workloads to serverless, converts a fixed cost into a variable one that tracks demand.

# Scale non-prod to zero outside business hours
resource "aws_autoscaling_schedule" "scale_down_nightly" {
  scheduled_action_name  = "scale-down-nightly"
  min_size               = 0
  max_size               = 0
  desired_capacity       = 0
  recurrence             = "0 20 * * MON-FRI" # 8pm weekdays
  autoscaling_group_name = aws_autoscaling_group.staging.name
}

Step three: commit to the corrected footprint

Only now do commitments make sense. After reshaping, the stable baseline of your workload is smaller and more predictable, so a savings plan covers real, durable usage rather than waste you should have deleted. We target 70–80% coverage of the post-optimization baseline, leaving headroom for on-demand to absorb spikes.

What good looks like after 90 days

• Every dollar of spend maps to a team and a service, visible in a dashboard the whole org trusts.
• Non-production scales to zero automatically; nobody files a ticket to turn environments off.
• Production tracks demand within a predictable band, and commitments cover the durable baseline.

The reason this order matters is compounding: reliability improvements and cost improvements come from the same work. A workload that scales with demand is both cheaper and more resilient under load. That is why we treat FinOps as an engineering discipline, not a procurement exercise.