Cloud Account and Governance Structure
The boundaries that make governance possible
Accounts, organizations, folders and projects create the containment boundaries that make IAM policies, budgets and audits comprehensible. Structure the boundaries before you need them.
What you will learn
- Explain why isolation per team/environment beats one giant account
- Describe the account/folder hierarchy of AWS, management groups of Azure and projects of GCP
- Apply guardrails (SCPs, org policies, budgets) at hierarchy nodes
Before you build anything, decide the boundaries: AWS accounts, Azure subscriptions under management groups, GCP projects under folders. Every policy, budget and audit gets attached to a boundary — getting it wrong means retrofitting governance onto grown infrastructure.
What is this?
An account (or project/subscription) is an isolation + billing container. AWS gives you accounts organized under Organizations with service control policies (SCPs) at folder nodes; Azure has subscriptions under management groups with policy; GCP has projects under folders within an organization, with org policies. The hierarchy lets you attach guardrails, budgets and identity once at a high node and have them cascade to everything below.
Why do you need it?
- Security: a breach in one team's sandbox shouldn't reach production — account-level isolation contains blast radius.
- Billing: per-account cost attribution becomes automatic triage, not an afternoon of forensics.
- Guardrails: deny public storage or lock regions at the folder/OU level before anyone can mis-configure.
- Audits run against well-formed boundaries; flat mega-accounts are unauditable by humans.
Mental model
Floors and rooms of an office building with department keycards
An account/folder hierarchy
Each department gets its rooms (accounts/projects), the building's floors (folders/OUs) carry shared rules, and the security desk (governance root) sets building-wide policies once.
How it works
- An account/project container holds resources; its identity system authenticates principals with policies scoped to it.
- Hierarchy nodes (organizations, OUs/folders, management groups) let your SCPs/policies/budgets inherit downward.
- Service control policies (AWS SCPs), Azure Policy, and GCP org policies constrain what child containers may do.
- Identity federates to the hierarchy root; each container then scopes role grants to its own resources.
- Billing consolidates per container, making chargeback a structural property, not a guess.
A canonical multi-account / multi-project hierarchy.
In production
- An AWS landing zone lays out a security OU, workload OUs per team and a shared-services OU with SCPs denying production-only regions to dev.
- A GCP org puts each team in a folder, applies org policies preventing external egress, and gives the finance folder a hard budget alarm.
- Azure management groups carry policy assignments so every new subscription inherits encryption, tagging and NSG defaults.
Best practices
- Create dev/staging/prod isolation first; adding boundaries later is retrofitting governance.
- Place guardrails high (folder/OU) and grants low (specific project/account) — inherit restrictions, escalate permissions locally.
- Give each account/project clear purpose tags and an owner whose name is in the metadata.
- Treat the root/mgmt account as break-glass only: no daily workloads, MFA-only, monitored access.
Common mistakes
- Running everything in one account 'to keep it simple' until a production leak finds the dev sandbox.
- Yol-ing a root account with permanent keys for daily work.
- Applying SCPs after software is live and watching everything break at once.
- Naming accounts by project instead of by environment+team, then discovering you can't write a clean policy.
Common issues
Team can create resources but a folder-wide SCP later blocks themGuardrails were added after the resources were created
Introduce guardrails early and in stages: audit in solve-report mode before switching to deny.
New dev VMs land in the production accountNo account boundary or 'just use my account' habit
Give every team its own account/project and remove prod-write access from dev credentials.
Billing can't attribute cost to a teamResources untagged and accounts/prejects not matched to teams
Enforce tagging at creation, align accounts to teams, and add per-account budgets.
Debugging tips
- When a resource ends up somewhere unexpected, check the org/folder inheritance before the specific policy.
- 'Not authorized' despite a grant often means an SCP/org policy is denying it higher up the tree.
- Audit the hierarchy quarterly: list accounts/projects, note orphaned ones, drop empty containers.
- When cross-account access breaks, verify the trust relationship in BOTH accounts (grantor and grantee).
Interview checkpoint
Hands-on lab
- Design an OU/folder hierarchy for a staged company
- Attach guardrails and budgets to hierarchy nodes
- Validate placement rules with a small script
Sketch and Validate a Cloud Account Structure
25 min · intermediate
Quick quiz
Where is the best place to attach a 'deny public storage' guardrail?
The root/management account should host your daily production workloads.