Cloud Foundations, Explained End to End
A landing zone is not a collection of cloud resources. It is a governed starting environment that lets teams build and operate safely without reinventing identity, security, connectivity, observability, recovery and cost control for every workload. This ten-part series follows Blyde Financial Services, a fictional South African financial-services group modernising customer service, document processing, fraud operations and employee knowledge, from four project-built environments to shared foundations. Parts 1 to 5 cover the cloud landing zone: the serviced-estate idea, the six design areas, the boundary between the platform landing zone and application landing zones, running the landing zone as a product, and turning standards into verified modules. Parts 6 to 10 build upward to the data landing zone, the AI landing zone and the agentic landing zone, compare all four in one enterprise, and close with a 12-month roadmap. The series is vendor-neutral across Microsoft Azure, AWS and Google Cloud. Research claims were checked on 7 November 2026.
10 articles
- Part 1A cloud landing zone is a serviced estate, not an empty subscriptionAn empty subscription is undeveloped land: every team that arrives has to bring its own identity, network, policy, logging, recovery and cost controls. Part 1 of Cloud Foundations, Explained End to End explains what a cloud landing zone is, what a workload team should receive on day one, and what a landing zone deliberately does not include.9 min read
- Part 2The six design areas every landing zone must resolveEvery cloud landing zone, on any provider, has to answer the same six sets of questions: organisation, identity, connectivity, security and governance, operations, and automation. Part 2 of Cloud Foundations, Explained End to End sets out each area, the decisions it contains, the order in which to make them, and what goes wrong when one is skipped.8 min read
- Part 3Platform landing zone versus application landing zoneA cloud landing zone has two halves with different owners: the platform landing zone that a central team runs for everyone, and the application landing zones in which workload teams build and operate. Part 3 of Cloud Foundations, Explained End to End draws the boundary, shows how to escalate across it, and names what central teams must not over-control.8 min read
- Part 4Landing zones are products, not one-off projectsA landing zone built as a project is finished on the day it starts to age. Part 4 of Cloud Foundations, Explained End to End explains how to run a cloud landing zone as a product: an owner and a roadmap, a service catalogue, guardrails released as versions, exceptions that expire, and four measures that show whether it is working.8 min read
- Part 5Azure Verified Modules: turning architecture standards into deployable building blocksA diagram, a standard, a module and a deployed environment are four different things, and most landing-zone trouble comes from treating them as one. Part 5 of Cloud Foundations, Explained End to End explains what Azure Verified Modules are, how to adopt them with provenance, pinned versions and tests, and why a module cannot make an architecture decision for you.9 min read
- Part 6A data landing zone is not just a data lakeA data lake gives you somewhere to put data. A data landing zone decides who owns it, how it is classified, who may read it, how long it is kept and what other teams can rely on. Part 6 of Cloud Foundations, Explained End to End sets out the governed foundation that analytics and AI need before they can trust anything.9 min read
- Part 7What is an AI landing zone?Cloud controls are necessary for AI and not sufficient. An AI landing zone adds the shared foundation that every AI workload otherwise rebuilds: approved models, a gateway, grounding through governed data, prompt and evaluation assets, safety, monitoring, cost and responsible-use controls. Part 7 of Cloud Foundations, Explained End to End defines it and draws the ownership boundary.9 min read
- Part 8Agentic landing zones: from governed intelligence to governed actionWhen an AI system can act rather than only recommend, the design problem changes from intelligence to authority. Part 8 of Cloud Foundations, Explained End to End sets out the agentic landing zone: agent identity, delegated and time-limited authority, a tool registry, policy before action, credential brokering, approval, durable state, observability and containment.10 min read
- Part 9One enterprise, four landing zonesCloud, data, AI and agentic landing zones are not four estates to build in parallel. They are four layers on one foundation, each assuming the one below. Part 9 of Cloud Foundations, Explained End to End compares them, separates shared from layer-specific controls, sets the order in which they must exist and follows one fraud workload through all four.9 min read
- Part 10A 12-month landing-zone roadmap for a mid-sized organisationPart 10 of Cloud Foundations, Explained End to End turns the series into a year of work: discovery, a minimum viable platform foundation, a first application landing zone, data and AI extensions for the workloads that need them, and a recommend-only agent pilot. Durations are illustrative estimates, and each phase starts only when the previous gate has evidence.9 min read
Working through any of this in your own organisation?
These articles come out of delivery work rather than theory. If the problems in this series look familiar, a short scoping conversation is usually the quickest way to work out what is worth doing first.
Talk to CloudNala