AWS vs Azure vs Google Cloud

The single most reliable predictor of which platform an organisation should choose is what it already buys and what its engineers already know. That sounds anticlimactic next to a service-by-service comparison, and it is nonetheless what we observe repeatedly. An organisation with an established Microsoft relationship, identity in Entra ID and engineers fluent in that ecosystem will get to a working, well-run system on Azure faster and more cheaply than on either alternative, and the reasons have almost nothing to do with the compute layer. An organisation whose engineers have run production on AWS for five years will do better staying there than moving to a platform where nobody has been paged at three in the morning yet.

The second factor is where your data is legally required to live, and which regions and services you actually need rather than which ones exist. This is a question with a checkable answer, and it should be checked against the current region and service availability for each provider rather than assumed, because service availability varies by region on all three platforms and the service you have designed around may not be present where you are obliged to run. Regulated organisations sometimes find this eliminates a provider outright, which is a much faster way to reach a decision than comparing databases.

The third is procurement, and it deserves more respect than engineers usually give it. If your organisation already has a signed agreement, an approved supplier, a completed security assessment and a route to raise a purchase order without a six month cycle, then choosing that provider saves real calendar time and real internal political capital. If choosing a different provider means a full new vendor onboarding, that cost is genuine and it lands on the project schedule. We have seen sensible technical choices lose to this constraint, and the organisations were usually right to let them.

The fourth is workload gravity. Most systems have one thing at their centre that determines whether they succeed. If that thing is a data warehouse serving analysts across the business, the analytics story should dominate the decision. If it is a large set of Windows and SQL Server applications, the Microsoft position should dominate. If it is a conventional set of containerised services with a relational database, no provider has a decisive advantage and you should decide on the earlier factors instead. Naming the one workload that matters most, before comparing anything, is the fastest route to clarity we know.

The fifth is exit cost, and it is the one people consider last and regret first. You are not choosing where to run something for a year. You are choosing what it will cost, in engineering months, to change your mind in five years. That number is under your control to a surprising degree, because it depends far more on which services you build against than on which provider you sign with.

We will not tell you which of the three is cheapest, and you should be sceptical of anybody who does without having seen your workload and your commercial terms. Published prices change, they differ by region on all three platforms, and large organisations do not pay published prices anyway. What is stable and worth understanding is the mechanism, because that is what your architecture controls.

All three bill along the same broad lines. You pay for compute by the time it is running and by how much of it you asked for. You pay for storage by volume and by class, so data that should have moved to a colder tier years ago is billed at a hot rate until somebody sets a lifecycle rule. You pay per request or per operation on many managed services, which means an inefficient loop in application code becomes a line on an invoice rather than merely a slow endpoint. And you pay for data movement, which is the part that catches people, because it is the one nobody draws on the architecture diagram.

Data movement deserves specific attention on any of the three. Traffic leaving the provider network towards the internet is chargeable. Traffic crossing availability zone or region boundaries is typically chargeable too, which means two chatty components placed carelessly can generate a recurring cost that looks like a fixed overhead nobody can explain. Managed network address translation and similar gateway services often charge for processing as well as for existing. The design response is the same everywhere: know which boundaries your traffic crosses and how often, put caching in front of anything cacheable, and treat placement as a cost decision rather than only a latency one.

The second cost mechanism worth understanding is what is metered on some services but not others. A serverless warehouse or query engine that bills on data processed shifts your cost control away from provisioning and towards how queries are written, how tables are partitioned and how much data each question has to read. That is a genuinely different discipline, and it can be either a large saving or a nasty surprise depending on whether anybody is watching. Provisioned infrastructure bills whether you use it or not, which is the opposite failure mode: predictable, and quietly wasteful.

Then there are commitment discounts, which every provider offers in some form: agree to a level of spend or usage over a term and pay less for it. The discount is real. So is the cost, which is flexibility. A commitment made before an architecture has settled locks you to the shape you had when you signed, and we have seen organisations keep running something they had decided to replace because the commitment had eighteen months to run. Our consistent advice on all three platforms is to stabilise the architecture first, right-size against observed usage, and only then commit, because committing to a year of infrastructure you were about to change is an expensive way to feel efficient.

One last mechanism that applies to all three and is almost never modelled: idle resource. Storage volumes detached from anything, load balancers with nothing behind them, non-production environments running through nights and weekends, log retention nobody chose, and environments created for a project that finished. None of these generate an alert. They generate a number that looks like it has always been there. Whichever provider you choose, the discipline that controls cost is attribution through consistent tagging, budgets set on the drivers rather than the total, and somebody whose job includes looking.

Engineers frequently dismiss "we are a Microsoft shop" as a non-technical reason, and it is worth explaining why we treat it as a strong one. Start with identity. If your organisation already governs users, groups, conditional access policies, multi-factor enforcement and the joiner and leaver process in Entra ID, then choosing Azure means your cloud access control is an extension of a system your security team already runs, already audits and already has evidence for. Choosing another provider means federating two systems, keeping them consistent, and accepting a second place where access can be wrong. Identity is the single most consequential thing to get right, and having one authoritative source is worth a great deal.

