Start with the operating model, not the platform

When we talk to businesses evaluating managed support, the AWS vs Azure question often dominates the conversation early. Our experience is that it rarely belongs there. The questions that determine whether a managed service will actually serve you well - response times, observability depth, improvement cadence, how incidents are handled at 2am, what happens when costs spike unexpectedly - are the same regardless of which cloud you are on. Get those right first, then let platform considerations refine the decision.

The operating model question is: when something breaks, who owns it, how fast do they respond, what do they have in place to see it before you do, and what are they doing the rest of the month to stop it happening again? A well-operated Azure environment is categorically better than a poorly-operated AWS one, and vice versa.

Where AWS tends to fit better

AWS tends to win when breadth and programmability are the primary drivers. The service catalogue is deeper, the automation and infrastructure-as-code tooling ecosystem is more mature, and the community of engineers who have built on AWS is larger. For teams that want to build their own abstractions on top of managed services, or where the engineering organisation already has strong AWS expertise, starting there usually produces less friction.

Specific scenarios where we typically see AWS as the better starting point:

  • Container and serverless-first architectures. ECS, EKS, and Lambda have a longer track record and the surrounding ecosystem of tooling is more developed. If your workload is primarily containerised microservices or serverless functions, the AWS operational tooling is ahead.
  • Multi-account, multi-region enterprise estates. AWS Organizations, Control Tower, and the Landing Zone Accelerator have been refined over more years. For large estates with complex account structures, the governance tooling is more mature.
  • Workloads with significant open-source dependencies. AWS's integrations with open-source ecosystems (Kubernetes, Terraform, Prometheus-compatible tooling) are generally ahead, particularly for DevOps-oriented teams.
  • Cost optimisation maturity. AWS Cost Explorer, Compute Optimizer, Savings Plans, and the tooling around CUR are more sophisticated. For businesses where cloud cost is a significant concern and the team wants detailed attribution and optimisation, AWS has more levers to pull.

Where Azure tends to fit better

Azure tends to win when the Microsoft ecosystem is already central to the business. For most UK SMBs, that is not a trivial observation - if the business runs on Microsoft 365, Azure AD (now Entra ID), and has existing volume licensing or enterprise agreements with Microsoft, the integration story for Azure is simpler. The commercial route via Microsoft's CSP programme also offers flexibility that can matter for smaller businesses.

Specific scenarios where we typically see Azure as the better starting point:

  • Microsoft stack workloads. .NET applications, SQL Server, Windows Server, Active Directory - these run more naturally on Azure with better native tooling support and licensing economics.
  • Regulated industries in the UK and Europe. Microsoft has invested heavily in UK-specific compliance coverage, and Azure Policy makes it easier to enforce governance requirements at scale. For FS, health, and public sector workloads, the compliance framework support is strong.
  • Teams with existing Azure expertise or Microsoft partner relationships. If the team already knows Azure well, or if there is a commercial relationship with Microsoft, the switching cost matters less and the execution risk of moving to AWS is real.
  • Security operations with SIEM requirements. Microsoft Sentinel, combined with Defender for Cloud and the Microsoft security stack, is a cohesive environment for security operations. For businesses that need a SIEM and want it tightly integrated with their cloud, Azure is often the path of least resistance.

The cases where it genuinely does not matter

For a significant number of workloads - web applications, APIs, background processing, databases, static hosting - both platforms are genuinely equivalent from an operational perspective. If the team has no strong existing preference, the decision often comes down to:

  • Which platform your engineers know better (execution risk is real and underestimated)
  • Which commercial route makes most sense (Azure CSP vs AWS Partner pricing, existing commitments)
  • Which platform your MSP has deeper operational experience with

For the third point: ask your MSP directly. A provider who operates both AWS and Azure every day - across multiple customer environments simultaneously - will have direct experience of the operational differences, not theoretical knowledge. Ask them which one they see more issues on, and what the failure modes look like. If they cannot give a specific, honest answer, take that as a signal.

How we operate both at Critical Cloud

We use Datadog as the observability layer across both AWS and Azure, which means the monitoring, alerting, and incident management workflow is consistent regardless of platform. A SEV-1 on an AWS environment goes through the same triage and response process as a SEV-1 on Azure. This matters operationally: when something breaks at 3am, the on-call engineer should not have to context-switch between different tooling and processes because the customer happens to be on a different cloud.

Below Datadog, we use the platform-native tools where they are the right tool for the job: on AWS that means CloudWatch, GuardDuty, Security Hub, Cost Explorer, and Systems Manager; on Azure it means Azure Monitor, Defender for Cloud, Sentinel, Azure Policy, and Cost Management. These are not replacements for Datadog - they are the platform layer that feeds into a unified operational view.

The improvement engineering work - the monthly allocation of SRE hours that works through the reliability, security, cost, performance, and governance backlog - is structured the same way on both platforms. The specific recommendations differ (AWS Savings Plans vs Azure Reservations, for instance) but the process and cadence are consistent.

The conversation to have before choosing

Before finalising a platform decision in the context of managed support, there are three conversations worth having with your MSP:

What does your team's operational split look like across AWS and Azure?

If an MSP is operating fifteen AWS customers and one Azure customer, they are going to be less operationally sharp on Azure. This is not a criticism - depth comes from repetition - but it is a real factor. Ask for an honest answer about where they have more experience, and factor that into the decision if the platforms are otherwise equivalent.

Are there migration implications to factor in?

If you are already running workloads on one platform and evaluating whether to migrate, the migration cost and risk are often underestimated. A platform choice that is slightly less optimal in theory may be better in practice if it avoids a complex migration. Be honest about what the real-world lift is before treating this as a greenfield decision.

What does the commercial model look like on each platform?

AWS and Azure have different pricing structures, different reservation and savings mechanisms, and different partner commercial routes. Ask your MSP about the commercial implications on both sides before treating the platforms as equivalent in cost.

The honest summary: for most UK tech-led SMBs without a strong existing position on either platform, the operating model matters more than the platform. A great MSP on Azure is better than a mediocre one on AWS. Get the operating model right - observability, incident management, improvement engineering, response times - and then let platform expertise and commercial factors inform the choice.