Most UK SMEs do not have a cloud spending problem so much as a cloud attention problem. The bill arrives, the figures look plausible, someone approves it, and a year later you are paying for a database nobody queries and a fleet of test servers that have been running since a migration in 2023. Cloud waste is unusually easy to fix compared with most business costs, because so much of it is configuration rather than headcount. What follows is the checklist worth working through before you renew anything.

Start with tagging, because untagged spend is invisible

Every cloud provider will tell you what you spent. Very few tell you who spent it. That is the job tagging does. Agree on a small, mandatory set of tags — environment, owner, project, cost centre — and apply them when resources are created, not six months later when someone finally gets round to it. Then let the tooling work: AWS Cost Explorer grouped by tag, Azure Cost Management, or a billing export you can query yourself.

Anything that arrives untagged should appear on a weekly report until it is fixed, and policy should stop the problem at source. That might be a service control policy, an Azure Policy definition, or a Terraform module that simply refuses to deploy without tags. It sounds like admin. It is the difference between "our cloud bill went up" and "the analytics team's staging cluster went up".

Right-size what you are already running

Read the numbers honestly

Pull thirty days of CPU, memory, disk and network utilisation for your ten most expensive instances. The pattern is usually dull: servers sitting between five and fifteen per cent CPU, sized for a launch that happened two years ago. Memory matters more than CPU for most web workloads, so if you only look at processor graphs you will resize the wrong thing and wonder why response times fell apart.

Change one thing, then watch

Drop down a size, leave it a week, and check latency graphs and support tickets before you go further. For variable workloads, autoscaling groups are usually cheaper than one large always-on box, provided the application is genuinely stateless. Database instances deserve more caution: check connection counts and IOPS before shrinking anything, and consider whether a managed service where you pay for capacity suits you better than a reserved chunk of tin.

Cover the baseline with commitments, not the peak

Reserved instances, savings plans and Azure reservations trade flexibility for a lower rate, and on a stable estate they are usually the biggest single lever available. The mistake is committing to peak capacity. Work out the floor — the compute that runs every hour of every day — and cover that. Anything above it stays on-demand or spot.

If your roadmap shifts often, one-year convertible commitments are easier to live with than three-year terms, even where the discount is smaller. If you already own Windows Server or SQL Server licences with Software Assurance, check whether bring-your-own-licence or hybrid benefit applies before buying anything new. Prepaid commitments are a finance decision as much as a technical one, so it is worth asking your accountant how the spend should be treated.

Give storage a lifecycle

Storage bills creep. Nobody deletes anything, because deleting feels risky and keeping feels free. It is not. A handful of rules does most of the work:

• Move objects to an infrequent-access or archive class automatically after 30 or 90 days, depending on how often they are genuinely read.
• Delete incomplete multipart uploads, which sit there invisibly and bill like normal data.
• Expire snapshots and old machine images on a schedule rather than from memory.
• Cap log retention. Ninety days is plenty for most application logs; anything older belongs in cold storage or nowhere.
• Find unattached block volumes and remove them once you have confirmed nobody is coming back for them.

Check your retention obligations before deleting anything. Some records must be kept for years, and some sectors have specific rules. A short conversation with whoever handles compliance is cheaper than a rebuild.

Sweep up idle and orphaned resources

Non-production environments are the usual offenders: development and test stacks running through the night for the sake of eight working hours. Schedule them off. Then hunt the leftovers nobody owns — idle load balancers, unattached IP addresses, forgotten NAT gateways, clusters spun up for a proof of concept that quietly became permanent. Watch data transfer as well. Keeping traffic inside a single region, and hosting in a UK region if your users are here, avoids paying to move bytes across the world and back again.

Where to start on Monday

You do not need to do all of this at once, and trying to will annoy everyone involved. Pick two items. Tag the top three accounts. Run a rightsizing review on the ten most expensive instances. Set one lifecycle rule on your biggest storage bucket. Turn your non-production environments off between seven in the evening and seven in the morning.

Then build the habit rather than the one-off clean-up: a monthly half-hour cost review with a named owner, budget alerts at around eighty per cent of expected spend, and a cost-per-customer figure sitting on the same dashboard as your uptime. Savings tend to be largest in the first month and taper afterwards, which is fine. The point is that the bill stops being a surprise and starts being a decision.

Photo: https://kaboompics.com/ / Pexels