アカウントA（111111111111）のEC2インスタンスには、インスタンスプロファイル経由でIAMロール AnalyticsRole がアタッチされている。アカウントB（222222222222）が所有するS3バケット reports-bucket へ、このEC2上のアプリケーションが追加のAPI呼び出し（AssumeRole等）を挟まず、既存の一時認証情報のまま GetObject できるようにしたい。この要件を実現する設計として最も適切なものを選べ。（単一選択）
- AアカウントBに新しいIAMロールを作成し、信頼ポリシーで
AnalyticsRoleをAssumeRole可能にする。EC2アプリケーションはまずこの新ロールを引き受けてからGetObjectを呼ぶ - BアカウントBの
reports-bucketのバケットポリシーで、プリンシパルにarn:aws:iam::111111111111:role/AnalyticsRoleを指定してs3:GetObjectを許可する。EC2アプリケーションは既存のAnalyticsRoleの認証情報のまま追加のAssumeRoleなしにアクセスできる - CアカウントAとアカウントBを同一のOrganizationに参加させれば、それだけで自動的にS3への相互アクセスが許可される
- DアカウントBのS3バケットをパブリックアクセス可能に設定し、
AnalyticsRoleのARNをホワイトリストとしてアプリケーション側のコードに埋め込んでチェックする
正解・解説・誤答理由・ひっかけを見る▼ open
解説
多くのAWSサービス（EC2、RDS等）はリソースベースポリシーを持たないため、クロスアカウントアクセスには
ターゲット側にロールを作り、呼び出し元が sts:AssumeRole で引き受ける方式が基本になる。
しかしS3はバケットポリシーというリソースベースポリシーを持つ数少ないサービスの一つであり、これを使うと
ロールを新たに引き受ける手順を挟まずに、呼び出し元が“自分自身の既存のIAMロールの認証情報のまま”クロスアカウントでアクセスできる。
具体的には、アカウントBの reports-bucket のバケットポリシーで、
プリンシパルに arn:aws:iam::111111111111:role/AnalyticsRole を指定して s3:GetObject を許可する。
アカウントA側は追加のAssumeRole呼び出しをせず、EC2インスタンスが元々持つ AnalyticsRole の認証情報のままS3 APIを呼べる
（リクエスト評価時にIAM側のAllow ∩ バケットポリシー側のAllowの両方が必要）。
これに対し、EC2やRDSのようにリソースベースポリシーを持たないサービスのリソースへアクセスする場合は、
ターゲットアカウント側にロールを作り明示的に AssumeRole するアプローチが必要になる。
なおLambdaはリソースベースポリシーを持つ側であり、関数のリソースベースポリシーで他アカウントのプリンシパルに
lambda:InvokeFunction を直接委任できる（S3と同じくAssumeRoleを挟まない委任が可能）。「EC2とLambdaはどちらも委任できない」と一括りにしないこと。
- A追加の
AssumeRole呼び出しを挟むことになり、「追加のAPI呼び出しを挟まない」という要件を満たさない。S3ではこの手順を挟まない方式が使える。 - C同一Organization配下であること自体はアクセス許可を自動生成しない。明示的なIAM/バケットポリシーでの許可が別途必要。
- Dパブリック公開は最小権限・セキュリティの観点で不適切。ARNチェックをアプリコード側で行うのはAWS側のアクセス制御ではなく信頼できる境界にならない。
AssumeRole）が必要」という思い込みが罠。
S3などリソースベースポリシーをサポートするサービスは、バケットポリシー側でクロスアカウントの他社ロールを直接プリンシパル許可できるため、
呼び出し元は自分のロールの認証情報のまま（追加のAssumeRoleなしで）アクセスできる場合がある。この違いを混同しないこと。