トップ > AWS Control Tower > 【マルチアカウント設計】AWS Organizations / AWS Control Tower 導入前に整理すべきポイント

【マルチアカウント設計】AWS Organizations / AWS Control Tower 導入前に整理すべきポイント

AWS Control Tower AWS Organizations マルチアカウント
記事タイトルとURLをコピーする

本記事では、AWS のマルチアカウント設計を考える必要がある方向けの記事になります。

こんにちは！クロスインダストリー第1本部 の日高です。
今回は、マルチアカウント設計を進めるうえでの「設計観点」について、まとめてみたいと思います。

あくまで本記事で紹介するのは“自分なりの分解の仕方・考え方”の共有にはなりますが、設計観点の整理に悩んでいる方のヒントになれば幸いです。

はじめに

AWS のマルチアカウント設計を実施していく上で、AWS Organizations や AWS Control Tower はマルチアカウント環境を効率的に管理するための非常に有用なサービスです。
ガバナンスの強化や運用の標準化を目的に、多くの企業が導入を実施・検討しています。

一方で、これらのサービスを導入する前に、必ず整理しておきたいテーマがあります。
それが「マルチアカウント設計の考え方」です。

たとえば、次のような観点です。

  • どの単位でアカウントを分けるのか
  • どこまで統制を強くかけるのか
  • 誰が何を管理するのか
  • 将来の拡張をどのように見据えるのか

これらを十分に整理しないまま導入を進めてしまうと、次のような状況につながることもあります。

  • 想定以上に統制が強くなり、現場が動きづらくなる
  • 自社の方針や文化とのギャップに、後から気づく
  • なぜその設計にしたのかをうまく説明できない

ツール自体は正しくても、「なぜその構成にしたのか」という設計の背景が曖昧だと、組織全体の納得感や持続性に影響が出ます。

そのため本記事では、マルチアカウント設計をどのような観点で整理すべきかについてまとめていきます。

マルチアカウントが推奨される背景

マルチアカウント設計を進める上で、前提として「なぜ AWS はマルチアカウントを推奨しているのか？」も整理しておきましょう。

docs.aws.amazon.com

上記のAWS の公式ドキュメント「Organizing Your AWS Environment Using Multiple Accounts」 では、マルチアカウント戦略はクラウド基盤の“土台”であると述べられています 。

その理由は、大きく次の5点に集約できると考えています。

1. セキュリティ境界を明確にできる

  • AWS アカウントは分離境界として利用することで、IAM だけに依存しない、シンプルな境界設計が可能になります。
  • 以下の性質 / 分離の例
    • アカウント間はデフォルトでアクセス不可
    • 明示的に許可しない限りリソース共有は発生しない
    • 本番と非本番を物理的に分離できる

2. 影響範囲を限定できる

  • 単一アカウントにすべてのワークロードを配置した場合、次のような事象が全体に波及します。
    • 誤操作
    • 権限設定ミス
    • セキュリティインシデント
    • クォータ枯渇
  • マルチアカウント構成を取ることにより、問題の影響範囲をアカウント単位で封じ込めることができます。

3. 組織・責任構造と整合できる

  • ホワイトペーパーでも、ワークロードをビジネス目的や所有単位で分離することが推奨されています 。
  • 技術構成と組織構造を揃えることで、以下のようなメリットを享受できます。
    • 責任主体を明確化できる
    • 変更権限を整理できる

4. コストとクォータを管理しやすい

  • AWS の課金や Service Quotas はアカウント単位が基本です。
  • そのためアカウントを分ることにより以下が自然に行えることになります。
    • 事業別の原価管理
    • クォータ枯渇の影響分散
    • スケール前提の構造化

5. 運用モデルの違いに対応できる

  • 組織によって、AWS 運用の形は異なります。
  • マルチアカウント構成にすることで、統制を中央に置く部分と、各チームに委譲する部分を整理しやすくなります。

