Why cloud bills drift upward
Cloud spend rarely explodes in one decision. It grows through hundreds of small ones: a larger instance chosen to be safe, a staging environment left running for a demo, a snapshot nobody deleted, a log retention setting that defaults to forever. Each looks harmless. Together they become a line item the CFO asks about.
A single audit helps, but the bill creeps back. That is why we run cost optimisation as a recurring part of our Managed DevOps service: findings feed into capacity planning, and results appear in the monthly report.
What a good review looks like
A useful review has a clear order of operations, because the order determines how much you save and how much risk you take.
- Attribute spend. Without tags or account structure that says who owns what, every number is an argument.
- Remove waste. Delete what is unused. This is the safest saving.
- Right-size. Match capacity to observed demand with headroom.
- Change the shape. Use autoscaling, schedules, spot capacity and cheaper storage tiers.
- Commit. Only now buy reserved instances or savings plans against the stable baseline.
- Prevent regression. Budgets, anomaly alerts and pull request cost estimates keep it from creeping back.
Buying commitments first is the most common expensive mistake. You lock in a discount on the wrong size.
How it works in practice
Visibility
We turn on cost allocation tags, define a small tag standard (environment, team, service), and enforce it in Terraform so new resources are tagged automatically. For Kubernetes, OpenCost or Kubecost allocates node spend to namespaces and workloads, because the cloud bill only shows nodes.
Finding waste
A short list of classics explains a surprising share of waste:
- Unattached block volumes and old snapshots.
- Idle load balancers and NAT gateways in forgotten environments.
- Non-production databases and clusters running overnight and weekends.
- Over-retained logs and unlimited metric cardinality.
- Data transfer between zones or regions that architecture could avoid.
A quick AWS CLI query illustrates how a finding becomes evidence:
aws ec2 describe-volumes \
--filters Name=status,Values=available \
--query 'Volumes[].{Id:VolumeId,GiB:Size,Created:CreateTime}' \
--output table
Every item in the output has no attachment, so it costs money and does nothing. We confirm the owner, snapshot if needed, then delete.
Right-sizing
Sizing uses measured data, not instinct. For instances we look at CPU, memory and network over a representative period, including month-end or campaign peaks, using Compute Optimizer or Prometheus. For Kubernetes the key work is pod requests: if requests are far above real usage, the scheduler reserves capacity nobody uses, and the node count balloons. Correcting requests and limits lets the horizontal pod autoscaler and node autoscaler work as intended, with Karpenter selecting nodes that fit. Our guide to EKS cost optimisation covers the Kubernetes levers one by one, and you can try the EKS cost calculator for a rough view.
Commitments
Savings plans and reserved instances reward predictability. The method: take the lowest sustained usage over a few months, commit to a fraction of it, and revisit as usage settles. Spot capacity suits stateless, interruption-tolerant jobs such as batch processing and CI runners, but not databases or singletons.
| Option | Flexibility | Best for |
|---|---|---|
| On-demand | Highest | Unpredictable or new workloads |
| Savings plan | Medium | Steady compute across instance types |
| Reserved instance | Lower | Very stable, specific instance usage |
| Spot | Interruptible | Batch, CI, stateless tolerant services |
Alerts
Budgets warn when forecast spend crosses a threshold. Anomaly detection notices unusual patterns by service. Both route to a person, not a mailbox. A runaway job should be a message to its owner that day.
A short review checklist
Each cycle we walk the same list, which keeps reviews fast and comparable month to month:
- Which accounts, teams or environments grew fastest, and was that planned?
- Are there resources with no tag or no owner?
- Which non-production environments could be scheduled off outside working hours?
- Where does requested capacity far exceed used capacity?
- Are storage classes, snapshot lifetimes and log retention still appropriate?
- Is commitment coverage too low, or utilisation too low?
- Did any alert fire and go unanswered?
None of this needs special software. It needs a habit, a named owner and a place where answers are written down.
Trade-offs and honest limits
Cheaper is not always better. Squeezing headroom saves money and costs reliability. We keep a margin for failover and spikes, and we align changes with load testing so reductions are proved safe.
Engineering time is a cost. A saving of a few dollars a month is not worth a risky change. We prioritise by impact and effort.
Commitments create lock-in. If your architecture is about to change, delay the purchase.
When this is not worth buying. If your cloud bill is small relative to engineering payroll, a quarterly self-review may be enough. Reviews pay off as spend and complexity grow.
Common failure modes
- No owner. Findings without a named owner never close.
- Savings reverted by drift. A resized instance gets scaled back up during an incident and never reduced. We track it.
- Optimising the wrong bill. Chasing compute while data transfer or logging dominates. Spend breakdown comes first.
- Over-committing. Buying a three-year commitment, then migrating architecture.
Delivery and handover
We begin with a baseline review and a ranked backlog. Safe items are executed straight away; riskier ones go through architecture review and your change process. Each month we show spend by team, realised savings, and what we plan next. You keep the dashboards, tags and alert rules.
How to tell it is working
Look at cost per unit of value (per request, per customer, per environment) rather than total spend, since healthy growth increases the bill. Track the share of spend that is tagged, the count of idle resources, and commitment coverage versus utilisation. If unit cost falls while reliability holds, the reviews are paying for themselves. To discuss your bill, get in touch.