AWS Organizations入門｜マルチアカウント管理とSES活用ガイド

「なぜAWSアカウントを1つで運用してはいけないのか？」——AWS案件に初めて参画するSESエンジニアが直面する最初の壁が、マルチアカウント管理の概念です。

AWS Organizationsは、複数のAWSアカウントを一元管理するサービスです。エンタープライズ案件では事実上必須のスキルであり、SESエンジニアの市場価値を大きく高める知識です。

この記事を3秒でまとめると

AWS Organizationsは複数AWSアカウントを組織単位（OU）で階層管理するサービス
SCP（サービスコントロールポリシー）でセキュリティガードレールを設定
エンタープライズSES案件では必須知識。コスト管理・ガバナンス・セキュリティの全てに関わる

AWS Organizationsとは？マルチアカウント管理の基本

まず、AWS Organizationsの基本概念と、なぜマルチアカウント管理が必要なのかを理解しましょう。

なぜマルチアカウントが必要なのか

AWSアカウントを1つで運用すると、以下のリスクがあります。

セキュリティリスク: 開発環境の設定ミスが本番環境に波及する
コスト管理の困難: どのプロジェクトがどれだけコストを使っているか把握できない
権限管理の複雑化: IAMポリシーが肥大化し、最小権限の原則が守れなくなる
サービスクォータ: 1アカウントのサービス制限にプロジェクト全体が影響される
コンプライアンス: 監査時にデータの分離を証明できない

マルチアカウント戦略は、これらの課題をアカウントという物理的な境界で解決するアプローチです。

組織単位（OU）の概念と設計

AWS Organizationsでは、アカウントを**組織単位（Organizational Unit: OU）**で階層的にグループ化します。

Root
├── Security OU
│   ├── ログアーカイブアカウント
│   └── セキュリティ監査アカウント
├── Infrastructure OU
│   ├── ネットワークアカウント
│   └── 共有サービスアカウント
├── Workloads OU
│   ├── Production OU
│   │   ├── プロジェクトA本番アカウント
│   │   └── プロジェクトB本番アカウント
│   └── Non-Production OU
│       ├── 開発アカウント
│       └── ステージングアカウント
└── Sandbox OU
    └── 検証アカウント

この階層構造により、OU単位でポリシーを適用し、効率的なガバナンスを実現できます。

AWS Organizationsのマルチアカウント構成

マルチアカウント戦略のベストプラクティス

AWSが公式に推奨するマルチアカウント戦略を見ていきます。

AWS推奨のアカウント構成パターン

AWSは「AWS Organizations のベストプラクティス」として以下のアカウント構成を推奨しています。

必須アカウント:

管理アカウント: Organizations全体の管理。ワークロードは配置しない
ログアーカイブアカウント: CloudTrail、Config、VPCフローログの集約先
セキュリティ監査アカウント: GuardDuty、Security Hub、IAM Access Analyzerの集約先

推奨アカウント: 4. ネットワークアカウント: Transit Gateway、Direct Connect、VPN接続の管理 5. 共有サービスアカウント: Active Directory、CI/CDパイプライン、共有リソース 6. ワークロードアカウント: プロジェクト・環境ごとに個別作成

本番・ステージング・開発の分離設計

環境分離は最も基本的なマルチアカウントのユースケースです。

環境	アカウント	目的	アクセス制限
Production	専用アカウント	本番ワークロード	最小限のアクセス
Staging	専用アカウント	リリース前検証	開発者は読み取りのみ
Development	専用アカウント	開発・テスト	開発者に広い権限
Sandbox	専用アカウント	技術検証	自由だがコスト上限あり

この分離により、「開発環境で試した設定変更が本番に影響する」という事故を構造的に防止できます。

ログ・セキュリティ専用アカウント

ログとセキュリティを専用アカウントに分離することのメリットは以下の通りです。

改ざん防止: ワークロードアカウントの管理者でもログを削除できない
統合監視: 全アカウントのセキュリティアラートを一箇所で確認
コンプライアンス: 監査人に最小限のアクセスでログを提供可能

AWS CloudTrailセキュリティ監査でログ管理の詳細を解説しています。

SCP（サービスコントロールポリシー）の活用

SCPはAWS Organizationsの最も強力な機能の一つです。OU単位でAWSサービスの使用を制限できます。

SCPの基本と記述方法

SCPはIAMポリシーに似たJSON形式で記述しますが、**「アカウント全体の上限」**を定義する点が異なります。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeaveOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    }
  ]
}

重要な原則: SCPは「許可」を与えるものではなく、「上限」を設定するものです。SCPで許可されていても、IAMポリシーで権限がなければ操作はできません。

よく使うSCPテンプレート5選