まとめると、マルチアカウントが推奨される理由は、上記で紹介したようなクラウド基盤の“設計原則”そのものに直結しているためです。
では次に、こうした前提を踏まえたうえで、マルチアカウント設計をどの観点で整理すべきかを見ていきましょう。

マルチアカウント設計の整理観点 全体像

本記事ではマルチアカウント設計を、以下示すように 4 つのレイヤーに分けて整理していこうと思います。

① 役割を決める ―どんな AWS アカウントを作っていくか？

まず整理すべきは、「AWS 利用において、どんな AWS アカウントが必要か」という問いです。
ここが曖昧なまま後続の設計を進めていくと、後から手戻りになってしまいます。

② 形を決める ― どう並べるのか？

必要な AWS アカウントが決まったら、それをどう構造化するかを考えます。
ここで初めて AWS Organizations - OU 設計の話になります。

OU は単なるフォルダではなく、統制単位です。
どの単位で制御をかけたいのかを意識して構成を決めていきます。

③ ルールを決める ― 構成の中で、何を許す/許さないか？

構成が決まったら、その上に統制を設計します。
ここで初めて、SCP / Control Tower のコントロール / AWS Config / AWS Security Hub といった具体的な実装手段が意味を持ちます。

④ 運用を決める ― 誰がどう運用するのか？

最後に決めるのは、この仕組みを誰がどう運用するのか？です。
以下のような観点について整理します。

  • アカウント払い出しのプロセス
  • 初期設定の標準化
  • 例外管理
  • 定期レビュー

マルチアカウント設計は構造設計で終わりではありません。
継続的に破綻しない運用モデルを作ることが必要です。

役割を決める

マルチアカウント設計の最初のステップは、「どんな役割の AWS アカウントを作るのか」を決めることです。
全体像の図では、最も左側に位置している工程です。

AWS アカウントの分類

マルチアカウント設計を整理するうえで、まず押さえておきたいのが「アカウントの役割の違い」です。
これからアカウントを、個別アカウントと共通アカウントの2種類に大別して設計を考えていきます。

個別アカウントとは...

  • 個別アカウントとは、実際にワークロードを動かすためのアカウントです。
  • アプリケーションやシステムが稼働し、事業価値を直接生み出す場所がここに該当します。
  • 例えば、次のようなものです。
    • 顧客向けサービスの本番環境
    • 社内基幹システム
    • データ分析基盤
  • ここでは EC2、RDS、Lambda、EKS などのリソースが稼働し、ユーザーや業務に直接影響を与えます。

共通アカウントとは...

  • 共通アカウントはワークロードを直接動かすためのものではありません。組織全体を支えるための役割を持つアカウントです。
  • 具体的には、次のような機能を担います。
    • 組織全体の統制（Organizations 管理や SCP 適用など）
    • セキュリティ監視・脅威検知
    • 監査ログの保管・証跡管理
    • 共通ネットワークや認証基盤の提供
    • CI/CD などの横断的な基盤機能
  • これらは「ビジネスを直接動かす機能」ではなく、「ビジネスを安全かつ継続的に動かすための機能」です。
  • 共通アカウントを分離する最大の理由は、統制機能と統制される側を分けるためです。
  • もしセキュリティ監視やログ保管がワークロードと同じアカウントに存在すると、不正アクセスや誤操作が発生した場合に証跡が消されたり、監視機能そのものが無効化されたりするリスクがあります。
  • そのため、複数のワークロードを跨ぐ横断機能は、ワークロードから分離して配置するのが基本思想になります。

個別アカウントの設計

個別アカウントの設計で最初に考えるべき問いは、「どの単位でビジネスを分離するか？」 です。
言い換えると、どこまでを1つの責任範囲とするのか/ どこまでの影響を許容するのかを決める工程です。

個別アカウントは、事業価値を直接生み出す場所であるため、その分割単位は組織の統制思想やリスク許容度と直結します。

