Amazon Web Services ブログ

AWS Organizations – 複数の AWS アカウントのポリシーベースの管理

複数の AWS アカウントを管理しているお客様が少なくありません。いくつかの理由が考えられます。AWS を徐々に導入して全体に広げている組織では、個別のチームや部門が一元管理されることなくクラウドコンピューティングに移行している場合があります。合併や買収を通じて成長している組織では、既存のアカウントを引き継ぐ場合があります。厳格なコンプライアンスのガイドラインに従うため、またはアプリケーション間に強い隔離障壁を設けるための通常の対策として複数のアカウントを作成する場合もあります。さらに開発、テスト、実稼働の目的別に異なるアカウントを使用する場合もあります。アカウント数が増大すると、全体をスケーラブルに管理する方法が必要になります。お客様は、チーム、部門、アプリケーションごとのアカウントを個別に扱わずに、アクセスコントロールポリシーを定義して全体、一部、または個別のアカウントに簡単に適用する方法を求めています。このようなお客様は、さらに請求やコスト管理にも関心が高い場合が多く、ボリュームディスカウントやリザーブドインスタンスなどの AWS の料金面でのメリットを、より広範囲にアカウントに反映できることを希望しています。

AWS Organizations がプレビューから一般公開へ
このユースケースの重要性が増していることから、本日より、AWS Organizations のプレビューを終了して一般提供を開始します。AWS Organizations では複数の AWS アカウントを一元管理できます。組織単位 (OU) の階層構造を作成して各アカウントを OU に割り当て、さらにポリシーを定義して階層構造の全体、特定の OU、または特定のアカウントに適用できます。また、既存の AWS アカウントを招待して組織に追加できます。新規アカウントを作成することもできます。以上のすべての機能は、AWS Management Console、AWS Command Line Interface (CLI)、および AWS Organizations API から利用できます。AWS Organizations の理解に役立つ重要な用語と概念をいくつか紹介します (ユーザーが組織の AWS アカウント全体に対して全権を持ち、マスターアカウントを担当する管理者であることを前提とします)。

