AWSマルチアカウント・ガバナンスの仕組みと設定 — どの道具がどの層で効くか

AWS Organizationsで複数アカウントを束ねたマルチアカウント環境では、「誰がどこまで触れるか」を制御する道具が層ごとに分かれています。本記事は、これらのガバナンスの道具を「どの道具がどの層で効くか」という視点で、公式ドキュメントの仕様に沿って整理します。なお仕様・条件キー名・手順は公式ドキュメントに従い、変わり得る数値や提供条件は公式の最新をご確認ください。

マルチアカウントでガバナンスが難しい理由

単一アカウントなら、「このIAMユーザーに何を許可するか」を考えれば足ります。しかしOrganizationsで複数アカウントを束ねた環境では論点が増えます。組織全体で許可の上限をどこに敷くか、アカウントをまたいでアクセスをどう割り当てるか、どの経路からのアクセスを許すか、誰が何をしたかをどう監査するか——これらが層ごとに別の道具で制御されます。

逆に言えば、道具と層の対応さえ正しく押さえれば、ガバナンス設計の見通しが立ちます。まずはその対応関係を整理します。

どの道具がどの層で効くか — 統制の道具マップ

ここが本記事の核です。ガバナンスの道具は、効く層と役割が異なります。とくに「上限を絞る道具」と「アクセスを付与する道具」を混同しないことが、事故防止の出発点です。

道具	効く層	役割
SCP（サービスコントロールポリシー）	アイデンティティ（IAMユーザー/ロール）	許可の上限ガードレール（付与はしない）
RCP（リソースコントロールポリシー）	リソース	許可の上限ガードレール（付与はしない）
リソースベースポリシー	リソース	アクセスを付与する（誰が何をできるか）
IAM Identity Center	マルチアカウント	複数アカウントへの権限割当を一元化
Console Private Access	経路	ブラウザ経路の統制（VPCエンドポイント＋PrivateLink）
AWS Sign-inポリシー	事前認証	どのネットワークから・どのアカウントにサインインできるか

最も重要な区別は、SCPとRCPの性質です。いずれも「許可の上限」を定めるガードレールであって、それ自体は何の許可も付与しません。SCPはメンバーアカウントのIAMユーザー/ロール（rootを含む）に効く上限、RCPはリソースに効く上限です。一方、実際にアクセスを付与するのはリソースベースポリシー（およびアイデンティティベースのポリシー）です。

公式の定義では、**実効的な権限は「SCP・RCPで許可された範囲」と「アイデンティティ/リソースのポリシーで付与された範囲」の論理積（重なり）**になります。つまり、ガードレールを通過し、かつ明示的に付与されたものだけが効きます。「SCPで許可を与える」「RCPでアクセスを付与する」という理解は誤りで、ここを取り違えると統制設計の事故につながります。

新しく加わったのが、AWS Sign-inのコンソール向けポリシーです。2026年6月にGA（一般提供）され、全商用リージョン（東京を含む）で追加費用なしに使えます。マネジメントコンソールへのサインインに対し、アカウント単位のリソースベースポリシーと、組織横断のRCPを適用でき、「どのネットワークからサインインできるか」「どのアカウントに到達できるか」を制御できます。Console Private Accessと組み合わせることもできます。

ネットワークの制御には、aws:SourceIp・aws:SourceVpc・aws:SourceVpce・aws:VpcSourceIp・aws:RequestedRegion といったAWSグローバル条件キーを使います。Sign-in固有の条件キーは signin:PrincipalArn の一つだけで、これは認証が完了する前（事前認証フェーズ）にサインインを開始したプリンシパルを識別するためのものです。

ここに設計上の落とし穴があります。公式仕様では、1回のリクエストには aws:SourceIp（パブリック経由）か aws:SourceVpc（VPCエンドポイント経由）のどちらか一方しか含まれません。そのため両方の経路をまとめて拒否したい場合は、NotIpAddressIfExists のような IfExists 系の演算子を使うか、ステートメントを分ける必要があります。これを知らずに単純な拒否を書くと、意図した経路制御が効かないことがあります。

ガバナンスを組み立てる順序

道具マップを、統制を組み立てる順序に並べ直すと、次のようになります。

1. 事前認証：AWS Sign-inポリシーで、サインインを許可するネットワークやアカウントを絞る。
2. 経路：Console Private Accessで、ブラウザの通信をVPCエンドポイント経由に閉じる。
3. 組織の上限：SCP/RCPで、組織・アカウント・リソースの許可の上限（ガードレール）を敷く。
4. アクセスの付与：リソースベースポリシーやIdentity Centerの割当で、必要な権限だけを付与する。
5. 監査：CloudTrailなどで、誰が何をしたかを記録・追跡できるようにする。

