Resource Hierarchy

⭐️☁️ PlatformDefine a cloud resource hierarchy structure that facilitates tenant isolation and policy enforcement. Maintain the integrity of this hierarchy to ensure capabilities built atop of it remain effective.

Every cloud platform has a concept of multi-tenancy. At the most basic level, every resource or service in a cloud platform belongs to a “tenant”. Tenants provide strong isolation guarantees between different customers so that resources in one tenant can not affect resources belonging to another tenant.

Tenants and cloud resources therefore always form the concept of a hierarchy. This hierarchy allows operators to establish rules and policies at the tenant level, that then apply to all resources within the tenant. One example of those are RBAC roles that grant permissions to modify an object storage bucket. When a user has this RBAC role assigned on the tenant level, they will have permission to modify any object storage bucket within the tenant.

Most cloud platforms today also offer higher-level constructs that allow modeling resource hierarchies above the tenant level, e.g. by grouping related tenants under folders or organization units. These higher-level constructs afford cloud foundation teams to centrally define and enforce policies across multiple tenants, thereby reducing complexity and simplifying governance.

Designing and leveraging the cloud resource hierarchy is therefore an important starting point for establishing proper cloud governance. By deliberately placing cloud tenants in this hierarchy right from the start (see Tenant Provisioning), cloud foundation teams can easily ensure the consistent enforcement of guardrails like Service and Location Restrictions.

Examples of Cloud Resource Hierarchy

The following list is a quick reference to the different resource hierarchies in cloud platforms. The list uses bold font to denote the tenant concept.

  • AWS: Organization → Organization Unit → AccountResources

  • Azure: Root Management Group (AAD Tenant) → Management Group → Subscription → Resource Group → Resources

  • GCP: Organization → Folder → ProjectResources

  • Kubernetes (and OpenShift): Namespace (Project)Resources

    • OpenStack: Domain → ProjectResources
  • Cloud Foundry: Foundation → Organization → Space → Resources

Despite all the differences in naming and implementation details, there are a lot of conceptual similarities between the different platforms. Cloud foundation teams on a mission to implement a multi-cloud strategy can leverage these conceptual similarities to drive a consistent governance approach across multiple clouds.

Best Practices for Setting up Cloud Resource Hierarchy

💡 Cloud Resource Hierarchy is an important early design decision to make in your cloud journey. Pay attention to its scalability along these dimensions

  • managing a large number of tenants
  • managing day-two operations like reorganization and changing responsibilities
  • adopting a multi-cloud strategy

As Flat as Possible, as Deep as Necessary

Keep the resource hierarchy above the tenant level as flat as possible to reduce complexity and management overhead. Every layer in the resource hierarchy can define its own set of policies and exceptions. Deeply nested structures thus make it more difficult to track the final set of policies that a tenant inherits. This complexity makes it more difficult to maintain and evolve your cloud foundation.

Automate Deployment and Maintenance of the Resource Hierarchy

While it may be tempting to initially deploy a cloud resource hierarchy manually, maintaining the hierarchy is important because a lot of fundamental capabilities like Service and Location Restrictions or Tenant Provisioning built atop of it. Maintaining your resource hierarchy via infrastructure as code helps preventing configuration drift and enforcing consistency.

Decouple Cloud Resource Hierarchy from Your Org Chart

Avoid duplicating your organizational structure into the cloud resource hierarchy.

💡 Many IT systems outlive the organizational team that initially created or deployed them. As the cloud is an infrastructure platform, start with IT systems as the primary unit of organization.

Organizational structures are much more likely to change than IT systems. For example, an IT system may be handed over to another team for maintenance, but stay the same otherwise. Or your organization undergoes a reorganization with big changes to reporting hierarchies and department numbers. Would you want to reflect every one of these changes in the cloud platform resource hierarchy? It’s much easier to apply these organizational changes in a Cloud Tenant Database while leaving the IT system’s infrastructure otherwise untouched. Instead of encoding organizational metadata in the resource hierarchy, Cloud Tenant Tagging offers a more flexible way to bring up-to-date metadata into the cloud.

Design your resource hierarchy so that your internal customers can leverage dedicated tenants for the different stages (e.g. development, production) of IT systems. Most likely you will want to enforce different guardrails for productive and non-productive environments, which implies that they will live in separate parts of the resource hierarchy.

Structure your clouds

Check out meshcloud’s white paper “Best Practices of Modeling your Organizational Structure in the Cloud” as an introduction to organizational design in the cloud.

Tell me about structuring my clouds

Beware of Resource Hierarchies Serving Double-Duty

A lot of guidance about setting up cloud resource hierarchies you may find elsewhere is focused on helping an organization adopt a single cloud only. There are two challenges with this type of guidance. First, it looks at practices from the perspective of an organization that’s new to cloud and wants to solve the “onboarding” part of the cloud journey while paying little attention to day two operations. Second, it emphasizes outsourcing governance operations as much as possible to the cloud platform’s built-in capabilities. This can create “organizational vendor lock-in” and make it difficult to implement consistent governance across multiple clouds.

