Cutting a cloud bill by a third without re-architecting

When a client asks us to reduce their cloud bill, they usually expect a proposal to move to serverless or rewrite something in a faster language. In practice, the first thirty percent of savings almost never needs architectural change. It comes from paying for things nobody uses, paying list price for things you will use for years, and moving data around more than necessary. This is the review we run, in the order we run it, and the numbers we typically see.

Step one: get the bill into shape

You cannot cut what you cannot attribute. Before touching a single instance, we make sure every resource carries tags for environment, service and owner, and we enable the provider's detailed cost and usage export into a queryable store. Untagged spend above ten percent of the bill is a finding on its own.

Then we group costs three ways: by service type, by environment, and by owner. The picture that emerges is rarely what the team expects. On one recent review for a marketplace client, staging and development environments accounted for 34 percent of total spend, and nobody had looked at them in a year.

Step two: switch off and rightsize

The quickest savings come from resources that are idle or oversized.

• Non-production schedules. Staging, QA and demo environments rarely need to run nights and weekends. A simple scheduler that stops them outside working hours cuts their compute cost by around 65 percent.
• Orphaned resources. Unattached volumes, old snapshots, idle load balancers and elastic IPs pointing at nothing. Individually small, collectively often several hundred dollars a month.
• Rightsizing. Look at 30 days of CPU and memory utilization. Instances averaging below 20 percent CPU with peaks under 50 percent are candidates to drop a size. Databases are the most commonly oversized resource we find, because someone provisioned for a launch spike that never recurred.
• Newer instance generations. Moving to the current generation, and to ARM-based instances where your stack supports it, typically gives 10 to 20 percent better price-performance at no engineering cost beyond testing.

Rightsizing should be done gradually and with monitoring in place. Drop one size, watch for a week, then decide whether to go further. Pay particular attention to memory on application servers and to IOPS on databases, because those are the limits that bite first after a downsize. A server that looks idle on CPU can still be swapping, and a database that looks underused on average can be saturating its disk during nightly batch jobs. Check the peaks at the busiest hour of the busiest day of the month, not just the averages on the dashboard.

Step three: commit to your baseline

On-demand pricing is for workloads you might turn off next month. Anything that has run steadily for a year and will keep running should be covered by a commitment: savings plans, reserved instances or committed-use discounts depending on the provider. One-year commitments with no upfront payment typically save 25 to 35 percent and carry little risk if you only commit to the floor of your usage, not the peak.

Commit to the usage you are certain of, not the usage you hope for. The discount on a floor is guaranteed; the discount on a forecast is a bet.

We model commitment coverage against the lowest monthly compute usage over the prior six months, then leave everything above that line on demand or on spot capacity for stateless workers.

Step four: storage and data transfer

Storage costs grow silently. Logs retained forever, database backups kept at full resolution for years, and user uploads sitting in the most expensive storage class are the usual culprits. Lifecycle rules fix most of it:

{
  "Rules": [{
    "ID": "archive-old-uploads",
    "Filter": { "Prefix": "uploads/" },
    "Status": "Enabled",
    "Transitions": [
      { "Days": 90,  "StorageClass": "STANDARD_IA" },
      { "Days": 365, "StorageClass": "GLACIER_IR" }
    ]
  }]
}

Log retention deserves an explicit policy: we usually recommend 30 days hot, 12 months archived, and deletion after that unless compliance requires more.

Data transfer is the other hidden line. Traffic between availability zones, NAT gateway processing fees and egress to the internet can add up to more than the compute itself on media-heavy sites. Putting a CDN in front of static assets, adding VPC endpoints for object storage access and keeping chatty services in the same zone are straightforward fixes. On the marketplace review, a properly configured CDN reduced egress charges by just over half.

Step five: make it stick

Savings erode. New environments get spun up, someone doubles an instance size to fix a performance problem, and within a year the bill is back where it started. Three habits prevent that:

1. A monthly cost review, thirty minutes, with the engineering lead and whoever owns the budget.
2. Budget alerts per environment that notify the owning team, not just finance.
3. Infrastructure defined in code, so that every new resource is reviewed and tagged before it exists. Our infrastructure as code engagements make this the default rather than a policy people forget.

What to expect

Across the reviews we have run in the last two years, the median reduction from these five steps has been between 28 and 38 percent, with no change to application code. The marketplace client went from roughly 14,000 to 9,200 dollars a month over eight weeks. Beyond that point, further savings usually do require architectural work, such as moving bursty workloads to serverless functions or consolidating databases, and that is a separate conversation with its own business case. If your setup lives on AWS, our AWS setup and management service covers the review and the ongoing hygiene in one engagement.

Find out what you are overpaying

Share a recent invoice and a rough architecture sketch, and we will send back a fixed-price cost review proposal within a day, including the savings range we expect. Ask for your quote.