Thorough Guide to AWS Organizations: Learning Multi-Account Design by Comparing GCP’s Resource Hierarchy and Azure Management Groups

Introduction (Key Point Summary)

• In this article, we put AWS Organizations center stage and carefully整理 (structure) multi-account / multi-project era cloud design while comparing side by side with GCP’s resource hierarchy (Organization / Folder / Project) and Azure’s Management Groups + subscription structure.
• AWS Organizations is a service that lets you centrally manage multiple AWS accounts in a policy-based way, enabling automation of account creation, governance, cost management, and centralized auditing. It’s available at no additional cost and serves as the “foundation” for a scalable environment.
• In contrast, GCP provides the same kind of “hierarchical governance” using Organization / Folder / Project and Cloud IAM / Org Policy, while Azure uses Management Group / Subscription / Resource Group combined with Azure RBAC / Azure Policy.
• The key points of design are:
  1. Split accounts (or projects / subscriptions) not by the org chart, but by “governance and responsibility”.
  2. Use SCPs (Service Control Policies), Org Policy, and Azure Policy to define “upper-bound rules”.
  3. Prepare “hub” accounts / projects to centralize security, logs, and billing.
  4. Organize OUs / Folders / Management Groups by environment (prod / stg / dev) and team.
  5. Design naming, hierarchy, and permissions so they can be “reused across clouds”, keeping future multi-cloud in mind.
• This article is written for corporate IT cloud owners, SRE / platform engineers, security & governance staff, lead engineers in organizations with multiple products, and startup CTOs.
  • It’s ideal for the phase where you’re graduating from a single account and have begun thinking “it’s about time to split accounts” or “we want clear responsibility boundaries by department”.

1. What Is AWS Organizations? – A Service That Treats Multiple Accounts as “One Organization”

1.1 Basic Idea

To put AWS Organizations simply, it is:

“A service that bundles multiple AWS accounts into a single ‘organization’
and centrally manages account creation, policies, billing, and governance.”

Its main features are as follows:

• Centralized management of multiple accounts
  • You can attach multiple accounts under a single Organization and organize them in a hierarchy (OUs).
• Automation of account life cycle
  • You can automatically create new accounts via API / CloudFormation / various landing-zone solutions.
• Policy-based governance (SCP)
  • You can apply Service Control Policies (SCPs) at the Organization / OU / account level and define upper-bound rules, such as “no iam:* allowed anywhere in this organization” or “regions other than Tokyo are forbidden in this OU”.
• Consolidated billing
  • You can aggregate the usage fees of all accounts in the organization into a single bill, making cost management easier and letting you benefit more from volume discounts.

1.2 Main Components

Let’s briefly整理 the key terms that make up the AWS Organizations world:

• Organization
  • A collection of AWS accounts. A single management account sits at the top and multiple member accounts hang under it.
• Management Account
  • The “parent” account that first created the organization.
  • It has very strong privileges, such as inviting / creating accounts, setting SCPs, and managing billing, so ideally you don’t want people logging into it for day-to-day work.
• Member Account
  • A normal account that belongs to the organization. You can either invite an existing account or create a new one as a member.
• Root
  • The topmost node of the organization hierarchy. Applying an SCP here affects every account in the organization.
• OU (Organizational Unit)
  • A “folder-like” unit for grouping accounts. OUs can contain child OUs, so you can express a hierarchical organizational structure.

By combining these, you can organize accounts such as “security account”, “log archive account”, “Product A prod”, “Product A staging”, and so on.

2. Aligning the “Hierarchy Structures” of AWS / GCP / Azure

Let’s first answer the common question: “What is the equivalent of Organizations in GCP and Azure?”

2.1 Rough Comparison of the Three Clouds’ Hierarchy Structures

AWS (Organizations + IAM)

• Organization
  • Root
    • OU (represents departments / environments, etc.)
      • Account (AWS account)
        • Various resources (VPC, EC2, RDS, …)

GCP (Resource Manager + Cloud IAM)

