How to Cut Your Cloud Bill by 40% (Without Touching Your Architecture)

Most engineering teams are overpaying for cloud by 30 to 40 percent — not because of bad architecture, but because of quiet, invisible waste that accumulates over time. Idle compute instances left running over weekends. Snapshots from servers that were deleted six months ago. Oversized databases provisioned for a traffic spike that never came.

The good news: you don't need to redesign your infrastructure to fix it. Most cloud savings come from cleanup and right-sizing — changes that take hours, not months.

1. Hunt Down Idle Compute Instances

The most common source of cloud waste is compute instances running at near-zero utilization. A developer spins up a server to test something, forgets about it, and it runs 24/7 at full price for months.

How to find them:

• Look for instances with CPU utilization below 5% over the past 14 days
• Check for instances with no inbound network traffic over 7 days
• Flag any instance that hasn't been accessed via SSH in 30+ days

2. Delete Unattached Storage Volumes

When you terminate a compute instance, the attached storage volumes don't always get deleted. They sit there, unattached, accruing charges every hour.

Storage is cheap per GB — but unattached volumes add up fast across a team. A 500GB volume left unattached for a year can cost $40 to $120 depending on the storage tier and cloud provider.

• Audit all storage volumes and filter for those with no attachment
• Create a snapshot before deleting (just in case)
• Set up a policy to alert when volumes go unattached for more than 7 days

3. Clean Up Old Snapshots

Automated backup tools are great — until they've been running for two years and you have thousands of snapshots going back to 2022. Old snapshots are rarely needed but consistently billed.

A sensible retention policy for most teams:

• Keep daily snapshots for 7 days
• Keep weekly snapshots for 4 weeks
• Keep monthly snapshots for 3 months
• Delete everything older than 90 days unless explicitly required for compliance

4. Right-Size Oversized Instances

When developers provision infrastructure, they often pick larger instance types than they need — it feels safer. But running a production workload at 10% CPU on an instance sized for 100% CPU means you're paying for 90% of nothing.

Right-sizing means matching your instance type to your actual workload. A few rules of thumb:

• If average CPU is below 20% over 30 days, try the next size down
• If memory usage is below 30%, consider a compute-optimized instance over memory-optimized
• Test smaller sizes in staging first — most workloads handle the change with zero impact

5. Release Unused Static IP Addresses

Reserved IP addresses that aren't attached to a running instance are billed by most cloud providers. It's a small charge per IP — but across an organization with dozens of old projects and environments, it adds up.

Audit all reserved/elastic IP addresses and release any that aren't attached to an active resource.

6. Audit Idle Load Balancers

Load balancers are billed whether or not traffic flows through them. An old staging environment's load balancer that was never decommissioned can cost $200+ per year doing nothing.

• Look for load balancers with zero requests over the past 7 days
• Check if backend instances still exist and are healthy
• Delete load balancers for environments that have been shut down

7. Use Commitment-Based Discounts

Once you've eliminated the waste above, your remaining spend is more predictable — which means you can commit to it and get significant discounts.

• AWS: Reserved Instances and Savings Plans offer up to 72% off on-demand pricing
• GCP: Committed Use Discounts offer up to 57% off
• Azure: Reserved VM Instances offer up to 72% off

The key is to right-size first, then commit. Committing to oversized resources locks in waste at a discount — still wasteful.

Putting It All Together

A structured cleanup of idle compute, unattached storage, old snapshots, oversized instances, orphaned IPs, and idle load balancers typically yields 25 to 40 percent in savings for teams that haven't done this before. For teams spending $10,000/month on cloud, that's $30,000 to $48,000 back per year.

The challenge is doing this systematically — manually checking every resource across every region is time-consuming and error-prone. That's exactly the problem LessBill was built to solve.