Cloud governance and landing zones

Before a single workload arrives, somebody has to decide how the estate will be divided, who may act where, and what the platform will refuse to allow. That is cloud governance. A landing zone is its built form: a prepared set of accounts or subscriptions with identity integration, network foundations, central logging and guard rails, ready for teams to deploy into without renegotiating the basics each time. The work sits between architecture and administration, and when it is done well almost nobody notices it.

The building blocks, named once for each platform

• Containers for resources. AWS separates workloads into accounts grouped under an organisation; Azure uses resource groups inside subscriptions, gathered under management groups; Google Cloud has a resource hierarchy of its own. Each level is a boundary for billing, permissions and blast radius.
• Identity and roles. Identity and access management settles who may create, change or delete what, and at which level of the hierarchy a permission applies.
• Policy. Rules that refuse or flag risky settings, such as Azure Policy or AWS service control policies, so that mistakes are blocked instead of discovered.
• Tags. Labels for owner, cost centre and environment, the only practical way to attribute a shared bill after the fact.
• Budgets and cost views. Alerts before spending surprises anyone, a subject our cost and FinOps topic develops.
• Locks. Protection that stops a critical resource being deleted or altered by accident.

Much of this is least privilege applied to an entire estate: instead of trusting every team to configure safely, the platform hands out narrow roles and blocks the settings nobody should use. The resources being organised are mostly IaaS building blocks, machines, networks and disks, with managed services layered on top.

How the blueprints read it

AZ-900 weights Azure management and governance at 30 to 35 per cent of its skills measured, with objectives on the hierarchy of resource groups, subscriptions and management groups, and on tags, Azure Policy, resource locks and cost management. AZ-104 opens its administrator syllabus with managing identities and governance. On AWS, the associate architect exam asks for a security strategy across several accounts, and at professional level SAP-C02 starts with designing for organisational complexity. Google's Professional Cloud Architect expects the same fluency with its resource hierarchy and organisation policies. The AWS Well-Architected Framework has no governance pillar as such, yet three of its six pillars presuppose one: security with its management of user permissions, cost optimisation with its control over where money goes, and operational excellence with its agreed standards for daily running.