Cloud Hierarchy: Structure as Governance Foundation

Why structure comes before technology

Many cloud introductions begin with the question: “Which services do we use?” The more important question is: “How do we structure our cloud environment so that governance scales?”

A cloud hierarchy is the answer to that question. It defines how policies are enforced, costs are allocated, and permissions are managed — not for one environment, but consistently across all environments, regardless of provider and scale.

The core principle: governance requirements are defined once at hierarchy level and automatically inherited by all subordinate units. Without this structure, every security policy, every cost centre assignment, and every permission requirement must be manually configured for each environment — an unsolvable scaling problem.

Hierarchy Nodes: The logical groups

Hierarchy Nodes are logical grouping units that structure Cloud Spaces and centrally define policies. Five standard nodes form the skeleton of a well-designed platform architecture:

Platform

Contains all centrally managed infrastructure and platform services. Global requirements are defined here: security, networking, logging, cost management. Strictly separated from workloads — exclusively for platform-wide capabilities.

Workload

Contains all Cloud Spaces hosting business applications, organised by environment type: Production (highest requirements, restricted access) and Pre-Production (development, test, staging). Teams are assigned to Spaces in the Workload node.

Sandbox

An isolated environment for experiments, tests, and technology evaluations. Policies are intentionally less restrictive, allowing teams to explore new technologies without affecting production systems or regulated environments.

Policy

Dedicated to central evaluation and validation of policies. Compliance mechanisms are consolidated here and operated independently from production workloads — for isolated policy evaluation without operational risk.

The Graveyard node deserves special mention, though it rarely appears in concepts: it is a controlled holding area for decommissioned Cloud Spaces. Resources are temporarily retained before being permanently removed. This enables traceable decommissioning and prevents accidental dependency breaks that would go unnoticed during immediate deletion.

Cloud Spaces: The operational unit

A Cloud Space is the smallest administrative unit on the platform. It is the operational boundary within which resources are created, costs are captured, and permissions are assigned.

The technical implementation is provider-specific, but the conceptual function remains identical: every Cloud Space has exactly one responsible owner, is assigned to exactly one Hierarchy Node, and automatically inherits that node’s policies.

This trinity — Space as cost centre, permission boundary, and policy inheritor at once — is the core of the model. It allows questions like “Who created this?”, “Which team is charged for this?”, and “What rules apply here?” to always receive a consistent answer.

Direct permission assignments to individual identities are not permitted within Cloud Spaces — all access flows through groups. This ensures that onboarding and offboarding work automatically: leave the group = access immediately revoked.

Policies flow downward

The most powerful feature of a hierarchy structure is policy inheritance. A policy applied to a Hierarchy Node automatically applies to all Cloud Spaces beneath it.

This means: the central requirement that all resources must be deployed in specific regions does not need to be configured individually for each of a hundred environments. It is defined once at the appropriate node — and applies everywhere beneath it.

This works hierarchically: the higher up a policy is defined, the more units are affected by it. This enables finely graduated governance: global requirements at the top, environment-specific requirements in sub-nodes.

Introduction in the right order

1. Design the hierarchy structure: Which nodes does the organisation need? The five standard nodes are a good starting point — but every organisation has specific requirements that influence the structure. This step happens on a whiteboard, not in the console.

2. Define policies per node: Which requirements apply to which node? Start with the global ones (applying to all Spaces), then the node-specific ones. Security, costs, naming conventions — everything that should apply consistently.

3. Define the Cloud Space standard: What does a newly created Cloud Space look like? Which tags, which default groups, which budget alert? A reproducible Space standard prevents every environment from being configured differently.

4. Classify existing environments: What already exists? How does it fit into the new hierarchy? This inventory is often laborious, but it is the foundation for governance over the existing estate.

5. Define the Graveyard process: How are Cloud Spaces decommissioned? Who approves, who executes, how long is the retention period? An undefined process leads to unused, billable environments.

The technical implementation of the hierarchy structure is provider-specific, but the conceptual model remains consistent. Details on the Landing Zone as the technical implementation are in Landing Zone.