Think about an apartment building. Every unit has its own front-door lock, so a burglary in 4B does not reach 7C. Every unit also has its own electricity meter, so 4B's habit of running space heaters does not show up on 7C's bill. Those two facts are independent design decisions in a real building — you could imagine a building with individual locks and one shared meter — but in the cloud the same wall does both jobs. When you draw a boundary around a set of resources, you have simultaneously drawn a security perimeter and a billing perimeter, whether you meant to or not.

That is why "how many accounts should we have?" is a real architecture question and not an administrative one. You are deciding where the walls go.

Every major cloud gives you the same four-layer tree, with different words. A root at the top representing the whole company. A grouping layer beneath it for organising by environment, business unit, or compliance regime. An isolation unit — the thing that is genuinely a hard boundary. And resources at the leaves.

Two rules make the tree a control surface rather than just a filing cabinet:

1. Policy inherits downward and intersects. A restriction placed at a level applies to everything beneath it, and cannot be relaxed by an administrator lower down. Permissions are the intersection of every level's allowance, never the union.
2. Cost aggregates upward. Charges occur at the leaves and sum into every ancestor, so each level is automatically a reportable, budgetable unit without you configuring anything.

The second rule is why splitting into more isolation units improves cost visibility for free — a separate project is a separate cost report line. The first rule is why splitting also improves security for free. That coupling is the single most useful thing in this session.

If splitting is free value, why not give every workload its own isolation unit? Because splitting has costs that are invisible on day one and painful on day four hundred:

The nuance worth internalising: depth is cheap, width is expensive. Adding a grouping level costs almost nothing and buys you a policy attach point. Adding isolation units costs plumbing forever. So the mature pattern is a shallow-but-deliberate grouping tree with a modest number of isolation units, not a deep tree or a wide one.

The counter-failure is real too. Microsoft's landing-zone guidance explicitly warns against duplicating your org chart into the hierarchy, because org charts reorganise every eighteen months and hierarchies do not. Group by what a policy would say about it — production versus sandbox, regulated versus not — because those categories are stable.

Three ways to stop someone building an unsafe balcony. You can lock the door to the balcony so it can never be used — nothing bad can happen, and also nothing good can happen out there. You can put a camera on it and review the footage — everything stays possible, and you find out afterwards. Or you can require plan review before construction — the design gets rejected at drawing stage, before any concrete is poured.

Those are preventive, detective, and proactive controls. The word "guardrail" gets used loosely for all three, which is why it is worth pinning the definitions down now.

Preventive guardrails work by capping, not granting. This is the part that trips people up coming from C2's IAM. A guardrail never gives anyone a permission — it only removes permissions from the set that identity policy might otherwise allow. The effective permission is the intersection.

Here is what a preventive rule actually looks like as an artifact. This one is the canonical cost guardrail: it blocks launching anything outside two approved regions, which stops both accidental-region sprawl and the classic crypto-mining-in-an-unwatched-region incident.

// preventive guardrail: deny outside approved regions
{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "RequestedRegion": ["us-east-1", "us-west-2"]
    }
  }
}

And here is how a request is evaluated as it descends the hierarchy. Step through it:

Airline baggage tags. The bag itself does not know where it is going or who owns it; the tag carries that information, and every downstream system — sorting, routing, claims — reads the tag rather than inspecting the bag. Attach the tag at check-in and everything works. Attach it later and the bag is already in the wrong pile.

Cloud tags are exactly this, with one cruel difference: tags are not retroactive on cost data. Tagging a resource today does not attribute yesterday's spend. The bag that travelled untagged stays untagged in the record forever.

A working taxonomy needs surprisingly few keys. Four is usually right, and every one of them answers a question someone will actually ask:

The enforcement chain is what turns a taxonomy into data. A definition alone gets you maybe 40% coverage. The chain looks like this:

Showback is an itemised receipt taped to the fridge in a shared house: here is what each of you used. Chargeback is actually taking the money out of each housemate's account. The information is identical; the consequences are not, and so the political temperature is not either.

