AWS Organizations におけるOU設計について考えてみる

3月よりIE課（インターナルエデュケーション課）に異動しました山﨑です。

最近は一気に気温が高くなり、我が家で生活しているフレンチブルドッグがバテ気味なのでそろそろクーラーを付けようか悩んでいます。

さて、昨今AWS Organizations を用いたマルチアカウント構成を採用するケースが増えてきたと感じています。そこで今回はAWS Organizations の概要を整理した上で、OU設計について考えてみようと思います。

AWS Organizations について
OU設計について
まとめ

AWS Organizations について

AWS Organizations とは

AWS Organizations とは要約すると、ユーザーが管理する「組織」と呼ばれる管理単位に1つ以上のAWSアカウントを統合することで、複数のAWSアカウントを効率的に一元管理することができるアカウント管理サービスです。一元管理をする上で、組織の長となるAWSアカウントを「Management Account」と呼び、その他のAWSアカウントを「Member Account」と呼びます。

AWS Organizations で実現できること

AWS Organizations が複数のAWSアカウントを効率的に管理するために、様々な機能が用意されています。以下はよく利用される機能を一部整理したものです。

これらの機能を上手く活用することで、複数のAWSアカウントを効率的に一元管理することができるようになります。

AWS Organizations で実現できること	概要
一括請求	Management Account を使用して、組織配下の全てのAWSアカウントに対する請求を統合することができます。通常であれば、請求単位であるAWSアカウントごとに請求書が発行されますが、本機能ではManagement Account に対して統合された請求書が発行されるため請求管理がシンプルになります。
アカウント集約	既存のAWSアカウントを組織としてまとめて一元管理することができます。組織配下に新規AWSアカウントを作成することができ、他のアカウントを組織に招待することもできます。
AWSアカウントのグループ化	Organizational Units（OUs）という単位でAWSアカウントをグループ化することができます。例えば、人事関連システムを扱うAWSアカウントを「HR OU」等と命名してグループ化することができます。
AWSサービスへのアクセス制御	Service Control Polices（SCP）と呼ばれるアクセスポリシーを OUs または AWSアカウントにアタッチすることでAWSサービスへのアクセス制御が可能です。 AWS Organizations におけるSCP設計のポイントを整理してみる - サーバーワークスエンジニアブログ
バックアップの一括設定	バックアップポリシーと呼ばれる設定を適用することで、AWS Organizations の組織配下に AWS Backup のバックアッププランを適用することができます。【AWS Backup】バックアップポリシーを使ってOrganizations配下のリソースをバックアップしてみる - サーバーワークスエンジニアブログ
タグの標準化	タグポリシーを利用することで、AWS Organizations の組織配下のAWSアカウントにデプロイするAWSリソースに対して付与するタグにルールを設けることができます。 AWS Organizations タグポリシーで組織内のタグを標準化する - サーバーワークスエンジニアブログ
AWSサービスの統合	AWS Organizations 配下のAWSアカウントで利用するAWSサービスのタスクをManagement Account で代理実行し、集約管理することができます。（例）Security Hub の検出結果をManagement Account に集約する
AWSサービスの委任	通常AWS Organizations の統合によって集約されるAWSサービスの管理者はRoot OU配下のManagement Account となりますが、管理者を他のAWSアカウントに鞍替えする（権限移譲）ことができます（例）Security Hub の統合における管理者権限をセキュリティ専用のAWSアカウントへ移譲する

OUの利用シーンについて

「AWSアカウントのグループ化」で、Organizational Units（OUs）という単位でAWSアカウントをグループ化することができると説明しました。このOUの実際の利用シーンについて簡単に整理しておきます。

利用シーン	概要	例
AWSアカウントのグループ化	AWS Organizations の組織配下のAWSアカウントをその役割に応じてグループ化したい場合に利用します	人事関連アカウント＝HR OUとしてグループ化
SCPの適用によるアクセス制御	OUまたはAWSアカウントの役割に応じて、アクセス可能なAWSサービスを制御したい場合に利用します	監査ログを取り扱うAWSアカウントで誤操作によるデータ編集/削除ができないようアクセス制御を行う
AWSサービスの設定を一括適用	あるAWSサービスの設定を1つのAWSアカウントだけでなく、OU単位で適用したい	CloudFormation StackSets の自動デプロイ設定をOU単位で適用する

