Blyde Financial Services, a fictional South African financial-services group, has four cloud initiatives running at once. Customer service wants an assistant for its contact centre. Operations wants to automate the reading of loan and claims documents. Fraud operations wants faster case triage. HR wants employees to be able to search policies and procedures in plain language. Each initiative was approved separately, so each one asked for its own Azure subscription, and each received an empty one.
Eighteen months later the group has four ways of granting access, three network address plans that overlap, logs in four places (and none in one of them), and a cloud bill that finance cannot split by business unit. None of the teams did anything unusual. They each solved, from scratch and under deadline, problems that every workload has: who may get in, how traffic flows, which rules apply, where the evidence goes, how to recover, and who pays.
That is the problem a cloud landing zone solves. This article explains what one is, in plain terms, and sets the vocabulary for the rest of the series.
Undeveloped land versus a serviced stand
Anyone who has bought property in South Africa knows the difference between a stand on undeveloped land and a serviced stand. Undeveloped land is cheaper on paper, but before you can build you must arrange a road, water, electricity, sewerage and a survey, and every neighbour does the same, separately. A serviced stand arrives with those connections in place, to a municipal standard, and with rules about what may be built on it.
An empty subscription (an "account" in AWS, a "project" in Google Cloud) is undeveloped land. It technically works. You can deploy into it on the first afternoon. But every service the workload will eventually need has to be brought in by the team that got there first.
A cloud landing zone is the serviced stand: a governed starting environment in which identity, connectivity, policy, logging, recovery and cost controls are connected before the first workload is built, so that teams can build and operate safely without reinventing them each time.
The vendors describe the same idea in their own words. Microsoft's Cloud Adoption Framework calls an Azure landing zone "a proven and flexible architecture for governing, securing, and scaling a multi-subscription Azure environment", made up of a platform landing zone and workload landing zones (Microsoft Learn, checked on 7 November 2026). AWS describes a landing zone as "a well-architected, multi-account environment that's based on security and compliance best practices", which AWS Control Tower sets up and governs. Google Cloud calls it "a modular and scalable configuration that enables organizations to adopt Google Cloud for their business needs", also known as a cloud foundation (Google Cloud architecture guidance). The words differ. The idea is the same: govern the environment before the workloads arrive.
What is in the estate
A serviced estate is not a single thing. It is a set of services that each has to be designed, built and run. For a cloud landing zone, they are:
- An organisation structure. Subscriptions, accounts or projects arranged in a hierarchy (Azure management groups, AWS organisational units, Google Cloud folders), so that rules can be applied to groups of workloads rather than one by one.
- Identity and access. One identity directory, access granted to groups rather than individuals, privileged access that is approved and time-limited, and machine identities for pipelines.
- Connectivity. An address plan that does not overlap, a route to shared services and on-premises systems, and a decision about where traffic to and from the internet is inspected. Enterprise landing-zone networking covers this part in depth.
- Policy. Rules enforced by the platform rather than remembered by people: allowed regions, required tags, encryption, no public storage endpoints.
- Logging and monitoring. Activity and security logs sent to a central place that the workload team cannot switch off.
- Recovery. Backup policies, and a restore path that has been tested, because a backup is not restore confidence.
- Cost controls. Budgets, alerts and tags that let finance see who spent what, as argued in FinOps starts before deployment.
- A way to issue new plots. A repeatable process that creates a new, pre-serviced environment on request. Microsoft calls this subscription vending; AWS Control Tower calls its version Account Factory.
The last item is easy to miss and is what separates a landing zone from a well-built first environment. If the second team still has to wait for someone to hand-build its environment, the estate has one serviced stand and a lot of undeveloped land.
What a workload team receives on day one
The test of a landing zone is what a team gets when it asks for one. At Blyde, after the redesign, the fraud operations team completes a short request: the workload's owner, the expected budget, the data classification and the environments it needs. The platform team's vending pipeline does the rest.
On day one the team has a production subscription, already placed in the right part of the hierarchy, that has:
- access groups for engineers, readers and an approved break-glass route, with no individual owners;
- a spoke network with an allocated address range, peered to the shared hub;
- the group's policy set already applied, so a deployment to a disallowed region or an unencrypted store fails at deployment time rather than at audit time;
- diagnostic and activity logs flowing to the central security workspace;
- a default backup policy and a budget alert at the requested amount.
None of this required a design workshop. That is the point. The fraud team's time goes into fraud.
What a landing zone does not include
A serviced stand does not include the house. The most common misunderstanding about landing zones, and the cause of many disappointed steering committees, is to expect the platform to design and run the workload as well.
A cloud landing zone does not:
- Design the application. It provides the network and identity the application uses. It does not decide whether the fraud service should be event-driven or batch.
- Classify or govern the data. It can enforce encryption and block public endpoints. It cannot tell you which fields in a loan application are personal information, who owns them or how long to keep them. That is the job of the data landing zone, part 6 of this series.
- Make the workload secure. It removes whole classes of mistake (public storage, unmanaged admin accounts), but application security testing, dependency management and secure coding remain with the workload team.
- Write the runbooks. It provides a logging workspace and alert routing. Someone still has to decide what an alert means and who wakes up.
- Govern AI models or agents. It provides the environment in which an AI service runs. Which models are approved, how prompts are evaluated and what an agent may do are separate foundations, covered in parts 7 and 8.
- Replace an operating model. A landing zone encodes decisions about ownership. If nobody has made those decisions, the platform will encode the wrong ones. The operating model must move too makes the same point for migration.
Saying this out loud early prevents a familiar pattern: the landing zone is built, the first workload is still late, and the platform is blamed for not doing work it was never designed to do.
Why "build it once" is not enough
Blyde's first instinct, once it saw the problem, was to commission a landing-zone project, build the estate and hand it over. That gets the first stands serviced. It does not keep them serviced.
Policies change when regulations or threats change. New services appear and need rules. Workload teams ask for things the catalogue does not offer. Vendor reference implementations release new versions. AWS, for example, lists its Control Tower landing zone versions with release dates, version 4.0 being released in November 2025, and states that keeping the landing zone updated is the responsibility of the central cloud administrators (AWS Control Tower documentation, checked on 7 November 2026).
An estate needs a body corporate, not only a developer. Part 4 of this series argues that landing zones are products with owners, roadmaps and versioned guardrails rather than one-off projects.
Do you need one yet?
Not every organisation needs a full landing zone on day one. A start-up with one product, one team and one environment can reasonably begin with a carefully built single subscription, as long as it writes down the decisions it would want a landing zone to enforce later. The signals that the serviced estate has become necessary are practical:
| Signal | What it usually means |
|---|---|
| A second team is about to start building | Every decision the first team made by hand is about to be made again, differently |
| Nobody can say who has owner rights in production | Identity is being managed per project, not per organisation |
| Network ranges overlap, or a new workload cannot reach a shared service | Connectivity was designed per workload |
| Audit or risk asks for logs and they are in several places, or missing | Logging is optional rather than enforced |
| Finance cannot split the cloud bill by business unit | Tags and budgets are not part of the environment |
| Restores have never been tested outside a single team | Recovery is a feature of the workload, not of the estate |
| Security findings repeat across workloads | The fix is being applied per workload instead of once, as policy |
For a regulated group like Blyde, most of these were true before the fourth initiative started. Financial-services firms are usually asked to show who has access, where logs are kept and how recovery is proven, and answering those questions four different ways is expensive every time an auditor asks.
Key points
- A cloud landing zone is a serviced estate: a governed starting environment in which identity, connectivity, policy, logging, recovery and cost controls exist before the first workload does.
- Azure, AWS and Google Cloud use different words for the same idea, and each provides reference implementations. None of them removes the need to make the underlying decisions.
- The vending process that issues new, pre-serviced environments is what turns one good environment into a landing zone.
- A landing zone does not design the application, govern the data, secure the code, write runbooks or govern AI. Those are separate responsibilities, and the series covers the foundations for data, AI and agents in later parts.
- The estate needs ongoing ownership, because rules, threats and vendor implementations keep changing.
This is part 1 of Cloud Foundations, Explained End to End. Next: The six design areas every landing zone must resolve.
Background reading: What is an Azure landing zone? (Microsoft Learn), What is AWS Control Tower? (AWS) and Landing zone design in Google Cloud (Google Cloud), all checked on 7 November 2026.
How CloudNala can help
CloudNala runs landing-zone reviews for organisations that already have several cloud workloads and suspect each one was built on its own undeveloped land. We inventory what exists across identity, network, policy, logging, recovery and cost, show which decisions are being made repeatedly and inconsistently, and set out the smallest serviced estate that would let your next team start on day one with those decisions already made.
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