AWS CLF(Cloud Practitioner)対策
Organizationsと一括請求
このレッスンでは、複数の AWS アカウントをまとめて管理する AWS Organizations の利点を説明できるようになります。請求をまとめる効果と、権限に上限をかける仕組みの2本立てで整理します。
自分でサーバーを建てていたときは
部署ごとにサーバーを別々に調達すると、経理は部署の数だけ請求書を受け取ります。まとめ買いの割引は効かず、どこかの部署が余らせている容量を別の部署が使うこともできません。さらに、root のパスワードを渡した相手が何をするかは、渡した側にはもう止められませんでした。
AWS でも、本番環境と開発環境、部署ごとにアカウントを分けるのは推奨される作り方です。アカウントを分けると事故の影響範囲が閉じるからです。ただし分けたままだと、オンプレミスと同じ「請求もバラバラ、統制も効かない」状態になります。それを解くのが Organizations です。
Organizations の構造
組織はひとつの管理アカウント(management account)と、その配下のメンバーアカウントで構成されます。アカウントは組織単位(Organizational Unit, OU)というフォルダのような入れ物にまとめられ、本番用の OU、開発用の OU といった分け方をします。
一括請求(Consolidated Billing)の利点
請求を管理アカウントに集約すると、次の効果があります。
| 効果 | 内容 |
|---|---|
| 請求書がひとつになる | 経理はアカウントの数だけ処理する必要がなくなります |
| ボリュームディスカウント | 組織全体の使用量を合算して単価の階層が判定されるため、単独のときより有利になります |
| 購入した割引枠の共有 | リザーブドインスタンスや Savings Plans の未使用分を、組織内の他アカウントが活用できます |
| 内訳は保たれる | 支払いはまとまりますが、どのアカウントがいくら使ったかは分けて見られます |
「アカウントを分けたままコストは最適化したい」という要件には一括請求が答えになります。
サービスコントロールポリシー(SCP)
SCP は OU やアカウントに対して、使える権限の上限を定める仕組みです。ここを正確に押さえてください。
- SCP は権限を与えません。あくまで上限(ガードレール)を決めるだけです
- 実際に何ができるかは、SCP が許している範囲と IAM ポリシーが許している範囲の重なりで決まります
- SCP で禁止したことは、そのアカウントの管理者権限を持つ人でも実行できません
- 「特定リージョン以外を使わせない」「特定のサービスを組織全体で禁止する」といった統制に使います
IAM ポリシーが「この人に何を許すか」であるのに対し、SCP は「このアカウントでは何が可能か」を決めます。粒度が違うので、どちらか一方では代わりになりません。
試験ではこう出る
- 「複数アカウントの請求をまとめたい」「経理の手間を減らしたい」→ 一括請求
- 「使用量を合算して割引を効かせたい」「未使用のリザーブドインスタンスを無駄にしたくない」→ 一括請求
- 「アカウントごとの利用額は引き続き把握したい」→ 一括請求でも内訳は見られる
- 「組織全体で特定サービスの利用を禁止したい」「管理者にも触らせたくない操作がある」→ SCP
- 「アカウントを役割ごとにグループ分けして管理したい」→ 組織単位(OU)
引っ掛けは、SCP を「権限を付与する仕組み」と説明する選択肢です。SCP は上限を絞るだけで、単体では誰にも何も許可しません。もうひとつ、新しいアカウント群を標準構成で払い出す話が出たら AWS Control Tower が候補になります。
まとめ
- Organizations は管理アカウントとメンバーアカウント、OU で構成されます
- 一括請求は請求書の集約、ボリュームディスカウント、割引枠の共有をもたらします
- 支払いはまとまっても、アカウント別の内訳は失われません
- SCP は権限の上限を決めるガードレールで、権限そのものは付与しません
復習ミニクイズ
ある企業は部署ごとに AWS アカウントを分けて運用しています。アカウントの分離は維持したまま、組織全体で「特定のリージョン以外は使用できない」という制限を、各アカウントの管理者にも解除できない形でかけたいと考えています。最も適切な仕組みはどれですか。