AWS Organizationsが実現する集中型のポリシベースアカウント管理

re:Invent 2016から3ヶ月間のプレビューを経て、Amazon Web Serviceは先頃、AWS Organizationsを一般公開に移行した。新サービスでは、組織単位の階層内で複数のAWSアカウントの集中管理を実現するとともに、きめ細かいアクセス権を持つサービス制御ポリシの添付が可能になっている。さらにAWS Organizationsには、これまで個別であった請求機能の代替としての意味もある。

Amazon Web ServiceのチーフエバンジェリストであるJeff Barr氏が概説しているように、AWSユーザの多くは、組織内のチーム毎の段階的なクラウドの採用や、“コンプライアンス上の厳格なガイドラインの遵守”、あるいは開発やテスト、およびプロダクション環境の間などに“強固な隔離障壁を設ける”などの理由から、複数のアカウントを運用している。

またAWSは、VPCピアリングやEC2イメージの共有、EBSおよびRDSスナップショット、IAMロールを通じてのアカウント間のコンソールアクセスなどの機能により、同一組織内だけでなく、異なる組織が所有するアカウント間のコラボレーションもサポートしている。一方で、こういったアカウント間の相互依存性に関する一貫性のある管理が、即座に運用上の課題に結び付くことは想像に難くない。

このような複雑さを、“階層的なOrganizational Unit(OU)の生成、各アカウントのOUへの割り当て、ポリシの定義と階層全体への適用、OUあるいは特定アカウントの選択などを行なう機能を備えた、複数のAWS アカウントの集中管理”によって集中管理することを目的とした、専用のAWS Organizationsサービスが新たに用意されたのだ。

AWS Organizationsの概念には主に次のものがある。

• 組織(Organization) – 組織にはひとつのマスタアカウントと、ゼロ以上のメンバアカウントがあり、それらを階層的なツリー構造に構成することができる
• アカウント(Account) –  AWSリソースを含む通常のAWSアカウント
• ルート(Root) – 組織内のすべてのアカウントの親コンテナ
• 組織単位(OU) – アカウントのコンテナ。他のOUを内包して階層構造を形成し、OUにアタッチしたポリシを階層内の全アカウントに適用することも可能
• サービスコントロールポリシ(SCP) – IAM(Identity and Access Management)ポリシと同様なJSON形式のポリシで、対象となるアカウントのユーザおよびロールの実行可能なアクションを指定する

選択したマスタアカウント内に組織を作成した後、既存のメンバアカウントを組織に参加させるか、組織内に新たに作成するか、あるいはそれらの作業をCLIないしAPI経由でプログラム的に行なうことによって、一般的な機能要件を満足することができる。ただし、組織に参加した既存アカウントが組織を再び離れることは可能だが、組織内で作成したアカウントを組織から離したり、あるいは削除することはできない。組織内のアカウント数には20以内という既定の制限があり、サービス制限の変更要求によってのみ拡大可能であることから、この点には注意が必要だ。

これまで一括請求(consolidated billing)を利用していたAWSユーザはAWS Organizationに移行する。EC2およびRDSリザーブドインスタンスの利用やボリューム割引といった費用節約上のメリットについては、従来と同じものが適用される。移行のシナリオでは、新たなポリシベースのアクセス管理に対するマスタアカウントからのオプトインと、各メンバアカウントからの確認操作が必要だ。一括請求を行なわずにアクセス管理のみを使用する方法はサポートされない。

組織内の各アカウントは、最大5レベルの階層構造に配置された組織単位(OU)に割り当てることができる。この階層はルートコンテナから始まる。ルートコンテナは組織から独立しており、 近日中にローンチ予定のAmazon Cloud Directoryサービスの重要機能のひとつである、複数階層を将来的にサポート可能にしている。

サービスコントロールポリシ(SCP)を組織階層のノードにアタッチすることで、対象となるIAM(Identity and Access Management)ユーザとIAMロールに委譲可能なアクションが決定される。AWSは、組織のSCPとアカウントのIAMポリシの両方から、最も制限の多い権限の組み合わせを適用する。これによってエンティティは、組織とアカウント管理者の両方がアクセスを許可したアクションのみを使用可能になる。階層内のSCPは、同じ要素上のすべてのSCPと、ツリー内の複数の要素にまたがって継承されたSCPとの共通部分として評価される。

AWS Organizationsにデフォルトで設定されている方法では、SCPをブラックリストとして使用する。ルートと生成されたOUにはAWSの管理するFullAWSAccessポリシがアタッチされており、アカウントに対して特定のアクションを明示的に拒否するSCPをアタッチしない限り、すべてのアクションが明示的に許可される。デフォルトのFullAWSAccessポリシから必要なアクションのみを許可するSCPに変更すれば、SCPをホワイトリストとして使用することも可能だ。

AWS Organizationsのドキュメントとしては、“始めに(getting started)”の章を含むユーザガイドやAWS CLIリファレンス、APIリファレンスなどがある。FAQも別途用意されている。サービスは追加料金なしで提供されるが、マスタアカウントのオーナが“組織内のアカウントによって使用されるすべてのCPUやデータ、リソースの使用料を支払う義務がある”点には注意が必要だ。サポートは AWS Organizationsフォーラムを通じて行われる。