セクション 04 · タスク 1.4 · SAP-C02-034

AWS Resource Access ManagerによるResource共有

AWS RAM / リソース共有 / 組織 / 共有リソース / 集中管理されたリソース

このページのゴール

マルチアカウント環境で複数アカウントが同じインフラストラクチャリソースを必要とするとき、各アカウントへリソースを複製するのではなく、中央アカウントが所有する1つのリソースをAWS RAMで必要なプリンシパルへ共有するアーキテクチャを選択できることをゴールにします。

中央アカウント
↓
共有リソースを所有
↓
AWS Resource Access Manager
↓
アカウント / 組織 / OU / 対応するIAMプリンシパル
↓
分散利用

判断の中心は「別アカウントへアイデンティティとして入る」のか、「リソースそのものを複数アカウントで共同利用する」のかです。

1. AWS RAMはリソースそのものを共有する

AWS Resource Access Manager（AWS RAM）は、対応するAWSリソースを別AWSアカウントやAWS Organizationsの組織 / OUなどへ共有するサービスです。

ネットワークアカウント
└─ 中央リソース
      │
      ▼
    AWS RAM
      │
 ┌────┼────┐
 ▼    ▼    ▼
アプリ A アプリ B アプリ C

リソースを各利用側アカウントへコピーする仕組みではありません。リソースは所有者アカウントに存在したまま共有されます。

2. 中央所有と分散利用を分ける

共通リソースをアカウントごとに作ると、設定差異や重複管理が増えます。AWS RAMを使えば、共有可能なリソースを1か所で所有・管理しながら複数アカウントから利用できます。

集中管理されたリソース
        │
        ▼
      AWS RAM
        │
   ┌────┼────┐
   ▼    ▼    ▼
利用側アカウント

代表的な候補にはAmazon VPCサブネット、AWS Transit Gateway、Route 53 Resolverルール、VPC IPAMプール、AWS Cloud WANリソース、EC2キャパシティ予約などがあります。ただしすべてのAWSリソースがRAM対応ではありません。

3. リソース共有は3要素で考える

AWS RAMではリソース共有を作成して共有を定義します。

要素	判断
共有リソース	何を共有するか
管理アクセス許可	利用側へどの操作範囲を許容するか
プリンシパル	誰へ共有するか

リソース共有
=
共有リソース
+
管理アクセス許可
+
プリンシパル

4. 所有責任は所有者アカウントに残る

AWS RAMで共有してもリソース所有責任は移転しません。所有者アカウントがリソースを所有・中央管理し、利用側は許可された範囲で利用します。

所有者アカウント
├─ リソース所有責任
├─ 中央管理
└─ リソース共有
       │
       ▼
利用側

また、利用側は共有されたリソースをさらに別アカウントへ再共有できません。AWS RAMで共有できるのは自分が所有するリソースです。

5. 管理アクセス許可が共有側の最大操作範囲を決める

リソース共有ではリソースタイプごとに管理アクセス許可を関連付けます。AWS RAMが提供するAWSマネージドアクセス許可は、一般的な共有シナリオ向けの操作範囲を定義します。

対応リソースタイプではカスタマー管理アクセス許可を作成し、要件に合わせてアクションをさらに絞れます。

AWSマネージドアクセス許可
→ AWS定義の共有シナリオ

カスタマー管理アクセス許可
→ 対応リソースタイプで最小権限へ調整

すべてのリソースタイプがカスタマー管理アクセス許可に対応しているわけではありません。

6. アカウント共有では利用側IAM権限も確認する

別アカウントをプリンシパルとして共有する場合、RAM管理アクセス許可はそのアカウント内で付与可能な最大操作範囲になります。利用側アカウントの管理者は、実際に利用するユーザー / ロールへIAM権限を付与します。

RAM管理アクセス許可
→ 共有リソース側の最大操作範囲

利用側IAM権限
→ 個々のプリンシパルへ実際に付与

最終的な操作
→ 両方の範囲内

リソース共有へアカウントを追加しただけで、そのアカウント内の全プリンシパルが無条件に操作できるわけではありません。

7. プリンシパルはアカウント / 組織 / OUが基本

リソース共有の代表的なプリンシパルは次のとおりです。

AWSアカウント
AWS Organizationsの組織
組織の単位（OU）

さらに、対応するリソースタイプでは個別のIAMロール / IAMユーザーへ直接共有できます。対応可否はリソースタイプごとに異なります。

8. Organizations連携にはすべての機能とRAM側の有効化が必要

組織 / OUをプリンシパルとして使うには、AWS Organizationsがすべての機能で動作している必要があります。そのうえで、Organizationsの管理アカウントからAWS RAMの「AWS Organizationsとの共有を有効化」を有効化します。

AWS Organizations
すべての機能
        +
管理アカウント
        ↓
AWS Organizationsとの共有を有効化
        ↓
AWSServiceRoleForResourceAccessManager
        ↓
組織 / OUをプリンシパルに利用可能

AWS RAM側からこの操作を行うと、Organizationsとの信頼済みアクセスとRAM用サービスリンクロールが適切に構成されます。Organizations側で信頼済みアクセスだけを手動有効化して完了とは考えません。

9. 同一組織内は招待なしで共有できる

Organizationsとの共有が有効な状態で、同じ組織内のアカウント / 組織 / OUへ共有すると、リソース共有招待は不要です。

所有者アカウント
↓
リソース共有
↓
同一組織
↓
招待なしで範囲へ参加

一方、Organizationsとの共有を有効化していない場合は、同じ組織内の個別アカウントへ共有することはできますが、そのプリンシパルはOrganizationsメンバーシップとして扱われず招待の承認が必要です。

10. OU共有はメンバーシップ変更へ追従する

