【ガイドライン】AWS Organizations

作成日: 2023/06/21, 更新日: 2023/07/27

AWS 環境を構築するにあたり、環境や権限、AWS利用費用を分離する目的でマルチアカウント構成を行うことが一般的になりました。
AWS Organizations を利用することで、一元的にAWSアカウントを管理することができます。
本記事では、AWS Organizations の概要の説明と導入を検討するにあたって確認すべきポイントを記載いたしました。

AWS Organizations とは？
導入検討
ガイドライン策定
関連ドキュメント

AWS Organizations とは？

AWS Organizations は、複数の AWS アカウントを一元的に管理するためのサービスです。
AWS アカウント間でのリソース共有や、ポリシー管理、アクセス制御が簡単に行えるようになります。

導入検討

① AWS アカウントはどのようなアカウントモデル（契約形態）か？

AWS Organizations を利用する前に、アカウントのアカウントモデル（契約形態）を確認し管理アカウントの機能が使えるのか確認することが重要です。
アカウントモデル（契約形態）は大きく分けて「直接契約」と「リセラー契約」があります。

AWS と「直接契約」を行なって AWS アカウントを調達する場合、アカウント所有者が全てのリソースに対する完全な制御権を持つことができます。これにより、AWS Organizations の全ての機能を最大限に活用することが可能です。

対して「リセラー契約」の場合、リセラーが一部の制御を行います。リセラー契約の場合、一部の AWS Organizations の機能が制限される可能性があるため、確認が必要です。

関連資料
- AWS ソリューションプロバイダー向け AWS Control Tower のベストプラクティス | AWS JAPAN APN ブログ

② AWS Control Tower を利用するか？

AWS Control Tower は、AWS Organizations 上でのセキュリティやコンプライアンスのガバナンスを自動化するサービスです。
AWS Control Tower を利用することで、組織全体のセキュリティポリシーやアカウント管理が一元化され、運用管理が効率化されます。
ただし、導入の際にはコストや機能面での検討が必要です。

AWS Control Tower については、本ブログの【ガイドライン】AWS Control Tower | Moderniser.repo を参照ください。

関連資料
- AWS Control Tower の仕組み - AWS Control Tower

③ 検証目的で利用する場合、AWS サポートプランを契約するか？

AWS サポートプランは、AWS の専門家からの技術サポートを受けるためのプランです。
Business および Developer Support プランの場合、アカウントごとに請求されます。AWS サポートプランはサポートに登録されているアカウントに対してのみ対応するため、複数の AWS アカウントで検証を行なってしまうとその AWS アカウントそれぞれで AWS サポートプランの契約が必要となる場合があるかもしれません。

1 つの AWS アカウントのみ Developer Support プランに契約し検証するのであれば、ランニングコストを抑えるために AWS Organizations はすぐに利用しないという選択も検討する必要があります。

関連資料
- AWS Support プラン比較 | デベロッパー、ビジネス、エンタープライズ、エンタープライズ On-Ramp | AWS Support

ガイドライン策定

① ガイドラインに登場するアクターの整理

ガイドラインを策定するにあたって、組織内のステークホルダーの役割を明確化することが重要です。
以下の表に登場する担当者を参考にガイドラインに登場するアクターの役割を整理し、本ページの「③ AWS アカウントのアクセス方針検討」やその他のテーマの章で利用します。
- AWS 利用標準化ガイドライン策定のベストプラクティス | Amazon Web Services ブログの内容を参考に、言葉の定義を自分なりに整理してみました。
- CCoE、共通基盤管理者、セキュリティ担当者、経理・財務の 4 つのアクターは、組織によっては同じ部署や担当者が複数の役割を担う場合もあるかもしれません。

