Cloud Architecture and Landing Zone Design
Design cloud environments that can be governed and operated.
Align workload placement, identity, networking, security, resilience and cost with measurable business requirements.
Discuss this requirement →Start with the environment, risk and required outcome.
Align workload placement, identity, networking, security, resilience and cost with measurable business requirements. Namandla Consultants begins with evidence and recommends a proportionate engagement rather than a generic technology package.
Connected expertise for the wider environment.
Clear steps. Visible decisions.
Why cloud architecture is mostly about what comes first
Almost everything in cloud is easy to change except the foundations.
You can resize a virtual machine in minutes. Moving a workload between subscriptions, restructuring an account hierarchy, or re-addressing a network after fifty resources depend on it is a project. Those are the decisions cloud architecture is actually about, and they get made by default when the first workload lands without a structure waiting for it.
The pattern we see repeatedly: a proof of concept was built in a single account by one person. It worked, so it became production. Two years later there are forty resources, no tagging, no separation between environments, identity permissions that grew organically and no way to apply policy centrally. Nothing is broken and everything is harder than it should be.
A landing zone is the structure built before the workloads arrive. It costs two to four weeks. Retrofitting it costs considerably more and it needs downtime.
The cloud landing zone
The same components on both platforms, with different names.
Account and subscription structure
Separate environments. Production, non-production and sandbox in separate accounts or subscriptions rather than separated by tags or naming. Separation at the account boundary means a mistake in development cannot reach production, and it makes cost attribution automatic rather than dependent on tagging discipline.
A management or organisation account holding nothing but the organisation structure, billing and central policy.
A logging account that holds audit logs and to which nothing else has delete rights. Logs held in the same account as the resources they record are deletable by anything with access to that account.
A shared services account for anything genuinely common: directory services, connectivity to on-premises, shared tooling.
Identity
Federated to your existing identity provider rather than separate cloud-only accounts. Roles rather than long-lived keys. Least privilege from the start, because permissions accumulate and never reduce on their own. Just-in-time elevation for privileged roles.
Network topology
Hub and spoke is the pattern that suits most mid-market estates. A hub holding shared connectivity, inspection and on-premises links, with spokes per environment or per workload group.
Address planning across the estate, including your on-premises ranges, allocated with room to grow. Overlapping ranges between cloud and on-premises, or between cloud environments, is the most common obstacle in a later integration and it is expensive to unpick.
Explicit connectivity to on-premises where a hybrid state exists or is coming, which for most South African mid-market estates it does. Covered on hybrid cloud.
Policy guardrails
Preventive rather than detective. Service control policies on AWS, Azure Policy on Azure. Restrict which regions can be used, block public storage creation, require encryption, require tagging, prevent deletion of logging configuration.
Guardrails put in at landing zone stage cost nothing and prevent whole categories of finding. Retrofitted onto a populated environment they generate a remediation backlog first.
Tagging and cost attribution
A tagging standard, enforced by policy at creation rather than requested in a document. Owner, environment, cost centre, application. Without it, spend cannot be attributed and nobody manages a number they cannot see. Covered on cloud managed services.
AWS landing zone and Azure landing zone
AWS landing zone. Organisations for the account hierarchy, service control policies for guardrails, IAM Identity Center for federated access, Control Tower where a prescriptive approach suits, CloudTrail into a dedicated logging account, Transit Gateway for hub and spoke networking.
Azure landing zone. Management groups for the hierarchy, Azure Policy for guardrails, Entra ID for identity, subscriptions as the primary isolation boundary, diagnostic settings into a central Log Analytics workspace, Virtual WAN or hub-and-spoke virtual networks for connectivity.
Both vendors publish reference architectures and both are worth using as a starting point rather than a specification. The reference designs assume a larger organisation than most South African mid-market estates, and applying them wholesale produces a structure with more accounts and more separation than the environment can maintain. The right landing zone is the simplest one that satisfies your isolation, policy and attribution requirements, not the most complete one in the documentation.
Architecture decisions that recur
Managed services or self-managed
A managed database removes patching, backup and availability work at a higher unit cost. For most mid-market workloads that trade is worth taking, because the operational burden it removes is real and the alternative is a virtual machine somebody has to look after.
Availability zones
Spreading across zones within a region protects against a zone failure and it costs cross-zone data transfer. Worth it for the systems where an outage matters, and unnecessary for the rest. The same per-workload logic as everything else.
Regions and pairing
Azure South Africa North is paired with South Africa West, but South Africa West has restricted access and service availability, so an in-country dual-region design must be validated for the specific workload. AWS currently has one public cloud region in Africa, so a second AWS region means going offshore and raises a residency question.
Infrastructure as code
Templates rather than console clicks, so environments are reproducible and changes are reviewable. Worth adopting even at modest scale, because the alternative is an environment nobody can rebuild.
Where state lives
Databases, file storage and application state each need a deliberate answer. The failure mode is state ending up on a virtual machine disk, which makes that machine irreplaceable and undoes most of the benefit of being in cloud.
Well-architected review
Both providers publish a well-architected framework covering operational excellence, security, reliability, performance efficiency, cost optimisation and sustainability. A well-architected review works through an existing environment against those pillars.
It is genuinely useful and it is worth being clear about what it is: a structured set of questions, not an automated scan. The value comes from working through it with people who know the environment and being honest in the answers. A review that produces no findings was a form-filling exercise.
We run these against existing environments as a lighter alternative to a full architecture engagement, particularly where an environment works but nobody is confident it is right.
What Namandla delivers
Cloud architecture design. Account and subscription structure, identity, network topology, policy guardrails, logging, tagging standard and connectivity to on-premises.
Landing zone build on AWS or Azure, sized to your estate rather than to a reference diagram.
Architecture review of an existing environment, including a well-architected review where that shape suits.
Remediation planning where an environment grew without structure, phased so that it can be done while workloads keep running.
Infrastructure as code templates and the handover so your team can extend the environment without us.
Documentation written so a different engineer could maintain it.
Remote delivery nationally. Onsite in Gauteng where hybrid connectivity work needs it.
Common questions about Cloud Architecture
What is cloud architecture?
Cloud architecture is the structural design of a cloud environment: account and subscription hierarchy, identity, network topology, policy guardrails, logging and cost attribution. It covers the decisions that are expensive to change once workloads depend on them.
Almost everything else in cloud is easy to change. Resizing a virtual machine takes minutes. Restructuring an account hierarchy or re-addressing a network after fifty resources depend on it is a project with downtime. Cloud architecture is about getting that small set of decisions right before they calcify.
What is a cloud landing zone?
A cloud landing zone is the structure built before workloads arrive: account and subscription separation, identity, network topology, policy guardrails, logging and tagging. An AWS landing zone and an Azure landing zone use different services for the same purpose.
It typically takes two to four weeks to build. Retrofitting the same structure onto a populated environment takes considerably longer, needs downtime and generates a remediation backlog first. Building it before migration starts is the single most useful sequencing decision in a cloud programme.
We already have cloud resources with no structure. What now?
Assessment first, then a phased remediation. This is a very common position and it is fixable without a rebuild.
The usual sequence is: put the organisation and policy structure in place around what exists, tighten identity, get logging into a separate account, apply tagging retrospectively and then move workloads into properly separated accounts or subscriptions in waves. Each stage delivers something on its own, which matters because a remediation that only pays out at the end tends not to get finished.
Should we use the vendor reference architecture?
As a starting point rather than a specification. Both AWS and Azure publish reference landing zone designs and both assume a larger organisation than most South African mid-market estates.
Applied wholesale, they produce more accounts, more separation and more moving parts than the environment can maintain, and complexity nobody maintains is worse than simplicity. The right landing zone is the simplest one that satisfies your isolation, policy and cost attribution requirements.
Do we need separate accounts for each environment?
Separate accounts or subscriptions for production, non-production and sandbox is the one separation worth insisting on. Beyond that, it depends on the estate.
Account-level separation means a mistake in development cannot reach production, and it makes cost attribution automatic rather than dependent on tagging discipline. Separating environments by tags or naming within a single account is the arrangement that produces the incident where someone deletes the wrong resource.
How does cloud architecture handle our on-premises systems?
Explicitly, through a hub-and-spoke topology with defined connectivity to on-premises and an addressing plan covering both. Most South African mid-market estates are hybrid and will remain so.
The failure mode is designing the cloud environment as though it stands alone and adding connectivity afterwards, which usually surfaces an addressing overlap. Planning addressing across cloud and on-premises together, at the start, costs nothing and avoids a genuinely painful remediation. Covered on hybrid cloud.
What is a well-architected review?
A structured review of an existing environment against the provider’s framework pillars: operational excellence, security, reliability, performance efficiency, cost optimisation and sustainability.
It is a set of questions worked through with people who know the environment, not an automated scan, and the value depends entirely on honest answers. We use it as a lighter alternative to a full architecture engagement, particularly where an environment works and nobody is confident it is right.
Does architecture matter for a small cloud footprint?
Less, and the two things that still matter are separating production from everything else and getting identity right. Both are cheap at the start and awkward later.
If you have five resources in one account, a full landing zone is more structure than the estate justifies. Separate production, federate identity rather than using local accounts, enable logging and apply a basic tagging standard. That is a day of work and it means the environment can grow without needing to be unpicked.