For most of the last decade, the managed-versus-self-hosted debate in South Africa had an awkward shape. The managed option often meant running in a European region, and the self-hosted option meant running everything yourself in a local data centre. That shape has changed. All three major hyperscalers now operate cloud regions in the country, and each offers its managed Kubernetes service there.
That makes the decision more interesting, not simpler. A managed Kubernetes control plane in Johannesburg does not mean every add-on, registry, telemetry store and AI service around it runs in Johannesburg too. And "managed" covers a wide range, from a fully operated add-on to a cluster you still patch, upgrade and staff.
CloudNala's position is that the managed-or-self-hosted question should be asked component by component, not once for the whole platform, and that regional availability has to be checked against primary sources on the day you decide. Provider catalogues change faster than architecture documents.
Baobab Retail Group is fictional, and its systems and figures are illustrative. Baobab runs its containers on one hyperscaler in its South African region. When the board asked whether customer data "stays in South Africa", the platform team realised it could answer for the cluster but not for the logs, metrics, backups or container images.
What we could confirm in each region
We checked each provider's public documentation on 28 October 2026. The table below records only what we could confirm from a primary source that day. Where a cell says "check", it means we could not confirm it, not that the service is missing.
Azure South Africa North. Microsoft's region list places South Africa North in Johannesburg with three availability zones. Its paired region is South Africa West in Cape Town, which Microsoft marks as access-restricted, meaning it is reserved for specific scenarios such as disaster recovery and needs an access request. Microsoft announced general availability of Azure Kubernetes Service (AKS) in South Africa North in 2019, and Azure's public retail prices list Azure Container Registry meters for the region.
AWS Africa (Cape Town), af-south-1. AWS's region documentation lists af-south-1 with three Availability Zones and marks it as an opt-in region: it is disabled by default and has to be enabled for an account before use. AWS's service endpoint documentation lists both Amazon EKS and Amazon ECR endpoints in af-south-1, and its EC2 instance types by Region listing includes G4dn GPU instances there.
Google Cloud Johannesburg, africa-south1. Google announced the Johannesburg region as ready for customer use on 31 January 2024. Its Compute Engine documentation lists three zones (africa-south1-a, -b and -c). Google's regional service health page for the region lists Google Kubernetes Engine, Artifact Registry, Cloud Run, Cloud SQL and Secret Manager among its products.
Two observations matter more than the table itself. First, managed Kubernetes is available in-country from all three providers, so "we have to self-host to stay local" is no longer automatically true for the cluster. Second, the services around the cluster are uneven, and you have to check each one you depend on.
Residency is a data flow question
This section is general guidance, not legal advice. Take advice from your own legal and compliance teams on your obligations.
The Protection of Personal Information Act does not simply ban storing personal information outside South Africa. Section 72 sets conditions under which a responsible party may transfer personal information to a third party in a foreign country: for example, where the recipient is bound by law, binding corporate rules or an agreement providing adequate protection, or where the data subject consents. Your sector regulator, contracts and internal policies may impose stricter requirements than the Act itself.
What this means for a cloud-native platform is that "where is the cluster?" is the wrong question. The right question is "where does each copy of the data go?" For a typical Kubernetes platform, that list includes:
- application databases and object storage;
- container images, which may contain configuration and occasionally data;
- logs and traces, which routinely contain customer identifiers;
- metrics, which usually do not, but sometimes carry labels that do;
- backups and disaster recovery copies;
- support bundles and diagnostics sent to a vendor.
Managed add-ons are where this gets subtle. To give one example, Microsoft's Container insights documentation includes a region mapping table that lists South Africa North clusters against a West Europe Log Analytics workspace. Read that as a prompt to check, for every add-on you enable, where its data actually lands under your configuration. It is exactly the kind of detail that a "the cluster is in Johannesburg" answer misses.
For the cost side of in-country hosting, Keeping AI in the country: why data sovereignty can cost more makes the case for putting the residency premium in the business case up front. The same logic applies to platform components.
The managed-to-self-hosted staircase
For any single component, there are four broad options. The same CNCF project can sit on any of them.
Managed add-on. The cloud provider runs and patches it. You configure it. Your burden is lowest, and your control over versions and features is lowest too.
Vendor distribution. A commercial vendor packages, patches and supports the project. You run it, but with someone to call.
Self-hosted on managed Kubernetes. You install and operate the project yourself on a managed cluster. This is where most CNCF tooling actually lives in practice, including Baobab's GitOps controller and policy engine.
Self-hosted everything. You run the cluster and everything on it, in your own data centre or on virtual machines. Maximum control, maximum burden.
For a 15-person team, the useful question is not which step is best in general but which steps the team can staff properly. Every component on the third or fourth step needs an upgrade owner, an on-call path and a support ledger of the kind described in Part 2.
Operational burden and skills
Self-hosting cost is mostly people. A self-hosted component needs someone who understands it well enough to upgrade it, debug it under pressure and recognise when its defaults are wrong. In the South African market, experienced platform engineers are scarce and expensive, and a small team cannot be expert in fifteen tools.
Baobab's rule of thumb is that each self-hosted component must have two engineers who can operate it, so that leave, resignation or a bad week does not turn into an outage. With 15 people, many of whom build product-facing tooling, that rule alone limits how many self-hosted components the platform can carry. It pushed two of Baobab's candidates onto the managed step.
Managed services shift the skills requirement rather than remove it. Someone still has to understand the managed service's version lifecycle, quotas, failure modes and pricing. Managed Kubernetes services set their own version support windows, and a cluster left alone will eventually be upgraded for you, on the provider's schedule rather than yours.
Rand-denominated cost drivers
We do not quote prices here, because they change and depend on your agreement. The drivers, however, are stable.
Currency. Check whether your cloud agreement and any vendor support contracts are priced in rand or in another currency. Exchange-rate movement can change your monthly cost when usage has not changed at all.
Regional price differences. Prices for the same service can differ between regions. Compare the South African region with any alternative using the provider's own calculator, for the specific services you need.
Data egress. Moving data out of a region or out of the cloud costs money. Telemetry shipped to an external SaaS tool, backups copied to another region and images pulled across regions all add up.
Engineering time. For self-hosted components, the largest cost is usually the engineers who run them. A managed add-on that costs more on the invoice can be cheaper in total.
Extended support. Falling behind on versions can carry its own charge. AWS, for example, documents an additional per-cluster-hour cost for EKS clusters running a Kubernetes version in extended support.
What Baobab decided
Baobab kept its managed Kubernetes clusters in its South African region and listed every data flow leaving them. Three surprised the team: application logs shipped to a SaaS observability tool hosted outside the country, a container image cache in another region set up during a migration and never removed, and vendor support bundles uploaded during incidents.
The logs were the material issue. After review with the compliance team, Baobab moved log storage into the local region, redacted customer identifiers at the collector before anything left the cluster, and documented the remaining cross-border flows with the basis for each. The image cache was deleted. Support bundle uploads now go through a redaction step.
None of this needed a different cluster. It needed a list.
Next: Part 5, Kubernetes is the engine, not the platform. All parts are on the series page.
How CloudNala can help
CloudNala helps South African organisations decide where cloud-native components should run. We map every data flow out of your clusters, check service availability in the regions you can use against current provider documentation, and work through the managed-or-self-hosted decision component by component with your platform, security and compliance teams. We are not lawyers, and we will work alongside your legal advisers on residency questions.
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 Native Platform Review or write to us at consult@cloudnala.co.za