A Practical Guide to Cutting Your Cloud Bill in Half

Cloud bills rarely spike because of one dramatic mistake. They creep up from a hundred small ones: a load balancer nobody deleted, a database sized for a launch that happened a year ago, logs nobody set a retention policy on. The fix is rarely a rearchitecture. It's usually an audit.

Here's the shape a typical setup takes before anyone's looked closely at it:

A typical cloud architecture: users hit a load balancer, which routes through an API gateway to an autoscaling group, a managed database, and object storage

Start with what's running, not what's billed

Cost dashboards tell you what you're paying for, not why it's there. Before touching the bill, walk the actual infrastructure:

• List every compute instance and ask: is this still serving traffic?
• List every database and ask: does an application still connect to it?
• List every load balancer, NAT gateway, and static IP - these are cheap individually and expensive in aggregate when forgotten.

It's common to find double-digit percentages of a bill going to resources tied to a project that shipped, or shut down, months ago.

Right-size before you reserve

Reserved instances and savings plans are a great deal - on the correct instance size. Committing to a three-year reservation on an oversized instance just locks in the waste. The right order of operations is:

1. Right-size based on actual CPU/memory utilization over the last 30-90 days.
2. Only after that, commit to reservations or savings plans on the new, smaller footprint.

Doing it in the other order is one of the most common ways teams end up "saving money" on paper while still overpaying in practice.

Storage is the easiest silent leak

Object storage and log retention rarely get revisited once configured. A few checks that consistently surface savings:

# Example: find S3 buckets with no lifecycle policy configured
aws s3api list-buckets --query "Buckets[].Name" --output text | \
  xargs -I{} sh -c 'aws s3api get-bucket-lifecycle-configuration --bucket {} >/dev/null 2>&1 || echo "{} has no lifecycle policy"'

Pair that with a retention policy on logs, most teams don't need 100% of their logs kept at full fidelity forever. Moving old logs to cold storage, or deleting them past a reasonable window, is often one of the highest-leverage changes available.

Autoscaling is a cost tool, not just a reliability one

Autoscaling groups are usually set up to handle traffic spikes, but the same mechanism should be scaling down aggressively during quiet periods: nights, weekends, staging environments that nobody uses outside business hours. A staging environment that runs 24/7 identically to production is paying full price for a fraction of the value.

If an environment exists only for humans to test against during work hours, it should not be running at 3am.

Make it someone's job

The single biggest reason cloud waste accumulates is that cost isn't anyone's explicit responsibility, it belongs to "the team," which in practice means it belongs to no one. Assigning a rotating owner to review the cost dashboard monthly, even for twenty minutes, catches most of this before it becomes a six-figure surprise.