Then commercial terms. An enterprise agreement is not merely a discount, it is a negotiated relationship with terms, a support arrangement and an established route to buy. Reusing it removes a procurement cycle, a vendor security assessment and a set of legal reviews that would otherwise sit on the critical path. For a regulated organisation those can take months, and months of delay are usually more expensive than any architectural difference you were weighing.

Then licensing. If you already hold Windows Server and SQL Server entitlements, the commercial treatment of those entitlements when the workload runs on Azure is a real factor in what the workload costs. We are deliberately not quoting mechanics or figures here, because the details depend on your agreement and change over time, and the correct action is to have somebody who can read your specific agreement work it out. What we will say is that for an organisation with a significant existing Microsoft licence position, this is frequently large enough to decide the question on its own, and it should be modelled rather than ignored because it feels like an accounting matter.

And then people. A team fluent in one ecosystem is productive in it immediately and unproductive somewhere else for longer than anyone plans for. That cost is paid in the first year, in a currency, engineering time, that is more scarce than infrastructure spend for most organisations.

The honest counterweight is worth stating too. Choosing on the basis of an existing relationship binds your cloud position to a wider commercial relationship, and if that relationship changes, the consequences reach further than they would otherwise. It is also possible to end up with a platform choice nobody ever tested against the workload, which is a different failure from the one we usually warn about but a failure nonetheless. The right approach is to let the estate argument carry real weight, and then check that the workload is genuinely well served, rather than treating either half as sufficient on its own.

AWS pulls ahead on breadth, maturity and ecosystem. The value of that is not that you will use a large fraction of what is available, because you will not and should not. The value is that when you hit an unusual requirement, there is very likely a mature service for it, a long history of other organisations using that service in anger, and written answers to the problems they hit. It also has the largest pool of engineers who have run production on it, which matters more than teams expect at the point where the person who built the platform leaves. For an organisation without a dedicated platform function, that continuity argument is often the strongest single point in its favour.

Azure pulls ahead where an organisation already exists inside the Microsoft world, and the advantage compounds across identity, security tooling, endpoint management, licensing, procurement and staff familiarity at the same time. It is also a serious option for hybrid estates where substantial infrastructure will remain in your own buildings for the foreseeable future, because the management and identity story across both halves is coherent rather than assembled. And in the enterprise and public sector, its presence in procurement frameworks is a practical advantage that has nothing to do with technology and everything to do with getting a project started this quarter rather than next year.

Google Cloud pulls ahead on data. BigQuery is the clearest example anywhere across these three platforms of a service that is a legitimate reason to choose a provider rather than a service you use because you happen to be there. It lets an organisation ask questions of very large datasets without standing up, tuning and operating a warehouse cluster, and for data teams whose real constraint is how long it takes to get an answer, that changes what is possible rather than merely what is convenient. The platform also carries genuine Kubernetes heritage, since Kubernetes originated at Google, and GKE reflects that in how it is run. Its machine learning tooling has been a first-class priority rather than an addition, which shows.

It is equally worth naming where each is weaker, because a comparison that only lists strengths is a brochure. AWS has the steepest sprawl problem: there are usually several defensible ways to do anything, the documentation describes them all neutrally, and teams without experienced guidance regularly build something more complicated than they needed. Azure has areas where the product surface has grown by accretion and the naming and portal experience reflect that, and organisations sometimes choose it for estate reasons and then never test whether the specific workload is well served. Google Cloud has the smallest hiring pool of the three, thinner community coverage of unusual problems, and a reputation among some buyers for retiring or reshaping services, which is a concern you should test against the specific services you plan to depend on rather than accept as folklore.

Lock-in is not a property of the provider you sign with. It is a property of the services you build against, and it is graduated rather than binary. That distinction is the most useful thing we can give you on this subject, because it turns an anxiety into a decision you control.

At the portable end, containers running standard runtimes and a managed PostgreSQL or MySQL database commit you to very little. All three platforms will run your images, all three offer managed versions of the common open source engines, and moving means provisioning elsewhere, restoring a dump and repointing the traffic. It is work, and it is bounded work of a kind an engineer can estimate. Object storage sits close behind, since the interfaces are widely emulated and the data is yours to copy, subject to paying to move it out.

In the middle sit managed services that are provider-specific but have recognisable equivalents elsewhere: managed queues, managed caches, container platforms, secret stores. Leaving means rewriting integration code and reworking infrastructure definitions rather than redesigning the system. Uncomfortable, estimable, survivable.

At the deep end sit systems built on proprietary serverless compute, provider-specific event routing, provider-specific workflow orchestration and provider-specific identity primitives all bound together, and analytical estates holding years of history with a large body of queries, models and reports built on top. Leaving those is a rewrite of the integration surface or a data platform migration, not a redeployment. That is frequently the right choice, because those services remove enormous amounts of work and the productivity is real. What is not right is arriving there by accident because every tutorial pointed that way and nobody ever asked what the exit would cost.