When just starting out on a cloud journey, it’s tempting to leverage resource hierarchy to quickly offer self-service capabilities to larger organization units like departments or divisions by giving them their own place in the cloud resource hierarchy. For example, giving a department head Owner permissions on a Folder in a Google Cloud Organization can allow that department to quickly create new projects, manage IAM permissions and billing for all of their projects. However, this individual freedom will make it difficult to establish a scalable governance architecture leveraging landing zones to enforce consistency across a large number of cloud tenants. A proper Tenant Provisioning process, Federated Identity and Authentication and Monthly cloud tenant billing report can provide similar (or greater!) freedom to your internal customers while ensuring a scalable governance approach.

Another consideration is what governance concerns you want to leverage the resource hierarchy for. For example, if your primary aim is to leverage the resource hierarchy to establish and enforce consistent policies (e.g. to build landing zones), mixing this with billing concern (aggregate consumption charges per department) is going to result in a complex and less maintainable resource hierarchy. We thus recommend to separate concerns like Chargeback via consumption cost allocation to its own governance process instead of loading it onto the resource hierarchy.

Separate Shared Services and Internal Customer Workloads

As the cloud foundation team you will likely want to add more advanced capabilities like On-Premise Network Connection to your service offering later on. Separate these shared services and customer workloads in the resource hierarchy on a very high level up the tree. This is especially relevant if you want to simultaneously enforce policies like Service and Location Restrictions to enforce use of shared services.

Consider Separating Productive and Non-Productive Workloads

Strong separation of productive and non-productive workloads should go into different landing zones. Your resource hierarchy should reflect this. This especially critical if productive systems are facing additional regulatory requirements compared to development or test workloads.

  • meshStack

    meshStack’s Landing Zones allow cloud foundation teams to pre-define a desired resource hierarchy for newly created (and yet existing) cloud tenants. meshStacks supports the hierarchy concept for all public and private cloud platforms, e.g. Azure Management Groups & AWS Organization Units.

    Learn More open in new window
  • GCP Fabric FAST

    FabricFAST rolls out a best-practice resource hierarchy for a Cloud Landing Zone. A hierarchy that fits many companies is applied by default. It is divided into common branches like networking or security. A “Teams” branch contains all end-user projects. It can be easily customized via input variables (also see Tenant Provisioning below). Applying a completely different structure requires adaption to the Terraform files. For other hierarchy structures, you can also use blueprints provided outside the context of fast stages, see “example foundations”.

    Learn More open in new window
  • GCP CFT - Example Foundation

    The FCT Example Foundation rolls out a best-practice resource hierarchy for a Cloud Landing Zone. It only rolls out one specific resource hierarchy, which is separated by environment (dev, non-prod, prod). Using custom hierarchies must be implemented on your own.

    Learn More open in new window
  • GCP Setup Checklist

    You can pick from 4 different hierarchies, which makes it quite easy to find a hierarchy that matches your needs. Using even more custom ones is also possible by adapting the generated Terraform code in the end.

    Learn More open in new window
  • Azure LZ accelerator - ES

    It creates a nice resource hierarchy with different levels. There is Platform MG which is dedicated to all the services and resources which need to be managed centrally. And the Landing Zones MG for the environments with internal or external connections.

    Learn More open in new window
  • Azure LZ Terraform module - ES

    The resource hierarchy it creates is based on the Azure landing zone conceptual architecture as part of the “Core Resources ”. The hierarchy is meant to be customized under the Landing zones level.

    Learn More open in new window
  • Azure CAF Terraform Modules

    The resource hierarchy it creates is also based on the Azure landing zone conceptual architecture as part of the “Core Resources ”. The hierarchy is meant to be customized under the Landing zones level.

    Learn More open in new window
  • AWS Control Tower with Account Factory

    Creates 2 Organizational units (OUs), Security and Sandbox. It also creates 3 shared accounts; a standalone management account (not belonging to an OU), and log archive and security audit in the Security OU. The Sandbox OU remains empty to contain the new provisioned accounts. You can create new OUs based on your desired structure. They will be governed by CT. AWS also offers a sample hierarchy with additional OUs that you can manually include.

    Learn More open in new window
  • AWS Control Tower with AFT

    Additional to what CT provides, AFT offers a GitOps approach to provision accounts under specified OUs through an automated workflow.

    Learn More open in new window
  • AWS Landing Zone Accelerator

    By default it creates 2 OUs, Infrastructure and Security. You can easily define more OUs in the config. Another great feature it provides is the option to use a Quarantine OU where almost everything is forbidden. It is used for newly created accounts that are still under construction by the accelerator. That way unintended access or changes during creation can be avoided.

    Learn More open in new window