組織は、管理対象の AWS アカウントの統合セットです。新しい組織を作成して、サービスコントロールポリシーなどの高度なアカウントレベルのコントロールを実装できます。組織の管理者は、アカウント別に許可および拒否する AWS API 関数やリソースのリストを管理できます。たとえば、先端 R&D チームには広範な AWS のサービスへのアクセス権を与え、メインストリームの開発およびテストアカウントにはアクセス権を一部制限できます。または、実稼働環境では、HIPAA の準拠に該当する AWS のサービスに限ってアクセスを許可できます。AWS の既存のお客様は、一括請求 (コンソリデーティッドビリング) と呼ばれる AWS の機能を利用している場合があります。この機能で支払いアカウントを選択すると、複数の AWS アカウントのアカウントアクティビティを 1 つの請求書にまとめてコストを一元管理できます。今回のリリースで、現在一括請求をご利用のお客様は、AWS Organizations を通じて一括請求のすべての機能を利用できます。ただし、本日から提供開始される新しい機能 (サービスコントロールポリシーなど) はデフォルトでは利用可能になりません。この場合、AWS Organizations のすべての機能は簡単に有効にすることができます。まず、組織のマスターアカウントから AWS Organizations のすべての機能を使用可能にして、次に、この変更を各メンバーアカウントに認証してもらいます。最後に、当社では一括請求機能のみをサポートする組織の新規作成を今後もサポートします。今後も一元化された請求機能のみを使用できます。その場合は、マスターアカウントの管理者が組織のメンバーアカウントに詳細なポリシーコントロールを適用することを許可しません。AWS アカウントは、AWS リソースのコンテナです。マスターアカウントは、組織の管理ハブであり、組織のすべての AWS アカウントの支払いアカウントでもあります。また、マスターアカウントは、既存のアカウントを招待して組織に追加できます。新規アカウントを作成することもできます。メンバーアカウントは、組織のマスターアカウント以外のアカウントです。組織単位 (OU) は、AWS アカウントのセットのコンテナです。OU は、最大 5 階層で構成される階層構造内に配置できます。OU の階層構造の最上位は、管理ルートとも呼ばれます。サービスコントロールポリシー (SCP) は、組織のマスターアカウントが組織、選択された OU、または選択されたアカウントに適用できるコントロールのセットです。OU に適用すると、SCP は当該の OU と階層構造でそれより下位にある他のすべての OU に適用されます。メンバーアカウントの有効な SCP では、そのアカウントのルートユーザーに付与するアクセス許可を指定します。アカウント内では、IAM ユーザーおよびロールを通常どおりに使用できます。ただし、ユーザーやロールのアクセス許可の内容にかかわらず、有効なアクセス許可のセットが SCP で定義されている範囲を超えて適用されることはありません。これを利用して、アカウントレベルで AWS のサービスや API 関数へのアクセスを細かくコントロールできます。招待は、AWS に対して組織への参加をリクエストする際に使用します。招待の承諾期限は 15 日間ですが、メールアドレスまたはアカウント ID を使用して延長できます。未承諾の招待は同時に最大 20 件まで保持できます。招待ベースのモデルでは、マスターアカウントから既存のアカウントを招待できます。招待が承諾されると、アカウントが組織に追加され、すべての該当するポリシーが有効になります。組織に追加されたアカウントは、適切な OU に移動できます。AWS Organizations は、管理対象の AWS アカウント間に強力な隔離障壁を設ける場合に有効です。ただし、AWS リソース (EC2 インスタンス、S3 バケットなど) は特定の AWS アカウント内にあり、アカウント間では移動できないことに注意してください。さまざまなクロスアカウントの AWS 機能にはアクセスできます。たとえば、VPC ピア接続、AMI の共有、EBS スナップショットの共有、RDS スナップショットの共有、クロスアカウントの E メール送信、IAM ロールによるアクセス委任、クロスアカウントの S3 バケットのアクセス許可、AWS マネジメントコンソールでのクロスアカウントアクセスなどの機能は利用できます。一括請求と同じように、EC2 および RDS リザーブドインスタンスの使用についても、AWS Organizations にはいくつかの利点があります。請求目的においては、組織のすべてのアカウントが 1 つのアカウントであるかのように扱われ、同じ組織の他の任意のアカウントで購入された RI の時間単位のコストメリットを受けることができます (このメリットが想定どおりに適用されるためには、RI のアベイラビリティーゾーンおよび他の属性が EC2 または RDS インスタンスの属性と一致する必要があります)。組織の作成 コンソールから組織を作成し、複数の組織単位を作成して、さらに複数のアカウントを作成してみましょう。まず、[Create organization] をクリックします。

次に [ENABLE ALL FEATURES] を選択して、[Create organization] をクリックします。

組織が数秒で作成されます。

新しいアカウントを作成するには、[Add account] をクリックして、[Create account] を選択します。

次に、詳細を指定します (IAM ロールを新しいアカウントで作成し、作成した IAM ロールからアカウントのカスタマイズに必要なアクセス許可を付与します)。

Dev アカウント、Test アカウント、Prod アカウントの作成後のコンソールは以下のようになります。

この時点では、すべてのアカウントが階層構造の最上位にあります。

下位構造を追加するには、[Organize accounts] をクリックして、[Create organizational unit (OU)] を選択し、名前を入力します。

2 つ目の OU にも同じ操作を行います。

次に Prod アカウントを選択し、[Move accounts] をクリックして、Operations OU を選択します。

次に、Dev アカウントと Test アカウントを Development OU 内に移動します。

この時点で 4 つのアカウント (最初の 1 つおよび先ほど作成した 3 つ) と 2 つの OU があります。次のステップとして、サービスコントロールポリシーを作成します。[Policies] をクリックして [Create policy] を選択します。ここで Policy Generator を使うか、既存の SCP をコピーしてカスタマイズするかを選択できます。Policy Generator を使うことにします。ポリシーに名前を付けて、Allow ポリシーとして指定します。

次に、Policy Generator を使用して EC2 と S3 への完全なアクセスと Lambda 関数を実行する (呼び出す) ことを許可するポリシーを構築します。