よくある分割パターン

個別アカウントの分割には、代表的に次のようなパターンがあります。

  • 環境単位で分割（本番 / 開発 / 検証）
  • システム単位で分割（System A / System B）
  • システム × 環境で分割

分割を考える際の整理軸

個別アカウントをどのように分けるかを検討する際は、次の観点で整理すると分かりやすくなります。

  • 統制強度：本番環境と開発環境をどの程度明確に分離したいか。本番のみ厳格な統制をかけるのか、非本番も同等に管理するのか。
  • 影響範囲：誤操作や障害が発生した際に、どこまで波及してもよいか。
  • データ機密度：個人情報や機密データを扱うかどうか。
  • コスト管理：事業単位・部門単位で原価を明確にしたいか。

これらの観点を整理せずに「とりあえず環境で分ける」「とりあえずシステムで分ける」と進めてしまうと、後から統制や責任分界で悩むことになります。

推奨

個別アカウントの分割方法には複数の選択肢がありますが、それぞれ得意・不得意があります。
先に整理軸（統制強度・影響範囲・機密度・コスト管理）に当てはめて比較してみましょう。

分割パターン 統制強度（Prod保護） 影響範囲の限定 機密度管理 コスト管理 特徴
環境単位（Prod / Dev） ◎ 環境ごとの統制は明確 △ 同一環境内で複数システムが影響し合う △ 本番/開発は分かれるが、システム単位での分離は弱い △ システム別の可視化が難しい 環境軸は強いが、ビジネス分離が弱い
システム単位（System A / B） △ 同一アカウント内にProd/Devが混在しやすい ○ システム間は分離できる △ 環境差を表現しにくい ◎ 事業単位で明確 ビジネス軸は強いが、環境分離が弱い
システム × 環境 ◎ 環境ごとに統制強度を設計可能 ◎ システム単位・環境単位の両方で限定 ◎ 本番のみ厳格管理が可能 ◎ システム単位で可視化可能 統制軸とビジネス軸を両立できる

このように整理すると、以下の違いが見えてきます。

  • 環境単位で分割 → 統制軸は強いが、ビジネス分離が弱い
  • システム単位で分割 → ビジネス軸は強いが、本番保護が弱い
  • システム × 環境 → 両方を満たせる

そのため、「統制強度」「影響範囲」「機密度」「コスト管理」といった複数の整理軸を同時に満たしやすい構造として、多くの企業にとって システム × 環境分割がバランスの良い出発点 になります。

共通アカウントの設計

個別アカウントで「ビジネスをどう分離するか」を決めたら、次に考えるのが「それらをどう支えるか」 です。
ここで設計するのが、共通アカウントです。

共通アカウントはワークロードを動かす場所ではなく、組織全体を横断して支えるための基盤として利用します。

共通アカウントの整理軸

共通アカウントを設計する際は、次の問いに「Yes」が多い機能を切り出します。

  • この機能は複数システムで共通利用されるか？
  • 統制の独立性を保つ必要があるか？
  • 侵害時にも影響を受けない場所に置くべきか？

これらに該当する機能は、個別アカウントではなく共通アカウント側に分離するのが基本です。
共通アカウントとしてどこまで独立させるかは企業ごとに異なりますが、多くの場合、横断機能は大きく 4つの役割 に整理できると考えています。

統制する役割 ― 組織全体をコントロールする中枢

AWS 環境全体のルールを決め、適用し、管理する役割です。
いわば“司令塔”にあたります。（代表例：管理アカウント）

以下のような役割を担います。

  • Organizations管理
  • SCP適用
  • アカウント払い出し管理
守る役割　― セキュリティを横断的に監視・防御する

各アカウントを横断して脅威を検知し、インシデントに対応する役割です。
“監視センター”のような位置づけです。（代表例：セキュリティアカウント）

