Design and Implement Cloud Hierarchy Structure

Why

Your cloud hierarchy IS your cost allocation strategy. Account-level isolation means 100% accurate cost attribution without relying solely on tagging — every resource inherently belongs to an account, and that account maps to an owner. A well-designed hierarchy makes roll-up reporting automatic: BU totals and application costs fall out of the structure naturally. Getting this right from day one avoids painful restructuring later.

What

Design a landing zone hierarchy across all cloud providers that aligns with your organisation’s financial reporting lines. Each workload gets its own dedicated account/subscription/project, placed within a defined hierarchy. New accounts are auto-registered in the CMDB and appear in cost dashboards.

How

Understand Provider Hierarchy Models

Each provider uses a different tree structure, but the goal is the same: group resources so structure naturally maps to financial reporting.

Key principle: Accounts/Subscriptions/Projects are the most reliable unit for cost allocation because every resource inherently belongs to one. Design so that one account = one workload + one environment.

Design the Hierarchy

Recommended pattern (all providers):

Hierarchy Design Pattern
═══════════════════════════════════════════════════════════════

  Root
  ├── Platform / Shared Infrastructure
  │     ├── Networking
  │     ├── Security / Identity
  │     ├── Logging / Monitoring
  │     └── Billing / FinOps
  │
  ├── Workloads
  │     ├── BU-A
  │     │     ├── Prod  → one account per app
  │     │     └── Non-Prod → one account per app
  │     ├── BU-B
  │     │     ├── Prod
  │     │     └── Non-Prod
  │     └── ...
  │
  └── Sandbox
        └── Developer sandbox accounts (budget-capped)

Cost allocation layers built from structure:

1. Structural allocation (primary): Accounts = most reliable. Every resource belongs to one.
2. Organisational aggregation: OUs/MGs/Folders = BU-level roll-up for executive dashboards.
3. Tag enrichment: Sub-structural detail (cost centre, team, project) for cases where teams share an account.
4. Shared cost distribution: Platform accounts distributed via allocation rules (see S1-04).

Define Naming Conventions

Names should be self-describing, lowercase kebab-case, and embed the hierarchy.

General Pattern:
  {org}-{bu}-{app}-{env}-{resource-type}-{qualifier}

  Where:
    {org}   = Company short code (2-4 chars)
    {bu}    = Business unit (fin, mkt, eng)
    {app}   = Application name
    {env}   = Environment (prod, stg, dev, sbx)

Examples per provider:

Watch out: Azure Storage Account names cannot contain hyphens (max 24 chars). GCP Project IDs are globally unique (max 30 chars). Plan abbreviations carefully.

Implement Landing Zone

Use provider-specific landing zone accelerators:

For existing organisations, plan a migration strategy for legacy shared accounts. This is the most labour-intensive part — restructuring existing accounts to fit the new hierarchy may require networking changes, IAM boundary updates, and resource moves.

Register in CMDB

Every new account/subscription/project must auto-register in the CMDB with: owner, application name, environment, business unit, cost centre, creation date. This enables automated dashboard population and cost reporting.

Deliverable Checklist

• Hierarchy design documented per provider
• Naming convention standard published
• Landing zone accelerator deployed
• Platform / Shared accounts created and tagged
• At least one BU workload provisioned in new structure
• CMDB auto-registration operational
• Legacy migration plan defined (if applicable)
• Cost dashboards reflect new hierarchy