Cloud Governance

Definition

Governance is the set of structures that let many teams move quickly in a shared estate without creating security, cost or compliance problems that someone else must clean up. It is mostly decided by the account and subscription topology, and it is very expensive to change later.

The components that matter

• Account structure. Separate accounts or subscriptions per environment and per major workload. This is the strongest available blast radius boundary — for security, for cost attribution, and for limits, which are usually per account.
• Identity. Central identity federation with short-lived credentials and no long-lived keys. Access granted by role and by group, reviewed periodically.
• Guardrails as policy, not documentation. Preventive controls that make the wrong thing impossible — no public storage, encryption required, approved regions only — plus detective controls that alert on what slipped through.
• Cost allocation from day one. Mandatory tags enforced at creation. Retrofitting attribution onto an estate with thousands of untagged resources is a project nobody funds.
• A paved road. Pre-approved modules and templates that are the easy path, so compliance is the default behaviour rather than an obstacle.

Industry example

Enterprise landing-zone guidance — the Microsoft framing being the most widely used — encodes exactly these decisions, and is simultaneously the most useful and the most over-adopted artefact in cloud architecture.

Useful, because account topology, identity boundaries and policy enforcement are genuinely hard to retrofit, and inheriting a considered structure is worth a great deal. Over-adopted, because the reference is drawn for a large regulated enterprise with many workloads, and a team running two services ends up operating a hub-and-spoke network with a firewall appliance that protects nothing.

The discipline: treat it as a checklist of considerations, decide each element explicitly, and record why when you exclude one. That record is what makes the omission defensible in a later audit — which is usually the actual reason teams over-adopt.

The governance that is cheap at any size

Identity federation. Separate environments. Mandatory tags. Encryption. Centralised logging with retention. Infrastructure as code. All are inexpensive now and painful to retrofit, and none of them requires enterprise scale to justify.

Failure scenarios

• One account for everything, so blast radius is total, limits are shared, and cost attribution is impossible.
• Long-lived access keys in CI systems and developer machines.
• Governance as a ticket queue, which teams route around by building shadow infrastructure.
• Policies that only detect, so violations are found weeks later in a report.
• No ownership metadata, so nobody can identify who owns an expensive idle resource.

Interview question

"You inherit a cloud estate with one account, no tags and shared credentials. What are the first three things you change and in what order?"