A CEO's guide to cloud cost optimisation

Cloud bills rarely surprise anyone by being large. They surprise people by growing faster than the business does, with no one able to explain which part grew.

This is written for the person who has to approve that bill rather than operate it — what is actually driving it, which levers move it, and what to ask for.

Why the bill outgrows the business

Four structural reasons, none of them anyone’s fault individually:

Nothing forces a decision to be revisited. An instance sized for a launch stays that size for three years. On-premises, over-provisioning was a one-time purchase you forgot about; in the cloud it is a monthly charge that compounds.

Spending is decentralised, accountability is not. Any engineer can create a resource. The bill arrives in one place, addressed to IT, where nobody has the context to question individual lines.

Convenience is priced. Managed services cost more than self-operated equivalents. That is often the right trade — but it is a trade being made repeatedly by people who are not being asked about cost.

Nothing gets deleted. Storage snapshots, unattached volumes, environments for projects that ended. Each is small; the aggregate is not.

The four levers, in order of return

Most cost programmes start with the hardest lever and stall. This is the order that works.

1. Attribution — make the bill legible

Before optimising anything, know who is spending what. Tag by team, product or cost centre, and report monthly.

This is not itself a saving. It is the precondition for every other lever, and it produces savings on its own through a behavioural effect: when a team sees its own number, it changes what it provisions. In practice this is the highest-return week of work in the whole programme.

2. Scheduling — turn off what should not be on

Non-production environments typically run 168 hours a week and are used for about 45. Shutting them outside working hours is reversible, low-risk, and often the largest single line-item reduction available.

Ask: which environments are running right now that nobody is using?

3. Right-sizing — match capacity to reality

Instances are usually sized from the old server, which was sized for the 2019 peak plus headroom. Measuring actual utilisation and resizing typically reclaims a meaningful share of compute spend.

This needs measurement first — a month of utilisation data — which is why it comes third rather than first.

4. Commitment — pay less for what is genuinely steady

Reserved capacity and savings plans reduce the rate for predictable workloads. The discount is real and the trap is obvious: committing to capacity you then right-size away.

Order matters. Commit after right-sizing, never before.

What does not work

Worth naming, because these consume programme time:

• A cost tool without an owner. Dashboards show the problem; they do not decide anything. Every tool purchase should come with a name attached.
• A one-off cleanup. Costs drift back within two quarters unless something recurring resists it.
• Optimising before migrating. If a workload is moving anyway, tune it after it lands.
• Cutting the logging bill. It looks like a saving and removes the evidence you need during an incident — and, for regulated workloads, part of what you are obliged to retain.

The governance that makes it stick

Three things, none of them heavy:

A named owner. One person, not a committee, who reports cost variance monthly alongside other business metrics. Without this, everything above is a project rather than a practice.

Guardrails instead of approvals. Budget alerts, required tags, size limits by default. An approval step for every resource slows engineering and gets routed around; a guardrail is checked automatically and only escalates exceptions.

A quarterly review with retirement on the agenda. The question “what can we switch off?” needs a standing slot, because it never arises naturally.

What to ask your CTO

Five questions that reveal where you actually are:

1. What percentage of our cloud spend can be attributed to a team or product? Below roughly 80%, attribution is the next project.
2. What do non-production environments cost, and when do they run?
3. What is our average CPU and memory utilisation? Very low averages indicate right-sizing headroom.
4. What have we committed to, and does it still match what we run?
5. Who reports cost variance, and to whom? If there is no name, there is no practice.

Measuring the result

Total spend is the wrong headline metric, because a growing business should spend more. Track unit cost instead — cost per customer, per transaction, per environment.

A programme that reduces total spend while the business shrinks has achieved nothing. One that holds unit cost flat while the business doubles has achieved a great deal, and only the unit measure shows it.

Related reading

• Swiss cloud adoption: five lessons on getting to real ROI
• Ten cloud migration mistakes mid-market companies still make
• Cloud & DevOps

If you want an outside review of where your spend is going, book a call. No obligation.