Cutting cloud costs without hurting reliability
August 26, 2026 · 1 min read
Cloud bills tend to grow quietly. A few experiments that were never turned off, instances sized for a launch-day peak, logs kept forever. The good news is that the first round of savings is usually boring and low-risk.
1. Make the bill legible
Before changing anything, tag resources by team, environment and product. If nobody can say what a line item is for, nobody can safely delete it. Even a rough tagging scheme beats none.
2. Remove what nobody uses
- Idle environments: staging copies that run 24/7 can often be scheduled off overnight and at weekends.
- Orphaned resources: unattached disks, old snapshots, unused load balancers and IP addresses.
- Excess retention: log and metric retention that exceeds what anyone actually queries.
3. Right-size with data
Look at real CPU, memory and connection metrics over a few weeks. Over-provisioned instances and databases are common, and moving down one size is easy to reverse if you're wrong.
4. Use pricing models that match your load
Steady baseline load is a good candidate for committed-use or reserved pricing. Spiky, interruptible work such as batch jobs and CI runners can often use cheaper preemptible or spot capacity.
5. Only then change architecture
Architecture changes, such as moving to serverless, splitting a service or adding caching, can give large savings, but they cost engineering time and carry risk. Do them last, and only where the measurements show a clear win.
Guardrails that keep it cheap
Set budgets and alerts, review the bill monthly, and treat infrastructure as code so that every resource has an owner and a pull request behind it. Cost is a reliability concern too: a runaway bill is an incident like any other.