OUをプリンシパルにすると、そのOUと子OUに属するアカウントが共有範囲へ入ります。

本番OUへリソース共有
        │
        ├─ 既存アカウント → アクセス対象
        ├─ 新しいアカウント追加 → アクセス対象へ
        └─ アカウントをOU外へ移動 → OU経由アクセスを失う

アカウントIDを静的に列挙せず、OUメンバーシップとリソース共有範囲を連動できる点がマルチアカウント環境で重要です。

11. 外部共有は3つの条件を見る

組織外のAWSアカウントへ共有する場合は、次を順番に確認します。

リソースタイプが外部共有対応？
        ↓
リソース共有で外部プリンシパルを許可？
        ↓
利用側が招待を承認
        ↓
共有リソースを利用

すべてのRAM対応リソースが組織外共有に対応するわけではありません。また、外部プリンシパルを許可しないリソース共有では外部アカウントを追加できません。

12. 外部組織のOUは直接指定できない

組織 / OUプリンシパルとして指定できるのは、リソース所有者が所属する自分の組織内です。別組織のOU IDを直接プリンシパルとして指定することはできません。

別組織へ共有する場合は、リソースタイプが外部共有に対応していれば、個別AWSアカウントなどの対応プリンシパルへ共有します。

13. AWS RAMとクロスアカウントロールを使い分ける

要件	アーキテクチャ候補
中央リソースそのものを複数アカウントから利用したい	AWS RAM
別アカウントへアイデンティティとして入り、そのアカウント内リソースを操作したい	クロスアカウントロール / AssumeRole

「クロスアカウント」という言葉だけでAssumeRoleを選ばず、リソース共有なのかアイデンティティアクセスなのかを切り分けます。

14. AWS RAMはリージョンサービス

AWS RAMとリソース共有はリージョンサービスです。リージョンリソースを共有する場合は、リソースが存在する同じリージョンでリソース共有を作成します。

リージョンリソース
ap-northeast-1
        ↓
リソース共有
ap-northeast-1

利用側もそのリージョンリソースをリソースが存在するリージョンから利用します。

15. グローバルリソース共有のホームリージョンはus-east-1

AWS RAMが対応するグローバルリソースを含むリソース共有は、現行仕様では指定ホームリージョンである米国東部（バージニア北部） / us-east-1に作成します。

サポート対象グローバルリソース
↓
AWS RAMリソース共有
↓
us-east-1

これはリソース自体がus-east-1限定になるという意味ではありません。グローバルリソースは引き続きグローバルリソースとして利用されます。

16. リソースタイプごとの機能を確認する

アーキテクチャ判断では、対象リソースタイプについて次の機能を確認します。

AWS RAMで共有可能か
組織外アカウントへ共有可能か
IAMロール / ユーザーへ直接共有可能か
カスタマー管理アクセス許可に対応するか

「RAM対応 = すべての共有方式に対応」ではありません。

17. 障害モード

共有すると所有責任が移ると思う

所有責任は所有者アカウントに残ります。

利用側が共有リソースを再共有できると思う

共有できるのは自分が所有するリソースです。

同じ組織なら常に招待不要だと思う

Organizationsとの共有をAWS RAM側で有効化している必要があります。

Organizations側で信頼済みアクセスだけ有効化すればよいと思う

管理アカウントからAWS RAMのOrganizationsとの共有を有効化し、RAM用サービスリンクロールを作成する手順を使います。

外部アカウントへRAM対応リソースなら必ず共有できると思う

リソースタイプの外部共有対応とリソース共有側の外部プリンシパル許可を確認します。

RAM管理アクセス許可だけで利用側の全ユーザーが使えると思う

アカウント共有では利用側プリンシパルへのIAM権限も必要です。

別組織のOUを直接プリンシパルにできると思う

組織 / OUプリンシパルは自組織内です。

リージョンリソースを任意リージョンのリソース共有へ入れられると思う

リージョンリソースとリソース共有は同じリージョンです。

18. SAP-C02判断フロー

複数アカウントで同じリソースを利用？
        │
        ▼
AWS RAM対応リソース？
   ┌────┴────┐
   │         │
  いいえ      はい
   │         │
別方式       ▼
        中央所有が有効？
             │
             ▼
        リソース共有
             │
      リソース + 権限 + プリンシパル
             │
             ▼
      同一組織？
        ┌────┴────┐
        │         │
       はい      いいえ
        │         │
 Organizations   外部共有対応？
 共有有効？       │
        │            ▼
        ▼        外部プリンシパル許可
 組織 / OU範囲       + 招待
        │
        ▼
集中管理されたリソース
+
分散利用

19. まとめ

AWS RAMは、リソースを複製せず、所有者アカウントで中央所有したまま複数アカウントへ共有するためのサービスです。

リソース共有
=
共有リソース
+
管理アクセス許可
+
プリンシパル

Organizationsとの共有を有効にすると組織 / OU単位で招待なしに共有でき、OUメンバーシップ変更を共有範囲へ反映できます。外部共有ではリソースタイプの対応、外部プリンシパル許可、招待を確認します。

また、アカウント共有ではRAM管理アクセス許可と利用側IAM権限の両方を見ます。最後に、リソース共有ならAWS RAM、別アカウントへアイデンティティとして入るならクロスアカウントロールと要件を切り分けます。

20. 主要AWS公式資料

AWS Resource Access Manager — AWS RAMの概要
AWS Resource Access Manager — AWSリソースの共有
AWS Resource Access Manager — 共有可能なAWSリソース
AWS Resource Access Manager — AWS RAMの管理権限
AWS Resource Access Manager — AWS Organizationsとの共有を有効化
AWS Resource Access Manager — リージョン単位のリソースとグローバルリソース

理解確認

このページの内容を16問で確認します。

理解確認16問へ →