OU設計について

OUにおける推奨構成

AWS Organizations におけるOUの推奨構成についてはAWSがホワイトペーパーを提供しており、以下の弊社ブログでも整理されています

blog.serverworks.co.jp

しかし、AWS Organizations を初めてご利用される方がいきなりホワイトペーパーの内容を読んでも、理解することは簡単ではないと思います。そこで、以降は私なりのOU設計における考え方を1つご紹介します。

OU設計＝組織図の設計に置き換えて考える

OU設計において頭を悩ませるのは「どの程度の粒度でグループを分けるのか」ということです。私はOU設計を企業の組織図に見立てることで、設計イメージを膨らますようにしています。

一般的な企業組織においては「営業部」「製造部」「管理部」のように組織が分かれており、各組織には役職者（部長や課長）が配置されています。ここで着目すべきポイントは各組織には「適切な役割と権限」が与えており、役割を全うする「責任者」が配置されているという点です

OU設計においても組織図と同様に「各OUにどのような役割と権限」を与え、「誰を責任者として配置するのか」と考えてみるとイメージしやすいのではないかと思います。この観点に立つと、OUには役割と権限を与えるだけではなく、OUを管理する責任者も合わせて設置することが望ましいと考えます。上述した組織図をOUに置き換えると以下のようなOU構成になります。組織図とOU構成はどこか似ているように見えるのではないでしょうか。

AWSが提供しているホワイトペーパーには数多くのOUが紹介されていますが、これらはAWS Organizations で複数のAWSアカウントを効率的に一元管理していく上で、OUに与えるべきであろう役割と権限をAWSが網羅的に整理したものだと考えてみてください。ホワイトペーパーで紹介されているOUを自組織に適用する際、必要になるであろうOUをピックアップしていくのが良いと思います。

OU構成例

OU設計には絶対的な解はありませんが、参考までにOU構成例を1つご紹介したいと思います。

OU階層	OU名	役割
0	Root	AWS Organizations における最上位のOU
1	Foundation	利用中のAWSアカウントを配置
1	Suspended	一時または恒久的に使用を停止するAWSアカウントを配置
2	Core	AWS Organizations 配下の全AWSアカウントに対して適用するインフラ共通基盤を配置
2	Sandbox	検証用で利用するAWSアカウントを配置
2	Workload	各事業部門が利用するAWSアカウントを配置
3	Log Intergration	監査用途等で利用するログを集約、保管するAWSアカウントを配置
3	Network	AWS Organizations 配下のAWSアカウントで利用されるネットワークコンポーネント（例: Direct Connect）を配置
3	Security	AWS Organizations 配下のAWSアカウントに対してセキュリティ上の統制管理を実施するAWSアカウントを配置
3	Monitoring	AWS Organizations 配下のAWSアカウントに対する監視基盤を提供するAWSアカウントを配置
3	SSO	AWS Organizations 配下のAWSアカウントへアクセスするためのユーザーIDを一元管理するAWSアカウントを配置
3	Backup	AWS Organizations 配下のAWSアカウントにバックアップポリシーを適用するためのAWSアカウントを配置
3	Sales-Group	営業部が利用するAWSアカウントを配置
3	HR-group	人事部が利用するAWSアカウントを配置
4	A-System	Aシステムを管理するためのAWSアカウントを配置
4	B-System	Bシステムを管理するためのAWSアカウントを配置
4	C-System	Cシステムを管理するためのAWSアカウントを配置
4	D-System	Dシステムを管理するためのAWSアカウントを配置
5	Production	各システムにおいて環境を分離し、本番システムをデプロイするためのAWSアカウントを配置
5	Staging	各システムにおいて環境を分離し、検証環境をデプロイするためのAWSアカウントを配置