Mechanically they are the same pipeline — tags and hierarchy produce attributed spend — and differ only in what happens at the end. Which is precisely why the technical work is identical and the organisational work is not.

The reason the distinction matters to an architect: chargeback demands accuracy that showback does not. Nobody disputes a receipt taped to a fridge. Everybody disputes a debit. The moment money moves, your shared-cost allocation method, your untaggable residual, and your tag coverage all become contested, and any weakness in the pipeline surfaces as an argument. So the sequencing rule is: get to high tag coverage and a defensible shared-cost method under showback first, and only then consider chargeback.

Chargeback creates real incentive — a team that pays for its own idle GPUs turns them off — but it also creates perverse ones. Teams start optimising for their line item rather than the whole: refusing to adopt a shared platform because the shared cost lands on them, or under-provisioning something the company needs. Showback creates awareness without those distortions, but awareness without consequence decays; the second monthly report gets read less than the first.

The pattern most organisations land on is showback everywhere, chargeback on the one or two line items large enough to change behaviour — which in a GenAI shop means accelerator hours and inference spend, and essentially nothing else.

Three ways to get to the gym. Pay at the door each visit — most expensive per visit, zero obligation, always available. Buy an annual membership — much cheaper per visit if you actually go, dead money if you stop. Or take whatever slot is left over at 5 a.m. when the gym is empty — nearly free, but they can turn you away at the door and you have to be able to leave immediately.

On-demand, committed, and spot. The whole pricing model is that trade: you are paid for reducing the provider's uncertainty. A commitment removes demand uncertainty; accepting interruption removes capacity-planning uncertainty. Both are worth money to them, so both are discounted for you.

Plotted, the curve looks like this. The vertical axis is effective price; the horizontal axis is how much certainty you have given up.

The curve is intuition. The decision is arithmetic, and it rests on one number: break-even utilisation.

The formula is embarrassingly simple. If a commitment costs you a fraction c of the on-demand price and you pay it whether or not you use it, then:

Three refinements that the simple formula hides, and that separate a good commitment decision from a bad one:

• Utilisation is measured against the commitment, not the machine. A spend-rate commitment of $10/hour is wasted if you only run $7/hour of eligible usage that hour — the other $3 evaporates. Unused commitment does not bank forward.
• Stranded commitment is the real failure. You commit to a GPU family, a better one launches nine months later, and you are now paying for hardware you do not want. This is why flexible commitments are worth their few points of discount for fast-moving workloads and rigid ones are for boring, stable ones.
• Ladder rather than lump. Buying your whole commitment on one day means it all expires on one day, at whatever prices exist then. Buying in monthly tranches gives you a rolling portfolio, continuous repricing, and the ability to shrink coverage gradually if demand falls.

A thermostat. It measures the temperature, compares it to a target, acts, and then measures again. What makes it a thermostat rather than a switch is the again. Cost management done once is a cleanup project; done as a loop it is a practice.

Its engine is a three-phase loop that a given workload cycles through continuously and independently of other workloads.

The framework describes maturity as crawl / walk / run, and the useful insight is that maturity is per-capability, not global. It is entirely normal — and correct — to be at "run" on commitment management because it is where your money is, and at "crawl" on sustainability reporting because nobody has asked. Trying to be uniformly mature is how FinOps programmes turn into overhead.

The second trade-off is where in the lifecycle you intervene. Acting after deployment (detect and clean up) is easy to implement and permanently reactive. Acting before deployment — "shift left", pricing an architecture at design review — is far more valuable and far harder, because it requires cost estimates for things that do not exist yet. The 2026 survey found pre-deployment architecture costing was the single most requested missing capability, with most teams building their own calculators. If you build one thing beyond the basics, build that.

Organizations is a free service that puts many AWS accounts under one umbrella so you can apply rules to groups of them and get one bill. That is genuinely the whole idea. The complexity is entirely in what rules and which groups.

The OU structure AWS itself recommends — and that Control Tower creates for you — is deliberately not an org chart:

Three different questions, three different policy types.

An SCP answers "what may our people do?" — it constrains the principals inside your accounts. But your S3 bucket can also be accessed by someone else's principal from outside your org entirely, and an SCP has nothing to say about that, because that person is not your people. So an RCP answers the mirror question: "what may be done to our resources, by anyone?"

Both are about permission. Neither can express "all our VPCs should have public access blocked", because that is not a permission, it is a configuration. A deny on the API that enables public access is brittle: AWS adds a new API next year and your policy does not cover it. So a declarative policy answers a third question: "what configuration should this service always be in, regardless of what APIs exist?"

The declarative-policy distinction is the subtle and important one. Authorization policies regulate access to APIs. Declarative policies are applied at the service's control plane to enforce durable intent — so when AWS ships a new way to make a VPC public next year, the declarative policy already covers it, whereas your SCP denying ec2:CreateInternetGateway does not.

Here is the cost-relevant SCP everyone should have, and the reason it is a cost control and not just a security one:

// SCP: only these instance families may be launched.
// A GPU typo — p5.48xlarge instead of g6.xlarge — is a $55/hour mistake.
{
  "Effect": "Deny",
  "Action": "ec2:RunInstances",
  "Resource": "arn:aws:ec2:*:*:instance/*",
  "Condition": {
    "ForAnyValue:StringNotLike": {
      "ec2:InstanceType": ["g6.*", "g5.*", "t3.*", "m7i.*"]
    }
  }
}

If Organizations is the filing system, Control Tower is the person who sets it up correctly and keeps checking it. You could build everything it builds by hand — an OU structure, a log-archive account, an audit account, centralised CloudTrail, a set of SCPs and Config rules, a way to vend new accounts. Control Tower does it in an afternoon and then continuously verifies it has not drifted.

Controls also carry a guidance level, which is the part that matters when you are deciding what to turn on: mandatory (always on, cannot be disabled), strongly recommended (AWS best practice, opt-in), and elective (useful for some organisations only). A sensible starting posture is all mandatory plus all strongly recommended on Prod, and mandatory only on Sandbox.

Control Tower is opinionated, and its opinions cost you flexibility. It expects to own the OU structure it creates; it enables Config in every governed account and Region, which is not free and is a real line item on a large estate; and its landing-zone updates occasionally require a coordinated re-enrolment across accounts.

Reach for raw Organizations plus your own IaC instead when you have a small number of accounts and strong Terraform practice, when you need an OU structure that fights Control Tower's model, or when Config's per-item recording cost is material relative to your total spend. Reach for Control Tower when you are vending accounts regularly, when you need auditable evidence that controls are applied, or when nobody on the team wants to own landing-zone drift.

Your §16 covers this at length. The governance-and-cost framing that the section under-emphasises: RAM is how you avoid paying for the same thing N times after you split into N accounts. The canonical case is a shared VPC — one networking account owns the subnets, NAT gateways and Transit Gateway attachments, and shares subnets to workload accounts. Twenty accounts then use one NAT gateway instead of twenty, which given NAT's hourly-plus-per-GB pricing from C4 is often the single largest structural saving in a multi-account migration.

The cost catch, and it is a good exam-style trap: with a shared VPC, the subnet owner pays for the NAT gateway and data processing, while the participant account pays for its own instances. So your networking account develops a large, growing bill that belongs to nobody in particular — the untaggable shared-cost problem from S1, in its most common concrete form. Decide the allocation rule for it when you design the sharing, not when finance asks.

AWS has a lot of cost tools and their names do not tell you how they relate. They sort cleanly into the S1 FinOps loop: some tell you what happened, some tell you what is about to happen, some tell you what to do about it.

The Budgets / Cost Explorer / Trusted Advisor triad in your §17 is still accurate but is now the older half of the toolchain. The 2025-era additions above — Cost Optimization Hub, the Efficiency Score, managed anomaly monitors, FOCUS 1.2 — postdate the material. AWS CFM, re:Invent 2025 launches