No ➖➖	担当者 ➖➖➖➖➖➖	役割 ➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖	タスク ➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖
01	CCoE	クラウド活用の推進および運営の中心	ガイドラインの整備
02	共通基盤管理者	クラウド環境におけるシステム横断的な共通基盤・機能を提供	共通基盤の構築・運用
03	セキュリティ	クラウド環境におけるセキュリティの維持	セキュリティポリシー定義, セキュリティ機能の構築・運用, セキュリティ監視・運用
04	システム担当	クラウド環境上で稼働するシステムの構築・運用	AWS リソースの構築・運用, システム構築・運用
05	運用	クラウド環境における運用管理	システム監視・運用
06	経理・財務	AWS利用コストの配分および適正化	コストの配分方針検討, 購入オプション検討, コスト監視, AWS利用料金の支払い

② AWS アカウントの構成検討

AWS アカウントは「共通アカウント」「個別アカウント」それぞれでどのように分割するかを検討します。

共通アカウント

「共通アカウント」が利用する機能（AWS サービス）として、以下のようなものがあります。
- AWS サービス名しか記載しておりませんが、SaaS や AD、WSUS など、AWS サービス以外のサービスを共通の機能として提供する場合もあります。

No ➖➖	カテゴリ ➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖	よく呼ばれるAWSアカウントの名称 ➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖	代表的なAWSサービス名 ➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖
01	アイデンティティ管理とアクセス管理	踏み台、ID管理	AWS IAM, AWS lAM Identity Center
02	発見的統制	監査、セキュリティ監視	AWS SecurityHub, AWS Cloudrail, AWS Config, Amazon GuardDuty, Amazon EventBridge
03	ネットワーク・インフラストラクチャ保護	共通ネットワーク、外部接続	AWS Transit Gateway, AWS Direct Connect, AWS Network Firewall
04	データ保護	ログ管理	Amazon S3
05	監視	システム監視	Amazon CloudWatch, Amazon EventBridge, Amazon SNS, AWS User Notifications
06	インフラプロビジョニング (CI/CD)	CI/CD	AWS CodeCommit, AWS CodePipeline, AWS CodeBuild, AWS CodeDeploy
07	運用管理	運用管理	AWS Systems Manager
08	コスト管理	管理アカウント *1	AWS Budgets, AWS Cost Explorer, AWS Cost Anomaly Detection

*1: 2023 年 7 月 11 日現在、個別アカウントのコスト管理情報は管理アカウントのみでしか閲覧できません。

AWS Control Tower では、「アイデンティティ管理とアクセス管理 (踏み台)」は管理アカウント、「発見的統制 (セキュリティ監視) 」は監査アカウント、「データ保護（ログ管理）」はログアーカイブアカウントとして 3 つのアカウントを構成します。
- 参考: AWS Control Tower の AWS アカウントについて - AWS Control Tower
それ以外のカテゴリの機能を基盤として共通機能で提供するのであれば、専用の共通アカウントを作成することを検討します。
決め方として、まずこのフェーズではどのような共通機能を採用するかを検討し、後述する「③ AWS アカウントのアクセス方針検討」でどのような人がアクセスするのかを整理し AWS アカウントの分割単位を検討します。

個別アカウント

「個別アカウント」は以下の観点で分割することを検討します。

システム: システムごとに分割することで、システムごとのリソースを分けることができます。
環境: 本番、検証、開発など、環境の違いによって分割いたします。本番環境と非本番環境を分けることで、本番環境のセキュリティを高めることができます。
統制: 大規模なシステムの場合、システムの中でも管理の都合上分割する場合もあります。

③ OU 構成検討

AWS Organizations では、AWS アカウントを OU という階層構造で管理することができます。
OU は適応する組織に応じて最適な設計を行う必要がありますが、まずは基本となる OU 構成をベースに組織に当てはまるかを検討し、必要に応じてカスタマイズを行う方法をおすすめします。
以下の記事は OU の設計のベストプラクティスについて記載しています。
- 参考： Best Practices for Organizational Units with AWS Organizations | AWS Cloud Operations & Migrations Blog

記事の中では以下の表に記載の OU 構成が基本だと紹介されていました。
- AWS Control Tower では Security OU のみがデフォルトで作成されますが、それ以外の OU も必要に応じて作成することを検討します。

