When Blyde Financial Services, the fictional South African financial-services group in this series, decided to replace its four project-built cloud environments with a single cloud landing zone, the first workshop produced a whiteboard with sixty-three items on it. Some were decisions ("one subscription per workload or per team?"), some were products ("which firewall?"), and some were complaints ("nobody answers the access-request queue"). It was all true, and none of it was usable as a plan.
What the group needed was a structure: a small number of areas that between them cover every decision a landing zone must make, in an order that stops later decisions from undoing earlier ones. This article sets out six. They are a CloudNala grouping, chosen to be provider-neutral, and they map closely onto the design areas that Microsoft, AWS and Google Cloud each publish.
Six areas, not sixty-three items
The six design areas are:
- Organisation and accounts: how subscriptions, accounts or projects are arranged, and where each workload lives.
- Identity and access: who and what may do which actions, and how that is granted, approved and removed.
- Connectivity: how traffic flows between workloads, shared services, on-premises systems and the internet, and where it is inspected.
- Security and governance: which rules are enforced by the platform, how compliance is shown and how drift is detected.
- Management and operations: how the estate is monitored, how incidents are detected and how workloads are backed up and recovered.
- Platform automation and delivery: how all of the above is deployed, tested and changed.
Microsoft's Cloud Adoption Framework lists eight design areas, grouped into environment areas (billing and tenant, identity and access management, resource organisation, network topology and connectivity) and compliance areas (security, management, governance, and platform automation and DevOps) (Microsoft Learn, checked on 7 November 2026). The six above fold billing and tenant into organisation, and security and governance into one area, because in most mid-sized organisations the same people decide them. Google Cloud's landing-zone guidance names identity provisioning, resource hierarchy, network and security controls as its core decisions, with monitoring and logging, backup and disaster recovery, compliance and cost as further elements (Google Cloud, checked on 7 November 2026). The names vary by provider. AWS and Azure use different names for many of the same ideas, and landing zones are no exception.
1. Organisation and accounts
The first area decides the shape of the estate. In Azure that means management groups and subscriptions; in AWS, organisational units and accounts; in Google Cloud, folders and projects. The decisions are:
- The unit of isolation. Is a subscription or account issued per workload, per workload per environment, or per team? Blyde chose one per workload per environment, because it makes access, cost and blast radius line up.
- The hierarchy. Which groupings carry different rules? A common pattern separates platform resources from workloads, and internally facing workloads from internet-facing ones, with a sandbox branch and a decommissioned branch.
- Billing and tenancy. Which commercial agreement and identity tenant the estate sits under, and how costs are attributed.
The hierarchy should reflect differences in rules, not the organisation chart. Business units reorganise. The fact that an internet-facing workload needs a web application firewall does not.
2. Identity and access
Identity is the primary security boundary in the cloud, and it is decided early because every other area depends on it: who can change the network, who can approve a policy exception, who can read the logs.
The decisions are about structure, not products: one directory or several; access granted to groups, never directly to people; privileged roles that are requested, approved and time-limited rather than permanent; managed identities for pipelines and workloads instead of stored secrets; and a break-glass route that is tested and monitored. Blyde's first estate had eleven individual owners on one production subscription. Its first identity rule was that nobody would own anything personally.
3. Connectivity
Connectivity decides how a workload reaches the things it needs and how the internet reaches it. The core decisions are the address plan (ranges that will never overlap, sized for growth), the topology (usually a hub with spokes, or a provider-managed equivalent), where inspection happens, how DNS resolves private names, and how the estate connects to offices and data centres.
This series does not repeat the detail. Enterprise landing-zone networking and IP addresses, CIDR and an address plan you will not regret cover it. The landing-zone point is simpler: the network is designed once for the estate, and each workload receives a slice of it.
4. Security and governance
This area decides which rules the platform enforces rather than requests. Examples include allowed regions, required tags, encryption at rest, no public network access to data stores, approved service lists and diagnostic settings that cannot be turned off.
Three decisions matter more than the individual rules:
- Enforce, audit or advise? Some rules should block a deployment, some should report a finding, and some should only be guidance. Deciding which is which, per rule, is more important than having many rules.
- Where is each rule assigned? Rules assigned high in the hierarchy apply to everything below. Assigning them at the right level is how you avoid exceptions.
- How are exceptions handled? Every estate needs them. An exception without an owner and an expiry date becomes a permanent hole, a point part 4 develops.
Security monitoring (posture management, threat detection, a security information and event management service) sits here too, because it is how the organisation knows the rules are holding.
5. Management and operations
This area decides how the estate is run day to day. It covers central logging and where logs are kept and for how long, monitoring and alert routing, patching and update management, backup policies and tested restores, and the boundary between what the platform team monitors and what each workload team monitors.
The common mistake is to treat this area as something to add after go-live. When Blyde's document-processing workload had its first serious incident, the team discovered that diagnostic logs had never been enabled on the storage account involved. The logs it needed did not exist. Logs, metrics and traces explains what each signal is for. The landing zone's job is to make sure they exist before the incident.
6. Platform automation and delivery
The sixth area decides how the other five are built and changed. A landing zone defined by hand in a portal drifts from its design within weeks. A landing zone defined as code, stored in version control, reviewed and deployed through a pipeline, can be rebuilt, tested and changed with evidence.
The decisions are the infrastructure-as-code language, the repository structure, who may approve a change to the platform, how changes are tested before they reach production, and how new workload environments are issued. Microsoft describes infrastructure as code as the recommended way to deploy its platform landing zone, with accelerators in Bicep or Terraform built on Azure Verified Modules (Microsoft Learn, checked on 7 November 2026). Infrastructure as code: why you need it and how to start small is a primer, and part 5 of this series looks at verified modules in detail.
The order matters
The six areas are not independent, and they are best decided roughly in order. The hierarchy decides where identity and policy are assigned. Identity decides who can change the network. The network decides where inspection and logging happen. Security rules depend on all three. Operations depends on the logs that the rules require. Automation encodes everything above it.
"Roughly in order" is deliberate. In practice the first pass through all six takes a few weeks, and later passes revisit earlier areas as workloads arrive with new needs. What matters is that a decision in a later area is never allowed to quietly override an earlier one. If the fraud team needs internet egress that the connectivity design does not allow, that is a connectivity decision to reopen, not a firewall rule to add.
A checklist for each area
Before Blyde's platform team declared its first version ready, it checked that each area had a written answer, an owner and evidence. The checklist below is the provider-neutral version.
| Area | Written decision | Owner | Evidence that it holds |
|---|---|---|---|
| Organisation and accounts | Unit of isolation, hierarchy, sandbox and decommission branches | Platform lead with finance | Hierarchy in code; every subscription placed |
| Identity and access | Group-only access, time-limited privilege, break-glass route | Identity lead | Access review report; no direct owner grants |
| Connectivity | Address plan, topology, inspection point, DNS | Network lead | Address register; routing tests |
| Security and governance | Rule set with enforce, audit or advise per rule; exception process | Security architect | Compliance report; exception register with expiry dates |
| Management and operations | Log destinations and retention, alert routing, backup and restore | Operations lead | Restore test record; alert routing test |
| Platform automation and delivery | Language, repository, pipeline, approval and vending process | Platform lead | Platform rebuilt from code in a test tenant or account |
The last column is what makes this a design rather than a document. A decision without evidence that it holds is an intention.
Key points
- Every cloud landing zone must resolve six design areas: organisation and accounts, identity and access, connectivity, security and governance, management and operations, and platform automation and delivery.
- The grouping is provider-neutral. Microsoft lists eight design areas and Google Cloud four core ones plus further elements; the underlying decisions are the same.
- Decide the areas roughly in order, because each one constrains the next, and reopen an earlier area rather than overriding it from a later one.
- Platform automation is what keeps the other five true over time. A landing zone built by hand drifts.
- Each area needs a written decision, a named owner and evidence that it holds.
This is part 2 of Cloud Foundations, Explained End to End. Previous: A cloud landing zone is a serviced estate, not an empty subscription. Next: Platform landing zone versus application landing zone.
Background reading: Azure landing zone design areas (Microsoft Learn), Plan your AWS Control Tower landing zone (AWS) and Landing zone design in Google Cloud (Google Cloud), checked on 7 November 2026.
How CloudNala can help
CloudNala runs design-area workshops that turn a whiteboard of sixty items into six written decisions with owners. We take your current estate through each area in order, mark which decisions are already made (often implicitly, and inconsistently), which are missing, and which are being overridden by later ones, and leave you with a checklist and evidence plan your platform team can build against on Azure, AWS or Google Cloud.
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 Landing Zone Review or write to us at consult@cloudnala.co.za