Choosing a cloud provider feels like a bigger decision than it usually is. Most UK SMEs don't need the best cloud — they need one that fits their team, their budget and the rules they have to follow. AWS, Microsoft Azure and Google Cloud all run UK regions, all sell sensible small-business pricing, and all will happily take your money. The differences that matter are narrower and more practical: where your data sits, how the bill behaves as you grow, who answers when something breaks, and whether the skills you need are already in the building.

It also helps to remember that this is rarely a permanent choice. Plenty of SMEs run one main provider and a small secondary footprint, and switching later is possible — expensive and irritating, but possible. The goal is not to make the perfect decision. It is to avoid a decision that traps you.

Begin with the workloads, not the logos

It is tempting to start with a comparison table and a favourite. Resist that. The provider question usually answers itself once you look at what you are actually running. A ten-person accountancy firm lifting a line-of-business application and a file server is solving a very different problem from a sixty-person ecommerce business running containers, a search index and a nightly data pipeline. They will not land in the same place, and they shouldn't.

If your business lives in Microsoft 365, Entra ID and Windows Server, Azure feels like an extension of what you already have. Single sign-on and licence reuse through Azure Hybrid Benefit are worth real money in staff time, even when the raw compute rate isn't the lowest.

AWS has the widest catalogue. That is both its strength and its trap: you can assemble a bespoke platform that nobody on your team can maintain. Every service you adopt adds something to learn, patch, monitor and eventually migrate away from.

Google Cloud suits data-heavy work — BigQuery, analytics, containers. If your team already writes Python and thinks in Kubernetes, it fits well. If not, it is often the steepest of the three for everyday IT workloads.

Pick the provider your team can run day to day, not the one that wins someone else's benchmark.

Where your data actually sits

All three run UK regions: AWS Europe (London), Azure UK South in London with UK West in Cardiff, and Google Cloud's europe-west2 in London. Each also has nearby EU regions — Ireland, the Netherlands, Frankfurt — which are useful for resilience but are not UK data residency.

Residency is not the same as sovereignty. Where data is stored is one question; who can access it, under which legal framework, and which sub-processors are involved are others. If you handle personal data, you remain the controller — the provider is not carrying that duty for you, no matter how reassuring the marketing page reads.

There is a practical trap here too. A service can be available in a region while a specific feature is not. A managed database might be live in London while an AI-assisted query tool or a particular machine-learning endpoint is offered only in a US region. Check the regional availability list before you design around a feature you cannot actually switch on.

Before you commit, check:

• Is the specific managed service you need available in the UK region, or only in the US?
• Do backups, logs and disaster recovery copies stay in the UK?
• Which support staff, in which countries, can access your environment?
• How quickly and cheaply could you move everything out?

Pricing: the sticker, the discounts and the extras

None of the three is simply cheap or expensive. Compute is billed by the second or hour, storage by the gigabyte-month, data by the gigabyte moved. The differences show up in how discounts work and how punishing the extras are.

Commitments

AWS offers Savings Plans and Reserved Instances. Azure adds Hybrid Benefit, which lets you apply existing Windows Server and SQL Server licences. Google Cloud has committed use discounts plus sustained use discounts that apply automatically to steady workloads. A one-year commitment typically beats on-demand, and three years beats one — but only ever commit to workloads you expect to keep running. Committing to something you might migrate off in eight months is how organisations end up paying for it twice.

The lines nobody budgets for

Bill shock for SMEs rarely comes from compute. It comes from the supporting cast: data egress, traffic crossing zones between your own services, logs and snapshots left in the hottest storage tier, per-unit managed services such as logging and monitoring, support plans priced as a percentage of monthly spend, and non-production environments left running all weekend.

Two concrete examples. A staging environment with a managed database, a load balancer and verbose logging switched on can quietly cost more than production, because nobody ever turns it off. And two terabytes of data egress a month — an entirely ordinary figure for a media, reporting or backup workload — can add a line to the bill that dwarfs the servers generating it.

Tag everything from day one and review the bill monthly with someone who can change the architecture. Cost control is an engineering task, not an accounting one. A finance team staring at a dashboard can tell you what is expensive; only an engineer can tell you why.

Support: who picks up at 2am

Every provider's free tier gives you documentation, forums and a billing contact. Beyond that you are buying response times, and all three scale the price with usage. For most SMEs a business-level plan with a defined response time for production issues is enough; enterprise tiers make sense when a critical system has no internal owner. Ask whether the plan includes architectural guidance or only break-fix, and whether you get a named contact who knows your account.

The honest answer for many small businesses is that the first line of support is the person who built the thing, and the provider is the second. That is fine, provided you know it before something breaks and you are reading a runbook for the first time.

The cost that never appears on the invoice

Skills are the largest and least visible line in any cloud decision. A platform with excellent documentation still needs someone who can read it. Ask three questions: who in the business can design a network, understand an identity model, and debug a production incident? If nobody can, you are not really choosing between three clouds — you are choosing between three managed service providers, and you should pick the one your partner knows best.

Certification matters less than familiarity. A team that has run Azure for three years will move faster on Azure, even if AWS is objectively broader. Retraining is a real cost, and it lands in the same busy week as the migration.

Exit costs and lock-in

Lock-in is not binary. Virtual machines, object storage and a managed database are broadly portable. A dozen proprietary serverless services with bespoke identity, queueing and workflow logic are not — and that is a legitimate choice, as long as it is a deliberate one rather than something you discover in year three.

Practically, that means keeping your data in formats something else can read, avoiding unnecessary glue that only one provider offers, and knowing roughly what a rebuild would cost. Portability has a price too; do not pay for it if you will never use it.

A practical way to decide

1. List your workloads and mark the ones that would hurt most if they stopped.
2. Check those workloads against each provider's UK regional availability.
3. Estimate three years of cost, including support, egress and non-production environments.
4. Name the person who will operate it, internally or externally.
5. Run a small pilot — one real workload, one month — before committing to anything.

Plenty of SMEs end up somewhere unglamorous: Microsoft 365 and Azure because the licences were already paid for, or AWS because the one contractor they trust knows it cold. That is not a failure of ambition. It is the correct answer to a practical question. Choose the provider that leaves your team competent, your data where it should be and your bill explainable — then revisit the decision in a year, when you know far more than you do now.

Photo: Brett Sayles / Pexels