はじめに
私はSIerでアーキテクト／コンサルタントとして、複数のお客様とCCoEの立ち上げやAWSガバナンス設計を支援してきました。
AWS Organizations は、マルチアカウント戦略が一般化した現在では「使っていて当たり前」の存在になりつつありますが、設計段階で最初に悩むのが「本番・開発をOrganizationsレベルで分けるべきか」という問いです。
AWSのベストプラクティスでは、単一のOrganizationsに統合するのが最適とされています。私自身もそれがベストだと考えていましたが、実務の中であえて分離する判断をした現場もありました。本記事では、その設計判断と得られた学びを共有しようと思います。
本記事の前提条件
対象読者
- AWS Organizations をこれから導入、または設計を見直している方
- マルチアカウント構成を前提にガバナンス設計を考えている方
- 本番・開発の分離方針で悩んでいるアーキテクト、CCoEメンバー
- ベストプラクティスと現場事情のギャップに直面している方
AWSの基本的なサービスやAWS Organizationsの概念については
ある程度理解している前提で記載しています。
環境
- エンタープライズ
- 外部ベンダーの再販（リセール）モデルでAWSを利用
- AWSアカウント数は30~40程度
- 厳格な統制が求められる
- すでにある程度環境が出来上がっており、途中からjoinしマルチアカウント戦略を構想
「大規模環境」や「理想的なガバナンス」ではなく、
現実的な運用を前提とした設計判断の話です。
なぜ「1つのAWS Organizationsで統一する」のが一般的なのか
AWSのベストプラクティスや多くの事例では、以下の理由から
本番・開発を1つのAWS Organizationsで管理する構成が推奨されることが多いです。
- SCPやガードレールを一元管理できる
- 委任管理アカウントを1つに集約できる
- セキュリティサービスやログを横断的に集約しやすい
- 同じ設定を複数Organizationsで繰り返す必要がない
私自身も当初はこの考え方に強く同意しており、
「AWS Organizationsを分けるのは非効率で、例外的な対応」
という認識を持っていました。
【図1】本番・開発環境を一つのAWS Organizationsに統合
それでも本番・開発を分離する判断に至った理由
それでも最終的に、本番と開発でAWS Organizationsを分離する判断をしました。
理由は単一ではなく、複数の前提条件が重なった結果です。
【図2】本番・開発環境でAWS Organizationsを分離
① ID管理がすでに本番・開発で分離されていた
元々、IAMユーザーやグループは
本番・開発それぞれ専用の集約アカウントで管理されていました。
この状態でAWS Organizationsだけを統合しても、
運用上の分離は解消されず、
「技術的には統合されているが、実態は分かれている」
という中途半端な状態になります。
② 再販（リセール）モデルによる請求・契約の分離
本案件では、外部ベンダーの再販（リセール）モデルを利用しており、
請求および契約が本番・開発で異なっていました。
AWS Organizationsは「請求をまとめて管理する」こともメリットの一つですが、
すでにベンダーによって請求・契約がまとめられており、
本番・開発で契約や請求がすでに分離されている環境では、
AWS Organizationsも分けた方が全体として自然でした。
請求代行など外部ベンダーからAWSを利用している場合、
プランによってAWS Organizationsを利用できない場合があります。
利用可能かどうかはベンダーに確認してください。
③ 統一しても検証用AWS Organizationsは結局必要だった
AWS Organizationsでは、OUを分けることでSCPの検証や
権限制御の確認を行うことは可能です。
そのため必ずしもOrganizationsを分けなければ検証できない、というわけではありません。
一方で、Organizationsレベルでの設定を完全に本番から分離して検証したい場合、
単一のOrganizations内で完結させることには限界があります。
例えば、以下のようなケースです。
- AWS Control Tower の有効化・更新時の挙動確認
- ガードレール（予防・検知）の影響範囲の検証
- 委任管理アカウントを利用したサービスの管理設定の確認
- Organizations全体に影響する設定変更の事前検証
これらはOUを分けていても、
誤った設定がOrganizations全体に影響する可能性があり、
心理的にも運用的にも検証のハードルが高くなります。
そのため、統一したAWS Organizationsを運用している別の現場でも
本番環境とは完全に切り離された検証専用のAWS Organizationsを別途用意しており、
AWS Organizationsを分離したとしてもそこまでの運用負荷にはならず、
結果として検証しやすく、安全に運用できる
と判断しました。
④ 組織として求められる統制と心理的分離
本案件では、ID管理や環境にアクセスする端末を本番・開発で分離するなど、
高いレベルの統制を前提とした運用が求められていました。
このような組織では、
技術的に可能かどうかとは別に、
「どこまで影響が及ぶ可能性があるか」を
明確に説明できることが重要になります。
本番環境とそれ以外の環境が
同一のAWS Organizationsに存在する構成は、
説明や合意形成の観点で心理的なハードルが残るケースがあります。
そのため、AWS Organizationsレベルで環境を分離することで、
影響範囲を明確化し、運用・監査の両面で扱いやすい構成としました。
分けて正解だったと感じた瞬間
本番環境へのアクセスは、
- 事前申請
- 承認フロー
- 接続元端末の制限
など、複数の統制ステップが求められていました。
Organizationsの管理操作（OU変更、SCP更新、委任管理設定など）や
委任管理された各種サービスの検証・変更作業など
本番と同じ統制下に置くと、
ガバナンス強化と引き換えに運用が著しく滞る懸念がありました。
本番・開発をOrganizationsレベルで分離したことで、
- 本番：厳格な統制を維持
- 開発：スピード感を持って設計・検証
という住み分けができ、
結果として「分けて正解だった」と感じています。
逆に、正直しんどかった点
当然ながら、デメリットもあります。
- AWS OrganizationsやSCPの設定を本番・開発それぞれで実施
- AWS Organizations連携サービスを2回設定
- 構成差分が生まれやすい
特に悩ましかったのは
「どこまで同一構成に保つか」という点です。
意図しない差分はガバナンスの抜け漏れにつながるため、
CloudFormation を用いた IaC による設定管理を取り入れ、
再現性を担保する工夫が必要でした。
また、Amazon GuardDutyなどのセキュリティイベントも
AWS Organizationsごとに分かれるため、
横断的な可視性が下がるという課題も残りました。
この点については別途SIEMを導入するなどして対策しています。
判断基準：本番・開発をOrganizationsで分けるかどうか
以下は、実際に検討時に重視した判断基準です。
- ID管理や請求がすでに本番・開発で分離されているか
- 統一運用でも検証用Organizationsが必要か
- 委任管理アカウントの操作をどこまで分離したいか
- 作業ミス時の影響範囲を完全に分離したいか
- 本番と開発で作業統制レベルが明確に異なるか
まとめ
AWSとしてのベストプラクティスは、
単一のAWS Organizationsで統一的にガバナンスを効かせることです。
しかし実務においては、契約形態、ID管理、組織文化、
求められる統制レベルによって、その前提が成り立たないケースも存在します。
AWS Organizations分離はアンチパターンではなく、
組織にとって合理的であれば選ぶべき「設計上の選択肢」 です。
AWS設計において重要なのは、
ベストプラクティスに従うことではなく、
自分たちの組織に合った判断をできるかどうかだと考えています。