Most comparisons of AWS, Azure and Google Cloud are written for an audience that doesn’t exist: a company with no infrastructure, no staff preferences and no existing contracts, choosing a cloud platform in a vacuum. Real decisions don’t work like that. By the time a business is asking the question, it already has a Microsoft 365 tenant, a developer who has only ever used Terraform against AWS, or a data team that lives in BigQuery. The right answer depends far more on that context than on which provider tops a feature list this year.
Start with what you already run, not what’s on the label
Before comparing services, answer three questions about the business as it stands today:
- Is the organisation already committed to Microsoft infrastructure – Active Directory, SQL Server, Windows-based line-of-business software? Azure removes a specific category of integration pain here that the other two don’t.
- Does the team have hands-on experience with one platform already? Migrating a working system to a “better” cloud rarely pays for itself once you count the retraining and the mistakes made while learning a new provider’s quirks.
- Is there a data or machine learning workload at the centre of the product, or is the cloud mostly hosting a fairly ordinary web application and a database?
For a genuinely blank slate – a new product, a new team, no existing contracts – the choice opens up. That’s the case worth spending real time on, and it’s also the case most comparison articles quietly assume applies to everyone.
The three factors that matter more than the feature comparison
AWS, Azure and Google Cloud all offer compute, storage, managed databases, container orchestration and a queueing service. Arguing over which one has the better version of each is mostly noise for a small business – all three are competent enough that the difference won’t be what makes or breaks the project. Three things will.
Data residency and where your compliance obligations actually point
All three providers operate UK regions now, so “can I keep data in the UK” is rarely the blocker it was a few years ago. The question that does still trip businesses up is which specific services are available in which region – some newer managed services launch in US regions first and take time to reach London or other UK-adjacent locations. If a project depends on UK data residency for contractual or regulatory reasons, check the regional service list for the exact services you plan to use, not just the provider’s regional footprint in general. This is a five-minute check that saves a redesign three months in.
Egress costs, once the architecture actually moves data around
Cloud pricing calculators make compute and storage look like the whole bill. In practice, the cost that catches businesses out later is data egress – what it costs to move data out of the provider’s network, whether that’s to end users, to another cloud, or to an on-premises system. This matters disproportionately for workloads that push a lot of data outward: video, large file downloads, data feeds to partners, or multi-cloud setups where data has to cross providers. It matters much less for a typical CRUD application serving modest API responses. Model your actual data flows, not the marketing comparison of per-gigabyte compute prices, before assuming one provider is cheaper than another.
Depth of managed AI and data tooling, if that’s where the product is heading
If the roadmap includes anything beyond calling a third-party LLM API – training models, running large-scale analytics pipelines, or building on managed vector search and data warehousing – the maturity of each provider’s data platform is worth real evaluation time. This is genuinely one area where the three providers differ more than in commodity compute, and it’s worth a proof-of-concept on the actual workload rather than a read of the documentation. A day spent running a realistic query against a sample dataset on two candidate platforms tells you more than a week of comparing spec sheets.
Where lock-in actually bites
Lock-in gets raised constantly in these discussions and is usually described too broadly. The reality is more specific: running containers on a managed Kubernetes service, storing data in a standard relational database, or using object storage are all close enough to commodities that moving between providers, while not trivial, is a known and boundable amount of work. The lock-in that actually hurts comes from building deeply around a single provider’s proprietary managed services – a specific serverless orchestration tool, a proprietary NoSQL API, a bespoke identity and access model wired into every function. Those integrations are what turn a future “let’s move to a cheaper provider” conversation into a multi-month rewrite instead of a migration project.
The practical response isn’t to avoid managed services altogether – that trades a smaller risk for a much larger one, since you end up building and maintaining infrastructure a managed service would have handled for a fraction of the engineering cost. It’s to be deliberate about which parts of the system are allowed to be provider-specific, and to know that list before you start, rather than discovering it during a renewal negotiation with much less leverage than you’d like.
A pragmatic way to actually decide
Skip the platform-wide comparison and evaluate against the workload in front of you:
- List the two or three heaviest workloads the system will run in its first year – not every feature on the roadmap, just what actually needs to work well soon.
- Check which providers already fit the team’s existing skills and contracts, and weight that heavily; retraining costs are real and rarely show up in the initial comparison.
- For any workload involving UK-regulated data, confirm the specific services you need are available in a UK or approved region, not just that the provider “has a UK presence”.
- Model egress costs against your actual expected data flows, not generic per-gigabyte pricing tables.
- If AI or large-scale data processing is central to the product, run a short proof-of-concept on the real workload before committing, rather than deciding from documentation alone.
- Decide up front which parts of the architecture are allowed to use provider-specific managed services, and keep everything else portable by design.
None of this produces a universal winner, because there isn’t one. It produces a decision you can defend six months later, when the workload has grown and someone asks why this provider rather than the other two.