OU名 ➖➖➖➖➖➖	子OUの分割を検討する観点 ➖➖➖➖➖➖	必須/任意 ➖➖➖	用途 ➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖
Security	本番or非本番	必須	セキュリティ関連のAWSアカウントを格納
Infrastructure	本番or非本番	任意	共有インフラのAWSアカウントを格納
Sandbox	-	任意	PoCやAWSの学習のために利用するAWSアカウントを格納
Workloads	本番or非本番, システム名	必須	ソフトウェアライフサイクルを提供するAWSアカウントを格納

以下の OU は要件に応じて作成することを検討します。

OU名 ➖➖➖➖➖➖➖➖➖➖➖➖	必須/任意 ➖➖➖	用途 ➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖➖
Policy Staging	任意	SCPなどのポリシーやガードレールを検証するAWSアカウントを格納
Suspended	任意	利用が停止されたAWSアカウントを格納
IndividualBusinessUsers	任意	ビジネスユーザーのためのAWSアカウントを格納
Exceptions	任意	例外的なセキュリティポリシーを割り当てるAWSアカウントを格納
Deployments	任意	CI/CDのためのAWSアカウントを格納

④ 各アクターがアクセスする AWS アカウントの整理

このフェーズでは、どのような人がどの AWS アカウントにアクセスするのかを整理します。
以下の表は、アクターがアクセスする AWS アカウントを整理したものです。
- この表はあくまで例ですので、組織に応じてアクターがアクセスする AWS アカウントを整理してください。

アクター ➖➖➖➖➖➖➖	1.ID管理 ➖➖➖➖➖➖➖➖➖	2.監査 ➖➖➖➖➖➖➖➖➖	3.共通ネットワーク ➖➖➖➖➖➖➖➖➖	4.ログ管理 ➖➖➖➖➖➖➖➖➖	5.システム監視 ➖➖➖➖➖➖➖➖➖	6.CI/CD ➖➖➖➖➖➖➖➖➖	7.運用管理 ➖➖➖➖➖➖➖➖➖	8.管理 ➖➖➖➖➖➖➖➖➖	a.本番システム ➖➖➖➖➖➖➖➖➖	b.非本番システム ➖➖➖➖➖➖➖➖➖
CCoE	RW	RW	RW	R	RW	RW	RW	RW	RW	RW
共通基盤管理者	RW	R	RW	R	RW	RW	RW	R	R	R
セキュリティ	-	R	RW	R	-	-	-	-	RW	RW
システム担当	-	-	-	-	RW	RW	RW	-	RW	RW
運用	-	-	-	-	RW	RW	RW	-	RW	RW
経理・財務	-	-	-	-	-	-	-	-	R	R

「1.ID管理」~「8.管理」の共通アカウントへアクセスするアクターが同じ場合、作成する AWS アカウントをまとめることを検討します。
- 上の表の例でいうと、「5.システム監視」「6.CI/CD」「7.運用管理」は同じアクターがアクセスするので、1 つの AWS アカウントにまとめることを検討します。

⑤ 運用項目整理

ガイドラインを記載するうえで、以下の 3 点の運用項目を整理いたします。

AWS アカウントの作成・削除
- AWS アカウントの作成・削除を誰がやるか、どのようなフローで作成するかを検討します。
- AWS アカウント作成時に提供する AWS リソースについて、作成するかしないか選択できるものは、申請書で選択できるようにします。

サービスコントロールポリシーの作成・変更・削除
- 個別アカウントに適用するサービスコントロールポリシーの作成・変更・削除を誰がやるか、どのようなフローで作成するかを検討します。

ルートユーザーの利用・更新 - 以下のケースのように、ルートユーザーを使わなくてはならないケースが発生した場合、どのようなフローでルートユーザーを利用するかを検討します。
- ルートユーザー認証情報が必要なタスク - AWS アカウント管理
- 個別アカウントのルートユーザーにログインできず、管理アカウント経由で AWS サポートに問い合わせを行い個別アカウントの情報を変更したケースがあったのですが、IAM ユーザーからではなく管理アカウントのルートユーザーから AWS サポートへ連絡してほしいと言われたケースがありました。
- これはあくまでイレギュラーなケースですが、ルートユーザーはいざ使おうと思ったときに使えないということがないようにしておく必要があります。