Azure or AWS for a UK business? A practical comparison

The short answer

Both platforms will run your workload well. Anyone telling you one is decisively better is either selling something or has only used one.

For the typical UK business we work with — 20 to 500 staff, running Microsoft 365, some .NET applications, a SQL Server database and a website — Azure is usually the right choice, for reasons that have little to do with the technology and a lot to do with identity, licensing and hiring.

Where AWS wins is breadth of managed services, data and ML tooling, and situations where your team already knows it. Existing skills beat theoretical fit almost every time.

Cost in practice

Headline compute prices are close enough that comparing them is largely a waste of time. What actually moves the bill:

The pattern we see repeatedly: if you already own Windows Server and SQL Server licences with Software Assurance, Azure Hybrid Benefit alone can make Azure 20-40% cheaper for that workload. If you are all-Linux and open-source, the platforms are close and it is a coin toss weighted by skills.

Far more important than platform choice: nobody is watching the bill. In cost reviews of environments that grew organically we routinely find 20-40% of spend removable — oversized instances, orphaned disks and IPs, non-production environments running at weekends, and data sitting in hot storage that has not been read in two years.

Identity is the real lock-in

This is the argument that decides most UK cases, and it rarely appears in comparison articles.

If your organisation uses Microsoft 365, you already run Entra ID. That means every user, group, conditional access policy and MFA enrolment already exists in a directory that Azure treats as native. Single sign-on to Azure resources, role-based access control, privileged identity management and conditional access all just work.

Doing the same on AWS means federating Entra ID to AWS IAM Identity Center — entirely feasible, well documented, and an ongoing piece of integration to maintain. Not a blocker. But it is real work, and it is the sort of work that quietly consumes a small IT team.

Data residency and compliance

Both platforms offer UK regions — UK South (London) and UK West (Cardiff) on Azure, eu-west-2 (London) on AWS — so UK data residency is achievable on either. Both hold the certifications a UK buyer typically asks about, and both are used across UK public sector and financial services.

Two practical points that matter more than the certification list:

• Residency is a configuration, not a default. It is easy to deploy a resource to the wrong region, or use a global service that processes metadata elsewhere. Policy guardrails should enforce region restrictions rather than relying on care.
• Backups and logs travel too. Check where your backups replicate and where your telemetry lands. This is a common gap in otherwise careful setups.

Hiring and skills

In the UK mid-market, .NET and Azure skills are widely available and reasonably priced. AWS skills are also plentiful but concentrated in startup and scale-up environments, where salary expectations are often higher.

The question to ask is not "which platform is better" but "which platform can I still support in three years, at a salary I can pay, if the person who built it leaves". For a Microsoft-centric organisation, that answer is usually Azure.

When the answer is neither

Both are overkill for some workloads, and saying so is not fashionable:

• A static or brochure website. Cloudflare Pages, Netlify or similar — free or near-free, faster, and no infrastructure to manage. Putting it on Azure App Service costs more and gains nothing.
• A single small internal application. A managed platform such as Render or Fly.io may be simpler and cheaper.
• A workload that genuinely does not move. Predictable, steady, licence-heavy workloads sometimes remain cheaper on dedicated hardware. This is unfashionable and occasionally correct.

Migration effort

Typical timelines from our own projects:

• Single application lift-and-shift: 3-6 weeks including testing and cutover.
• Re-platform to managed services (App Service, Azure SQL, managed identity): 2-4 months, and where most of the long-term benefit is.
• Multi-application estate: a programme, not a project. Establish the landing zone first, then migrate application by application.

The mistake we see most often is lift-and-shift with no follow-up. You end up with the same architecture at a higher cost and call cloud a disappointment. Lift-and-shift is a valid first step, but only as a step.

If you want an independent view on a migration you are planning, see cloud architecture and DevOps or get in touch.