Your cloud bill is too high. Here is where.

This is not about switching providers or rewriting anything. It is about the same workload costing less, which for most businesses is a week of attention and a permanent saving.

Where the money actually goes

1. Things nobody turned off

Test environments from a project that finished, servers from a migration completed two years ago, disks left behind when the machines they belonged to were deleted. This is the largest and least interesting category, and it is usually the first ten per cent.

2. Machines sized for a launch that never came

Somebody picked a size on day one, guessed high, and nobody revisited it. Look at actual processor and memory use over thirty days. Sustained use under ten per cent means the machine is at least two sizes too big.

3. Paying on demand for something that runs constantly

Every major provider discounts committed usage heavily, commonly thirty to sixty per cent for a one or three year commitment. If a system has run every day for a year, paying the casual rate for it is a choice.

4. Environments that run overnight and at weekends

Development and test environments used during business hours cost the same at three in the morning. Shutting them outside working hours removes roughly two-thirds of their cost, and it is a scheduled task, not a project.

5. Storage nobody has looked at

Backups kept forever, logs kept forever, files on premium storage that have not been read in two years. Retention rules and cheaper storage tiers for cold data are usually a quick, safe saving.

6. Data moving between places

Transferring data out of a provider, or between regions, is charged and rarely noticed. It is often a design accident: two systems that talk constantly, sitting in different regions for no reason anybody remembers.

7. Licences bought per seat and never trimmed

Not strictly cloud infrastructure, but it sits in the same bill and follows the same pattern. Count active users against paid seats. The gap is people who left.

8. The managed service you outgrew, or never grew into

Premium tiers chosen for a load that never arrived. Or the reverse: paying for a database ten times the size of the data in it.

A sensible first week

1. 1Export twelve months of billing and sort by cost. The top ten line items are usually most of the bill.
2. 2List everything running and ask, for each one, who uses it. Anything nobody can name gets a shutdown date, not a deletion.
3. 3Right-size the obvious over-provisioning based on thirty days of usage.
4. 4Schedule non-production environments to stop outside business hours.
5. 5Apply retention rules to logs and backups, and move cold data to a cheaper tier.
6. 6Only then buy commitments, once the shape of what you actually run is stable.

The order matters. Committing to a three-year term on infrastructure you were about to switch off is a common and expensive mistake.

Stopping it coming back

• One named owner for the bill. Not a committee. A person who sees the number monthly.
• A budget alert that reaches a human, set at a threshold that means something rather than at the number you are already spending.
• A monthly line in the leadership pack: cloud cost, and cloud cost per customer. The second number is the one that tells you whether growth is working.
• Tags enforced at creation. Anything untagged has no owner, and anything with no owner grows.

Cost per customer is the metric worth arguing about. A bill that grows while that number falls is a business scaling properly. A bill that grows while that number holds steady is a bill that will hurt at ten times the size. It is also one of the first things technical due diligence checks.