以下のような役割を担います。

  • GuardDuty の集約
  • Security Hub の統合管理
  • 脅威通知・インシデント対応
  • セキュリティ分析
記録する役割　― 証跡を安全に保管する場所

監査や調査に備えて、ログを改ざんされない形で保管する役割です。
“監査証跡の保管庫”にあたります。（代表例：ログ保管アカウント）

以下のような役割を担います。

  • CloudTrail集約
  • AWS Configログ保管
  • 改ざん防止ストレージ
支える役割　― ワークロードを横断的に支える共通基盤

個別アカウントが安全かつ効率的に動くための共通機能を提供する役割です。
“基盤チーム”のような位置づけです。

  • 認証・認可基盤（IAM Identity Center）
  • 共通ネットワーク（Transit Gateway 等）
  • CI/CD基盤
  • 運用管理基盤

形を決める

役割が決まったら、次に考えるのは「それらをどう並べるか？」 です。
全体像の図では、左側から２番目に位置している工程です。

この章では、作成したアカウント群を、どの構造で束ねるのかを決めます。
要するに、ここで決まるのが、AWS Organizations における OU（Organizational Unit）構成です。

前提

最初にお伝えしたいのは、特別な要件がない限り（※）は「いきなりオリジナル設計をしないこと」です。
AWS は公式ドキュメントを通じて標準的な OU 構成のベストプラクティスを提示しています。

まずはそれを基準にし、以下を整理するほうが合理的です。

  • どこが自社に合うのか
  • どこが過剰なのか
  • どこが不足しているのか

設計観点はこれから説明しますが、ゼロベースではなく、標準を起点に考える方が効率的かと思います。

※PCI DSS などの基準への対応が必要の場合はその基準に沿ったOU構成に考えていきます。PCI DSSの推奨OU構成は、以下のブログで解説しているので気になる方は参照ください。

blog.serverworks.co.jp

推奨 OU 構成（ベストプラクティス）

AWS の公式ドキュメント Organizing Your AWS Environment Using Multiple Accounts では、OU を 利用目的ごとに整理する構成が紹介されています。

この構成では、OU を大きく次の5つのカテゴリに分けています。

  • Foundational OUs（共通基盤）
  • Application OUs（ワークロード）
  • Experimental OUs（実験環境）
  • Procedural OUs（運用管理）
  • Advanced OUs（特殊用途）

ここではそれぞれの OU が なぜ存在するのか / どんな用途で使うのか を整理します。

※弊社佐竹のブログで推奨OU構成については詳しく解説されているので本ブログでは、各OUの概要の紹介をしていきます。

blog.serverworks.co.jp

Foundational OUs

組織全体を支える 共通基盤のアカウントを配置する OU です。
ここにはワークロードは配置せず、環境全体の統制と基盤機能を集約します。

セキュリティ機能やネットワーク基盤など、複数のアカウントを横断して利用される機能がここに配置されます。

2階層目のOU

OU 役割 利用用途
Security OU セキュリティ統制 GuardDuty・Security Hub・脅威検知
Infrastructure OU 共通基盤 ネットワーク・認証基盤・CI/CD

これらをワークロードから分離する理由は、統制機能の独立性を保つためです。

例えばログやセキュリティ監視がワークロードと同じアカウントにある場合、攻撃者がそれらを無効化できてしまう可能性があります。
そのため、セキュリティや基盤は 独立OUに配置する設計が推奨されています。

Application OUs

Application OU は 実際にビジネスシステムが稼働する OU です。
ここには実際に稼働するシステムが配置されます。

OU 役割 利用用途
Workloads OU ワークロード ビジネスシステム

この OU の特徴は「事業価値を生み出すアカウントが配置される場所」であることです。
つまり、「役割を決める」の箇所で決めた「個別アカウント」がここに配置されます。

Experimental OUs

Experimental OU は 実験用途の環境を配置する OU です。

