Six weeks into its new cloud landing zone, Blyde Financial Services, the fictional South African financial-services group in this series, had a predictable argument. The customer-service team wanted to deploy a managed search service that was not on the approved list. The platform team said no. The customer-service team escalated to its executive, who escalated to the CIO, who asked a reasonable question: whose decision was this supposed to be?
Nobody could answer, because the landing zone had been designed as a technical structure without an ownership boundary. Every cloud landing zone has two halves, and the argument was about where one stops and the other starts.
This article draws that line. It uses the series vocabulary: the platform landing zone is the shared foundation, and an application landing zone is the governed space in which one workload team builds and runs.
Two halves with different owners
Microsoft's Cloud Adoption Framework describes an Azure landing zone as two components: a platform landing zone, "the centralized foundation that establishes governance, security, and shared resources for all your Azure workloads", and workload landing zones, "the environments where workload teams deploy and operate workload resources within the guardrails of the platform landing zone" (Microsoft Learn, checked on 7 November 2026). Microsoft's current pages say "workload landing zone" where older guidance and many accelerators say "application landing zone". This series uses "application landing zone" throughout. They mean the same thing.
AWS draws the same line differently. In its standard set-up, an AWS Control Tower landing zone sets aside shared accounts for log archive and audit next to the management account, and workload accounts are created through Account Factory, which applies controls as part of provisioning (AWS, checked on 7 November 2026). Landing zone version 4.0, released in November 2025, makes several of these service integrations optional, so check which ones your own landing zone has enabled. Google Cloud's landing-zone guidance expresses it through the resource hierarchy of organisation, folders and projects, with identity, network and security controls decided for the whole hierarchy before workload projects are created (Google Cloud).
At Blyde, the platform landing zone contains five things: the identity structure and role definitions, the connectivity hub with its firewall and private DNS, the policy set, security monitoring, and the subscription vending process. Beneath it sit four application landing zones, one each for customer service, document processing, fraud operations and employee knowledge, each with production, test and development subscriptions.
What belongs in the platform landing zone
The platform landing zone exists to provide things that are better done once than many times. Microsoft's guidance puts the test well: "Only centralize capabilities that provide clear governance, operational, or economic benefits across multiple workloads." It also says most organisations should have only one platform landing zone per Microsoft Entra tenant.
Blyde applied a three-part test to every proposed shared capability:
- Is it a control that must be consistent? Identity, policy, security monitoring and log retention fail if each team does them differently. They are central.
- Is it a scarce or shared resource? The connection to the data centre, the internet egress point and the private DNS zones exist once. They are central.
- Is it cheaper or safer to run once? A shared firewall is usually both. A shared database server for four unrelated workloads is usually neither, so it stays out of the platform.
Anything that fails all three belongs to a workload. That rule removed about a third of the items from the platform team's first backlog, including a shared container cluster that nobody had asked for.
What belongs in an application landing zone
An application landing zone contains everything a workload team owns and operates, across all its environments: compute, data stores, application configuration, workload networking within its spoke, its alerts and runbooks, and its run cost.
Microsoft's subscription vending guidance describes the hand-off plainly. The platform team creates and configures the subscription, places it in the right part of the hierarchy and hands it to the workload team; the workload team should then "have autonomy to create the resources they need for their workload and manage operations", while the platform team "remains responsible for subscription governance". It also recommends giving workload teams the right to create their own subnets, while the platform team creates the virtual networks that peer to the hub.
That is the boundary in a sentence: the platform owns the shape of the plot and the rules of the estate; the workload team owns what is built on the plot.
Draw the boundary as decisions, not resources
A diagram of boxes shows which resources sit where. It does not settle arguments like the one about the search service, because that argument was about a decision, not a resource. Blyde's fix was to write the boundary down as a decision matrix, with a named escalation route for each row.
Three rows did most of the work:
- Service choice. The platform team sets the allowed list and the conditions attached to each service (private endpoints, encryption, diagnostic settings). The workload team chooses freely within it. Adding a service to the list is a platform decision with a published turnaround, not a favour.
- Policy exceptions. The workload team may ask for an exception; the platform team assesses it; risk approves it, with an owner and an expiry date.
- Run cost. The platform provides tags and budget alerts. The workload team owns the spend. Finance becomes involved when a budget is exceeded, not before.
The search-service argument now has an answer. The customer-service team requests the service. The platform team assesses whether it can be offered with the standard controls, publishes the conditions, and adds it to the list or explains why not. If the team disagrees, the architecture forum decides, within a stated time. Nobody escalates to the CIO.
What central teams must not over-control
The opposite failure is more common in regulated organisations, and it is quieter. A platform team that is held responsible for every incident responds by controlling everything: every resource deployed by ticket, every change reviewed centrally, every new service a six-week assessment. Workload teams respond by working around it, and shadow environments appear. The landing zone becomes the thing teams avoid.
Central teams should own the guardrails, not the steering wheel. In particular, they should not:
- Deploy workload resources on the team's behalf. If a workload team cannot deploy into its own application landing zone through its own pipeline, it does not have one.
- Review every workload change. Policy catches the rules automatically. Human review belongs to changes in the platform itself.
- Own workload alerts and on-call. The platform team runs the platform. The fraud team knows what a failed fraud-scoring job means; the platform team does not.
- Standardise what does not need to be standard. Naming, tags and log destinations, yes. Programming languages and application frameworks, no, unless there is a specific operational reason.
- Treat every new service as a security exception. A published, time-bound process for adding services to the allowed list is a guardrail. An open-ended review is a gate.
The case for platform engineering makes the broader argument that a platform exists to remove friction. A landing zone that adds friction to every change has misunderstood its job.
Escalation is part of the design
Even a good boundary produces disagreements, and how they are resolved determines whether teams trust the platform. Blyde's escalation rules are short:
- Every row in the matrix has a named escalation point, not "the platform team".
- Every escalation has a time limit, after which it goes to the architecture forum automatically.
- Exceptions are recorded, owned and dated. An exception without an expiry date is treated as a change request to the platform, not as an exception.
- Repeated exceptions are a signal. If three teams need the same exception, the rule is probably wrong, and the platform backlog gets an item to change it.
This turns the boundary from a wall into an interface. Part 4 shows how the platform team runs that interface as a product.
A test for your own boundary
| Question | Healthy answer | Warning sign |
|---|---|---|
| Can a workload team deploy to production without a platform ticket? | Yes, through its own pipeline, within policy | Every deployment needs a platform engineer |
| Who decides which cloud services a team may use? | Platform publishes an allowed list and a process to extend it | Decided case by case, or not at all |
| Who is paged when a workload fails? | The workload team | The platform team, for everything |
| Who owns the workload's cloud spend? | The workload team, with platform-provided budgets and tags | Nobody, or a central cost centre |
| How long does adding a new service to the allowed list take? | A published turnaround | Unknown, or indefinite |
| What happens to an exception after six months? | It has expired, been renewed with a reason, or become a rule | Nobody remembers it exists |
| How many platform landing zones are there? | One per identity tenant, in most organisations | One per project |
Key points
- A cloud landing zone has two halves: the platform landing zone, run centrally for everyone, and application landing zones, owned by workload teams. Microsoft's current documentation calls the latter workload landing zones.
- Centralise a capability only when it must be consistent, is genuinely shared, or is cheaper or safer to run once.
- The platform owns the shape of the plot and the rules of the estate. The workload team owns what it builds and runs on the plot, including alerts, on-call and run cost.
- Write the boundary down as decisions with named escalation points, not only as a diagram of resources.
- Central teams should own guardrails, not every change. Over-control drives teams to build around the landing zone.
This is part 3 of Cloud Foundations, Explained End to End. Previous: The six design areas every landing zone must resolve. Next: Landing zones are products, not one-off projects.
Related reading: Enterprise landing-zone networking for the network side of the same boundary, and Sandbox is a risk label, not a place to hide permanent systems for the sandbox branch most hierarchies include.
How CloudNala can help
CloudNala helps platform and workload teams agree the boundary between them before it becomes a dispute. We map which capabilities in your estate are central and which should not be, write the decision matrix with escalation points and time limits, and identify where the platform is over-controlling in ways that are pushing teams to build outside it.
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