The three major cloud platforms — Azure, AWS, and Google Cloud — are each capable of supporting most workloads most organisations have. Side-by-side feature comparisons rarely produce a clear winner because the platforms have copied each other’s services so thoroughly that the technical surface looks similar. The interesting questions are not which platform has the better managed Kubernetes service or the cheaper object storage by the gigabyte. The interesting questions are about fit.
This is a framework for comparing cloud platforms in a way that surfaces the decision factors that actually matter. We use it in advisory work where the brief is “we’re choosing a cloud” or “we’re already on one and considering another for a new workload”. It is deliberately vendor-neutral. We have customers running production work on all three.
What feature comparisons miss
The standard comparison article is a feature matrix. AWS has X services. Azure has Y. Google Cloud has Z. The matrix is not wrong, but it answers the wrong question. By the time you have read it, you know which platform has which compute, storage, database, networking, and AI services. What you still do not know is whether your team can operate the platform safely, whether the integration with your existing identity stack will be painful, what governance overhead you are signing up for, and what an exit looks like in five years.
The decision factors that actually drive long-term outcomes:
- Skills fit and operating model.
- Integration with existing identity, directory, and collaboration stack.
- Governance and policy maturity required to use the platform safely.
- Total cost of ownership including licensing, egress, support, and skills.
- Exit readiness if strategy or contract terms change.
A platform that is technically slightly better on paper but operationally a poor fit for your team is a worse choice than a platform that is competent and matches the way you already work.
The framework
We compare cloud platforms across six dimensions. Each is rated against your specific context, not in the abstract.
1. Outcome fit
What do you actually need the platform to do, and which platform is best positioned for that?
-
Microsoft-heavy environment, hybrid identity, productivity stack already on Microsoft 365. Azure has the lowest friction. Active Directory integration, hybrid identity, ExpressRoute connectivity to existing infrastructure, and the licensing alignment with existing Microsoft estates makes it the default for most South African enterprises and mid-market organisations.
-
Greenfield engineering, container-native, data-and-analytics-led. Google Cloud has the cleanest greenfield experience, particularly for teams that work with Kubernetes (GKE is widely considered the most polished managed Kubernetes), data warehousing (BigQuery), and machine learning. The platform feels coherent because it grew from a cohesive set of internal Google products.
-
Maximum service breadth, mature ecosystem, deep enterprise support. AWS has the largest service catalogue and the deepest set of partner tooling. If you need a niche managed service — a specific database flavour, a regional certification, a third-party marketplace integration — AWS is the most likely to have it.
These are starting points, not conclusions. The fit depends on what you are building, who is building it, and what they already know.
2. Operating impact
Cloud platforms are operationally different even where the services look similar. Three operating-impact dimensions matter most:
-
Skills and hiring. What does your team already know, and what is the local talent market like? In South Africa, Azure skills are most common, AWS skills are widely available, and Google Cloud skills are scarcer. Hiring plans should match the platform you choose.
-
Tooling ecosystem. Each platform has a different set of native tools and a different relationship with third-party tooling. Azure DevOps and GitHub are tightly integrated with Azure. AWS has CloudFormation and a strong CDK story. Google Cloud has Cloud Build and Deployment Manager. Crossing between platforms is possible but requires deliberate choices about Terraform, Pulumi, or other multi-cloud abstractions.
-
Operational discipline. Each platform’s defaults and guardrails are different. Azure landing zones via Enterprise-Scale provide strong governance defaults. AWS Control Tower and Organizations require more deliberate setup but reward it. Google Cloud’s resource hierarchy is conceptually clean but historically had fewer prescriptive guardrails.
The platform that fits your operating model is more important than the platform with the cleanest service. We have seen well-architected Azure environments outperform poorly-architected AWS environments and vice versa.
3. Integration effort
Cloud platforms do not run in isolation. They connect to identity, network, data, applications, and SaaS tools that already exist.
-
Identity. If you are on Microsoft 365 and Entra ID, Azure is one click away. AWS has good federation via SAML and OIDC but is a configuration step rather than a default. Google Cloud federates well to Google Workspace and to Microsoft Entra ID via SAML.
-
Network. All three platforms support hybrid connectivity via private circuits (ExpressRoute, Direct Connect, Cloud Interconnect) and VPN. Latency to South African workloads is best from Azure (Cape Town, Johannesburg) and AWS (Cape Town). Google Cloud routes through Johannesburg via Equinix peering — usable but a step less mature locally.
-
Data. The friction is not whether you can move data into the platform. It is how easily data can flow back out without egress charges, between platforms for multi-cloud architectures, and into existing on-premises systems. Egress pricing is a frequently underestimated cost line.
-
SaaS connectivity. Most enterprise SaaS providers offer integrations with all three. The maturity varies. Microsoft-stack SaaS (Dynamics, Power Platform) is best on Azure. Salesforce is strong on AWS. Snowflake, Databricks, and major data platforms are competent across all three.
4. Governance burden
Every cloud platform requires governance to use safely. The shape of governance differs:
-
Azure landing zones via the Enterprise-Scale framework or Azure Verified Modules provide a strong, prescriptive starting point. Management groups, subscription structure, network topology, identity, monitoring, and policy are documented in detail. Implementation effort is real but the destination is well-mapped.
-
AWS Control Tower + Organizations provides strong organisational-level controls. Account vending is mature. Service Control Policies are powerful. The path is more flexible, which means more decisions to make and more ways to get it wrong.
-
Google Cloud resource hierarchy is conceptually elegant — folders, projects, resources. Policies are inherited. Default guardrails have improved markedly over the past two years but historically were lighter than Azure or AWS.
The right question is not “which has the best governance?” but “which governance approach matches our maturity and capacity to operate it?”. A weaker team needs more prescriptive guardrails. A stronger team can build with more flexibility.
5. Total cost of ownership
Direct service pricing is similar across the three platforms when you compare equivalent services on equivalent commitment. The TCO differences come from:
-
Licensing alignment. Microsoft customers can use existing licences (Azure Hybrid Benefit) on Azure, which is significant for SQL Server and Windows Server workloads. The same workloads on AWS or Google Cloud require new licences or BYOL agreements.
-
Egress charges. The hidden tax of cloud platforms. Inter-region, cross-platform, and out-to-internet egress varies and adds up. Azure and Google Cloud have made egress concessions over the past two years; AWS still charges aggressive egress in many scenarios.
-
Support contracts. Each platform’s support tiers price differently. Plan for 3–10% of monthly spend on support depending on tier and need.
-
Reserved capacity and savings plans. All three offer 1-year and 3-year commitments at meaningful discounts. The shape of the commitment differs: AWS Savings Plans are the most flexible, Azure Reserved Instances are more granular, Google Cloud Committed Use Discounts are simplest.
-
Operational cost of governance. A poorly-governed cloud account can cost 30–50% more than a well-governed one through over-provisioned compute, idle resources, dev environments left running, and storage tier mismatches. This is platform-agnostic but worth budgeting for.
We typically model TCO on a 36-month horizon with assumed workload growth. Most decisions look different on a 36-month view than on a first-year view.
6. Exit readiness
The exit conversation is uncomfortable but necessary. If your strategy changes, your contract terms shift, the platform makes a pricing change you cannot accept, or an acquisition forces a platform change, how easily can you move?
The honest answer for all three platforms: it is hard. The cloud-portability story is mostly marketing. Real exits involve weeks or months of work even for relatively simple workloads.
What helps:
- Open formats and standards wherever possible. Postgres-compatible databases over proprietary engines. S3-compatible object storage over platform-specific stores. Kubernetes over platform-specific orchestration. OAuth and SAML over proprietary identity.
- Infrastructure as code that is platform-aware but not platform-specific. Terraform with modular code is generally portable in shape if not in literal apply.
- Data egress in the contract. Negotiate egress allowances during the deal, especially for multi-tenant SaaS-on-cloud arrangements.
- A documented exit plan that names the workloads, their dependencies, the data volumes, and the estimated effort to move. Updated annually.
We are not fundamentalists about portability. Some platform-specific services (BigQuery, Cosmos DB, DynamoDB) are good enough that lock-in is a reasonable trade. The point is to choose deliberately, with a clear understanding.
A worked example
A South African mid-market financial services firm came to us with a question: should they consolidate from a multi-cloud sprawl (some Azure, some AWS, a Google Cloud project for a data team) onto a single platform?
The framework outputs:
- Outcome fit: workloads were dominated by .NET applications, SQL Server databases, and Microsoft 365. Data team had built on BigQuery for two years and the team was happy.
- Operating impact: team strength was in Azure and Microsoft tooling. AWS skills were thinner. Google Cloud skills sat with the data team only.
- Integration effort: identity was already in Entra ID. Network connectivity to the data centre was via ExpressRoute to Azure.
- Governance burden: existing Azure landing zone was well-built. AWS account structure was inconsistent. Google Cloud was a single project with admin rights too widely shared.
- TCO: Azure Hybrid Benefit was material on the SQL Server estate. Egress costs from BigQuery to Azure were the largest cross-platform line item.
- Exit readiness: Azure-side workloads were Terraform-defined and would be moveable. BigQuery would be the hardest single item to leave.
The recommendation was not “consolidate to Azure”. It was: consolidate the application estate to Azure, keep BigQuery for the data team, and decommission the AWS workloads as the next refresh cycle came round. Standardise governance, reduce skills sprawl, and accept the BigQuery line as a deliberate platform-specific choice with documented exit cost.
The point: the answer was not “pick one cloud”. It was “pick what fits each part of the business, govern it well, and make the trade-offs explicit”.
Where most decisions go wrong
Three failure patterns we see across the cloud-selection conversations:
- Vendor-led design. The cloud was chosen because of an existing partner relationship or a sales discount, not because of fit. Sometimes that works. Often it does not.
- Greenfield bias. A small new project gets started on a different platform from the rest of the estate. Five years later, the small project has grown and the operational cost of running two platforms exceeds any benefit.
- Cost-led decision without TCO. Direct service pricing was compared. Egress, licensing, skills, governance, and operating overhead were not. The cheaper-on-paper platform turned out to be more expensive in operation.
A vendor-neutral assessment surfaces these patterns before the platform is chosen, not after.
Where to start
If you are choosing a cloud platform, comparing two, or unwinding a multi-cloud sprawl, the first practical step is a structured assessment using the framework above. Two to three weeks of focused work produces a comparison document, a TCO model, an integration map, and a recommendation that is defensible to the board.
We work vendor-neutral across all three platforms. The output of the engagement is a decision you can defend — including, sometimes, the decision to keep what you have.
Start the conversation if you want a sounding board on the comparison, or if a recent cloud decision has not delivered what was expected.