OU 役割 利用用途
Sandbox OU 実験環境 PoC・新サービス検証・学習

Sandbox は、以下の用途などに利用されます。

  • 新サービスの検証
  • エンジニアの学習
  • PoC

実験環境は誤設定やコスト増加が起きやすいため、本番環境と完全に分離して管理することが重要です。

Procedural OUs

Procedural OU は アカウントの状態管理を目的とした OU です。
これは「業務用途」ではなく、運用状態に応じてアカウントを管理するための OUになります。

OU 役割 利用用途
Exceptions OU 例外管理 特殊なポリシーが必要なアカウント
Transitional OU 移行管理 移管・再構築中のアカウント
Suspended OU 停止管理 利用停止したアカウント
Policy Staging OU ポリシーテスト SCPなど統制ポリシーの検証

これらの OU を用意することで、以下が可能になります。

  • 例外環境の隔離
  • 移管作業の管理
  • 統制ポリシーの安全な検証

Advanced OUs

Advanced OU は 組織の規模や運用モデルに応じて追加される OUです。
必須ではありませんが、大規模環境ではたまに利用されます。

OU 役割 利用用途
Individual Business Users OU 個人利用 個人開発環境
Deployments OU デプロイ基盤 CI/CD
Business Continuity OU 災害対策 DR環境

例えば Business Continuity OU では、災害対策用の環境を本番環境と分離して管理します。
これにより以下を実現できます。

  • 障害時の切り替え
  • 災害対策
  • リスク分散

推奨OU構成から自社へのカスタマイズ方法

ここまで紹介してきた OU 構成は、AWS が提示している ベストプラクティスの一例です。
ただし、この構成を そのまま自社に適用する必要はありません。

なぜなら、マルチアカウント構成は次の要素に強く依存するためです。

  • 組織構造
  • 統制ポリシー
  • システム規模
  • セキュリティ要件
  • 運用体制

そのため実際の設計では、ベストプラクティスをベースに自社環境へカスタマイズするという考え方が重要になります。
カスタマイズを行う際は、次の順番で整理するとスムーズです。

  1. 標準OU構成を前提にする
  2. 自社に不要なものを削る
  3. 統合できるものをまとめる
  4. 特殊要件のみ追加する

標準OU構成を前提にする

まずは AWS が提示している 標準 OU 構成をベースラインとして理解することが重要です。
この構成には、AWS の多くの顧客環境で共通して現れる設計思想が反映されています。

このような設計思想を理解せずに独自構成を作ってしまうと、統制設計が破綻したり、後から大きな手戻りが発生する可能性があります。
そのため最初のステップでは、「この OU 構成がなぜ存在するのか」を理解することが重要です。

自社に不要なものを削る

次に、自社環境にとって 過剰な OU を整理します。
AWS の推奨構成は、さまざまな企業に適用できるようやや広めの設計になっています。

しかし以下のようなケースではすべての OU を使う必要はありません。

  • 小規模組織
  • システム数が少ない環境
  • 統制要件がシンプルな環境

例えば以下です。

OU 不要になるケース
Advanced OU 小規模組織
Policy Staging OU 統制変更が少ない環境
Individual Users OU 個人アカウント運用をしない場合

このように 自社に不要な OU を削減していきます。

統合できるものをまとめる

逆に、役割が近い OU は 統合することも可能です。（統合しすぎると責任範囲が大きくなるため留意すること）
例えば次のようなケースです。

元のOU 統合例
Exceptions OU + Transitional OU Operations OU

特殊要件のみ追加する

最後に、自社固有の要件に応じて OU を追加します。
例えば次のようなケースです。

追加OU 目的
Customer OU 顧客専用環境
Data OU データ分析基盤

このステップは最後に行うことが重要です。
最初から独自OUを大量に追加してしまうと、構造が複雑になる / 統制が設計しづらくなる という問題が発生します。

カスタマイズ例

