Most landing zone advice you find online assumes you’re a Fortune 500 in North America or Western Europe. Azure CAF tells you to deploy across two regions for resilience. Microsoft’s reference architectures default to UK South + UK West, or East US + East US 2. The pricing examples are in USD with no FX hedging considered. The compliance assumptions are GDPR-centric.
If you’re running a bank in Lagos, an insurer in Nairobi, or a public sector platform in Pretoria, that advice gets you to a landing zone that’s expensive, slow, and missing the regulatory controls your auditors actually care about. Not because the framework is wrong, but because the defaults assume context you don’t have.
This is what we’d build instead, based on what we’ve shipped for African enterprises over the past five years. Specifics where they matter. Trade-offs called out. No marketing.
Azure has three regions that matter for African workloads in 2026: South Africa North (Johannesburg), South Africa West (Cape Town), and West Europe (Amsterdam). For Nigerian, Kenyan, and Ghanaian customers, latency to South Africa North averages 80-120ms. To West Europe, 90-150ms depending on submarine cable health.
For most workloads, South Africa North as primary and West Europe as DR is the right answer. Latency is acceptable for transactional systems. Data sovereignty is solved for clients who insist on data staying on the continent. Pricing is reasonable.
South Africa North to South Africa West works on paper as an in-region DR pair, but availability of services in West is patchy. Confidential VMs aren’t there. Some AI services aren’t there. Several Postgres flavours aren’t there. For a true active-active design, you’ll find capability gaps. We default to South Africa North + West Europe for DR unless the client has a hard sovereignty mandate.
If your regulator demands data physically stays in-country and Azure doesn’t have a region there, you have two options: deploy via Azure Stack HCI on local infrastructure, or use a different cloud entirely. Don’t pretend South Africa North satisfies a Nigerian Data Protection Regulation requirement because the data centre is on the same continent. Auditors increasingly distinguish.
CAF says: one platform subscription per landing zone, one workload subscription per app. We modify this.
For most African enterprises, you don’t need ten subscriptions on day one. You need three.
Platform subscription. Hosts the hub VNet, Azure Firewall, ExpressRoute or VPN gateway, log analytics workspace, key vault for platform secrets, private DNS zones, Bastion. Owned by the cloud team. Heavy on Defender for Cloud, Sentinel integration. No workload code runs here.
Production subscription. All production workloads. One subscription, multiple resource groups, separated by management group inheritance. RBAC is the boundary, not subscription IDs. Production budget alerts, production tagging policy.
Non-production subscription. Dev, test, UAT. Anything that isn’t customer-facing. Auto-shutdown policies on VMs after hours. Lower SKUs by default. Strict spend caps.
This gets you 80% of the governance benefit at 30% of the operational overhead. When you actually have separate product lines with separate ownership and billing, you split production into multiple subscriptions. Until then, you’re creating coordination overhead.
Hub-and-spoke. Hub in the platform subscription. Spokes per environment.
The hub VNet sits at the centre with Azure Firewall and the ExpressRoute or VPN gateway. Workload spokes peer to the hub. Spoke-to-spoke traffic forced through the hub via UDR. East-west inspection is non-negotiable for any regulated workload.
Azure Firewall Premium specifically. The Standard SKU misses TLS inspection, URL filtering, and IDPS. For a bank or healthcare client, these aren’t optional. The cost difference is real (about 4x) but the alternative is justifying to your auditor why you can’t see encrypted traffic between application tiers.
ExpressRoute or VPN? For most African enterprises, start with site-to-site VPN. Total monthly cost is around $35-55 USD plus egress. ExpressRoute starts at $200/month for the lowest tier and you need a partner who terminates locally, which isn’t trivial in West Africa. The latency difference matters for some database replication scenarios but not for most applications. Build the architecture so you can swap VPN for ExpressRoute later by adding a connection to the same gateway.
Private endpoints everywhere. Every storage account, every PaaS service, every database. The public network access toggle is set to disabled at deployment via policy. If you need to grant temporary access from a developer machine, do it via Bastion through a jump VM, not by enabling public access.
Entra ID as the tenant. Sync from your on-premises AD if you have one, or run cloud-native if you’re greenfield. Most African enterprises have a Microsoft 365 tenant already, so reuse it.
Three identity tiers. Tier 0 is platform admins. Tier 1 is workload owners. Tier 2 is developers. Tier 0 accounts get PIM with approval workflows, MFA enforced via Conditional Access, no standing access to production. Tier 1 gets just-in-time elevation. Tier 2 gets RBAC scoped to non-production resource groups by default.
Service principals are a problem. Most landing zone failures we audit have service principals with Contributor on entire subscriptions, no expiry, no rotation, and one of them is in a GitHub repo. Use managed identities wherever the workload runs in Azure. Federated credentials for CI/CD from GitHub Actions, Azure DevOps, GitLab. If you must use a service principal with a secret, store it in Key Vault and rotate via automation.
Three policies you implement on day one, enforced via Azure Policy at the management group level:
Region restriction. Resources can only be deployed to South Africa North, South Africa West, and West Europe. This prevents the classic mistake of someone testing in East US and quietly leaving production data there.
Tag enforcement. Every resource group must have CostCentre, Owner, Environment, DataClassification. Without these, Azure Cost Management is useless and you can’t enforce data handling policies downstream.
Storage account secure transfer. No HTTP. Minimum TLS 1.2. Block blob public access. This catches at deployment time the mistake that ends up on the BBC tech section six months later.
Add more as you mature. Defender for Cloud Security Benchmark policies are a good baseline once these three are landed.
The thing nobody tells you about Azure in NGN: the exchange rate moves more than the bill. A 10% NGN depreciation against the USD shifts your Azure spend by 10% next month. Plan for FX volatility, not just resource consumption.
Practical tactics:
Reserved instances on stable workloads. If you know you’re running a SQL Database for the next three years, buy the reservation. Saves 30-60%. Lock in USD pricing, accept the FX risk on that fixed amount rather than floating monthly.
Auto-shutdown on dev VMs. Tag-based. After 7pm WAT, shut down anything tagged Environment=Dev. Wakes back up at 7am. This alone saves about 30% on dev compute.
Storage lifecycle policies. Move blob storage to cool tier after 30 days, archive after 90. Logs, backups, audit data all qualify. Cost difference is significant.
Tag everything from day one. Cost allocation gets exponentially harder retrofitted. Set the tag policy before the first resource gets deployed.
We typically see clients reduce monthly spend 30-50% in the first six months on managed engagements. Not because Azure is overpriced, but because most clients arrived without these tactics in place.
A few things our landing zone reference doesn’t include that some larger consultancies push:
Azure Lighthouse for delegated management. Useful if you’re a managed service provider with many clients. Overkill for a single enterprise. Skip until you actually have a partner relationship that needs it.
Application Gateway at the hub. Application-layer routing belongs at the spoke, owned by the workload team. Putting it in the hub creates a chokepoint and a shared dependency that nobody wants to update.
A separate connectivity subscription. CAF suggests this. For most clients it’s three resources sitting in a separate billing boundary creating no real benefit. Keep ExpressRoute or VPN in the platform subscription.
Sentinel from day one. Sentinel is excellent. It’s also expensive and operationally heavy. Start with Defender for Cloud + Log Analytics. Add Sentinel when you have a SOC team to actually consume it, or when you’ve contracted us to run one for you.
Discovery and design: 2-3 weeks. We sit with the client, walk through existing systems, agree the trade-offs.
Platform deployment: 1 week. The hub, the firewall, the gateway, the policies, the management groups. Mostly Terraform or Bicep, peer-reviewed, deployed via pipeline.
First workload migration: 2-4 weeks per workload depending on complexity. We don’t do big-bang migrations. Workloads land in their own resource group, tested in non-production first, promoted to production via the same pipeline.
Handover: 1-2 weeks of runbooks, training, joint operation. Then optional managed services or you take it from there.
The whole thing for a mid-sized enterprise: 8-12 weeks to a production-ready platform with one workload migrated. Adding workloads after that is incremental and faster.
These come up often enough to call out:
The landing zone with no actual workloads in it. Beautifully architected, fully governed, hub-and-spoke perfection. Empty. The client spent three months on the platform and never started the migration. If you’re not landing a workload within six weeks of platform completion, something is wrong.
The “we’ll add security later” pattern. Public IPs everywhere, NSGs allowing 0.0.0.0/0 on port 22 with “we’ll restrict later.” It never gets restricted. Build secure from day one, even if it slows discovery.
Over-engineered cost allocation. Multiple subscriptions, multiple resource groups per workload, deep tag taxonomies. The client can’t operate it because nobody understands where things go. Start simple, add structure when there’s a real reason.
Reserved instances bought too early. Client commits to three years of an SKU they outgrow in six months. Wait until you have three months of steady-state usage data before purchasing reservations.
Six months after deployment, a healthy landing zone looks like this. Cost reporting is available per workload, per environment, per cost centre, without anyone in finance having to ask the cloud team. New workloads can be deployed without a ticket to the platform team because the patterns are documented and the pipelines exist. Security incidents are detected within hours, not weeks, because Defender for Cloud has actual visibility into traffic flows. Auditors come in, ask for evidence of access controls, and get it from Entra logs in fifteen minutes instead of three days.
That’s the goal. Not perfection on day one. Operability over time.
If you’re planning an Azure landing zone for an African enterprise and want a second opinion on your architecture, book a consultation. If you’re starting from scratch, request a quote and we can scope the work and give you a written proposal in a week.