Cloud bill out of control: the six items to check before negotiating

A cloud bill rising without explanation is a common symptom, and the usual reaction — negotiating with the provider — rarely addresses the cause. The largest gains are internal and require no negotiation.

The six items, by yield

1. Instance sizing. Almost always the first seam. Machines are sized at launch on a cautious estimate, then never reviewed. A ninety-day review of CPU and memory utilisation generally identifies a significant share of oversized instances.

2. Non-production environments running permanently. Development, staging and pre-production environments are used during business hours, roughly a quarter of calendar time. Switching them off in the evening and at weekends is a day of automation that produces an immediate and permanent effect.

3. Orphaned resources. Unattached disks, reserved but unused IP addresses, snapshots from finished projects, load balancers with no target. Individually cheap, they accumulate silently over years.

4. Log and backup retention. Default policies are generous. Keeping application logs for several years in fast storage is often a significant item, when a policy of tiering to cold storage after thirty days meets the same compliance requirement.

5. Egress traffic. It does not show up as a line to optimise because it is not tied to an identifiable resource. A review of cross-region flows and internet transfers sometimes reveals an architecture moving large volumes unnecessarily.

6. Reservation commitments. The only item that is genuinely a negotiation, and it must come last. Reserving capacity on oversized infrastructure means locking in the waste for three years.

Why the order matters

Many organisations start with reservations, because it is the most visible step and the easiest to present at a committee. That is the reverse of the effective order: optimise first, commit afterwards.

The condition that makes all of it possible

None of the above is achievable if resources are not tied to an owner. The first action in a FinOps effort is not technical: it is mandating systematic tagging of every resource with a responsible team, an application and an environment.

Without that tagging, nobody can decide to switch anything off, for fear of breaking an unknown use. With it, the question becomes simple: this disk belongs to that team, they confirm or they object.

Be wary of quoted percentages

A provider quoting a savings percentage before reading your bill is selling a pitch, not an audit. The gain depends entirely on your starting point: an already-optimised infrastructure holds almost nothing, an infrastructure never reviewed in three years holds a lot.

What is legitimate, by contrast, is a fixed-price audit that prices each item separately and leaves you to decide which to act on.