In an organisation where Azure is the default enterprise platform, AWS and Google Cloud usually arrive as exceptions. A product team wants to stay where it already ships. A data team has seen what BigQuery can do and wants it. The platform team worries, reasonably, about running three clouds with a team built for one.
Both requests can be right, and both can be wrong. AWS and Google Cloud often appear on the same shortlist, but they tend to win for different reasons, and the reasons are specific enough to test. That is the point of this part: to say what a winning case for each looks like, and to show how to settle a disputed advantage with evidence rather than a vendor demonstration.
Mopane Group is fictional, and its workloads and figures are illustrative. Mopane, the South African group we follow through this series, has made Azure its primary enterprise platform (Part 2). Two exceptions are on the table: its retail digital team of twelve engineers, who build the loyalty app and e-commerce site on AWS in Cape Town, and its four-person data team, who want to build retail demand forecasting on BigQuery.
When AWS should lead
AWS is a strong default for organisations with established AWS engineering, cloud-native product teams, and an operating model built around AWS accounts, infrastructure as code and clear service ownership. Its South African region is Africa (Cape Town), af-south-1, which at the time of writing (October 2026) has three availability zones. It is an opt-in region that has to be enabled per account, and it is AWS's only region in the country. AWS has announced, but at the time of writing not opened, a Johannesburg Local Zone. The three zones support in-region resilience when the services you choose are zone-aware, which, as with any provider, has to be checked service by service.
AWS should lead when:
- teams already deliver reliably on AWS, and switching would create no compensating benefit;
- the workload benefits from an AWS managed service that materially removes engineering work;
- event-driven, serverless or other cloud-native patterns suit the product, and the team can operate them;
- the business needs a broad global AWS footprint for customers or expansion;
- security, account vending, observability and FinOps controls are already implemented on AWS.
The first condition decides Mopane's loyalty app. The retail digital team inherited an AWS estate from an acquired startup, has run it for three years, deploys several times a day, and has its own account structure, pipelines and on-call rota. Moving the app to Azure for consistency would cost roughly a quarter of engineering time to rebuild what already works, and it would change nothing a customer can see. The app stays on AWS. What Mopane does change is the joins: the AWS accounts federate sign-in from Entra ID, send security logs to the group's SIEM and carry the same cost-allocation tags as everything else. Part 6 returns to why those joins matter more than the platform underneath.
Do not choose AWS because its catalogue is large. Every additional service a team adopts is another skill, control, cost line and exit decision. Mature AWS estates standardise a deliberate internal catalogue of approved services and patterns, and treat anything outside it as an exception that needs a reason.
AWS Outposts: AWS on your premises, still tied to a region
AWS Outposts brings AWS-managed infrastructure and APIs into a customer location, for workloads that need low latency to on-site systems, local data processing or data that must stay on the premises. It is important to describe it accurately: an Outpost stays connected to a parent AWS region through a service link, and depends on that region for its control plane. It is not a disconnected platform, and a design that assumes it will keep operating normally during a long WAN outage needs to be checked carefully against AWS's documentation.
Outposts can be anchored to the Cape Town region. Rack and server form factors support different sets of services, and not every feature available in a full region is available on an Outpost there; EKS local clusters, for example, are not supported in Cape Town at the time of writing. Check the current Outposts documentation for the exact service list before designing around it.
When Google Cloud should lead
Google Cloud deserves a leading score where the workload centres on data engineering, BigQuery, machine learning, Kubernetes, open-source platforms, or product engineering aligned to Google's ecosystem. Its South African region is Johannesburg, africa-south1, with three zones at the time of writing. Google is explicit that product availability varies by region and evolves over time, so the specific product you need must be checked against its current locations list.
Google Cloud should lead when:
- BigQuery or a Google-native data platform is central to the business case;
- the organisation has proven Google Cloud and Kubernetes engineering capability;
- a specific AI, data or analytics service produces a measurable advantage;
- the product has global users and Google's network and regional pattern fits the measured traffic;
- the organisation can run Google Cloud as a first-class platform rather than a specialist island maintained by one person.
That last condition is the one most often ignored. A Google Cloud project set up by one enthusiastic data engineer, outside the organisation's identity, logging, policy and cost controls, is not a platform. It is a single point of failure with a credit card.
Google Distributed Cloud air-gapped: a specialist answer
For strict sovereignty or genuinely disconnected requirements, Google Distributed Cloud air-gapped provides Google-managed hardware and software at a customer site, with no connection to Google's public cloud. It is designed for defence, intelligence, regulated industries and similar environments. It is a specialist platform, not a branch-office option: Google states that a production system can run on as few as four racks, and its published evaluation configuration pricing starts at USD 300,000 a month at the time of writing. Organisations considering it should obtain a current quotation and compare it honestly with simpler designs.
Choosing between AWS and Google Cloud
When both are in contention for the same workload, the signals that separate them are usually clear.
| Decision signal | AWS is usually stronger when | Google Cloud is usually stronger when |
|---|---|---|
| Existing competence | AWS accounts, controls and delivery are mature | Google Cloud, Kubernetes and data engineering are mature |
| Differentiating service | An AWS-native managed service removes material work | BigQuery, Google data or AI capability creates measurable value |
| Product architecture | Broad cloud-native or serverless AWS patterns fit | Data-intensive, ML or open-source patterns fit |
| Local requirement | The required AWS service runs in Cape Town | The required Google service runs in Johannesburg |
| Global requirement | Target countries align with AWS regions and network | Target countries align with Google regions and network |
For Mopane, competence settles the loyalty app. For retail analytics, only one signal points to Google at all, a differentiating service, and the data team cannot yet show the operating capability the fifth condition above demands. A claimed advantage on one signal, against a gap on another, is exactly the situation that calls for evidence.
Settle a disputed advantage with a spike
When the defining advantage cannot be proved on paper, run a short, evidence-led spike: take one real slice of the workload and test it the way a production decision needs, against every candidate still standing. A provider demo is not a benchmark. It was built to pass, on data chosen to flatter.
Mopane's data team took twelve months of store sales for one region, about a fifth of the group's volume, and ran the same five tests on BigQuery and on the group's existing Azure analytics stack:
- Performance. How long the weekly demand forecast took to build and refresh at realistic volume.
- Failure behaviour. What happened to the pipeline when a source extract arrived late or malformed.
- Developer effort. How many engineer-days it took to get from raw extracts to a working forecast.
- Controls. Whether sign-in, access, logging and data classification could meet group policy.
- Cost at peak. What the month-end and festive-season runs would cost, priced in dollars and modelled in rand.
The spike took two weeks. BigQuery was materially faster to build on and cheaper to run at this volume. The controls test surfaced the real issue: loyalty member data in the sales extracts is personal information. The team resolved it by pseudonymising member identifiers before the data leaves Mopane's environment, which keeps the analytics useful and reduces what is exposed. The operating gap was closed by federating Google Cloud sign-in from Entra ID, bringing it under the group's logging and tagging standards, and training two more data engineers, so that three people can run it rather than one.
The result was not "Mopane adopts Google Cloud". It was narrower and more defensible: Google Cloud for retail analytics only, under group controls, reviewed in twelve months.
Common mistakes
- Choosing AWS for its catalogue size. Breadth is only valuable for the services you will actually operate well.
- Moving a productive team to the default platform for tidiness. The cost is real engineering time; the benefit is usually a diagram.
- Describing Outposts as independent of the cloud. It relies on a service link to its parent region.
- Assuming a Google product runs in Johannesburg because the region exists. Check the product-by-location list.
- Letting one enthusiast run a cloud outside group controls. That is a single point of failure, not a platform.
- Treating a vendor demo as evidence. Test your own slice, against every candidate, on the hard parts.
A decision you can defend
We choose Google Cloud for Mopane's retail analytics because a two-week spike on one region's sales data showed BigQuery faster to build on and cheaper to run than our existing stack, with controls that meet group policy once member identifiers are pseudonymised. The main risks are a thin skills base and a third platform to govern. We will control them by federating sign-in from Entra ID, applying group logging and tagging standards, and training two more data engineers so that at least three people can operate it. We will reconsider in twelve months, or sooner if the analytics scope grows beyond retail or fewer than three people can operate the platform.
What to take from this part
AWS should lead where AWS competence and services remove real work. Not because its catalogue is large.
Google Cloud should lead where its data, AI or Kubernetes advantage is measurable. And only when it can be run as a platform, not an island.
On-premises options are not interchangeable. Outposts depends on its parent region; Google's air-gapped platform is a specialist, high-cost answer.
Settle disputes with a spike. One real slice, the hard tests, every candidate.
Next in the series: Where Huawei Cloud, Oracle Cloud and South African providers fit.
How CloudNala can help
We help organisations decide when an exception to their default cloud is worth having, and run short evidence spikes that test the hard parts (controls, failure behaviour, developer effort and cost at peak) rather than the easy ones. When an exception is approved, we help bring it under the same identity, logging and cost controls as the rest of the estate.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book a Cloud Platform Decision Review or write to us at consult@cloudnala.co.za