アカウント間のリソース共有設計 RAMとポリシーで安全につなぐ

この記事は SAP-C02 を目指す方に向けて、複数アカウント環境で「何を、どの仕組みで共有するか」を整理します。試験では共有できるかどうかではなく、要件に対して最小権限で運用しやすい方式を選べるかが問われます。

覚え方は3つの観点です。インフラを配る仕組み・データを見せる仕組み・操作を委譲する仕組み。この順に当てはめると迷いません。

インフラを配る AWS Resource Access Manager

RAM は Transit Gateway、サブネット、Route 53 Resolver のルール、License Manager の設定などを、組織内の別アカウントへそのまま使わせる仕組みです。使いどころはネットワークを1アカウントに集約したいとき。ネットワーク専用アカウントが大きなVPCを1つ持ち、20の業務アカウントへサブネットだけを配る構成にすると、VPCピアリングを20本張る必要がなくなり、IPアドレスの重複管理からも解放されます。共有されたサブネットに置いたENIの課金は利用側、VPC本体の管理は所有側という責任分界も覚えておきましょう。

データを見せる リソースベースポリシー

S3バケット、KMSキー、SQSキュー、Lambda関数、Secrets Manager のシークレットなどはリソース側にポリシーを書けます。使いどころは相手アカウントに継続的な読み取りだけ許したいとき。特にKMSキーは、キーポリシーで相手アカウントを許可したうえで、相手側のIAMポリシーでも許可する二重の許可が必要です。片方だけでは失敗するため、暗号化データを他アカウントへ渡す設問で頻出します。

操作を委譲する クロスアカウントIAMロール

監査チームが全アカウントを読み取る、運用チームが本番へ限定的に入る、といった要件はロールの引き受けが基本です。外部のベンダーに渡す場合は信頼ポリシーの条件に sts:ExternalId を入れ、第三者がロール名を推測して悪用する事故を防ぎます。

チェックリスト

• RAMで共有できる代表的なリソースを3つ挙げられる
• 共有サブネット構成での課金と管理の責任分界を説明できる
• 他アカウントからKMS暗号化データを読むのに必要な許可を両側で示せる
• 外部ベンダー向けロールに ExternalId を付ける理由を説明できる
• SCPによる拒否が個別の許可より優先されることを理解している

まとめ

共有の設計は、インフラはRAM、データはリソースポリシー、操作はロールという3層で考えると整理できます。そのうえで両側の許可とSCPの拒否を確認すれば、設問の選択肢はほぼ絞り込めます。

理解を確かめるにはクイズで腕試しを、最新の出題範囲はAWS認定 公式ページで必ず確認してください。