AWS now has four commitment vehicles plus spot. Your §18 covers three of them.

Discount ceilings are 3-year, all-upfront figures and vary by instance and region. The Compute-vs-EC2-Instance gap is about 6 percentage points — the price of total flexibility. 2026 comparison, sourced to AWS pricing AWS Savings Plans

Layering. These stack without conflict, and AWS applies them in a fixed order — RIs first, then Savings Plans, with the highest-savings usage covered first within each tier. So the practical strategy is a base layer of Compute Savings Plans covering your steady floor, RIs only where the extra points justify the rigidity, and spot on everything interruptible. You cannot double-discount an instance-hour, and you cannot accidentally conflict them.

Spot mechanics you need for the math below. AWS gives a 2-minute interruption warning via instance metadata. Spot Instance Advisor publishes trailing 30-day interruption frequency by instance type and region — check it before choosing a family, because the variation is enormous. Current published figures: H100 spot on p5.48xlarge runs under 5% interruption, while A100 spot on p4d.24xlarge runs 15–20%. That is not a small difference; it changes which one is cheaper in practice.

Cloud GPU spot interruption rates, 2026 · check live figures in the AWS Spot Instance Advisor before committing a fleet design.

Azure calls the place a rule applies a scope, and there are four of them stacked: management group, subscription, resource group, resource. Assign anything — a policy, a role, a budget, a lock — at any scope, and it applies to that scope and everything beneath it. One word, one mechanism, four levels. That consistency is the nicest thing about Azure governance.

The reference hierarchy that the Azure Landing Zone accelerator builds is worth memorising, because you will meet it in every enterprise Azure estate:

In S2 you learned that AWS needs three policy types because permission-denial, resource-protection and configuration-pinning are structurally different jobs. Azure's answer is different: one policy language, and each policy declares an effect — what to do when a resource matches the rule. Change the effect and the same rule becomes preventive, detective, or self-healing.

The analogy: AWS gives you three tools. Azure gives you one tool with a dial on it. The dial includes settings the AWS tools do not have — most notably "fix it".

Here is that policy's core, which is the artifact worth recognising on sight:

// Modify effect: inherit cost-center tag from the resource group
"then": {
  "effect": "modify",
  "details": {
    "roleDefinitionIds": ["/providers/.../Contributor"],
    "operations": [{
      "operation": "addOrReplace",
      "field": "tags['cost-center']",
      "value": "[resourceGroup.tags['cost-center']]"
    }]
  }
}

The distinction from AWS is worth stating plainly. Control Tower is a managed service — AWS operates it and it has opinions you cannot easily override. The Azure Landing Zone accelerator is infrastructure-as-code you own — you fork it, modify it, and maintain it. More flexibility, more responsibility. Practitioners report the accelerator handles roughly 80% of an enterprise landing zone with the remaining 20% being customisation.

The Azure-specific move worth learning: budget → action group → Automation runbook. Because action groups can invoke a runbook or Function, an Azure budget can do more than notify — it can deallocate VMs in a scope, scale a set down, or apply a policy. §10 mentions budgets integrate with action groups but does not draw out the consequence, which is that Azure's budget-to-action path is more flexible than AWS's fixed set of budget actions, at the cost of you having to write the runbook.

The 7-percentage-point gap between Reservations (72%) and savings plan (65%) is the price of flexibility, and closely mirrors AWS's ~6-point gap between EC2 Instance and Compute Savings Plans. Microsoft's 65% figure is based on a specific configuration (an M64dsv2 in East US over 36 months) — treat all published ceilings as best-case. 2026 comparison

Same four-level tree as the other two clouds: organization → folders → projects → resources, with policy inheriting downward. §12 states this clearly and correctly. The GCP-specific instinct to build is that projects are cheap. Unlike an AWS account — which needs an email address, a payment method and a plumbing pass — a GCP project is a lightweight thing you create with one command. That changes the default: where an AWS architect asks "can we avoid another account?", a GCP architect more often asks "why is this sharing a project?"

