Cloud Computing Architecture Guide

Resource Hierarchy as an Operating Model

Goal

Cloud hierarchy is the structure through which an organization assigns resources, permissions, policy, cost, and lifecycle. Designing it is therefore an operating-model decision, not an exercise in filing resources neatly.

The Short Version

A useful hierarchy answers five questions:

  1. Who owns this workload and its risk?

  2. Which policies and access rules apply?

  3. Who pays and reviews the cost?

  4. Which resources share a lifecycle and environment?

  5. How far can a mistake, compromise, or quota problem spread?

Organization / tenant
  |
  +-- Governance grouping
      |
      +-- Account / subscription / project boundary
          |
          +-- Resource collection
              |
              +-- Resources

This is a generic model. AWS and Azure use different structures and inheritance behavior. Translate only after defining the operating outcomes.

Hierarchy Creates Attachment Points

Cloud controls need a scope. Hierarchy provides places to attach:

  • access roles and privileged administration;

  • preventive and detective policy;

  • budgets and cost reporting;

  • network and security baselines;

  • logging and compliance evidence;

  • deployment automation and lifecycle rules.

Placing a rule too high can constrain unrelated teams. Placing it too low creates inconsistent repetition and gaps. The architecture should put stable, widely applicable intent high in the hierarchy and workload-specific choices near the workload.

Organize Around Durable Differences

Good boundaries reflect differences that remain meaningful over time:

  • production versus non-production risk;

  • business or product ownership;

  • regulatory or data classification;

  • platform and shared-service ownership;

  • geographic or legal separation;

  • distinct lifecycle and recovery needs.

Avoid building the hierarchy from a temporary org chart alone. Teams reorganize. A hierarchy based only on today's reporting lines can force disruptive moves without improving control.

Example: Growth Without Ownership

A company began with one cloud boundary for all experiments. Two years later it has customer-facing production systems, prototypes, shared networking, and abandoned resources together. No one can answer which costs belong to which product, and broad administrator access is common because separation is difficult.

The company redesigns around durable workload and environment boundaries:

  • dedicated security and logging capabilities have central owners;

  • production workloads receive distinct major boundaries and named business owners;

  • non-production is separated from production and governed with proportionate controls;

  • shared services are isolated and expose explicit interfaces;

  • experiments expire unless an owner promotes them through a governed path.

The migration is phased. New workloads use the target structure first; existing workloads move according to risk and value. Hierarchy becomes a platform capability rather than a one-time cleanup.

Provider Lenses

AWS commonly uses AWS Organizations, organizational units, and multiple accounts to group and isolate workloads. Azure commonly uses a Microsoft Entra tenant, management groups, subscriptions, resource groups, and resources. Both provide hierarchical policy and access mechanisms, but their scopes and defaults differ.

Do not ask "What is the exact equivalent?" Ask where each provider offers the needed ownership, isolation, billing, policy, and lifecycle boundary.

Common Mistakes

  • Putting unrelated production and experimentation into one major boundary.

  • Copying the current org chart without considering workload lifecycle.

  • Creating deep hierarchy that adds administration but no distinct policy.

  • Designing policy scopes without naming accountable owners.

If Someone Asks You

Why is resource hierarchy an architecture topic?

Because hierarchy determines where ownership, access, policy, cost, and lifecycle controls apply. Those choices shape risk and operating behavior throughout the workload's life.

What You Should Remember

Hierarchy is the operating shape of ownership, access, billing, and policy.

Questions to Check Your Understanding

  1. Which durable differences justify separate hierarchy boundaries?

  2. Why can policy attached too high or too low cause problems?

  3. Why should a hierarchy not simply reproduce the org chart?

Further Study