When someone asks me Azure or Google Cloud, I ask what they already have

Whenever someone asks me which cloud is better, Azure or Google Cloud, I answer with another question: what do you already have? Having built on both, the honest answer is that at this level either one does everything an average company needs, and what decides lies elsewhere.

The criterion almost nobody puts first

Identity. If the company runs Microsoft 365, its user directory is already Entra ID, Azure's directory. Users, groups, conditional access and second factor already exist and are already paid for. Moving that company to Google Cloud means federating two directories, keeping them in sync and doubling access governance.

That cost shows up in no service comparison, and it's the one I've seen tip the balance most often. A company on Microsoft 365 that picks another cloud pays for identity twice: once in licenses it already owns, and again in the work of federating. Google Workspace pulls the other way just the same, though more weakly, because Workspace is less tied into its cloud's control plane.

The six, in order of weight

• ·The directory and identity that already exist.
• ·Where the data lives today, because moving it takes time and data egress is billed.
• ·Current commercial commitments: an agreement with committed spend makes that cloud cheaper for that customer.
• ·The licenses they already pay for. Windows Server and SQL Server get a hybrid licensing benefit on Azure, and taking them elsewhere means paying for them twice.
• ·Data residency and regulation, which restrict regions and sometimes rule out a provider entirely.
• ·Who will run the platform. An architecture the customer's team can't sustain comes back as an incident.

None of the six compares services. Technical capability comes in when these six are tied, and they rarely are.

Where each one really wins

When the case calls for it, the differences are real. Azure has the edge with an organization already living in Microsoft 365, with current Windows Server or SQL Server licenses, and with an on-premises Active Directory that needs extending rather than replacing.

Google Cloud has it when the case is data and analytics, because a serverless warehouse billed per query changes a project's economics; when the design is multi-region from the start, because its global network simplifies what on Azure takes several peered networks; and with small teams, where a simpler permission and network model leaves less room for error.

That last one I lived while building the lab for this series. On Azure the network allows everything inside until you override it, logs get declared one by one, and owning the subscription doesn't give you access to the data. It gives you more control and charges for it in work, and that work belongs in the budget.

Both at once

This is where the most smoke gets sold. Multi-cloud for resilience is almost never justified. It promises to survive a provider outage and charges for it by doubling operations, splitting the team's experience in two and forcing you to keep two equivalent security postures. Running two clouds badly is riskier than one going down, and a single cloud run well, with recovery in a second region, solves the same problem better.

There are four cases where both do make sense, and they're specific:

• ·An inherited reality, like a merger or acquisition that left workloads on both. The job is deciding what gets consolidated.
• ·A clearly better service for one specific piece: the application on Azure because identity lives there, and analytics on Google Cloud because its warehouse has no rival for that case.
• ·A contractual or regulatory requirement not to depend on a single provider, common in the public and financial sectors.
• ·Negotiating leverage. Being able to actually move a workload changes the renewal conversation, and it's better to call it a commercial reason than to dress it up as architecture.

How I use this in a conversation

First I ask what they have: directory, licenses, contracts, where the data lives and who will run it. Then I name the pull those answers create, with its cost in money when it can be estimated. I recommend a single cloud with the reason spelled out and say what's lost by choosing it, because a recommendation without a stated cost is just a preference. And I leave the door open per service, not per cloud.

Did your last cloud decision come from what your company already had, or from a service comparison that nobody on your team was going to run?