Blyde Financial Services, the fictional South African financial-services group in this series, ran its cloud landing zone as a project. There was a budget, a partner, a plan, a go-live date and a closure report that said the platform was delivered. The project team moved on to the next initiative.
Within nine months the estate looked familiar. Two new policies had been added by hand in the portal and were not in the code. The vending pipeline still issued subscriptions with a log retention setting that risk had changed. Three teams were waiting for a managed service to be added to the allowed list, and nobody knew whose job that was. A vendor reference implementation had moved on two releases. Nothing was broken. Everything was slowly becoming untrue.
A landing zone is not finished when it is deployed, any more than a payments system is finished when it goes live. This article argues that a cloud landing zone should be run as a product, and shows what that means in practice.
Why the project model fails
A project has a fixed scope, a delivery date and a team that leaves. That suits building a bridge. It does not suit something that many teams use every day and that must keep up with changing threats, regulations, services and vendor releases.
Three things change after go-live whether or not anyone is responsible for them:
- The rules. New threats, audit findings and regulatory expectations produce new guardrails, and old ones need to be relaxed or retired.
- The demand. Workload teams ask for services, patterns and environment types that were not in the original scope.
- The upstream. Cloud providers release new services and retire old ones, and reference implementations change. AWS, for example, publishes numbered Control Tower landing zone versions and states that keeping the landing zone updated is the responsibility of the central cloud administrators (AWS, checked on 7 November 2026). Microsoft maintains its Azure landing zone accelerators as code that is updated over time (Microsoft Learn).
If no one owns those changes, they happen anyway, by hand, without tests, and the estate drifts away from its own design.
What makes it a product
A product has customers, an owner, a roadmap and a support model. For a landing zone the customers are the workload teams, and the product is the experience of getting and running a governed environment.
Blyde's product model has six parts:
- A product owner. One named person who owns the landing zone's roadmap and backlog and decides priorities between competing requests. In Blyde's case this is a senior platform engineer with a part-time role, not a new executive.
- Intake. A single front door for requests: new application landing zones, new services, new patterns and exceptions. Microsoft's subscription vending guidance describes this as "an official front door for workload teams to request subscriptions" (Microsoft Learn).
- A service catalogue. The things a team can ask for, written for the team: types of application landing zone (internal, internet-facing, sandbox), approved services with their standard conditions, and patterns for common workloads. Microsoft calls the subscription types a platform team vends "product lines", which is a telling choice of words.
- Releases. Changes to the platform, including guardrails, ship as versions with release notes, not as silent edits.
- Support and adoption. A help channel with a stated response time, office hours, and documentation that a new team can follow without a meeting.
- Measures and a roadmap. A small set of measures, reviewed monthly, that decides what goes into the backlog next.
This is the same discipline that applies to an internal developer platform. The case for platform engineering argues for it, and How to graduate an internal developer platform sets out the evidence for promoting one. The landing zone is the governed foundation underneath such a platform, and it needs the same product discipline even if the organisation never builds a developer portal.
Guardrails are versioned like software
The most important product habit is to treat a guardrail change as a release.
When Blyde's security architect decided that storage accounts should no longer allow public network access, the project-era approach would have been to switch the policy to deny on a Friday afternoon. Instead, the rule went through the same path as any other platform change.
The rule was written in the policy repository as a candidate for version 2.4. It was assigned in audit mode for two weeks, which reported every non-compliant resource without blocking anything; Azure Policy's audit effect and AWS Control Tower's detective controls both support this way of working. Each workload team received a list of what would fail and why. Two teams fixed their resources in a day. One, document processing, had a supplier integration that depended on a public endpoint and could not change it before the release date. It received an exception with an owner, a compensating control and an expiry date. Version 2.4 then enforced the rule, and the release notes said so.
Versioning guardrails gives three things that silent changes do not:
- Predictability. Teams know what will change, and when.
- Reversibility. If a release breaks something unexpected, the platform team can roll back to the previous version from code.
- Evidence. An auditor who asks when a control came into force gets a release record, not a recollection.
Exceptions are part of the product
Every estate needs exceptions. The question is whether they are managed or merely granted.
An exception is a temporary, owned departure from a guardrail, with a reason, a compensating control and an expiry date. Blyde keeps them in an exception register that the policy engine reads, so an exception is applied as code and expires automatically. In Azure, a policy exemption can carry an expiry date and is categorised as either a waiver (non-compliance accepted for a time) or mitigated (the intent is met another way), and an expired exemption stops applying (Microsoft Learn, checked on 7 November 2026). At each expiry date there are three possible outcomes: the team has fixed the issue and the exception lapses; the reason still holds and the exception is renewed, with a new date and a fresh approval; or several teams have needed the same exception, and the rule itself is changed.
That third outcome matters more than it looks. Exceptions are the product's most honest feedback. A guardrail that half the teams need to be excused from is a design problem, not a compliance problem.
Paved roads, not only guardrails
Guardrails say what a team may not do. A product also needs to make the right thing the easy thing. At Blyde the paved roads are:
- Application landing zone types that arrive pre-configured for the common cases, so most teams never have to think about network inspection or log routing.
- Workload patterns for the four initiatives that drove the programme: an internal web application, an event-driven document pipeline, a batch scoring job and an internal search service. Each is a tested template that already complies with the policy set.
- Starter pipelines with the identity, approval and policy checks already wired in.
A team that follows the paved road gets compliance for free. A team that leaves it can, within the guardrails, but carries the extra work itself. That is a better incentive than a review board.
Four measures that show whether it works
A product needs measures that reflect its customers' experience, not only its own activity. Blyde reviews four each month:
| Measure | What it shows | Illustrative target at Blyde |
|---|---|---|
| Onboarding time | Days from a complete request to a team deploying its first workload into a new application landing zone | Under five working days |
| Policy compliance | Share of resources compliant with the current guardrail version, and number of open exceptions past expiry | Above 95 per cent, zero expired exceptions |
| Recovery readiness | Share of production workloads with a restore tested in the last quarter | All tier-one workloads |
| Support demand | Requests per team per month, by type, and how many were caused by missing documentation | Falling as patterns mature |
The targets are illustrative, not benchmarks. What matters is the direction and the conversation each one starts. If onboarding time rises, the vending process or the catalogue needs work. If support demand is dominated by one question, the documentation or the pattern is wrong. If compliance falls after a release, the audit period was too short.
Avoid measuring only what the platform team does, such as the number of policies deployed or tickets closed. Those numbers can rise while teams quietly route around the landing zone.
A product checklist
Before calling its landing zone a product, Blyde checked that it had:
- A named product owner with time allocated to the role.
- One intake route for all requests, with stated turnaround times.
- A published catalogue of landing zone types, approved services and patterns.
- Every platform change, including guardrails, in code and released as a version with notes.
- New guardrails run in audit mode before enforcement, with impact reports to teams.
- An exception register with owners, compensating controls and expiry dates, applied as code.
- A support channel and documentation a new team can follow alone.
- Four measures reviewed monthly and used to rank the backlog.
- A plan for taking on upstream releases of the reference implementation it started from.
Key points
- A landing zone built as a project starts to drift the day the project closes, because rules, demand and vendor releases keep changing.
- Run it as a product: an owner, an intake route, a service catalogue, versioned releases, support and a roadmap driven by measures.
- Treat every guardrail change as a release: propose it, audit before enforcing, report impact, then enforce, with notes.
- Exceptions should be owned, dated and applied as code. Repeated exceptions mean the rule needs to change.
- Measure the customer's experience: onboarding time, policy compliance, recovery readiness and support demand.
This is part 4 of Cloud Foundations, Explained End to End. Previous: Platform landing zone versus application landing zone. Next: Azure Verified Modules: turning architecture standards into deployable building blocks.
Related reading: What does production-ready actually mean? and Cloud cost governance: the framework every South African organisation needs.
How CloudNala can help
CloudNala helps organisations turn a landing zone that was delivered as a project into one that is run as a product. We assess drift between your platform's code and its live state, set up the release path for guardrails and the exception register, define the catalogue and paved roads your teams actually need, and agree the four measures your product owner will report on, so that the landing zone keeps getting better after the project team has gone.
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