ここまで紹介した考え方をもとに、推奨 OU 構成をベースに 一般的な企業環境で利用される構成例を整理してみました。
参考がてらご利用ください。

OU構成を設計する6つの問い（整理軸）

OU構成を設計する際は、次の6つの問いを整理しながら検討すると、設計の方向性を整理しやすくなります。
基本的には、前章で紹介した 「推奨OU構成から自社へのカスタマイズ方法」 の手順に沿って整理することで、多くのケースは対応できます。

ただし、組織の統制方針や既存環境の制約などにより、標準的な構成をそのまま適用できない場合もあります。

そのような場合には、以下に示す整理軸を参考にしながら、「どの単位でアカウントを整理し、どこに統制を適用するのか」 を検討して行っていただければと思います。

整理軸（問い） 検討ポイント 設計で決まること
トップレベルの分類をどうするか 統制思想の違い / 統制強度の違い / ワークロードの種類 Root直下のOU構造
共通アカウントをどこに配置するか 横断責務を持つアカウントの配置場所 基盤OU（Security / Infrastructureなど）
個別アカウントをどの単位でまとめるか ビジネス分離（システム単位） / 統制強度（Prod / NonProd） Workloads OU構造
例外・移管・停止アカウントをどう扱うか 運用状態でアカウントを管理する必要性 Exceptions / Transitional / Suspended OU
依存関係が逆転していないか 本番が非本番に依存していないか / 基盤がワークロードに依存していないか OU構造の健全性
将来拡張に耐えられる構造か 新規事業追加 / 組織変更 / システム増加への対応 OUの拡張性

ルールを決める

次に設計するのが、「何を許可し、何を許可しないのか」というルールです。
全体像の図では、左側から 3 番目に位置している工程です。

この章では、マルチアカウント環境における統制を 次の2つの観点から整理します。

統制の種類 目的 概要
予防的統制 問題が起きないように事前に防ぐ セキュリティインシデントの原因となる問題を取り除く、もしくは、軽減させるための対策です。
例えば、権限分離によってユーザーが利用できる機能を制限する、というような統制を指します。
発見的統制 問題が起きたときに検知する セキュリティに関わるイベントが発生した際に、問題の早期検知と記録を行い、進行中のインシデントに対して関係者にアラートをあげるような統制を指します。
例えば、不審な通信や通常とは異なるユーザーの異常な振る舞いがないかを分析し、アラートメールを送る、というようなものです。

セキュリティ対策において重要な原則の一つが 「多層防御（Defense in Depth）」 です。
これは、一つの防御策だけに依存するのではなく、複数の異なる対策を重ねることで、万一の際のリスクを低減する考え方です。

そのため、マルチアカウント環境の統制設計においても予防的統制・発見的統制の両方を組み合わせて設計することが重要になります。

これらの統制を実現するための AWS サービスは数多く存在しますが、サービスごとに設計観点が多く存在するため、特定のサービスを例に挙げながら 統制設計の考え方や設計の整理軸 に焦点を当てて整理していきます。

予防的統制をどう設計するか

予防的統制とは、「そもそも問題が起きる操作を実行できないようにする仕組み」です。
AWS では主に次のような仕組みで実装されます。

代表的な手段
Service Control Policy（SCP）
Control Tower コントロール
IAMポリシー

この中でも、マルチアカウント環境における統制の中核となるのが Service Control Policy（SCP）です。
そのため、本ブログでは、SCPをどのような観点で設計していくのかについて整理していきます。

※SCP以外のAWS Organizations におけるポリシーは以下の弊社ブログをご覧ください。

blog.serverworks.co.jp

ブラックリスト形式かホワイトリスト形式か？

まず決めるべきなのは、統制の基本方針（制御モデル）です。
つまり、「何を基準に操作を制御するのか」という考え方です。

一般的には次の2つのパターンがあります。