• Organization
  • Folder (arbitrary-depth folders representing departments / systems / environments)
    • Project
      • Various resources (Compute Engine, Cloud SQL, GKE, …)

Azure (Management Groups + Subscriptions)

• Management Group (top-level container for the organization)
  • Management Group (can be nested)
    • Subscription
      • Resource Group
        • Various resources (VM, Storage, SQL DB, AKS, …)

All three clouds follow a rule that policies and permissions set on upper-level nodes are inherited by the nodes beneath them, implemented via:

• AWS: SCP + IAM
• GCP: Cloud IAM Allow / Deny policies + Org Policy
• Azure: Azure RBAC + Azure Policy

2.2 Intuitive Mapping Table

You can roughly think of the mapping like this:

• AWS Organization ⇔ GCP Organization ⇔ Azure Tenant + Management Groups
• AWS OU ⇔ GCP Folder ⇔ Azure Management Group
• AWS Account ⇔ GCP Project ⇔ Azure Subscription

They’re not perfectly identical, but in terms of “top-level folder structure of the cloud”, they play almost the same role.

3. Representative Use Cases – When Do You Use Organizations?

3.1 Splitting Accounts by Department / Environment to Enforce Governance

A common tree structure looks like this:

• Root

  • security OU
    • Security tooling account
    • Log aggregation account
  • shared-services OU
    • Network hub account
    • Common platform (CI/CD, IAM Identity Center, etc.)
  • workloads OU
    • prod OU
      • Product A prod account
      • Product B prod account
    • nonprod OU
      • Product A dev / staging account
      • Product B dev / staging account

• Security / network / shared platform lives in “shared services” accounts.

• Each product team works within its own account, while dangerous actions are restricted via SCPs.

This gives you clear responsibility boundaries and cleaner operations.

On GCP, you’d create security / shared / workloads Folders under the Organization and attach Projects under them. On Azure, you’d create subscriptions under Management Groups in a similar structure, achieving nearly the same setup.

3.2 Cost Management with Consolidated Billing

When you want to separate accounts by department while still having a single bill for accounting, Organizations is very helpful.

• You can see usage per account in Cost Explorer and billing reports.
• But invoices are aggregated at the organization level, so payment is simple.
• Volume discounts and Savings Plans also apply more effectively across the organization.

GCP offers something similar via billing accounts + projects, and Azure via Enterprise Agreements / CSP + multiple subscriptions, but AWS has particularly tight integration between Organizations and its cost management tools.

3.3 Guardrails for Regulatory / Compliance Requirements

Examples of organization-wide rules include:

• “In this organization, only specific regions may be used.”
• “In this OU, root user operations are forbidden.”
• “This department may not use certain services (e.g., risky test services).”

You can define these as SCPs attached to the Root / OU, preventing configuration drift at the individual account level.

Similarly, you can use Org Policy in GCP or Azure Policy + Management Groups in Azure to define organization-level rules such as “region restrictions,” “service restrictions,” and “mandatory tags.”

4. Setting “Upper Bounds” with SCP (Service Control Policy)

4.1 The Role of SCP

While IAM policies specify permissions granted to a user or role, SCPs define:

“What an account (or accounts under an OU) must never be allowed to do in the first place.”

In other words, SCPs are “upper-bound guardrails.”

• Even if something is Allowed by an IAM policy, a Deny in an SCP will still block it.
• Conversely, even if an SCP allows an action, it still won’t succeed unless allowed by IAM.

So you get a two-layer control structure.

4.2 Representative SCP Samples

4.2.1 Forbidding root User API Usage

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRootUser",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:root"
        }
      }
    }
  ]
}

Attach this SCP to the Root or a specific OU to completely block API operations by the root user (console behavior around login / billing views depends on AWS’s implementation, but at least you prevent “accidental root key usage”).

4.2.2 Forbidding Use of Regions Other Than Tokyo

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRegionsExceptTokyo",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": "ap-northeast-1"
        }
      }
    }
  ]
}