このポリシーでは、アカウント内の実行可能なアクションのフルセットを定義するだけであることに注意してください。これらのアクションをアカウント内の IAM ユーザーが使用することを許可するには、さらに適切な IAM ポリシーを作成してユーザーにアタッチする必要があります (すべてに操作はメンバーアカウント内で行います)。[Create policy] をクリックしてポリシーを作成します。

次に開発およびテスト用として 2 つ目のポリシーを作成します。このポリシーでも、AWS CodeCommit、AWS CodeBuild、AWS CodeDeploy、および AWS CodePipeline へのアクセスを許可します。

ここまでで、アカウントを作成して OU 内に配置しました。さらに OU のためのポリシーを作成しました。次にポリシーを使用可能にし、ポリシーを OU にアタッチする必要があります。ポリシーを使用可能にするには、[Organize accounts] をクリックして [Home] を選択します (ホームはルートと同じではありません。Organizations は複数の独立した階層構造をサポートするように設計されています)。さらに Root OU のチェックボックスをオンにします。次に、右側の [Details] セクションを展開し、[Enable] をクリックします。

これで、すべての要素が揃いました。Root OU をクリックして階層構造内に移動し、Operations OU のチェックボックスをオンにします。次に、右側の [Details] セクションを展開し、[Attach policy] をクリックします。

次に [OperationsPolicy] を見つけて [Attach] をクリックします。

最後に、[FullAWSAccess] ポリシーを削除します。

また、Development OU に DevTestPolicy をアタッチできます。上で説明したすべてのオペレーションを行うには、AWS Command Line Interface (CLI) を使用するか、以下の関数を呼び出すこともできます。 CreateOrganization、 CreateAccount、 CreateOrganizationalUnit、 MoveAccount、 CreatePolicy、 AttachPolicy、および InviteAccountToOrganization。CLI を使用する方法については、「AWS Organizations を発表: 複数の AWS アカウントの一元管理」を参照してください。

AWS Organizations を使用するためのベストプラクティス
最後に、AWS Organizations を使用するためのベストプラクティスを紹介します。マスターアカウント – マスターアカウントには、オペレーション用の AWS リソースを (1 つを例外として) 関連付けないことをお勧めします。これにより、適切なコントロールを判断しやすくなり、AWS の請求内容を理解しやすくなります。CloudTrail – メンバーアカウントでのすべての AWS 使用状況を一元的に追跡するには、マスターアカウントで AWS CloudTrail (これが例外) を使用します。最少の特権 – OU のポリシーを設定する場合は、割り当てる特権をできるだけ少なくします。組織単位 – ポリシーはアカウントにではなく OU に対して割り当てます。これにより、組織構造および必要な AWS アクセスレベルがより適切にマッピングされます。テスト – スケールアップする前に 1 つのアカウントで新規ポリシーと変更されたポリシーをテストします。自動化 – API と AWS CloudFormation テンプレートを使用して、すべての新規作成されたアカウントが適切に設定されていることを確認します。テンプレートで IAM のユーザー、ロール、およびポリシーを作成できます。ログ記録の設定、VPC の作成と設定などを行うこともできます。

詳細
以下は、AWS Organizations の使用を開始するために役立つリソースです。

 

主要事項
AWS Organizations は、China (Beijing) と AWS GovCloud (US) を除くすべての AWS リージョンで本日から無料で公開されます (より正確には、サービスエンドポイントが US East (Northern Virginia) にあり、SCP はすべての該当リージョンで適用されます)。すべてのアカウントの販売者は同一でなければならず、同じ組織内で AWS と AISPL (インドで AWS のサービスアカウントのリセラーとなっている現地インド法人) を合わせて使うことはできません。AWS Organizations は今後大きく拡張される予定であり、複数の支払いアカウント、リザーブドインスタンス割引の割り当てのコントロール、複数の階層構造、その他のコントロールポリシーなどに対するサポートの追加が現在検討されています。今回も、皆さまからのご意見やご提案をお待ちしております。

— Jeff;