AWS Organizationsの設計に必須なOU設計のベストプラクティスを学ぶ

「OrganizationsのOU設計、難しすぎでは…」

AWS Organizationsでマルチアカウント環境を構築していくとき、避けて通れないのがOrganizationsにおけるOUの設計。SCPに紐づく単位というざっくりした知識はありながらも、いざ設計を開始すると途方にくれる人も多いんじゃないでしょうか。

そんな（自分も含めた）迷える子羊に向けて、AWSがその解となりうるブログを公開しています。

Best Practices for Organizational Units with AWS Organizations

このブログは、上記記事をベースにOU設計のベストプラクティスを掴むことを目的として日本語で纏めたものとなります。完全な翻訳ではないことをご承知おきください。また、ハマコーの独自視点で、部分的に具体例などを追記しています。

ぜひ、この記事をきっかけに壮大なるAWSのマルチアカウント管理の世界に足を踏み入れてください。

（祭） ∧ ∧
　Y　 ( ﾟДﾟ)
　Φ[_ｿ__ｙ_l〉     Organizations ﾏﾂﾘﾀﾞﾜｯｼｮｲ
　　　 |_|＿|
　　　 し'´Ｊ

マルチアカウントなAWS環境を構築する上でのベストプラクティス

ベストプラクティスを学ぶ前に、改めてOrganizationsの用語についておさえておきます。組織単位（OU）は、AWS Organizations内のアカウントを論理的にグルーピングします。OUで複数のAWSアカウントをグルーピングすることにより、全体の管理統制が効率化されます。

サービスコントロールポリシー（SCP）をOUに対し設定することで、そのOUに紐づく全てのAWSアカウントに各AWSアカウントのルートユーザー権限でも操作できない強力なポリシーを強制することができます。

以降、AWSが想定するベストプラクティスに基づき、AWS Organizations上に必要となるOUについて解説していきます。

本番環境とソフトウェア開発サイクル（SDLC）

OUの設計を始める前に、ソフトウェア開発ライフサイクルの実現について検討します。ほとんどの企業においては、アプリケーション稼働するAWSアカウントは、本番ワークロード（Production）と非本番用（SDLC）に分類されます。

SDLC OUのアカウントは、dev, test, pre-prodなどの環境をホストします。これらのアカウントは本番環境との依存関係を持つべきではありません。

そのため、OU設計において、Prod環境とSDLC環境はOUレベルで区別して管理し、別ポリシーを適用することを推奨します。以下に具体例を記します。サービスコントロールポリシーは、個別のAWSアカウントへの適用ではなく、OUに対して設定することを推奨します。

例）本番環境と非本番環境でOUを区別する場合

• Prod OU
  • Prod Account
• SDCL OU
  • stg Account
  • dev Account

例）本番環境と非本番環境を区別し、さらにステージング環境と開発環境のOUを区別する場合

• Prod OU
  • Prod Account
• Stg OU
  • stg Account
• Dev OU
  • dev Account

Foundational OU（基盤となるOU）

AWSでは全体設計を、まずはセキュリティとインフラから開始することを推奨します。殆どの企業では、これらのニーズに対応するための専門の組織や管理チームが存在するため、これら特定の機能の基盤となるOUを、インフラとセキュリティのOUに分けて作成することを推奨します。

Infrastructure OU（インフラOU）

ネットワークやITサービスなどの共有インフラサービスに使用されます。必要なインフラの種類ごとにアカウントを作成します。

例）Infrasturucture OUの構造

オンプレネットワークへのアクセスを提供する3つの共有インフラとネットワークサービス、RabbitMQを使用したホスト型メッセージングサービスと一般的な共有インフラのアカウントを持っている場合。

• SDLC OU
  • NetworkTestAccount
  • NetworkDevAccount
  • RabbitTestAccount
  • SharedInfraServiceTestAccount
• Prod OU
  • NetworkProdAccount
  • RabbitProdAccount
  • SharedInfraServiceProdAccount

Security OU（セキュリティOU）

セキュリティ関連のアクセスやサービスをホスティングするために使用されます。このOU配下のOUやAWSアカウントはセキュリティを扱う部署が所有し、管理する必要があります。

例）Security OU構造

• SDLC OU
  • SecurtyToolingTestAccount
• Prod OU
  • SecurityReadOnlyProdAccount
  • SecurityBreakGlassProdAccount
  • SecurityToolingProdAccount
  • LogArchiveProdAccount

Log Archive

環境内のすべてのAWSから収集したセキュリティ関連のAWSアクセスログや監査ログを集約するAWSアカウント

Security ReadOnlyAccess（人間）

監査、セキュリティテスト、調査をサポートするために、セキュリティチームのメンバーがAWS環境内のアカウントに読み取り専用の権限でアクセスできるように設計する。例えばセキュリティインシデント調査の初期段階では、チームメンバーはこのAWSアカウントにアクセスし、読み取り専用のIAMクロスアカウントロールを使用し他のAWSアカウントにアクセスして、リソースの状態を確認・監視します。

Security Breakglass（人間）

基本的に利用しない。セキュリティインシデント発生時に、セキュリティチームのメンバーが利用でき、AWSアカウントへの広範囲に渡る書き込み権限を有する。すべてのアクセスは詳細に記録される。

Security Tool（人間）

セキュリティ関連のワークロードやサービス、ツール、データをホストするAWSアカウント。Amazon GuardDutyマスターアカウント、AWS Security Hubマスターアカウント、Amazon Detectiveマスターアカウント、サードパーティーのクラウド・セキュリティ監視サービスやツールなどが設置されます。

管理目的でこれらのAWSアカウントに人がアクセスすることは最小限にとどめ、Infrastructure as Codeを利用した自動化された手法で構築することを推奨します。

Sandbox OU（隔離されたOU）

主に技術者のためのAWSアカウントで、AWSのサービスを学んだり試したりするために利用されます。このOU内のAWSアカウントは顧客社内ネットワークから切り離して構築し、一定の料金制限を設定することを検討してください。例えば、毎月100ドルの支出制限を設定しリーダーに報告することで、異常値や過剰な利用を追跡可能です。

例）Sandbox OU構造

• KimLarsenAccount
• HamakoWassyoiAccount
• HamakoWassyoiCTDemoAccount
• ReneAuclairAccount

Workload OU(ワークロードOU)

ソフトウェアライフサイクルを提供するAWSアカウントが格納されるOU。ソフトウェアサービスを分離するためにワークロードアカウントを作成することを推奨します。なぜなら、アカウントへのアクセスのチームy変更は簡単ですが、アプリケーションを他のアカウントに写すのは大変な作業です。

SDLCや非Prod OUのアカウントは、ソフトウェアをステージングすることを目的としており、他のOUに依存させるべきではありません。

例）Workload OU構造

製造、コンシューマーサービス、マーケティングの異なるビジネスユニットは全てガバナンスと運用モデルを共有しています。コンシューマーサービスはパブリックベータがありますが、これはOUを保持していません。

• SDLC OU
  • ConsumerServiceQaAccount
  • ConsumerServiceEarlyTestAccount
  • ManufacturingServiceQaAccount
  • ManufacturingServiceEarlyTestAccount
  • MarketingServiceQaAccount
  • MarketingServiceEarlyTestAccount
• Prod OU
  • ConsumerServiceProdAccount
  • ConsumerServiceEarlyBetaAccount
  • ManufacturingServiceProdAccount
  • MarketingServiceProdAccount

AWS Organizationsの基本的なOU構成図

ここまで、基本的なOUの説明をしてきました。これらを整理すると、以下のOU構成図となります。

上記内容で、あなたのクラウドジャーニーを開始することは可能ですが、さらに個別のニーズに応じて、以下のOUを作成することを推奨します。

PolicyStaging OU（ポリシー検証用OU）

AWS Organizationsにポリシーや構造的な変更を加える際に検証するためのOU。Organizations管理者が、これから検討しているOUやAWSアカウントのセットアップをテストし、ポリシー適用結果を検証するために利用します。

例）PolicyStaging OU構造

ポリシーチームは、セキュリティ、インフラ、ワークロード、コード、およびデプロイメントポリシーを管理している。

• Security OU
  • PolicyStagingSecurityToolingAccount
• Infrastructure OU
  • PolicyStagingInfrastructureAccount
• Workloads OU
  • PolicyStagingWorkloadsAccount
• Deployments OU
  • PolicyStagingDeploymentsAccount

Suspended OU（廃棄対象アカウント格納OU）

利用が停止されAWS Organizationsから削除中のAWSアカウントが含まれます。すべてのアクションを拒否するSCPを適用しておくことで、利用停止であることを強制します。削除から90日間経過したアカウントは永久削除の対象となり、その後はアカウントとそのリソースは回復できません。アカウントが完全に削除されると、AWS Organizationsからは見えなくなります。

IndividualBusinessUsers（ビジネスユーザー用OU）

技術者ではないビジネスユーザーのためのAWSアカウントを格納するOU。S3バケットを設定しレポートを共有したり、パートナーとファイル共有したりするなど、ビジネスの生産性に関連したアプリケーションを作成可能。

Exceptions OU（例外用OU）

ユースケースには、Workloadsで定義されているセキュリティや監査条件から除外される必要がある場合があります。このようなケースでは、AWSアカウントに例外的なセキュリティポリシーを割り当てて利用可能です。ユースケースのカスタム性のため、サービスコントロールポリシー（SCP）は、OUではなくAWSアカウントに直接適用します。

Deployment OU（デプロイ用OU）

CI/CDデプロイのためのAWSアカウントを格納するOU。Workloads OUのアカウントとCI/CDのためのガバナンスや運用モデルが異なる場合は、このOUを作成します。CI/CDのOUを用意することで、中央集権的にCI/CDを管理し、Workload OUとの依存関係を減少させることが狙いです。

デプロイメントパイプラインはAWSのCode系サービスや、セルフホストサービスなどを利用可能です。

例）Deployment OUの構造

顧客には、3つの異なるビジネスユニットが存在します。産業用IoTサービスを提供しており、独自の運用モデルでガバナンスを行っている製造業、ガバナンスと運用モデルを共有しているコンシューマサービス、そしてマーケティングです。

• SDLC OU
  • MarketingDeploymentQAAccount
• Prod OU
  • ConsumerServiceDeploymentAccount
  • MarketingDeploymentAccount

CI/CD DeploymentのOUは、他のOUとガバナンスや運用モデルがことなるため、別の階層とAWSのアカウントに分けて管理することをお勧めします。

AWS OraganiztionsのOU設計のための参考動画

こちらの動画では、AWS Organizationsにおけるマルチアカウント設計のための全体論が述べられています。特に中盤あたりでは、OUの設計方針とともに、そのOU配下におけるAWSアカウント内にどのようなAWSリソースを配置し、それぞれのOUがどのように依存関係をもって存在するかの全体像まで学ぶことができます。

具体的なOU設計に入る前に、このAWSリソースの関連までイメージに含めておくことで、より精度の高いOU設計が可能となりますので、ぜひ上記の動画も事前にみておくことを、ハマコーオススメします。

OU設計はAWS Organizations全体設計の核心。後悔しないよう入念な検討を推奨

以上、OU設計のベストプラクティスを纏めてみました。こうやって眺めてみると、ユースケースによって様々なOUが必要になってくるのがおわかりになったかと思います。

ただ、今回挙げたOU設計の内容はあくまでベストプラクティスとして纏められたものであり、あらゆる組織において最適なものとは限りません。アプリケーションの規模やそれを扱う組織構造によっては、OUの分割はもっとシンプルで良いかもしれません。あるいは、もっと細かい単位で分ける必要が出てくるかもしれません。

慣れていないとOU設計すすめるのは難しいと思いますが、理論は理論で抑えておきながらも、実際にOUやSCPやAWS アカウントを作成し、その中で仮のワークロードを格納しながら実際の組織に適合する唯一のOU設計を試行錯誤してもらえれば良いと思います。

それでは、今日はこのへんで。濱田（@hamako9999）でした。