実務でよく使われるSCPテンプレートを紹介します。

リージョン制限: 東京リージョンとバージニアリージョン以外の使用を禁止
ルートユーザー制限: ルートユーザーのAPI操作を全面禁止（コンソールログインのみ許可）
セキュリティサービス保護: GuardDuty、CloudTrail、Configの無効化を禁止
高額サービス制限: p4d.24xlargeなどの高額インスタンスの起動を禁止
データ流出防止: S3バケットのパブリックアクセスを組織全体で禁止

ガードレールとしてのSCP設計

SCPの設計アプローチは2種類あります。

ブロックリスト方式: デフォルトで全て許可し、危険な操作のみ禁止（運用が楽だがリスクあり）
許可リスト方式: デフォルトで全て禁止し、必要な操作のみ許可（安全だが運用コスト大）

実務ではブロックリスト方式をベースに、重要なセキュリティ操作を禁止するアプローチが一般的です。AWS IAMセキュリティガイドで権限管理の詳細を解説しています。

AWS Control Towerとの連携

AWS Control Towerは、マルチアカウント環境のセットアップと継続的なガバナンスを自動化するサービスです。

Control Towerによるランディングゾーン構築

Control Towerを使うと、以下が自動的にセットアップされます。

OU構造: Security OUとSandbox OUの自動作成
必須アカウント: ログアーカイブアカウントと監査アカウントの自動作成
ガードレール: 必須・推奨のSCPが自動適用
SSO設定: AWS IAM Identity Center（旧AWS SSO）の初期設定

自動化されたガバナンス管理

Control Towerは「ガードレール」と呼ばれる事前定義済みのポリシーを提供します。

必須ガードレール: CloudTrailの有効化、ログバケットの暗号化など（無効化不可）
強く推奨されるガードレール: ルートユーザーのMFA有効化、S3バケットの暗号化など
選択的ガードレール: リージョン制限、特定サービスの使用制限など

マルチアカウント環境のコスト管理

マルチアカウント環境でのコスト管理は、単一アカウントよりも複雑ですが、適切に設計すればより精緻な管理が可能になります。

一括請求（Consolidated Billing）の仕組み

AWS Organizationsでは、全アカウントの請求が管理アカウントに集約されます。

メリット:

ボリュームディスカウント: 全アカウントの使用量が合算され、より高い割引ティアが適用
RIとSavings Plansの共有: 1つのアカウントで購入したRIを組織全体で共有可能
無料利用枠の共有: S3やLambdaの無料枠を組織単位で活用

コスト配分タグ戦略

マルチアカウント環境でのコスト分析には、タグ戦略が不可欠です。

推奨するタグ体系:

aws:cost-center: "project-a"
aws:environment: "production"
aws:team: "backend"
aws:owner: "[email protected]"

SCP で「必須タグなしのリソース作成を禁止」するポリシーを設定することで、タグ付け忘れを防止できます。コスト最適化の詳細はAWS FinOpsコスト最適化を参照してください。

SES案件で求められるAWS Organizations実務スキル

SES案件でAWS Organizationsのスキルが求められるシーンを具体的に紹介します。

新規環境構築: エンタープライズ案件でのランディングゾーン構築。Control Tower + Organizationsのセットアップ
セキュリティ設計: SCPの設計・実装・テスト。セキュリティチームとの連携
コスト管理: 部門別・プロジェクト別のコスト集計基盤の構築
運用改善: 既存のマルチアカウント環境のガバナンス強化

これらのスキルを持つエンジニアの月単価は65〜85万円と高水準です。AWS SESエンジニアガイドでAWSスキルのキャリアパスを確認できます。

まとめ：マルチアカウント管理はAWSの必須スキル

AWS Organizationsとマルチアカウント管理について振り返ります。

基本概念: アカウントを物理的な境界として、セキュリティ・コスト・ガバナンスの課題を解決
SCP: OU単位でサービス使用を制限するガードレール。ブロックリスト方式が実用的
Control Tower: マルチアカウント環境のセットアップとガバナンスを自動化
コスト管理: 一括請求とタグ戦略で精緻なコスト配分を実現

AWSのWell-Architectedフレームワークでも、マルチアカウント戦略はセキュリティの柱における基本原則として位置づけられています。

2026年現在、エンタープライズのAWS案件でマルチアカウント管理は当たり前のスキルです。SESエンジニアとしてAWS案件のレベルアップを目指すなら、Organizations + Control Tower + SCPの3点セットは確実に押さえておきましょう。

AWSシリーズの他の記事も読む

👉 AWS Well-Architectedガイド 👉 AWS IAMセキュリティガイド 👉 SES BASEで案件を探す