Up to here, the Kladde has had one subscription, one resource group per environment and one budget per environment (lesson 4.1.5). That is enough for one office and one person who keeps everything in their head. With the tenant model from lesson 4.7.6, that changes: There is a control plane, soon several stamps, practice and trial environments like the restore drill from lesson 4.7.5, and the question “What does an office cost us?” should have a number, not an estimate.

Governance means here: rules that apply without anyone having to think of them. No resource is created outside the EU, every resource says which stamp it belongs to, every database writes its diagnostic data, and a warning arrives before a month gets more expensive than planned. In this lesson you design the structure for that, write the rules in Bicep and calculate the cost per office from tags.

Three levels, three kinds of boundaries

Azure arranges everything in a hierarchy. Each level is a boundary for something different:

Level Boundary for in the Kladde
Management group policies (Azure Policy) and role assignments that are inherited by everything below rules for all subscriptions of the Kladde in one place
Subscription billing, quotas and service limits, permissions, policies one per purpose: platform, production, development, practice
Resource group lifecycle (what is created and deleted together), permissions one per environment and stamp, such as rg-kladde-prod-s1

A few facts from Microsoft's documentation that shape the design:

  • Each directory has exactly one hierarchy with one root management group. Below it, up to six levels are possible, not counting the root and not counting the subscriptions. Every management group and every subscription has exactly one parent.
  • What is assigned to a management group applies to everything below it, and an owner of a subscription below it cannot switch it off.
  • New subscriptions first land under the root group. And without further settings, every signed-in person of the directory may create new management groups. Both can be changed in the hierarchy settings: a default group for new subscriptions and the requirement of having a permission to create them.

The Cloud Adoption Framework (CAF) gives recommendations for the structure, which Microsoft calls “Azure landing zones”. The most important ones for the Kladde:

  • Keep it flat, three to four levels if possible. The hierarchy does not mirror the org chart but groups with the same rules.
  • No management groups for production, test and development. The environments are subscriptions in the same group, because the same rules should apply to them. Otherwise you check something different in development than what applies in production.
  • One group for the platform, that is, for what all workloads share.
  • A “sandbox” group for trying things out, separate from everything else. It is a good place for new subscriptions until someone classifies them.
  • Permissions for work teams on a subscription or resource group, not on management groups. Management groups mainly carry policies.

For the Kladde with its control plane and stamps, this gives the following proposal:

mermaid
flowchart TB
  root["Root management group of the directory"]
  kladde["mg-kladde<br/>EU regions only"]
  platform["mg-kladde-platform<br/>required tags, diagnostics"]
  workloads["mg-kladde-workloads<br/>required tags, diagnostics"]
  sandbox["mg-kladde-sandbox<br/>default for new subscriptions"]
  subPlatform["Subscription kladde-platform<br/>Front Door, registry, control plane, Log Analytics"]
  subProd["Subscription kladde-prod<br/>rg-kladde-prod-s1, rg-kladde-prod-s2"]
  subDev["Subscription kladde-dev"]
  subSandbox["Subscription kladde-sandbox<br/>drills, rehearsals as in 4.7.5"]
  root --> kladde
  kladde --> platform --> subPlatform
  kladde --> workloads
  workloads --> subProd
  workloads --> subDev
  kladde --> sandbox --> subSandbox

Three reasons that belong in the ADR for it:

  • The platform has its own subscription, because its cost belongs to no stamp and because only the control plane may deploy there (least privilege from lesson 4.8.5, one level up).
  • The stamps share the subscription kladde-prod, each with its own resource group. A stamp gets a subscription of its own only when it hits a quota or an office demands it by contract. That goes under “Revisit when”.
  • The “EU only” rule sits at the very top, so that it also applies to the sandbox. A drill in a region outside the EU is the way real data ends up there, for example in a restore rehearsal with a copy of production.

If you learn on your own, you usually have a single subscription and no permission on the root group. That is no obstacle: You design the structure as a document and assign the rules from this lesson to your own subscription. The same Bicep file can later be switched to a management group with one line.