Every organisation that moves onto AWS in earnest hits the same wall: the practices that worked for twelve accounts quietly stop working at two hundred. This module explains what actually breaks, why the instinctive fixes make it worse, and the three-part frame the rest of the course builds on.
The awkward truth about enterprise cloud adoption is that it is never one project. AnyCompany is simultaneously building brand-new cloud-native services, lifting existing on-premises systems across, and reworking older applications into something more modern. Each of those streams has a different pace, a different risk profile and a different set of people driving it — and all three land in the same AWS estate.
New services designed for AWS from day one. Fast-moving teams, short release cycles, and an appetite for managed services that did not exist in the data centre.
The long tail. Hundreds or thousands of applications, most of them older than the team maintaining them, each carrying its own licensing, support and deployment quirks.
You cannot re-architect everything, so you sequence it. Some workloads become containers, some become functions, some become somebody else's SaaS, and some stay exactly as they are.
These are widely-cited figures from published industry research on cloud and DevOps adoption. Treat them as a sense of magnitude rather than a promise — the useful signal is the spread. The gap between the bottom and the top of each range is mostly a governance and operating-model gap, not a technology gap.
Break a monolith into forty microservices and you have not created forty times the work — you have created forty times the objects to be governed. Forty sets of IAM roles. Forty deployment pipelines. Forty places a security group could be opened too wide. Forty line items on a bill that somebody has to explain.
Add the hybrid edge and it compounds again. A migrated workload that still needs to reach an on-premises database has a network path, a set of credentials and a data-residency question attached to it. Multiply by a portfolio in the hundreds and manual review stops being merely slow. It becomes a fiction: the review still happens, but it no longer meaningfully covers the estate.
That is the setup for the rest of the module. Not "cloud is complicated", but something more specific — the growth in things to govern outpaces the growth in people available to govern them. Any answer that scales has to be an answer that runs without a human in the path.
Ask a platform team what they are optimising for and you will usually get an honest admission that they are refereeing a fight. The security and finance side of the house wants consistency, evidence and a way to say no. The engineering side wants to ship this afternoon. Framed that way, every governance decision looks like a tax on delivery, and every delivery decision looks like a risk somebody will have to answer for later.
A defensible security posture across every account, not just the ones that were reviewed.
Evidence an auditor will accept — who had access, what changed, when, and under whose authority.
Costs that map to budget holders rather than arriving as one unexplained invoice.
Consistency, so that a control means the same thing in the tenth account as it did in the first.
Getting an idea in front of real users before somebody else does.
Experimenting cheaply, including experiments that turn out to be wrong.
Not waiting on a queue to get an environment, a role, or a database.
Responding to change in days, not in the next quarterly release train.
Before anyone reaches for a governance framework, there are three reflexive responses. Each one is a reasonable instinct. Each one fails for a structural reason rather than because it was executed badly.
The change-advisory board, the request ticket, the environment-build runbook. It already exists, everyone knows it, and it satisfies the auditor. So it gets pointed at the cloud.
Why it breaks: the process was calibrated for a world where provisioning took weeks anyway, so a three-day approval was invisible. In an environment where the resource itself takes ninety seconds, the approval is the lead time. Throughput is capped by the size of the review team, and teams quickly learn to batch changes into large, riskier releases to amortise the wait.
No defined process, so accounts appear when someone needs one — on a corporate card, under a personal email, for a proof of concept that then goes to production.
Why it breaks: without a standard creation path there is no baseline, so every account differs. You end up unable to answer basic questions — who owns this, what is running in it, is logging even switched on, is anything here in scope for our compliance regime. The gap is not only security. It is financial too: unattributed spend cannot be forecast, challenged or reduced.
An abstraction layer in front of AWS that promises one console, one policy language and one bill across providers.
Why it breaks: you have added a translation layer between your intent and the platform that enforces it. New AWS capabilities arrive only when the broker supports them, native controls and broker controls can disagree about what is actually enforced, and troubleshooting now spans two systems with two support models. The broker becomes another thing to govern rather than the thing that does the governing.
This is the framework the rest of the course hangs off. Governance at scale is not a service you switch on — it is three concerns handled together, because handling any one of them alone leaves an obvious hole. Get accounts right but ignore cost and you have a well-organised estate nobody can afford. Automate security but leave account creation informal and your automation only covers the accounts it knows about.
Standardise how accounts come into existence, who can get into them, and what baseline they carry from birth. Centralise, standardise, automate — in that order.
Express your rules as things the platform evaluates rather than things a person checks. Assessment, access grants and enforcement all become code.
Treat spend as a governed resource with the same rigour as permissions. Allocate it, watch it in real time, and let the platform act when a limit is approached.
An AWS account is the strongest isolation boundary the platform gives you. That makes it the natural unit of governance — and it means the way accounts are created determines almost everything downstream. Three mechanisms carry this focal point.
Agility, compliance and security are not in competition, but they are all defeated by the same thing: a step that requires a person. This focal point is about removing people from the enforcement path while keeping them firmly in the decision path.
Grant access by role, not by individual. Someone joining a team inherits what that team can do; a new service added at the OU level becomes reachable for everyone below it without a per-account change. Access becomes a property of the org structure rather than a stack of tickets.
Assessments run continuously against templates encoding your requirements, so a new project is compliant on the day it launches rather than on the day it gets reviewed. It also shortens the response side — when a violation appears, the reaction can be automatic, up to and including withdrawing access.
Constrain which Regions, which services and which resource configurations are permitted — and attach that constraint at whichever level of the hierarchy matches the obligation. The request that would create a non-conforming resource simply does not succeed.
Take a concrete case. A developer in a team subject to payment-card obligations tries to create an S3 bucket without the encryption and access settings the standard requires. There is no queue and no reviewer. The API call is evaluated against the policy attached above that team in the hierarchy and it fails immediately, with an error the developer can read.
Two things are worth noticing. First, the feedback arrives in seconds rather than days, which is why this is better for the developer than a review board, not merely cheaper for the platform team. Second, the rule was never written for that developer — it was attached once, at a level, and every account under it inherited it. Which is exactly the mechanism the next tab lets you drive.
The third focal point is the one engineers most often skip and finance most often raises first. It gets a tab of its own — see Budget as a control — because the interesting part is not reporting on spend, it is treating a budget limit as an enforceable control in the same family as an IAM policy.
| Focal point | The question it answers | Where the course delivers it |
|---|---|---|
| Account management | How does an account come to exist, and what does it carry on day one? | M02 — Organizations, Control Tower, IAM Identity Center, Account Factory |
| Security & compliance automation | How do my rules get enforced and verified without anyone checking? | M03 for preventive controls, M04 for detective controls and remediation |
| Budget & cost management | Who is spending what, against whose budget, and what happens at the limit? | M03 — AWS Budgets and budget actions inside the Service Catalog workflow |
A control is a pre-packaged governance rule you select rather than author. The mechanic that makes controls scale is inheritance: you attach a control at one point in the hierarchy and everything beneath that point is covered, including things that do not exist yet. Choosing the attachment level is the governance decision — too high and you impose obligations on teams that do not carry them, too low and you have a rule you must remember to attach again next time.
The org chart below is AnyCompany. Pick a node, then attach a framework and watch the cascade. The counters tell you exactly how much of the estate you just brought into scope.
Attachment point: AnyCompany (organization root) — click any node to move it
Rules that apply to the whole organisation regardless of team — approved Regions, mandatory logging, no disabling of the audit trail — belong at the root. Attaching them once means new accounts arrive already covered.
A framework that only some workloads are subject to should sit at the OU that contains exactly those workloads. Push it higher and you make unrelated teams carry restrictions they gain nothing from.
A nested OU accumulates everything attached above it plus whatever is attached to it directly. An account three levels down can be simultaneously in scope for a root-level rule and a branch-specific one.
Most organisations treat cost as something you find out about. The invoice arrives, someone builds a dashboard, a meeting happens, and in the best case a team is asked to look into it next sprint. That is reporting. Governance at scale asks a harder question: can a budget limit behave like a policy — something the platform knows about and acts on while the spend is happening?
A funding source gets subdivided down the organisation so each department, team and project holds a share it can be held to. Dashboards then give the people who own those shares a live view rather than a monthly retrospective. The point of planning is not accuracy — it is that every dollar has a named owner before it is spent.
Each layer of the hierarchy carries its own limit, monitored continuously. As actual or forecast spend approaches that limit the platform notifies the people who can do something about it, and beyond a chosen threshold it can act on its own. This is what makes a budget a control rather than a number.
The useful design is graduated. Nothing should go from "fine" to "everything stopped" in one step, and nothing should stay at "send another email" forever. A workable ladder looks roughly like this.
A threshold is crossed on actual or forecast spend and the owner hears about it while there is still room to react. No technical change, no disruption.
Provisioning stays open, but only for resources under a defined cost. A team can keep working; it just cannot reach for the largest instance family while it is running hot.
New resource creation in the affected scope is throttled or stopped outright. Existing workloads are untouched, so nothing in production degrades — the growth is what pauses.
The last rung. Configuration and data are archived first so the environment can be rebuilt, then resources are stopped, terminated or removed. Reserve this for non-production scopes where the cost of being wrong is a rebuild, not an outage.
Because it uses the same mechanism. A budget attaches to a scope in the hierarchy, and the scope determines both who is accountable and what the automated action can reach. A limit set on the Developers OU covers every project underneath it, including projects created next month. A limit set on one nested project OU covers only that project, which is what you want when one team's experiment should not be able to consume a department's allocation.
The practical consequence is that your OU design is simultaneously your security boundary and your cost boundary. Those two do not automatically want the same shape — a security regime might group by data sensitivity while finance groups by cost centre — and reconciling them is one of the genuinely hard design conversations in a landing zone. It is worth having deliberately rather than discovering it after two hundred accounts exist.
The concrete implementation — AWS Budgets, budget actions, and the way a budget constraint gets attached to a Service Catalog product so a builder sees the limit at the moment of provisioning — is covered in M03: Preventive Controls.
| Scope | Sensible enforcement ceiling | Reasoning |
|---|---|---|
| Sandbox / experimentation OU | Reclaim — stop and deprovision | Nothing here is load-bearing. Aggressive reclamation is what keeps a sandbox from quietly becoming the largest line on the bill. |
| Development / test OU | Throttle new provisioning | Teams need what exists to stay up, but pausing growth is a reasonable consequence of running past a limit. |
| Production workload OU | Constrain resource types, inform loudly | Automated destruction here trades a cost problem for an availability incident. Restrict what can be added, never what is running. |
| Shared services / audit accounts | Inform only | These accounts hold logging and security tooling for everyone else. Throttling them degrades the visibility you need most when something is going wrong. |
This module is deliberately conceptual — there is no lab attached to it. Its job is to give you the vocabulary and the frame that make the next four modules cohere instead of arriving as a list of services. Judge it against these.
M01 established that the answer has to be automated. M02 is where that stops being an assertion — it is the largest module in the course and the structural heart of it.
Multi-account design patterns, the landing zone reference architecture, AWS Control Tower setup and prelaunch checks, centralised workforce identity through IAM Identity Center, Account Factory, and the first proper look at control types. Everything M01 argued for, built.
The natural sequel to the inheritance explorer on this page. Assemble a landing zone one decision at a time — add OUs, place the shared accounts, choose where a control attaches — and see what changes when you move a control one level down.
The concepts in this module have not moved. The mechanisms have — substantially. AWS Organizations grew two entirely new policy types alongside SCPs, the SCP language itself got a lot more expressive, and the quotas that used to shape how people designed OU hierarchies went up. If you are designing a governance model today, design it against this list rather than against the slides.
The old SCP grammar was a deliberately reduced subset — no conditions, no individual resource ARNs, no NotAction with Allow. That is gone. SCPs now accept conditions, specific resource ARNs, NotAction inside Allow statements, and wildcards in Action and NotResource.
Why it matters here A great deal of the “you cannot express that as an SCP, so put it in an IAM policy instead” advice in older material is now wrong. You can write “deny this API unless the request carries this tag” at the OU level. Existing SCPs keep working unchanged — the change is additive.
The ceiling used to be five SCPs attached to any single root, OU or account, each capped at 5,120 characters. Both numbers doubled.
Why it matters here The old limit is the reason so many organisations ended up with one enormous, unreadable “kitchen sink” SCP per OU. With ten slots you can split policies by intent — one for region pinning, one for root-user protection, one for logging protection — and actually understand what is attached where when you open the inheritance explorer on the previous tab.
When the caller and the resource are in the same account and organisation, the error now includes the ARN of the specific policy responsible — and it covers SCPs and RCPs, not just identity-based policies, session policies and permission boundaries.
Why it matters here This is the single biggest quality-of-life change for anyone operating an inheritance hierarchy. The classic failure mode of nested OUs is a denial arriving with no indication of which of the six attached policies caused it. Now the message tells you, and you can go straight to the attachment point.
This is the structural change. When this course was written, an organisation policy meant an SCP: a constraint on what your principals could do. There are now two more families, and they answer questions SCPs never could.
An SCP constrains your principals. An RCP constrains your resources — it caps what any principal, including one from outside your organisation entirely, can do to a resource in a member account. This is the primitive that makes a data perimeter expressible in one place instead of in every bucket policy.
Neither an allow nor a deny — a desired configuration. You state the account-level setting you want, and AWS keeps it that way for every account in scope, including accounts created after you wrote the policy. There is no API call to intercept and no drift to detect, because the setting itself is centrally owned.
The per-organisation RCP limit went from 1,000 to 2,000 in July 2026. Service coverage widened over the same period — Amazon Cognito and Amazon CloudWatch Logs in January 2026, Amazon DynamoDB in February 2026, on top of the services supported at launch.
Why it matters here Coverage is the thing to check before you promise a data perimeter. RCPs only constrain the services that support them, so the supported-services list in the documentation is a live design input, not background reading.
Block Public Access can now be set as a policy attached at the organisation root, at an OU, or at named accounts, propagating to everything in scope. Attachment and enforcement are auditable through CloudTrail.
Why it matters here “No public buckets” used to be a two-part answer: an SCP denying the API that turns BPA off, plus a Config rule to catch the buckets that slipped through before you attached it. Now it is one setting you own centrally. It is the clearest illustration in the whole course of a preventive control that needs neither an API interception nor a detective backstop.
The EC2 Allowed AMIs setting gained four new criteria — Marketplace product codes, deprecation time, creation date and AMI name patterns — so you can express “nothing older than this” rather than just “from these accounts”. Separately, VPC Encryption Controls became centrally manageable, replacing a per-VPC enable-and-configure-exclusions chore with one policy plus an organisation-wide status view.
Why it matters here Both are examples of the same pattern: a setting that used to be per-account or per-resource becoming an organisation-level property. When you audit your own estate, the question “is there a declarative policy for this now?” is worth asking before you write an SCP.
Create an organisation through the console today and AWS attaches a lightweight baseline for you, including SCPs that stop member accounts leaving or closing themselves. The defaults can be changed or removed at any time.
Why it matters here “Deny organizations:LeaveOrganization” is the canonical first SCP in every guardrail tutorial, this course included. For new organisations it is now already there — so check what is attached before you write it, and spend the effort on the guardrails that are actually missing.
The previous tab makes the argument that a budget is a governance control rather than a finance report. Two of the three things that made that awkward in practice have been addressed.
Two separate changes. The detection algorithm moved to rolling 24-hour windows, comparing spend against the equivalent period on previous days rather than an incomplete calendar day against historical daily totals — which removes a structural lag and a class of false positives. And a single AWS managed monitor can now track every linked account, cost allocation tag or cost category separately, including values that appear after you created it.
Why it matters here The old model asked you to create and maintain a monitor per team. That does not survive an organisation that vends accounts through Account Factory, because monitor creation was never part of the vending pipeline. One managed monitor that follows the tag is the version that actually scales.
An Investigate with Amazon Q action on any detected anomaly correlates cost data with CloudTrail events and resource activity, then tells you whether the change was usage-driven or rate-driven, which services, accounts and Regions contributed, and — for usage-driven changes — which API calls and IAM principals were behind it.
Why it matters here This closes the loop the cost tab leaves open. An alert that says “spend is up 40%” is a detection; an answer that says “this principal launched these instances in this Region” is something you can act on. Note the CloudWatch Logs Insights charge if you investigate across accounts using an organisation trail.
Net unblended and net amortised cost joined the available metrics, alongside additional filtering, so a budget can be scoped to what a team actually pays after discounts rather than to list price.
Why it matters here A budget that tracks pre-discount cost fires at the wrong number, and a control that cries wolf gets ignored or deleted. If you are using budget actions as a real guardrail, the metric choice is part of the control design.
Each module page carries its own What’s new tab covering the services that module owns. Control Tower and the landing zone are in M02, Service Catalog and CloudFormation Hooks in M03, and the detective stack — Config, Systems Manager, GuardDuty, Security Hub — in M04.