Kanji
・クラウドエンジニア / フリーランス ・1993年生まれ ・愛媛県出身 / 東京都渋谷区在住 ・AWS歴5年 プロフィールの詳細
目次
AWS Organizations は、 複数の AWS アカウントを一元的に管理するためのサービスです。 AWS アカウント間でのリソース共有や、ポリシー管理、アクセス制御が簡単に行えるようになります。
AWS Organizations を利用する前に、 アカウントのアカウントモデル（契約形態）を確認し管理アカウントの機能が使えるのか確認することが重要です。 アカウントモデル（契約形態）は大きく分けて「直接契約」と「リセラー契約」があります。
AWS と「直接契約」を行なって AWS アカウントを調達する場合、アカウント所有者が全てのリソースに対する完全な制御権を持つことができます。これにより、AWS Organizations の全ての機能を最大限に活用することが可能です。
対して「リセラー契約」の場合、リセラーが一部の制御を行います。リセラー契約の場合、一部の AWS Organizations の機能が制限される可能性があるため、確認が必要です。
AWS Control Tower は、 AWS Organizations 上でのセキュリティやコンプライアンスのガバナンスを AWS マネージドに展開するサービスです。 AWS Control Tower を利用することで、組織全体のセキュリティポリシーやアカウント管理が一元化され、運用管理が効率化されます。 ただし、導入の際には「① AWS アカウントはどのようなアカウントモデル（契約形態）か？」に記載の通り、アカウントモデル（契約形態）を確認して、AWS Control Tower の機能が利用可能かを確認する必要があります。
AWS Control Tower については、本ブログの以下の記事をご覧ください。
組織におけるAWS環境のセキュリティ対策として、システムを開発・運用するにあたり標準となる事項を定めた「ガイドライン」を策定するケースが多くなりました。 そのアプローチの一つとして、AWS Contr ... [続きを読む]
AWS サポートプランは、AWS の専門家からの技術サポートを受けるためのプランです。 Business および Developer Support プランの場合、アカウントごとに請求されます。AWS サポートプランはサポートに登録されているアカウントに対してのみ対応するため、複数の AWS アカウントで検証を行なってしまうとその AWS アカウントそれぞれで AWS サポートプランの契約が必要となる場合があるかもしれません。 1 つの AWS アカウントのみ Developer Support プランに契約し検証するのであれば、ランニングコストを抑えるために AWS Organizations はすぐに利用しないという選択も検討する必要があります。
Organizations の設計を策定するにあたって、 組織内のステークホルダーの役割を明確化することが重要です。 以下の表に登場する担当者を参考に登場するアクターの役割を整理し、本ページの「③ AWS アカウントのアクセス方針検討」やその他のテーマの章で利用します。 AWS 利用標準化ガイドライン策定のベストプラクティス | Amazon Web Services ブログ の内容を参考に整理してみました。 CCoE、共通基盤管理者、セキュリティ担当者、経理・財務の 4 つのアクターは、組織によっては同じ部署や担当者が複数の役割を担う場合もあるかもしれません。
AWS アカウントは「共通アカウント」「個別アカウント」それぞれでどのように分割するかを検討します。
「共通アカウント」が利用する機能（AWS サービス）として、以下のようなものがあります。 AWS サービス名しか記載しておりませんが、SaaS や AD、WSUS など、AWS サービス以外のサービスを共通の機能として提供する場合もあります。
*1: 2025年6月15日現在、すべての個別アカウントのコスト管理情報を一元的に見ることができるアカウントは、特別な機能を実装しない限り管理アカウントになります。
AWS Control Tower では、「アイデンティティ管理とアクセス管理 (踏み台)」は管理アカウント、「発見的統制 (セキュリティ監視) 」は監査アカウント、「データ保護（ログ管理）」はログアーカイブアカウントとして 3 つのアカウントを構成します。 それ以外のカテゴリの機能を基盤として共通機能で提供するのであれば、専用の共通アカウントを作成することを検討します。 決め方として、まずこのフェーズではどのような共通機能を採用するかを検討し、後述する「③ AWS アカウントのアクセス方針検討」でどのような人がアクセスするのかを整理し AWS アカウントの分割単位を検討します。
「個別アカウント」は以下の観点で分割することを検討します。 以下に記載していない観点として、「システム料金の請求先」「AWS リソースのクォータ」などの観点が候補にあがりますが、あまりにも AWS アカウントを分割しすぎると、管理が煩雑になるため、推奨しません。
AWS Organizations では、AWS アカウントを OU という階層構造で管理することができます。 OU は適応する組織に応じて最適な設計を行う必要がありますが、まずは基本となる OU 構成をベースに組織に当てはまるかを検討し、必要に応じてカスタマイズを行う方法をおすすめします。 以下の記事は OU の設計のベストプラクティスについて記載しています。
記事の中では以下の表に記載の OU 構成が基本だと紹介されていました。 AWS Control Tower では Security OU のみがデフォルトで作成されますが、それ以外の OU も必要に応じて作成することを検討します。
以下の OU は要件に応じて作成することを検討します。
このフェーズでは、 どのような人がどの AWS アカウントにアクセスするのかを整理します。 以下の表は、アクターがアクセスする AWS アカウントを整理したものです。この表はあくまで例ですので、組織に応じてアクターがアクセスする AWS アカウントを整理してください。
「1.ID管理」~「8.管理」の共通アカウントへアクセスするアクターが同じ場合、作成する AWS アカウントをまとめることを検討します。 上の表の例でいうと、「5.システム監視」「6.CI/CD」「7.運用管理」は同じアクターがアクセスするので、1 つの AWS アカウントにまとめることを検討します。
以下の 3 点の運用項目を整理いたします。