Multi-Account Cloud Security — AWS Organizations, Azure Management Groups & GCP Folders Guide

In this tutorial, you'll learn about Multi. We cover key concepts, practical examples, and best practices to help you understand and apply this topic effectively.

Multi-account Cloud Security uses hierarchical management structures like AWS Organizations, Azure management groups, and GCP folders to apply centralized security policies, isolate workloads, and enforce Compliance boundaries across multiple accounts.

What You Will Learn

How to design a multi-account architecture, apply organization-wide guardrails, and delegate administration while maintaining centralized security visibility.

Why It Matters

A single account or subscription cannot scale securely. Multi-account architectures provide Blast Radius isolation, workload segmentation, and clear ownership boundaries. Proper security policy enforcement at the organization level prevents misconfigurations across hundreds of accounts.

Real-World Use

DodaTech runs 200 AWS accounts organized into organizational units for production, staging, development, and security. Service control policies prevent production accounts from using non-approved regions and enforce encryption on all S3 buckets. Security Hub aggregates findings across all accounts.

Multi-Account Hierarchy

flowchart TD
  Root[Organization Root] --> OU_Security[OU: Security\nAudit Account\nLog Archive]
  Root --> OU_Workloads[OU: Workloads]
  Root --> OU_Sandbox[OU: Sandbox]
  
  OU_Workloads --> OU_Prod[OU: Production]
  OU_Workloads --> OU_Staging[OU: Staging]
  
  OU_Prod --> Account_Prod1[Account: App-1]
  OU_Prod --> Account_Prod2[Account: App-2]
  OU_Staging --> Account_Stg1[Account: App-1-Staging]
  
  SCP[Service Control Policy] -.->|Applies to| OU_Workloads
  SCP2[SCP: Deny Non-US Regions] -.->|Applies to| OU_Prod
  
  style Root fill:#f90,color:#fff
  style SCP fill:#390,color:#fff

AWS Organizations

AWS Organizations lets you group accounts into organizational units and apply service control policies that restrict what member accounts can do.

# Create an organization
aws organizations create-organization \
  --feature-set ALL

# Create organizational units
aws organizations create-organizational-unit \
  --parent-id r-1234 \
  --name Production

aws organizations create-organizational-unit \
  --parent-id r-1234 \
  --name Staging

# Create a service control policy that denies non-US regions
aws organizations create-policy \
  --name "DenyNonUSRegions" \
  --description "Block all AWS regions outside US" \
  --type SERVICE_CONTROL_POLICY \
  --content '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["us-east-1", "us-west-2"]
        }
      }
    }]
  }'

# Attach SCP to the Production OU
aws organizations attach-policy \
  --policy-id p-scp12345 \
  --target-id ou-prod-12345678

# List accounts in the organization
aws organizations list-accounts \
  --query 'Accounts[*].[Name,Id,Status]' \
  --output table
# Output:
# ----------------------------------------
# | Name        | Id              | Status |
# | audit-account | 123456789012 | ACTIVE |
# | prod-app-1  | 234567890123   | ACTIVE |
# | prod-app-2  | 345678901234   | ACTIVE |
# ----------------------------------------

Azure Management Groups

Management groups organize subscriptions into a hierarchy for applying Azure Policy and RBAC at scale.

# Create a management group hierarchy
az account management-group create --name dodatech --display-name "DodaTech"
az account management-group create --name dodatech-production --parent dodatech --display-name "Production"
az account management-group create --name dodatech-nonprod --parent dodatech --display-name "Non-Production"

# Assign a policy to the Production management group
az policy assignment create \
  --name "DenyPublicStorage" \
  --display-name "Deny public storage accounts" \
  --policy /providers/Microsoft.Authorization/policyDefinitions/... \
  --scope /providers/Microsoft.Management/managementGroups/dodatech-production

# Move a subscription under a management group
az account management-group subscription add \
  --management-group dodatech-production \
  --subscription 12345678-1234-1234-1234-123456789012

# View management group hierarchy
az account management-group show \
  --name dodatech \
  --expand \
  --query "{Name:displayName, Children:children[].{Name:displayName, Type:type}}"
# Output:
# {
#   "Name": "DodaTech",
#   "Children": [
#     {"Name": "Production", "Type": "/subscriptions"}, "#     {"Name": "Non-Production"", "Type": "/subscriptions"}
#   ]
# }

GCP Folders and Organization Policies

GCP folders create a hierarchy under the organization node. Organization policies enforce constraints on all projects in a folder.

# Create a folder structure
gcloud resource-manager folders create \
  --display-name="Production" \
  --organization=123456789012

FOLDER_ID=987654321098

gcloud resource-manager folders create \
  --display-name="Staging" \
  --folder=$FOLDER_ID

# Set an organization policy to restrict VM external IPs
gcloud resource-manager org-policies set-policy \
  --organization=123456789012 \
  --policy-file='{
    "constraint": "constraints/compute.vmExternalIpAccess",
    "listPolicy": {"deniedValues": ["0.0.0.0/0"]}
  }'

# Move a project into a folder
gcloud projects add-iam-policy-binding my-project \
  --member="user:admin@dodatech.com" \
  --role="roles/resourcemanager.projectMover"
gcloud projects move my-project \
  --organization=123456789012 \
  --folder=$FOLDER_ID

Centralized Logging and Security

Each multi-account architecture should include dedicated security accounts for log aggregation, security tooling, and audit.

Common Mistakes

1. No SCP or organization policy guardrails: Without guardrails at the root or organization level, individual teams can bypass security controls by creating resources in non-compliant configurations.
2. Flat account structure: Untiered accounts with no hierarchy make policy application impossible at scale. Use OUs, management groups, and folders.
3. No dedicated security account: Security tools like SIEM, CSPM, and logging should live in a separate security account with restricted access.
4. Overly permissive SCPs: An SCP that allows everything but a few denials does not prevent misconfiguration. Use allow-list SCPs that only permit approved services and regions.
5. Not testing SCPs before production: A misconfigured SCP can block critical infrastructure. Test in a sandbox OU first.

Practice Questions

1. What is the difference between AWS SCPs and IAM policies?
2. How do Azure management groups enable policy inheritance?
3. What is the role of GCP organization policies in multi-project governance?
4. Why should a dedicated security account be separate from workload accounts?
5. How does OU hierarchy affect SCP application in AWS?

Challenge

Design a multi-account architecture for a company with three product lines. Each product line has development, staging, and production environments. Use AWS Organizations with OUs for each product line and environment. Apply SCPs that deny non-US regions for production OUs, enforce encryption, and require CloudTrail in every account. Create a dedicated security account with centralized logging. Write the AWS CLI commands to create the hierarchy, SCPs, and log archive.

FAQ