AWS ソリューションアーキテクト – アソシエイト学習サイト CP 学習サイトへ戻る

Organizations・Control Tower・IAM Identity Center

会社が AWS を本格的に使うと、本番・開発・監査用など AWS アカウントがいくつも増えます。AWS Organizations・AWS Control Tower・AWS IAM Identity Center は、複数のアカウントをまとめて管理し、ルールと権限を一元的に配るためのサービスです。SAA では「複数アカウントのセキュリティ戦略」として、SCP の効き方と、どのサービスを選ぶかが問われます。

ひとことで言うと: Organizations は「アカウントの組織図」、Control Tower は「組織図と社内ルールを最初からそろえて作る仕組み」、IAM Identity Center は「社員が 1 回のサインインで担当のアカウントに入れる受付」です。

たとえるなら、本社（管理アカウント）の下に部署（OU）があり、各部署に支店（アカウント）がある会社です。本社が「この部署では〇〇をしてはいけない」と決めると、その部署の全支店に効きます。

このページで押さえる論点

ポリシーの評価ルール（明示的な拒否・許可・暗黙の拒否）、クロスアカウントロール、Condition の aws:PrincipalOrgID は AWS IAM のページで扱っています。

Organizations の構成とアカウントを分ける理由

AWS Organizations は、複数の AWS アカウントを 1 つの組織にまとめて管理するサービスです。組織を作ったアカウントが管理アカウントになり、組織に入るほかのアカウントはメンバーアカウントになります。アカウントはOU（組織単位 = Organizational Unit。アカウントを入れるフォルダのようなもの）にまとめ、OU は入れ子にできます。一番上の入れ物をルートと呼びます。

用語意味試験でのポイント
管理アカウント組織を作り、アカウントの招待・作成、ポリシーの管理、請求の支払いをするアカウントSCP が効かないので、ワークロード（アプリやデータ）は置かず、管理の作業だけに使う
メンバーアカウント組織に所属するアカウント。同時に所属できる組織は 1 つだけSCP の制限を受ける。新規作成するか、既存アカウントを招待して参加させる
OU（組織単位）アカウントをまとめる入れ物。入れ子にできる「本番 OU」「開発 OU」のように分け、OU に付けたポリシーを配下の全アカウントに効かせる
ルート組織の最上位の入れ物ルートに付けたポリシーは組織内のすべてのアカウントに効く

アカウントを分けるのは、アカウントが AWS でいちばん強い境界だからです。本番と開発を別のアカウントにすれば、開発者の操作ミスが本番に及ばず、請求もアカウントごとに分かれます。監査ログを保管するアカウントを分ければ、ほかのアカウントの管理者がログを消すこともできません。

SCP の効き方

SCP（サービスコントロールポリシー）は、ルート・OU・アカウントに付けて、そのアカウントの IAM ユーザーやロールが使える操作の上限を決めるポリシーです。「ガードレール（はみ出し防止の柵）」とも呼ばれます。IAM ポリシーとの関係は IAM のポリシー評価ルールで詳しく扱っています。ここでは組織の階層でどう効くかを押さえます。

組織を作ると、すべての操作を許可する FullAWSAccess という SCP が自動でルート・OU・アカウントに付きます。そこに「この操作は禁止」という Deny の SCP を足していく拒否リスト方式がよく使われます。逆に FullAWSAccess を外して、使ってよいサービスだけを Allow する許可リスト方式もあります。

SCP と対になるものとして、RCP（リソースコントロールポリシー）もあります。SCP が「組織の人が何をできるか」の上限なのに対し、RCP は「組織のリソース（S3 バケットなど）に何ができるか」の上限で、組織の外の人からのアクセスにも効きます。

操作できるシミュレーター

SCP の階層を切り替えて、操作が上限の内側か見てみよう

ルートには FullAWSAccess（すべて許可）が付いています。アカウントが入る OU と、試す操作を選んでください。

ルート FullAWSAccess
アカウントが入る OU
試す操作とアカウント

※簡略化しています: アカウント自身には FullAWSAccess だけが付いている想定です。操作はサービス単位にまとめています。SCP の内側でも、実際に使うには IAM ポリシーで Allow されている必要があります。管理アカウントは本来 OU に入れずルートの直下に置きます。

Organizations のそのほかの機能

機能内容使う場面
一括請求（コンソリデーティッドビリング）全アカウントの請求を管理アカウントにまとめて支払う。使用量を合算するので、量が多いほど安くなる料金の割引を受けやすい。リザーブドインスタンスや Savings Plans の割引を組織内で共有できる「複数アカウントの請求をまとめたい」「割引を全アカウントで使いたい」
組織の証跡（CloudTrail）管理アカウント（または委任管理者）で作ると、全メンバーアカウントの操作ログを 1 つの S3 バケットに集める。メンバー側では証跡を止めたり消したりできない「全アカウントの API 操作を一元的に記録したい」
委任管理者GuardDuty・Security Hub などの管理を、管理アカウント以外のメンバーアカウント（セキュリティ担当のアカウントなど）に任せる管理アカウントでの作業を減らし、セキュリティのサービスを専用アカウントから一元管理する
AWS RAM（Resource Access Manager）サブネット・Transit Gateway などのリソースを組織内のほかのアカウントと共有する「VPC のサブネットを複数アカウントで共有したい」
タグポリシー・バックアップポリシーなどタグの付け方のルールや、AWS Backup のバックアップ計画を組織全体にそろえて適用する「全アカウントでタグの表記をそろえたい」「全アカウントのバックアップ設定を統一したい」

