Azure South Africa North went generally available in 2019. It was a landmark moment for the South African technology sector — a hyperscale cloud region on local soil, with the data residency and latency characteristics that local workloads had long needed. Microsoft followed with Azure South Africa West as a paired region, giving organisations a foundation for genuine geographic redundancy within the country.
That is the good news. The less-discussed reality is that not all of Azure runs in South Africa. A meaningful subset of Azure services — including some of the most commercially interesting ones — are only available in global regions. If you design an architecture without accounting for this, you will either discover gaps during implementation or end up with a hybrid deployment that is more complex and more expensive than you planned.
This guide is for technology leaders and architects who are either starting on Azure in South Africa or auditing an existing deployment. It covers what is available, what is not, how to plan around the gaps, and the SA-specific considerations that do not appear in Microsoft's global documentation.
What South Africa North gives you
The South Africa North region (Johannesburg) is a full-featured Azure region with availability zones — three physically separate datacentre locations within the metro, connected by high-speed private fibre. This matters for resilience design: a zone-redundant architecture in Johannesburg can survive the failure of an entire datacentre without service interruption.
The core platform is well covered. Compute (Virtual Machines across most series, Virtual Machine Scale Sets, Azure Kubernetes Service), storage (Blob, Files, Queues, Tables, Managed Disks), networking (Virtual Networks, Load Balancer, Application Gateway, Firewall, ExpressRoute), databases (Azure SQL, Cosmos DB, Database for PostgreSQL, Database for MySQL), and the major integration services (Service Bus, Event Hubs, API Management, Logic Apps) are all present and production-ready.
For most enterprise workloads — line-of-business applications, data warehouses, web APIs, ERP integrations, document management systems — South Africa North is sufficient.
Where the gaps are
The gaps appear at the edges of the platform, particularly in newer and more specialised services. A few categories worth knowing:
Azure AI and Cognitive Services. The AI service landscape in South Africa North is partial. Core services like Azure AI Search, Azure AI Vision, and Azure AI Language are available. Azure OpenAI Service has had limited regional availability and has historically required capacity allocation in regions like East US or Sweden Central. This is changing, but if your architecture depends on Azure OpenAI with low latency to South African end users, verify current regional availability before committing to a design — do not assume it because you read that it was coming.
Confidential Computing. Services like Azure Confidential VMs and Azure Confidential Ledger are not available in South Africa North. For financial services and health organisations with specific hardware-level data isolation requirements, this is a design constraint.
Some higher-tier VM families. While standard compute series are available, certain GPU-intensive VM types and the latest-generation high-memory series may have limited or no availability. If you are building AI training workloads or high-performance compute, validate SKU availability before designing around specific instance types.
Some PaaS services. Service availability changes — Microsoft adds regional coverage continuously — but at any given point, a handful of platform services (certain tiers of Azure Container Apps, specific Azure Spring Apps features, preview services generally) may not yet be available in South Africa. The authoritative source is the Azure products by region page, and it should be the first tab you open when evaluating any Azure service for a South African deployment.
The paired region question
South Africa West (Cape Town) is the designated paired region for South Africa North. Azure uses region pairs for platform-managed replication, geo-redundant storage failover, and sequential update rollouts — if Azure needs to apply a platform update, it will do one region in the pair at a time, so both do not go offline simultaneously.
The practical implication: if you want geo-redundant storage (GRS) or read-access geo-redundant storage (RA-GRS) with your primary data in Johannesburg, the secondary copy goes to Cape Town by default. For POPIA compliance, this is generally fine — both regions are within South Africa. But the service parity between the two regions is not identical. South Africa West is a smaller region and carries fewer services than North. For most replication use cases this does not matter. For active-active multi-region architectures where both regions need to serve live traffic, you need to validate that every service in your stack is available in both.
The global region fallback
When a service is not available locally, the standard workaround is to run it in a global region and connect it to the South African deployment over the Azure backbone. Microsoft's global network is private — traffic between Azure regions does not traverse the public internet — so the connectivity is reliable and the latency is predictable.
The considerations are:
Latency. The round-trip latency from Johannesburg to West Europe (Amsterdam) is typically 160–180ms. To East US it is similar or slightly higher. For synchronous API calls in a user-facing workflow, this is noticeable. For background processing, batch jobs, or async integrations, it is not. Design accordingly: services that require sub-50ms response as part of a critical path need to be local. Services that run in the background can tolerate global regions.
Data residency. If a service processes personal information and you are using a global region, you have moved that processing outside South Africa. For POPIA purposes, cross-border transfers of personal information require that the recipient country provides adequate protection — or that you have appropriate contractual protections in place. Running an Azure AI service in a Microsoft-operated EU region with a Microsoft data processing agreement in place is a defensible position for many use cases. Running it in a region with weaker protections or without understanding the data flow is not. Get legal clarity on what data your globally-hosted services receive before assuming it is fine.
Cost. Egress from global Azure regions back to South Africa is charged differently to intra-region traffic. If you have high-bandwidth flows between a globally-hosted service and a locally-hosted workload, model the egress cost before committing to the architecture.
The currency and pricing reality
Azure pricing is published in USD. Your invoice, if you are billed locally through a Microsoft partner, may be converted at rates that do not reflect the spot rate on the day of consumption. The rand has depreciated materially against the dollar over the past decade, and cloud budgets set in rands that were not stress-tested for exchange rate movement have been absorbing significant unplanned cost increases.
There are three practical responses to this:
Set your cloud budget in USD and manage the rand exposure at the treasury level rather than in the technology team. This is the most honest approach — it makes the currency risk visible to the people who manage currency risk.
Build exchange rate sensitivity into your cloud business cases. A business case that only models the cost at the current exchange rate is incomplete. Model at 10% and 20% rand depreciation scenarios as well.
Consider Microsoft Azure Savings Plans or Reserved Instances where your baseline consumption is predictable. These commit you to USD spend, but they significantly reduce the per-unit cost, which creates more buffer before currency movement becomes a problem.
ExpressRoute and connectivity options
If your organisation has significant data transfer requirements or needs reliable, low-latency connectivity between on-premises infrastructure and Azure, ExpressRoute is the right answer. Microsoft has ExpressRoute peering locations in Johannesburg through multiple carriers, and the private connectivity this provides is meaningfully different from internet-based VPN in both reliability and performance.
For most small to mid-size deployments, a well-configured site-to-site VPN over a quality internet connection is adequate. ExpressRoute becomes relevant when you are transferring terabytes per day, when your workloads require sub-10ms on-premises-to-cloud latency, or when your security policy prohibits traversal of the public internet.
Loadshedding and availability zones
Availability zones in Azure South Africa North are genuinely useful insurance against loadshedding. An outage that takes down one datacentre location — whether caused by infrastructure failure, prolonged power disruption, or anything else — does not affect the other zones.
The cost of zone-redundant deployment is real: zone-redundant storage and databases carry a premium over locally-redundant configurations, and running compute across zones increases your VM footprint. But for any workload that cannot afford downtime measured in hours, the premium is worth it.
The architecture pattern that works well for South African workloads: zone-redundant for the data tier (databases, blob storage), zone-distributed for the compute tier (VM Scale Sets or AKS node pools spread across zones), and a zone-redundant load balancer in front. This gives you resilience to a single-zone failure with no manual intervention and manageable cost overhead.
Planning your Azure deployment: the short checklist
Before you finalise an Azure architecture for a South African workload:
- Verify every service you plan to use is available in South Africa North on the products-by-region page — do this at design time, not delivery time.
- Identify any services that will need to run in global regions. Map the data flows, assess the POPIA implications, and model the egress cost.
- Decide your redundancy strategy: locally-redundant (cheapest, no zone protection), zone-redundant (higher cost, survives a single-zone outage), or geo-redundant (highest cost, failover to Cape Town).
- Build your cost model in USD. Apply exchange rate sensitivity analysis. Do not present a single-point estimate to the business.
- If you have on-premises connectivity requirements, engage a carrier for ExpressRoute peering early — the provisioning lead time is measured in weeks, not days.
- Review your South Africa West service availability if you intend to run active-active multi-region, not just passive failover.
Azure is a capable and well-supported platform for South African workloads. The organisations that run it well are the ones that understand the boundaries of the local regions, plan for the gaps, and build their commercial models around the currency reality. The organisations that struggle are the ones that assumed the global feature set, discovered the gaps during implementation, and absorbed the rework cost.
CloudNala specialises in Azure architecture and deployment for South African enterprises, financial services organisations, and public sector bodies. If you are designing or reviewing an Azure deployment, talk to our team.