This is useful when you need to restrict allowed regions for compliance reasons.
In GCP, you would do something similar using Org Policy with constraints/gcp.resourceLocations, and in Azure, via a Policy on a Management Group restricting location, achieving almost the same behavior.

5. Account Structure Patterns – “Templates” by Scale

5.1 Small Scale / Startups (2–5 Accounts)

• management (or root): for Organizations management and billing only (no day-to-day logins)
• security: CloudTrail aggregation, security tools, log storage
• shared: VPC hub, IAM Identity Center, shared CI/CD
• prod: production workloads
• nonprod: development / test workloads

This level of simplicity is usually enough to start. You can later add prod-a, prod-b, and so on as needed.

On GCP, this corresponds to security / shared / prod / nonprod Folders and Projects under the Organization. On Azure, you’d reflect this via Management Groups and multiple subscriptions.

5.2 Medium–Large Organizations (By Department / Country / Business Unit)

An example:

• security OU
• shared-services OU
• corp-it OU (internal IT systems)
• business-unit-a OU
  • prod / nonprod
• business-unit-b OU
  • prod / nonprod

Here, you define OUs by business unit × environment, and apply common SCP rules (region restrictions, root bans, mandatory logging, etc.).

On GCP (Folders) and Azure (Management Groups), you’d typically have something like:

• org
  • shared
  • corp-it
  • bu-a
  • bu-b

with governance enforced at each level.

6. Governance “Hot Spots” Seen in Comparison with GCP and Azure

6.1 Combination with IAM

• AWS:
  • SCPs in Organizations define “what’s allowed at most”, while IAM policies define “who actually gets what permissions”.
• GCP:
  • Cloud IAM roles + Org Policy control Allow / Deny at each hierarchy level.
• Azure:
  • RBAC roles + Azure Policy applied at the Management Group / Subscription / Resource Group levels.

All clouds share the pattern of “setting guardrails at the upper containers and granting day-to-day permissions at lower levels.”

6.2 Integration with Logging and Auditing

• In AWS, a common pattern is to create a log-archive account under Organizations and centralize logs such as:
  • CloudTrail
  • Config
  • Security-related logs
• In GCP, you’d prepare a log sink destination project, and forward logs from each project there. In Azure, you would create a central Log Analytics workspace and send Activity Logs and diagnostic logs to it.

6.3 A Cross-Cloud “Way of Thinking”

Across AWS, GCP, and Azure, you can design in the same pattern if you think in three steps:

• Place “company-wide rules” at the top node (Organization / Tenant / top Management Group).
• Use intermediate nodes (OU / Folder / Management Group) to represent department / system / environment.
• Use the billing unit (Account / Project / Subscription) to separate responsibility and budget.

7. Common Pitfalls and How to Avoid Them

7.1 Cramming “Everything into a Single Account” Before Moving to Organizations

• Problem:
  • VPC, IAM, tags, and naming conventions grow messy in one account.
  • When you finally decide to split accounts, migration costs explode.
• Avoidance:
  • Get into the habit of using Organizations + at least 2–3 accounts while you’re still small.
  • Similarly, on GCP, use multiple Projects from the start, and on Azure, multiple Subscriptions, treating that as “normal.”

7.2 Over-Tightening with SCP and Getting Stuck

• Problem:
  • If you say “let’s go ultra-secure” and slap Deny * all over the place in SCPs,
  • you’ll later find that essential services are blocked and have to do a massive redesign of SCPs.
• Avoidance:
  • Start with only the “blatantly dangerous actions” (root APIs, region restrictions, etc.) in SCPs.
  • In GCP / Azure, also roll out Org Policy / Azure Policy gradually, instead of enabling every rule across the board from day one.

7.3 Making OU Structure Too Close to the HR Org Chart

• Problem:
  • Every time HR reshuffles departments, you’re tempted to change OUs, Folders, or Management Groups.
  • Moving governance policies around becomes a nightmare.