権限の上限を決める SCP・RCP に対して、タグポリシーやバックアップポリシーは「管理用のポリシー」で、アクセスの許可・拒否には関係しません。

AWS Control Tower

AWS Control Tower は、ベストプラクティスに沿ったマルチアカウント環境（ランディングゾーン）を自動で作り、その後もルールが守られているかを見張り続けるサービスです。裏側では Organizations・IAM Identity Center・CloudTrail・AWS Config などを組み合わせて設定します。Organizations を手作業で設定する代わりに、「最初から正しくそろった環境」をすばやく用意したいときに選びます。

要素内容
ランディングゾーン組織・OU・共有アカウント（ログを集めるログアーカイブアカウントと、監査用の監査アカウント）・ログの集約をまとめて用意した環境
コントロール（旧称: ガードレール）OU 単位で適用するルール。予防的（違反する操作をそもそも防ぐ）・検出的（違反した状態を見つけて知らせる。例: S3 バケットにパブリックな読み取りが許可されていないか）・プロアクティブ（リソースを作る前に設定をチェックする）の 3 種類がある
Account Factory決められた設定（ネットワーク・コントロールなど）がそろった新しいアカウントを、テンプレートから発行する仕組み
ダッシュボードコントロールに違反しているアカウント・リソースを一覧で確認できる

Organizations は「組織とポリシーを作る部品」、Control Tower は「その部品を使って、ルールのそろった環境を自動で組み立てて見張る仕組み」と区別します。問題文に「ベストプラクティスに沿ったマルチアカウント環境を素早く」「新しいアカウントを標準の設定で払い出す」「ガードレール」とあれば Control Tower です。

IAM Identity Center

AWS IAM Identity Center（旧称: AWS Single Sign-On）は、社員が 1 回サインインするだけで、組織内の複数の AWS アカウントや業務アプリに入れるようにするサービスです。基本的な説明は IAM のフェデレーションと IAM Identity Center にあります。ここでは組織全体での使い方を押さえます。

AWS Directory Service と Active Directory のフェデレーション

多くの会社は、社員のアカウントを Active Directory（AD） という Microsoft のディレクトリサービス（社員名簿とログインの仕組み）で管理しています。AWS Directory Service は、AWS で AD を使えるようにするサービスで、SAA では次の 2 つの区別が問われます。

種類仕組み使う場面
AWS Managed Microsoft ADAWS 上に本物の AD をマネージドで動かす。社内の AD と信頼関係を結ぶこともできるAWS 上に AD が必要（AD に参加させる EC2 の Windows サーバーなど）。社内 AD と連携しつつ AWS 側にも AD を置きたい
AD ConnectorAWS 側にはユーザーを持たず、認証の問い合わせを社内の AD に中継するだけの窓口（プロキシ）社内の AD をそのまま使い、AWS に名簿のコピーを置きたくない

どちらも IAM Identity Center の ID ソースにでき、AD の社員が AD のパスワードでサインインして、IAM ロールの一時的な認証情報で AWS を操作できます（IAM ロールを使ったフェデレーション）。AD の社員ごとに IAM ユーザーを作る必要はありません。

問題文のキーワード → 選ぶべき答え

問題文の言い回し答えと理由
「複数アカウントの請求をまとめる」「割引を全アカウントで共有」Organizations の一括請求
「組織内の全アカウントで、特定のリージョン・サービスの利用を禁止」ルートや OU に付ける SCP
「メンバーアカウントのルートユーザーの操作も制限したい」SCP（メンバーアカウントのルートユーザーにも効く）
「ベストプラクティスに沿ったマルチアカウント環境を素早く構築」「ガードレール」AWS Control Tower（ランディングゾーンとコントロール）
「新しいアカウントを標準の設定で自動作成」Control Tower の Account Factory
「全アカウントの API 操作ログを 1 か所に集め、メンバー側で止められないようにする」Organizations の組織の証跡（CloudTrail）
「社員が 1 回のサインインで複数の AWS アカウントに入る」「職務ごとの権限を一元管理」IAM Identity Center とアクセス許可セット
「社内の Active Directory の認証情報で AWS にサインイン。AWS 側にユーザーを複製しない」AD Connector（＋ IAM Identity Center などでロールにフェデレーション）
「AWS 上に AD が必要」「Windows サーバーを AD に参加させる」AWS Managed Microsoft AD
「サブネットや Transit Gateway を組織内のアカウントで共有」AWS RAM

引っかけポイント

まとめ: SAA 試験で押さえるポイント

確認問題

参考リンク

AWS 公式ドキュメント（外部サイトが開きます）。