AWS Organizationsとは ― SCPと一括請求
Organizationsは、
AWS Organizationsとは、複数のAWSアカウントを1つの組織にまとめて管理するサービス
AWSアカウントを本番用と開発用、部門ごとなどで分けると、権限の管理と料金の支払いの手間がアカウントの数だけ増えます。AWS Organizationsは、こうした複数のアカウントを1つの組織にまとめて、その手間を減らすサービスです。組織内のアカウントに共通のルールを適用し、利用料金の支払いも1つにまとめられます。Organizationsそのものに、追加の料金はかかりません。
Organizationsでできることは、大きく2つに分かれます。1つはSCPというポリシーで、各アカウントで使える権限の上限を決めることです。もう1つは一括請求で、すべてのアカウントの料金を1か所でまとめて支払うことです。
AWSアカウントを分けるのは、権限・費用・被害の範囲に境界を作るため
AWSの資料は、AWSアカウントを権限・セキュリティ・費用・ワークロードの自然な境界と説明しています。ワークロードとは、1つの業務を動かすアプリとリソースのまとまりです。1つのアカウントに本番と開発を同居させると、開発の作業ミスが本番のリソースに及ぶおそれがあります。アカウントを分けると、リソースはアカウントごとに切り離されます。開発のアカウントで誤ってリソースを削除しても、本番のアカウントのリソースは残ります。
費用も、アカウントごとに把握できます。部門やシステムごとにアカウントを分ければ、どこでいくらかかったかがすぐに分かります。AWSは、規模が大きくなるときは複数のアカウントを使う構成を勧めています。アカウントごとに分けたVPCどうしをつなぐ方法は、VPCピアリングとTransit Gatewayの記事で比べています。
ただし、アカウントが増えるほど、設定をそろえる手間と支払いの手間も増えます。Organizationsは、こうした管理を組織全体でまとめて行えるようにします。たとえばGuardDuty・Inspector・Macieでは、組織のアカウントを1つのアカウントからまとめて管理できます。
組織の構成は、ルートの下にOUとアカウントを置く木構造
組織を作ったアカウントは、管理アカウントになります。管理アカウントは組織の所有者で、アカウントの作成と招待、ポリシーの付け外しを行います。管理アカウントを、あとから別のアカウントに変更することはできません。
組織に入るほかのアカウントを、メンバーアカウントと呼びます。メンバーアカウントは、同時に1つの組織にしか所属できません。
組織の一番上には、ルートが1つだけあります。ルートの下には、アカウントをまとめる単位を作れます。この単位をOU(Organizational Unit)と呼びます。OUの中には、さらにOUを作れます。
ポリシーは、木構造の上から下へ継承されます。OUに付けたポリシーは、その中のOUとアカウントにも効きます。OUの入れ子は、ルートと一番下のアカウントを除いて5段までです。
組織には、機能の範囲が2種類あります。既定の「すべての機能」では、一括請求に加えてSCPなどのポリシーも使えます。「一括請求だけ」の組織では、SCPを使えません。
| 比べる | すべての | 一括請求だけ |
|---|---|---|
| 一括請求 | 使える | 使える |
| SCPなどの | 使える | 使えない |
| ほかの | 使える | 使えない |
SCPとは、権限を与えずに、使える権限の上限を決めるポリシー
SCP(サービスコントロールポリシー)は、メンバーアカウントのIAMユーザーとロールが使える権限の上限を決めるポリシーです。SCPは、権限を1つも与えません。実際に権限を与えるのは、IAMポリシーなどです。
操作が許可されるのは、SCPとIAMポリシーの両方が許可したときだけです。AWSの資料は、この関係を「2つが許可する範囲の共通部分」と説明しています。IAMポリシーでAdministratorAccessを付けても、SCPが上限から外した操作はできません。
SCPは、メンバーアカウントのルートユーザーにも効きます。IAMの記事で説明したとおり、ルートユーザーにはIAMポリシーを付けられません。SCPを使うと、そのルートユーザーの操作を組織の側から制限できます。
SCPを使えるようにすると、ルート・すべてのOU・すべてのアカウントに、FullAWSAccessというSCPが付きます。FullAWSAccessは、すべてのサービスと操作を上限の中に置くSCPです。基本の使い方は、ここに、拒否したい操作を書いたSCPを追加していくことです。
SCPの拒否は、付けた階層より下のすべてに効きます。下の階層のSCPで許可していても、明示的な拒否が優先されます。許可のほうは、ルートからアカウントまでのすべての階層で必要です。途中のOUからFullAWSAccessを外すときは、代わりに許可を書いたSCPを付けます。付けないと、その下のアカウントは何もできなくなります。
IAMポリシーとSCPの組み合わせで、操作が許可されるかを確かめる
次の図では、IAMユーザーがS3バケットを削除しようとしています。SCPには、FullAWSAccessが付いた状態を前提にしています。アカウントの種類・IAMポリシー・SCPを選ぶと、削除できるかどうかとその理由が表示されます。
- SCPすべての
操作が 上限の 中に あります - IAMs3:DeleteBucketを
許可しています
- SCPS3バケットの
削除を 明示的に 拒否しています - IAMs3:DeleteBucketを
許可しています
- SCPすべての
操作が 上限の 中に あります - IAM削除を
許可する ポリシーが ありません
- SCPS3バケットの
削除を 明示的に 拒否しています - IAM削除を
許可する ポリシーが ありません
- SCP管理アカウントには
効きません - IAMs3:DeleteBucketを
許可しています
- SCP管理アカウントには
効きません - IAMs3:DeleteBucketを
許可しています
- SCP管理アカウントには
効きません - IAM削除を
許可する ポリシーが ありません
- SCP管理アカウントには
効きません - IAM削除を
許可する ポリシーが ありません
メンバーアカウントで削除できるのは、IAMポリシーが許可し、SCPも拒否していない組み合わせだけです。SCPがすべてを許可していても、IAMポリシーの許可が無ければ削除できません。管理アカウントでは、SCPを選んでも結果が変わりません。どちらで拒否された操作も、CloudTrailにエラーを含むイベントとして記録されます。
SCPは管理アカウントには効かない
SCPが効くのは、メンバーアカウントだけです。ルートにSCPを付けても、管理アカウントのユーザーとロールは制限されません。管理アカウントで何ができるかは、SCPを除いたIAMポリシーなどの許可で決まります。
そのため、AWSは管理アカウントに業務のリソースを置かないよう勧めています。本番や開発のリソースはメンバーアカウントに置き、管理アカウントは組織の管理にだけ使います。リソースを分けておくと、請求書の内容も把握しやすくなります。
メンバーアカウントの中にも、SCPが効かないものがあります。AWSのサービスが連携のために使うサービスリンクロールは、SCPで制限できません。また、AWSはSCPをルートに付ける前に、少数のアカウントを入れたOUで影響を試すよう勧めています。
一括請求は、すべてのアカウントの料金を管理アカウントがまとめて支払う仕組み
一括請求では、管理アカウントがメンバーアカウントの料金をまとめて支払います。請求書は1つにまとまり、アカウントごとの料金も管理アカウントから見られます。一括請求に、追加の料金はかかりません。
請求の計算では、AWSは組織のすべてのアカウントを1つのアカウントのように扱います。S3やデータ転送のように、使用量が多いほど単価が下がるサービスがあります。一括請求では、すべてのアカウントの使用量を合算して、どの単価の段階に当たるかを決めます。
AWSの資料には、この割引を説明する計算の例があります。この例では、最初の10TBを1GBあたり0.17ドル、次の40TBを0.13ドルと仮定しています。2つのアカウントが8TBと4TBのデータを転送すると、合わせて12TBになります。
1TBを1,024GBとすると、10TBまでは1TBあたり174.08ドル、そこから先は133.12ドルです。合算して計算すると、174.08×10+133.12×2で2,007.04ドルです。別々に計算すると、どちらも10TBに届かないので、174.08×12で2,088.96ドルです。合算より81.92ドル高くなります。
リザーブドインスタンスとSavings Plansの割引も、組織内で共有できます。あるアカウントが買ったリザーブドインスタンスの割引を、ほかのアカウントも受けられます。管理アカウントは、アカウントごとにこの共有を止められます。
請求書は、OUの構成を反映しません。部門やシステムごとに費用を分けて見たいときは、リソースにコスト配分タグを付けます。購入オプションとそれぞれの割引の考え方は、AWSの料金の記事にまとめています。
Control Tower・IAM Identity Centerとの違い
AWS Control Towerは、AWSが推奨する構成で複数のアカウントの環境を作り、継続して管理するサービスです。Control TowerはOrganizationsの上に構築されていて、その機能を組み合わせて使います。Control Towerの予防のためのルールは、SCPなどで実装されています。
AWS IAM Identity Centerを使うと、社員などの利用者が1か所から複数のAWSアカウントにサインインできます。組織で使うときは、管理アカウントで有効にします。どの人がどのアカウントを使えるかは、1か所で決めます。SCPが決めるのは、アカウントで使える権限の上限です。Identity Centerが決めるのは、誰がどのアカウントにサインインできるかです。
組織のすべてのメンバーアカウントの点検の結果は、Trusted Advisorの組織ビューでまとめて見られます。
参考にした資料
- AWS「What is AWS Organizations?」(Organizationsの定義、アカウントを分ける理由)
- AWS「Terminology and concepts for AWS Organizations」(ルート・OU・管理アカウント・メンバーアカウント、機能の範囲)
- AWS「Service control policies (SCPs)」(SCPが権限を与えないこと、管理アカウントに効かないこと)
- AWS「SCP evaluation」(FullAWSAccess、許可と拒否の引き継ぎ)
- AWS「Billing and pricing for AWS Organizations」(Organizationsの料金、請求書とOUの関係)
- AWS「Consolidating billing for AWS Organizations」(一括請求の利点)
- AWS「Effective billing date, account activity, and volume discounts」(ボリューム割引と計算の例)
- AWS「Reserved Instances」とAWS「Reserved Instances and Savings Plans discount sharing」(割引の共有)
- AWS「What Is AWS Control Tower?」とAWS「How controls work」(Control TowerとOrganizations・SCPの関係)
- AWS「What is IAM Identity Center?」(複数のアカウントへのアクセスの管理)
練習問題(全5問)
正解:操作できない。
SCPは、
正解:どの
SCPは
正解:管理アカウント
ルートに
正解:管理アカウントが、
一括請求では、
正解:アカウントBも、
一括請求では、
選んでから「採点する」を押すと、解説つきで答え合わせができます。