• Avoidance:
  • Build your OU / Folder / Management Group structures around “responsibility & governance,” “system architecture,” and “environment (prod / nonprod)”, and keep the link to the HR org chart fairly loose.

8. How This Helps Each Target Reader

8.1 For Corporate IT / Central Cloud Owners

• As multiple departments and products start using AWS, a common question arises: “How should we split accounts to make management, auditing, and cost control easier?”
• By using AWS Organizations with a combination of security / shared / workloads OU structure + SCP + log-archive accounts, you can:
  • Let departments have freedom while ensuring “these minimum things are mandatory,” and
  • Centralize all account activity logs and billing in one place,
    enabling “practical governance” that strikes a balance between control and autonomy.

8.2 For SRE / Platform Engineers

• In tasks like “designing the landing zone” and “distributing secure baselines,” Organizations is a must-have piece.

• If you take the patterns in this article and codify them via IaC:

  • OU structure
  • Account roles and responsibilities
  • SCP templates
  • Log aggregation patterns

  you can roll out new products and teams quickly using the same blueprint.

8.3 For Security and Governance Staff

• SCP / Org Policy / Azure Policy let you implement “what our company must never do in the cloud” not only as documents but as technical guardrails.

• If you set:

  • root user restrictions
  • region restrictions
  • mandatory logging

  as SCPs at the Organizations level and replicate the same rules into GCP / Azure, you can maintain consistent multi-cloud compliance more easily.

8.4 For Startup CTOs and Tech Leads

• In the very early stage, it’s tempting to say “let’s just do everything in one account,” but splitting later is extremely painful.

• If you adopt the “5-account structure” from the start, you’ll have the room to support:

  • Explanations to investors and audits
  • Adding new products
  • Overseas expansion

  with much smoother transitions.

9. Three Steps You Can Start Today

1. Inventory your current accounts / projects / subscriptions.
   • Write down “what each environment is for,” “who is responsible,” and “where logs and billing go.”
2. Map them into the “5-account (or 5 project / subscription) model.”
   • Assign them to security / shared / prod / nonprod / management and identify any gaps.
3. Create a minimal hierarchy in Organizations (or GCP Org, Azure Management Groups).
   • Don’t aim for perfection at first—just creating OUs / Folders / Management Groups such as security / shared / workloads directly under Root already brings a lot of clarity.

10. Summary: Split Accounts by “Responsibility & Governance”, Not by the Org Chart

AWS Organizations is more than just a service to bundle accounts. It is:

• A framework for defining “templates” of account design,
• The foundation for laying organization-wide guardrails via SCPs, and
• A central point for aggregating logs, billing, and security.

GCP’s Resource Manager (Organization / Folder / Project) and Azure’s Management Groups + Subscriptions share the same purpose.
Rather than getting lost in the minor differences between clouds, focus on mastering this common mindset:

1. Put company-wide rules at the top level.
2. Use intermediate layers to represent departments, systems, and environments.
3. Use the billing unit (Account / Project / Subscription) to separate responsibility and budgets.

Once you have this “cross-cloud way of thinking,” the multi-cloud world becomes far less confusing.

In the next article, we’ll dive deeper into cloud design from the perspective of “where and how to run applications,” using ECS / EKS (container platforms closely tied to Organizations, IAM, and VPC) and comparing them with GCP (GKE / Cloud Run) and Azure (AKS / Container Apps).
Let’s gradually grow a cloud environment that is resilient and scalable together.

Reference Links (Official Docs in Japanese & English)

• What Is AWS Organizations? (User Guide)

• AWS Organizations Product Page (Cloud Management)

• AWS Organizations Explanation (Japanese, Black Belt slide deck)

• Google Cloud Resource Manager: Resource hierarchy

• Azure Management Groups / Subscriptions Overview

  • Management Groups Overview
  • Overview of Azure Subscriptions

※ For specific limits, the latest features, and pricing, always refer to each cloud provider’s official documentation and pricing pages.