IAM Identity Centerは、この流れの「割当」を担う道具です。複数アカウントへの権限割当を一元管理でき（組織インスタンスの機能）、アカウントごとに個別管理する煩雑さと設定ミスを減らせます。

ここで主語を明確にしておきます。本記事で扱う「認可」「最小権限」は、人間やアカウント（IAM・組織レベル）を主語にしたものです。 生成AIエージェントが実行時に外部リソースへアクセスする際の認可は、主語も設計も別物です。そちらの深掘りは専門領域として、Bedrock Guardrailsとエージェントの制御 のようなAIセキュリティの記事に接続します。

設定の主体と、多層防御としての位置づけ

ここまでの道具の多く——SCP/RCP、IAM Identity Centerの組織インスタンス、Console Private Accessのネットワーク設計など——は、AWS Organizationsの管理アカウント権限やVPC設計を伴う、組織レベルで設定するものです。メンバーアカウント単体では設定できない点を、設計時に押さえておきます。

また、これらは多層防御（defense in depth）の一部であり、「導入すれば完全に安全」ではありません。層を組み合わせ、運用と監査で継続的に確かめてはじめて、統制として機能します。SCP/RCPの上限、付与ポリシー、経路、事前認証、監査のどれか一つに寄せきるのではなく、層として重ねることが設計の前提になります。

Console Private Accessの対応範囲

東京リージョンでの利用可否は、設計上よく問われる点です。Console Private Accessは全商用リージョンで利用でき、東京リージョンも対象です。 ブラウザの通信をVPCエンドポイント経由に閉じ、パブリックインターネットを経由させずにコンソールを使えます。費用は、PrivateLinkのVPCエンドポイントの利用とデータ処理に対して発生します（具体的な金額は変動するため、公式のVPC料金ページでご確認ください）。

ただし、対応するのはサービスコンソールのサブセットである点に注意が必要です。ガバナンス関連のコンソール——IAM、AWS Organizations、KMS、EC2、S3、CloudTrail、GuardDuty、Security Hubなど——は対応していますが、すべてのコンソールが対象ではありません。たとえばAWS BillingコンソールはPrivate Access経由では利用できず、CloudShellやDefault Regionの設定などは無効化されることがあります。「東京で使えるが、全コンソールが対象ではない（主要なガバナンス系は対応）」と正しく押さえておきます。

ガバナンスも”agentic”に — AWS Security Agent（プレビュー）

統制の領域でもAIによる支援が現れ始めています。AWS Security Agentの脅威モデリング機能は、設計ドキュメントやソースコードを解析してSTRIDEの6カテゴリで脅威と緩和策を生成し、KiroやClaude CodeといったIDEと連携して、設計段階で脅威を洗い出す「左シフト」を後押しします。

ただし本機能は執筆時点でパブリックプレビューで、提供リージョン（東京での可否を含む）や正式提供後の料金は公式に明示されていません。本記事では断定せず、「ガバナンスがagentic化しつつある」流れの紹介に留めます（利用検討時は公式の最新情報をご確認ください）。

まとめ — ガバナンス設計のチェックリスト

マルチアカウント環境のガバナンスは、道具と層の対応を押さえたうえで、次の観点で設計します。

1. 上限と付与を分ける：SCP/RCPは上限ガードレール（付与しない）、リソースベースポリシーが付与する、という区別を取り違えない。
2. 実効権限は論理積：ガードレールを通過し、かつ付与されたものだけが効く。
3. 経路と事前認証を絞る：Console Private AccessとSign-inポリシーで、どこから・どのアカウントに入れるかを制御する。
4. 割当を一元化する：Identity Centerで複数アカウントの権限割当をまとめ、設定ミスを減らす。
5. 監査を欠かさない：CloudTrailなどで記録し、多層防御の一部として継続的に確かめる。
6. 設定の主体を押さえる：SCP/RCPやIdentity Centerの組織インスタンスは、組織の管理アカウント権限で設定する。

マルチアカウント・ガバナンスは、道具がどの層で効くかという対応関係を起点に、上限と付与を分け、経路・事前認証・監査を組み合わせて設計します。単一アカウントでのIAMの初期設定そのものは、別の入門記事で扱う範囲です。

出典

• AWS Sign-in でコンソールにリソースベースポリシー/RCPを適用（AWS What’s New, 2026-06-16）
• AWS Sign-In condition keys reference（公式docs）
• Service Authorization Reference: AWS Sign-In（公式docs）
• AWS Organizations サービスコントロールポリシー（SCP・公式docs）
• AWS Organizations リソースコントロールポリシー（RCP・公式docs）
• Identity-based policies と resource-based policies（IAM公式docs）
• AWS Management Console Private Access（公式docs）
• Console Private Access の対応リージョン・コンソール・機能（公式docs）
• IAM Identity Center とは（公式docs）
• AWS Security Agent による脅威モデリング（AWS What’s New）