§12's organisation best practices are sound and match the other two clouds: separate projects per environment, folders per department or function, and a dedicated project for shared infrastructure so networking and logging are not duplicated. The section's suggestion of multiple billing accounts for larger enterprises is where GCP genuinely diverges — and it deserves a caution the material does not give, which appears in section D.

Where an AWS SCP says "this principal may not call this API", a GCP organization policy says "resources in this scope may not be configured this way". It is closer to AWS's declarative policies than to SCPs — it constrains the shape of your infrastructure rather than who may act on it.

That difference has a practical consequence worth holding: GCP's answer to "stop people using expensive regions" is a constraint on where resources may exist, not a deny on the principals who create them. The effect is similar; the mental model is not.

The two constraints that do the most cost work, and are worth setting on day one:

# constraints/gcp.resourceLocations — where resources may exist
# stops region sprawl and the unwatched-region mining incident
constraint: constraints/gcp.resourceLocations
listPolicy:
  allowedValues: [ in:us-central1-locations, in:us-east4-locations ]

# constraints/compute.vmExternalIpAccess — no public IPs
# a security control that is also an egress-cost control
constraint: constraints/compute.vmExternalIpAccess
listPolicy:
  deniedValues: [ ALL ]

Both are list constraints. allowedValues and deniedValues are mutually exclusive on a single policy — you pick a posture, exactly as you pick between an AWS deny list and allow list.

§12 introduces the service but is thin on the resolution rules, which is where the real behaviour lives. Three that matter:

In AWS, a tag is one thing that does two jobs: it groups costs and it can gate access. GCP splits those jobs across two different systems with almost the same name, and then adds a third unrelated thing also called a tag.

The intuition to hold: labels are for the accountant, Tags are for the auditor, network tags are for the firewall. If you take nothing else from this section, take that sentence — it resolves most GCP naming confusion in design reviews.

The reason this split exists is sound, even if the naming is not: a cost dimension needs to be cheap, unvalidated and editable by whoever owns the resource, while a policy dimension needs to be centrally defined and IAM-controlled. AWS uses one mechanism for both jobs and consequently has a weaker policy story around tags. GCP separated them. Tags overview

S1 made the general point that a budget is a smoke detector, not a sprinkler. GCP is the cloud where that is most literally true, and where the documentation says so in its own words: a budget's purpose is to trigger notifications. It does not cap spend, it does not stop resources, and by default the only thing that happens when you blow through it is that some email arrives.

Where AWS gives you budget actions from a fixed menu and Azure lets a budget invoke a runbook, GCP hands you an event on a message queue and says: build what you want. That is more work and more power. It is also the single most common gap between what a team believes it has configured and what it actually has. Cloud Billing budgets

A GCP cost-response system is four components you assemble yourself. The stepper walks the path a single dollar of overspend takes:

Given all of the above, here is the honest ordering of GCP's spend controls by how reliably they stop money leaving, strongest first. It is not the order most teams configure them in.

GCP is the only major cloud that gives you a volume discount for doing nothing. Run a VM for most of a month and the price drops automatically — no purchase, no term, no commitment. That is the sustained-use discount, and it is genuinely unusual: on AWS and Azure, the discount for steady usage requires you to sign something first.

The analogy is a coffee shop that quietly starts charging you less once you have come in most days this month, versus one that sells you a punch card up front. The first is friendlier. It is also the reason GCP list prices and AWS list prices are not directly comparable, and the reason a naïve three-cloud price comparison spreadsheet is usually wrong in GCP's disfavour.

And there is a catch that lands squarely on your workloads. Hold that thought until Pass 3.

How they stack. Spot is priced separately and does not combine with commitments. SUD and CUD do interact: committed-use discounts apply first to the resources they cover, and sustained-use applies to eligible on-demand usage beyond that. In practice, the shape of a well-run GCP compute bill is a committed floor, sustained-use credits on the on-demand layer above it, and Spot handling anything interruptible. CUD overview Sustained use discounts