選択肢 内容
Denyベース（ブラックリスト型） 原則は許可し、危険な操作のみ拒否する
Allowリスト（ホワイトリスト型） 原則は拒否し、必要な操作のみ許可する

多くの環境では、Denyベースの設計が現実的な選択肢になります。
その理由は、AWSのサービスは継続的に追加・更新されるためです。

Allowリスト型で統制を設計した場合、新しいサービスやAPIが追加されるたびに 許可ポリシーの更新が必要になります。

その結果、次のような問題が発生しやすくなります。

  • 新サービスを利用するたびに SCP を更新する必要がある
  • 開発チームが新機能を利用できない状態が頻繁に発生する
  • SCP の運用負荷が大きくなる

このような理由から、実務では「原則許可し、危険な操作だけを禁止する」Denyベースで設計するケースが多くなります。

トップレベルで禁止する内容は何か？

次に考えるのは、組織全体で絶対に許可しない操作です。
これらは Root OU または最上位OU に適用される統制になります。

整理軸 例 目的
法規制 特定リージョン利用禁止 データ越境防止
監査要件 CloudTrail削除禁止 証跡保護
致命的リスク ルートユーザー操作制限 セキュリティ強化

例えば次のような制限が導入されます。

  • 未承認リージョンの利用禁止
  • CloudTrail / Config の削除禁止
  • IAM root の利用制限

これらは 全環境共通の安全装置として設計されます。

OUごとの制限は何か？

次に設計するのが、OU単位の統制レベルです。
これらは 各OU に適用される統制になります。OU設計のメリットの1つは、OUごとに統制強度を変えられることです。

設計では次のような観点で整理します。

整理軸 内容 例
環境の性質 環境ごとの役割 Prod / NonProd / Sandbox
統制強度 セキュリティレベル 高統制 / 標準 / 緩い
業務特性 ワークロードの種類 外部公開 / 社内システム
影響範囲 障害時の影響度 ミッションクリティカル
データ機密度 扱うデータの重要度 個人情報 / 機密情報

例えば、個人情報を扱うシステムを含む OU では、以下のようなより強い統制を設計するケースがあります。

  • IAM操作制限
  • データ削除制限
  • 特定サービスの利用制限

発見的統制をどう設計するか

予防的統制が「防ぐ」仕組みなら、発見的統制は異常に気づく仕組みです。
代表的なAWSサービスとしては次があります。

サービス
AWS Config
AWS Security Hub
Amazon GuardDuty
AWS CloudTrail

ただしここでは、個別サービスではなく検知設計の考え方を整理します。

状態検知をどう設計するか

状態検知とは、あるべき構成からの逸脱を検知する仕組みです。
設計では次の観点を整理します。

設計観点 内容
あるべき状態 セキュリティベースライン
検知対象 ネットワーク / IAM / ログ
適用単位 全体 / OU / アカウント
評価タイミング 継続評価 / 定期評価
逸脱時の対応 通知 / チケット / 自動修正

振る舞い検知をどう設計するか

振る舞い検知は、通常とは異なる操作を検知する仕組みです。
例えば以下のようなものが該当します。

  • 不審なAPI操作
  • 異常なアクセス
  • 異常なネットワーク通信

設計では次の観点を整理します。

設計観点 内容
異常定義 脅威モデル
検知対象 API / ネットワーク / IAM
適用単位 全体 / OU / アカウント
即時性 リアルタイム / 準リアルタイム
重大度 Severity分類
対応 通知 / 遮断

運用を決める

最後に整理するのが 「その仕組みをどう運用していくのか」 です。

クラウド環境の運用には以下のような様々な観点がありますが、本記事ではその中でもAWS Organizations / Control Tower を前提としたアカウント運用に焦点を当てて整理します。

  • コスト管理
  • セキュリティ運用
  • 監視運用

アカウント運用の整理観点