So the practical advice is to make the choice deliberately and per service rather than as a single philosophical position. Decide which parts of your system must remain portable because they are load-bearing and long-lived, and keep those on open standards and open engines. Let the parts where the productivity gain is largest and the replacement cost is bounded be as provider-specific as you like. Define infrastructure in code either way, because rebuilding an environment from a repository is far easier than reconstructing it from one person’s memory, whichever platform you are rebuilding it on. And write down, once, what the exit would involve, so that in three years it is a document rather than an argument.

Multi-cloud arrives in conversations as a way of not deciding, and it is frequently the most expensive decision in the discussion. The pitch is appealing: avoid lock-in, use the best service from each provider, keep commercial leverage in negotiations. In practice, running production across more than one provider multiplies the work in every direction at once, and most organisations that adopt it end up with the costs and only a fraction of the benefits.

Consider what actually multiplies. Your team needs genuine operational competence on each platform, not familiarity, because being paged for a system you half understand is worse than not having it. Identity and access has to be designed, governed and audited in each place, and kept consistent, which is precisely the sort of duplicated authority that produces access mistakes. Networking, observability, security policy, cost management, backup and disaster recovery all need a version per provider. Your infrastructure code has to express both, or you accept two dialects. Compliance evidence has to be gathered twice. And every one of those is a permanent standing cost rather than a one-off setup, which means it is paid for as long as the system exists.

The lowest common denominator problem is just as real. To make a workload genuinely portable across providers you must avoid the services that make each provider worth using, so you end up running virtual machines and self-managed software on rented infrastructure, forgoing exactly the managed capability you were paying a premium to reach. That is a legitimate architecture, but be clear that it is what you have chosen: you have taken on more operational work in order to preserve an option you may never exercise.

The cost argument usually turns out to be backwards as well. Data moving between providers is chargeable and the volumes involved in a genuinely distributed system are rarely trivial. Splitting your spend across providers weakens rather than strengthens your position on commitment discounts, since those reward concentration. And the negotiating leverage that multi-cloud is supposed to create depends on being credibly able to move, which is the very thing the standing operational burden makes harder, not easier.

There are versions of multi-cloud that are legitimate, and it is worth naming them precisely so the exceptions do not get used to justify the general case. A regulator or a customer contract that explicitly requires it. An acquisition that brought a second estate and a deliberate, funded plan to consolidate or to keep both. A genuine sovereignty requirement that no single provider satisfies. One clearly bounded workload placed on a second provider because a specific service there is decisively better, with a clean interface between it and everything else, which is a very different thing from running your platform in two places. And using one provider for production and another for something entirely separate, such as an analytics estate, with a deliberate boundary rather than a distributed system spanning both.

What is not a legitimate reason is a general unease about depending on one company. If that is the concern, the effective response is portability discipline inside a single provider: standard engines, containers, infrastructure as code, data you can extract, and a written understanding of what an exit would involve. That gives you most of the optionality at a small fraction of the cost of actually running two platforms. For the large majority of organisations, one provider run well beats two run adequately, and it is not close.

The first thing to understand is that the compute layer is rarely the hard part. Moving containerised services from one provider to another is real work but it is well understood, estimable work: rebuild the infrastructure definitions, provision the equivalent networking and identity, adjust the deployment pipeline, and shift traffic. Teams that have containerised and defined their infrastructure in code find this part goes roughly as planned. Teams that have not find that the migration project quietly becomes a containerisation project first, which is worth knowing before the timeline is agreed.

The hard parts are data, identity and the proprietary edges. Data because it has volume, gravity and a residency position: moving it costs money in egress, takes time that is measured against a live system that keeps writing, and needs a plan for how the two sides stay consistent during the transition. Identity because access control is rarely a like-for-like translation between platforms and the differences are the sort that produce either an outage or a hole. Proprietary edges because every place your system depends on a provider-specific serverless runtime, event router, workflow engine or managed service without a direct equivalent is a piece of code to rewrite rather than redeploy, and those tend to be discovered rather than inventoried at the start.

Analytical estates deserve their own warning. A warehouse holding years of history with a large body of queries, scheduled jobs, models and reports built on top of it is one of the harder things in this field to move, because the data is only half of it. The other half is every query, every dashboard and every downstream dependency, many of which nobody has a full list of. If you are choosing a platform partly because of its analytics story, understand that you are making a longer commitment there than anywhere else in the stack.

Whatever the direction, the risk in these projects concentrates in the cutover rather than in the platform. Run both sides in parallel, move one clearly bounded workload first and keep a route back, verify against real behaviour rather than a test plan written from the design, and sequence the data migration so it is the most rehearsed part of the whole exercise. Cutovers attempted in a single step tend to discover their problems while the business is watching.

One last piece of advice we give consistently: be honest about why you are moving. Cost dissatisfaction is the most common trigger and the least reliable one, because an ungoverned account is expensive on any platform and the same architecture lifted unchanged to a different provider usually costs about the same for the same reasons. Before you migrate for cost, find out whether the problem is the provider or the way the estate has been run. Quite often the answer is that a fraction of the migration budget spent on right-sizing, storage lifecycle rules, removing idle resource and fixing traffic paths would deliver most of the saving without any of the risk. If a proper look shows the platform genuinely does not suit the workload, or a residency or procurement position has changed, then move deliberately and with a real plan.