現場実践｜AWS Organizations設計

AWS OrganizationsとSCP設計｜マルチアカウント戦略とサービスコントロールポリシーの実践

「AWSアカウントを複数管理したい」「各アカウントで特定のリージョンしか使えないように制限したい」——AWS Organizationsのマルチアカウント設計・OU（組織単位）の構成・Service Control Policy（SCP）の実践を解説します。

読了目安：約18分更新日：2026年4月

💡 AWS Organizationsはマルチアカウント環境の統合管理サービス。SCPでアカウント横断のガードレールを設定することで「誤操作による意図しないリソース作成」を組織全体で防ぐことができます。

この記事を書いた人

現役ITエンジニア・IT講師（経験14年）

CCNA・CCNP 取得LPIC-1 保有SES現場を複数経験

AWSマルチアカウント環境のOrganizations設計・SCP適用を複数の大規模案件で担当してきた立場から解説します。

1. マルチアカウント戦略のOU構成例

Root
├── Security（セキュリティ集中管理アカウント）
│   └── GuardDuty・CloudTrail・SecurityHub統合
├── Management（管理アカウント）
│   └── Billing・Cost Explorer・Organizations管理
├── Sandbox（開発者学習用）
│   └── 個人ごとのAWSアカウント。削除制限なし
├── Workloads
│   ├── Dev（開発環境）
│   ├── Staging（ステージング環境）
│   └── Prod（本番環境）
│       └── SCPで削除操作を制限
└── Shared Services
    └── ECR・Route53・DirectConnect共有アカウント

2. SCPの実践例

// 東京リージョン以外でのリソース作成を禁止するSCP
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "ap-northeast-1",  // 東京
            "us-east-1"  // バージニア（グローバルサービス用）
          ]
        }
      }
    }
  ]
}

3. SCPのよく使うユースケース

本番アカウントでのRDS削除禁止：「rds:DeleteDBInstance・rds:DeleteDBCluster」をDenyするSCPをProd OUに適用する
GuardDutyの無効化禁止：「guardduty:DeleteDetector」をDenyしてセキュリティ監視を組織全体で強制する
特定のインスタンスタイプ制限：コストコントロールのため「t3.nano〜t3.large以外のEC2は起動禁止」をSandboxアカウントに適用する

📌 この記事のポイント

OUはSecurity・Management・Sandbox・Workloads（Dev/Stg/Prod）・SharedServicesで分割するのが標準パターン
SCPはリージョン制限・RDS削除禁止・GuardDuty無効化禁止のガードレールとして組織全体に適用する
SCPはDenyで書く。ルートに適用すると管理アカウント以外の全アカウントに強制される強力な制御ツール