整理軸（SQ） 何を決めるか 主な運用内容
SQ1 アカウントのライフサイクル管理 アカウントをどのように作成・移管・廃止するか アカウント払い出しプロセス / 初期設定の標準化 / OU配置 / 移管時チェック / 停止・廃止手順 / 定期棚卸
SQ2 誰がどの権限で運用するか 運用責任と権限の分担 統制オーナー / セキュリティ責任者 / ワークロード責任者 / Delegated Administrator設計 / 職務分離（SoD）
SQ3 統制変更の管理 統制ルールの変更をどう管理するか SCP変更フロー / ガードレール追加・削除 / 例外申請フロー / 影響評価 / 承認プロセス / ポリシーバージョン管理
SQ4 発見結果への対応 検知した問題をどう対応するか アラート受付窓口 / チケット化ルール / 重大度定義 / 自動是正範囲 / インシデント対応 / 再発防止レビュー
SQ5 継続的改善 運用をどのように改善し続けるか 定期レビュー会 / 統制強度の見直し / OU構成の再設計判断 / ガバナンス成熟度評価

AWS Organizations / Control Tower の利用場面

最後に、これまで整理してきた内容を踏まえてAWS Organizations AWS Control Tower の利用場面について触れていきます。

これまでの章では、マルチアカウント設計を次の4つのステップで整理してきました。
それぞれのフェーズにおいて、Organizations と Control Tower は次のような役割を持ちます。

フェーズ Organizations の役割 Control Tower の役割
① 役割整理 マルチアカウント管理の基盤サービス（Organizations がないとマルチアカウント管理はできない） Organizations を前提として追加利用するガバナンスサービス
② 形の設計 OU構造を自由に設計する基盤 標準構成（Security / Log Archive Account）を一部提供
③ ルール設計 SCPによる予防的統制を設計 AWSが提供するコントロールにより予防的統制＋発見的統制を標準化
④ 運用設計 Organizations単体では運用機能はほぼ提供されない Account Factory によるアカウント払い出しやガバナンス設定の自動化

AWS Control Tower は内部的に AWS Organizations を利用して構築されたサービスです。
そのため、Organizations は マルチアカウント環境の基盤サービスであり、Control Tower はその上でガバナンス設定 / アカウント払い出し / セキュリティ統制などを 自動化・標準化するサービスと言えます。

AWS Control Tower の利用判断

AWS Control Tower の利用判断の目安としては以下かと考えています。

  • マルチアカウント環境を早期に標準化したい
  • Landing Zone をゼロから設計するリソースがない
  • 予防的統制だけでなく発見的統制も標準化したい
  • アカウント払い出しや統制運用を自動化したい

特に、次のようなニーズがある場合には Control Tower のメリットが大きくなります。

  • Account Factory によるアカウント払い出しの自動化
  • コントロール による統制の標準化

逆にControl Tower 導入が不要なケースは自由度を重視する場合です。
Control Tower は標準化された構成を前提とするため、自由度を重視する場合はOrganizations中心の設計が適しています。

  • マルチアカウント設計を自社で設計できる
  • OU構造や統制設計を自社で細かく設定していきたい（SCPを細かく設計したい）

まとめ

今回、マルチアカウント設計の整理観点についてまとめてみましたが、実際に書いてみるとかなりのボリュームになりました。
それだけ、マルチアカウント設計は検討すべき観点が多いテーマなのだと改めて感じました。

本記事で整理した内容が、これからマルチアカウント設計を進める方の参考になれば嬉しいです。

日高 僚太(執筆記事の一覧)

表彰：2024 Japan AWS Jr. Champions / Japan AWS Jr. Champions of the Year 2024 / 2024-2025 Japan AWS All Certifications Engineers / 2025 Japan AWS Top Engineers (Services)

クロスインダストリー第1本部所属。2022年IT未経験でSWXへ新卒入社。
記事に関するお問い合わせや修正依頼⇒ hidaka@serverworks.co.jp