AWS Resource Access Manager（AWS RAM）は、1つのアカウントで作ったリソースを、他のAWSアカウントや組織・OU、IAMロール／ユーザーへ安全に共有するためのサービスです。マルチアカウント構成が育ち、VPCサブネットやTransit Gatewayを部門ごとに複製したくない——そんな場面で使います。この記事では、リソース共有（Resource Share）を構成する「リソース・プリンシパル・managed permissions」の仕組みを実装者目線で整理し、AWS Organizationsとの統合、共有できるリソースタイプ、IAMのクロスアカウントロールやPrivateLinkとの使い分け、そして「どのマルチアカウント要件なら採用すべきか・単一アカウントやロール委譲で足りる場面はどこか」までが、この記事で示す判断軸です。あわせて、Organizations連携の有効化からサブネットをOUへ共有し、共有先アカウントで見えることを確かめるまでを、AWS CLIとTerraformの実行例で追います。記載は2026年9月時点の公式ドキュメントに基づきます。
まとめ：AWS RAMは「リソースそのものを複数アカウントで共用する」土台
AWS RAMの役割は、アカウントをまたいでリソースの実体を1つに保ったまま、複数の利用者アカウントから使えるようにすることに尽きます。各アカウントでVPCやTransit Gatewayを個別に立てる代わりに、所有アカウントで1回作り、RAMで共有先を指定する——これで重複プロビジョニングと構成のばらつきを同時に減らせます。AWS RAMのFAQが示すとおり、RAM本体での共有に追加料金は発生しません。コストは共有した基盤リソース（Transit Gatewayのデータ処理料など）の実利用分にのみかかります。
採用の分かれ目はマルチアカウントの規模と共有対象です。共有ネットワークを複数アカウントで束ねたい、License Managerのライセンスを組織横断で使い回したい、Route 53 Resolverの解決ルールを全アカウントに配りたい——こうした「リソースの実体を共用したい」要件が固定化したら採用の目安になります。逆に、他アカウントのAPIを一時的に呼びたいだけなら、後述するIAMのクロスアカウントロールで足ります。
実装で押さえる点は3つです。組織内へ招待なしで配るには管理アカウントでenable-sharing-with-aws-organizationを1回実行すること、VPCサブネットのように組織の外へは共有できない種類があること、そして組織・OU宛に共有しても共有先の管理者がIAMポリシーを付けるまでは使えないことです。以降で、共有の構成要素、コマンドでの作り方、採用・見送りを分ける具体的な条件の順に扱います。
AWS RAMの全体像と、リソース共有が必要になる実務上の理由
最初に、RAMが何を共有する仕組みなのかを押さえます。ここを「アカウントを越えた権限付与」と混同すると、後段のプリンシパル設計やIAMとの使い分けがぼやけます。
AWS RAMの定義と、実体を複製せず1つに保つという基本発想
AWS RAMの公式ユーザーガイドによれば、RAMは、あるアカウントが所有するリソースを、他のAWSアカウント・AWS Organizationsの組織／OU・IAMロールやユーザーへ共有するサービスです。共有先のアカウントからは、そのリソースが自分のアカウントにあるかのように参照・利用できます。要点は、リソースの実体は所有アカウントに1つだけ存在し、コピーは作られないことです。共有をやめれば、共有先からの参照が外れるだけで、リソース自体は所有アカウントに残ります。
この発想が効くのは、複数アカウントで同じネットワークや基盤を共用したいケースです。たとえばVPCサブネットを共有すれば、複数のアプリアカウントが同一VPC内にリソースを配置でき、VPCピアリングやアドレス設計の重複を避けられます。「アカウントは分けたいが、土台のネットワークは1つに寄せたい」という要求に、リソースの複製なしで応えるのがRAMの立ち位置です。
もう1つ前提として、RAMはリージョン単位のサービスです。共有先のプリンシパルは、リソースが作られたのと同じリージョンからしか共有リソースを使えません。東京リージョンで作ったサブネットを共有すれば、共有先も東京リージョンで使う、という対応関係になります。
シングルアカウント運用や個別複製の限界と、共有に切り替える判断材料
マルチアカウント構成でネットワークや基盤リソースをアカウントごとに個別に立てると、同じ設定を何度も再現することになり、構成のドリフト（ばらつき）と運用工数が積み上がります。Transit Gatewayを部門アカウントごとに作れば、相互接続とルーティングの設計は指数的に複雑になりがちです。RAMで1つのTransit Gatewayを共有すれば、接続の中心を1点に集約でき、設計と監査の対象を絞れます。
共有へ切り替える代表的な軸は次の3つです。実務ではまず「共有ネットワーク」から入り、必要に応じてライセンスや名前解決へ広げるのが無理のない順序です。
- ネットワーク基盤：VPCサブネットやTransit Gatewayを共有し、アカウント間の接続とアドレス設計を1点に集約する
- ライセンス・キャパシティ：License Manager設定やEC2キャパシティ予約を組織で共用し、コストと在庫を無駄なく回す
- 名前解決・ガバナンス：Route 53 ResolverルールやIPAMプールを配布し、全アカウントで一貫した設定を保つ
リソース共有の3要素とAWS Organizations統合の仕組み
RAMの実力は、共有の単位である「リソース共有」をどう組むかに集約されます。リソース共有は「リソース・プリンシパル・managed permissions」の3要素で定義します。
リソース・プリンシパル・managed permissionsの役割
1つ目のリソースは、共有対象そのものです。共有できるのはリージョナルリソースなら共有と同一リージョンのもの、グローバルリソースはus-east-1（バージニア北部）のリソース共有に含めるものに限られます。自分が所有するリソースだけが共有でき、他から共有されたリソースを再共有することはできません。2つ目のプリンシパルは共有先で、個別のAWSアカウント・Organizationsの組織全体・OU・IAMロール／ユーザーを指定できます（IAMロール／ユーザーへ共有できるかはリソースタイプに依存）。
3つ目のmanaged permissions（管理アクセス許可）は、共有先のプリンシパルが共有リソースに対してできる操作を定めます。リソースタイプごとに関連付けられるのは1つのmanaged permissionだけです。managed permissionsの公式解説にあるとおり、AWSが用意する「AWSマネージド」と、最小権限に合わせて自作する「カスタマー管理」の2種があり、共有先のアカウントに与えられる操作はこのmanaged permissionが上限になります。複数の版があるmanaged permissionは、既定に指定された版しか付けられません。IAMのプリンシパルや権限の考え方はAWS IAMの仕組みとユーザー/ロール/ポリシーの違いを実装者目線で解説した記事に整理しているので、共有先での実効権限を詰める前提として確認してください。
見落としやすいのは、組織やOUへ共有しても共有先アカウントの全員がすぐ使えるわけではない点です。公式の共有手順ページによると、共有先アカウントの管理者が、共有リソースのARNへのAllowを含むIDベースのポリシーを自アカウントのプリンシパルに付けて初めて操作できます。そのポリシーでもmanaged permissionを超える操作は許されません。例外は所有アカウント自身で、組織やOUの範囲に所有アカウントが含まれると、所有アカウントの全プリンシパルがmanaged permissionの範囲で共有リソースにアクセスできる状態になります（RAMが付けるリソースベースポリシーが"Principal": "*"を使うため）。
AWS Organizationsとの統合と、招待なしで組織・OUへ共有する仕組み
共有先を個別のアカウントIDで列挙する代わりに、AWS Organizationsと統合すると組織全体または特定OUをプリンシパルに指定できる点が要点です。組織内での共有を有効化すると、通常は必要な招待の承諾プロセスが不要になり、対象アカウントは共有を自動で受け取れる仕組みです。OUを指定すれば、そのOUと配下の子OUに属するアカウントがまとめて対象になり、アカウントをOUへ追加すれば自動で共有が届き、組織から外せば自動でアクセスを失います。アカウントの増減に合わせて共有先を手作業で足し引きする手間が消えるため、アカウントが継続的に増える組織ほど効果が出ます。
有効化には条件があります。組織が「すべての機能」モードであること、そして管理アカウントからRAMのコンソールかenable-sharing-with-aws-organizationで有効化することです。Organizations側のコンソールやenable-aws-service-accessで信頼されたアクセスを有効にしただけでは、RAM用のサービスリンクロールAWSServiceRoleForResourceAccessManagerが作られず、組織内共有ができません。ここは手順の章で実行例を示します。
AWSの発表（2026年2月27日）で、アカウントが組織を離れても共有を維持するRetainSharingOnAccountLeaveOrganizationパラメータと、同名の条件キーram:RetainSharingOnAccountLeaveOrganizationが追加されました。組織の再編やM&Aでアカウントを別組織へ移しても、Route 53 ResolverルールやTransit Gateway、IPAMプールといった共有が途切れないよう設定でき、条件キーを使えばSCPで組織横断に一貫した方針を強制することもできます。
ただし効く範囲は限定的です。公式の共有手順ページによれば、この設定はアカウントを個別に指定した共有にだけ効き、OU宛や組織全体宛の共有には効きません。allowExternalPrincipalsがtrueであることが前提で、新しいリソース共有を作るときにしか設定できず、VPCサブネットのような組織内限定のリソースはその共有に入れられません。有効にすると組織内のアカウントにも招待が送られ、承諾後は外部プリンシパルと同じ扱いになります。「組織を移っても共有が続く」のはTransit GatewayやResolverルールなど組織外へ共有できる種類をアカウント宛で配ったときだけ、と読んでおくのが正確です。マルチアカウント統制の土台となるOrganizations側の仕組みはAWS Organizationsのマルチアカウント管理・SCP/RCP・一括請求を解説した記事で扱っているので、共有先の制御とあわせて押さえてください。
共有できるリソースタイプの代表例と、共有先での見え方・所有境界
共有可能なリソースタイプはネットワーク系を中心に幅広く、対象は順次拡大しています。共有可能リソースの公式一覧に掲載されているリソースタイプは、2026年9月時点で80件超です。代表例は次の通りで、すべてがIAMロール／ユーザーへ共有できるわけではない点は導入時に公式ドキュメントで確認します。
| 分類 | 共有できるリソース例 | 典型的な用途 |
|---|---|---|
| ネットワーク | VPCサブネット／Transit Gateway | 共有VPC・接続の集約 |
| 名前解決・IP | Resolverルール／IPAMプール | DNS解決とIP割当の統一 |
| ライセンス | License Manager設定 | ライセンスの共用 |
| データ・他 | Aurora／Network Firewall等 | DB・設定の共用 |
共有されたリソースは、共有先アカウントのコンソールやAPIから自分のリソースと並んで見えます。たとえば共有サブネットは、共有先アカウントがそのサブネット内にEC2やロードバランサーを起動できるようになる、という見え方です。所有と課金の境界は所有アカウント側に残るため、「誰が所有し、誰が使うか」を分けて設計できます。なお、アベイラビリティーゾーンの名前（ap-northeast-1aなど）と物理的な位置の対応はアカウントごとに異なるため、サブネットのようにAZに結び付くリソースを共有するときは、アカウント間で共通のAZ ID（apne1-az1など）で位置をそろえて会話するのが安全です。
組織外やIAMへ共有できる種類を公式一覧の可否の列で見分ける方法
公式一覧の表は、リソースタイプごとに「IAMユーザー・ロールへ共有できるか」「組織外のアカウントへ共有できるか」「カスタマー管理のmanaged permissionを使えるか」「サービスプリンシパルへ共有できるか」の列を持っています。設計で効くのは前の3列です。代表的な種類を2026年9月29日時点の一覧で拾うと、次のようになります。
| リソースタイプ | 組織外へ | IAMへ | カスタマー管理 |
|---|---|---|---|
| ec2:Subnet | 不可 | 不可 | 不可 |
| ec2:TransitGateway | 可 | 不可 | 不可 |
| Resolverルール | 可 | 不可 | 不可 |
| ec2:IpamPool | 可 | 可 | 可 |
| Network Firewallポリシー | 可 | 可 | 不可 |
| License Manager設定 | 可 | 不可 | 不可 |
| ec2:PrefixList | 可 | 不可 | 不可 |
| rds:Cluster（Aurora） | 可 | 不可 | 不可 |
表中のResolverルールの正式なリソースタイプ名はroute53resolver:ResolverRule、Network Firewallポリシーはnetwork-firewall:FirewallPolicy、License Manager設定はlicense-manager:LicenseConfigurationです。
読み取れるのは、共有VPCの中心となるサブネットは組織内でしか配れず、Transit GatewayやResolverルールは取引先など組織外のアカウントにも配れる、という違いです。カスタマー管理のmanaged permissionで操作を細かく絞れる種類も限られるため、「最小権限は自作の権限で絞る」という方針を立てる前に、対象の種類がその列で「可」になっているかを確かめます。EC2のキャパシティ予約は組織外へ共有できますが、Capacity Blocksは組織内限定、という具合に同じサービス内でも扱いが分かれる例もあります。
IAMのクロスアカウントロール・PrivateLinkとの役割分担
RAMは「アカウントをまたぐアクセス」を実現する唯一の手段ではありません。IAMのクロスアカウントロールやPrivateLinkと目的が違うため、取り違えると過剰な共有や不要な結合を生みます。
クロスアカウントIAMロールとRAMの違いと実務での使い分け
IAMのクロスアカウントロールは、別アカウントのプリンシパルにロールをAssumeRoleさせ、一時的にそのアカウントのAPIを操作させる仕組みです。操作の主体は呼び出し側で、対象アカウントに「入って」作業します。対してRAMは、リソースの実体を共有先へ渡し、共有先が自分のアカウントの一部として恒常的に使う仕組みです。前者は「他アカウントで作業する権限」、後者は「他アカウントのリソースを自分の環境で使う」——この違いが使い分けの軸です。
他アカウントのS3バケットへ一時的にアクセスしたい、運用ツールから複数アカウントを横断操作したい、といった一過性・操作系の要件はクロスアカウントロールが向きます。共有サブネットやTransit Gatewayのように、複数アカウントが継続的に同じ基盤を使う要件はRAMが素直です。両者は排他ではなく、RAMで共有した基盤の上で、個別操作はロールで委譲する、という重ね方も一般的です。
PrivateLink・VPCピアリングとの違い（リソース共有か、接続の提供か）
AWS PrivateLinkは、あるアカウントのサービスへプライベートに接続させる仕組みで、リソースの所有や設定は提供側に閉じたままです。利用側はエンドポイント経由でサービスを呼ぶだけで、相手のVPCやサブネットの中身は見えません。RAMがリソースの実体を共有先の管理下に置くのに対し、PrivateLinkは接続点だけを渡す点が本質的に異なります。SaaS的にサービスを提供したい、あるいはネットワークを疎結合に保ちたい場合はPrivateLinkという選択が素直です。接続の仕組みと料金・採用判断はAWS PrivateLinkの仕組みとVPCエンドポイントとの違いを解説した記事にまとめています。
整理すると、同一VPC内に複数アカウントのリソースを同居させたいなら共有サブネット（RAM）、アカウント間をルーティングでつなぐならTransit Gateway（これもRAMで共有）、サービスへの接続だけを渡すならPrivateLink、という住み分けになります。要件が「共用」か「接続」かで最初に切り分けると迷いにくくなります。
AWS CLIでリソース共有を作成し、共有先アカウントで使うまでの手順
仕組みを理解したら、実際に共有を組む順序に落とします。共有の巧拙をほぼ決めるのは、プリンシパルの粒度とmanaged permissionの絞り方です。ここでは「ネットワークアカウントが所有するサブネットを、アプリ用OUへ共有する」構成を例に、AWS CLI v2で打つコマンドを順に示します。アカウントIDやARNは例示用の値なので、自環境の値に置き換えてください。
共有作成のステップと、Organizations有効化・承諾の要否
所有アカウントでリソース共有を作成する流れは次の通りです。個別アカウント宛と組織宛で、承諾プロセスの有無が変わる点が最大の勘所です。
- 共有したいリソース（サブネット、Transit Gateway等）を所有アカウントで用意する
- RAMでリソース共有を作成し、対象リソースを選択する
- プリンシパルとして個別アカウント／組織／OU、または対応リソースならIAMロール・ユーザーを指定する
- リソースタイプごとにmanaged permission（AWSマネージドかカスタマー管理）を選び、共有先の操作範囲を絞る
- 組織内共有を有効化していれば組織・OU宛は承諾不要、個別アカウント宛は共有先での招待承諾を経て利用開始
共有先アカウントでは、承諾（必要な場合）の後、共有されたリソースが自分のリソース一覧に現れます。managed permissionで許された範囲の操作だけが可能で、想定外の操作までは通りません。まず検証用アカウントかテスト用OUへ共有して見え方と操作範囲を確認し、そのうえで本番の組織・OUへ広げるのが安全な段取りです。
管理アカウントでOrganizations連携を有効化するコマンドの実行例
組織・OU宛に招待なしで配るには、管理アカウントの認証情報で次を1回実行します。公式手順によれば、このコマンドはどのリージョンで実行しても、RAMが使える全リージョンで組織内共有を有効にします。
# 管理アカウントで1回だけ実行する
aws ram enable-sharing-with-aws-organization
# 期待する出力
{
"returnValue": true
}実行者にはram:EnableSharingWithAwsOrganization、iam:CreateServiceLinkedRole、organizations:enableAWSServiceAccess、organizations:DescribeOrganizationの権限が要ります。組織が一括請求機能だけのモードのままだと有効化できないため、先に「すべての機能」へ切り替えておきます。
次に、所有アカウント（ここではネットワークアカウント 111111111111）で共有を作ります。先にリソースタイプに対応するmanaged permissionを一覧し、どれが既定かを確かめておくと、共有先に渡る操作範囲を把握したまま進められます。create-resource-shareのCLIリファレンスにあるとおり、--permission-arnsを省略すると各リソースタイプの既定版が自動で付き、--allow-external-principalsの既定はtrueです。
# サブネットに付けられるmanaged permissionを確認する
aws ram list-permissions \
--resource-type ec2:Subnet \
--query "permissions[].[name,arn,isResourceTypeDefault]" \
--output table
# サブネット2つをアプリ用OUへ共有する（組織外へは出さない）
aws ram create-resource-share \
--region ap-northeast-1 \
--name shared-vpc-app-subnets \
--resource-arns \
arn:aws:ec2:ap-northeast-1:111111111111:subnet/subnet-0aaa1111bbbb22223 \
arn:aws:ec2:ap-northeast-1:111111111111:subnet/subnet-0ccc3333dddd44445 \
--principals arn:aws:organizations::111111111111:ou/o-exampleorg1/ou-ab12-cdef3456 \
--no-allow-external-principals \
--tags key=owner,value=network-team
# 関連付けが ASSOCIATED になったかを確認する（完了まで数分かかることがある）
aws ram get-resource-share-associations \
--association-type PRINCIPAL \
--query "resourceShareAssociations[].[resourceShareName,associatedEntity,status]" \
--output table--no-allow-external-principalsを付けると、その共有には組織外のアカウントを追加できなくなります。サブネットはもともと組織内限定ですが、Transit GatewayやResolverルールを共有するときは既定のtrueのままだと取引先のアカウントIDを誤って足せてしまうため、組織内で閉じる共有では明示しておくのが無難です。Transit Gatewayを同じ要領で共有し、アタッチメントやルートテーブルまでTerraformで組む手順はTransit Gatewayをクロスアカウントで構築しRAMで共有する手順を解説した記事で扱っています。
共有先アカウントで招待を承諾し、共有リソースを確認するコマンド
組織内共有を有効にしてOU宛で配った場合、共有先に招待は届かず、そのまま次の一覧に現れます。組織外のアカウントや、組織離脱後も共有を保つ設定の共有では招待が届くので、共有先アカウントの認証情報で承諾します。
# 保留中の招待を確認する（組織外・個別アカウント宛の共有のとき）
aws ram get-resource-share-invitations \
--query "resourceShareInvitations[?status=='PENDING'].[resourceShareName,senderAccountId,resourceShareInvitationArn]" \
--output table
# 招待を承諾する
aws ram accept-resource-share-invitation \
--resource-share-invitation-arn arn:aws:ram:ap-northeast-1:111111111111:resource-share-invitation/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111
# 他アカウントから共有されているリソースを一覧する
aws ram list-resources \
--resource-owner OTHER-ACCOUNTS \
--query "resources[].[type,arn,status]" \
--output table招待には期限があります。accept-resource-share-invitationのリファレンスで承諾でき、公式の共有手順ページによれば、サブネット・Transit Gateway・Resolverの転送ルール・License Manager設定・キャパシティ予約・プレフィックスリスト・Auroraのクラスターなどは7日、一覧にない種類は12時間で失効します。12時間の種類は、共有を作った当日のうちに共有先へ承諾を依頼しておかないと作り直しが必要です。承諾後は、先に触れたとおり共有先の管理者が共有リソースのARNを許可するIAMポリシーを自アカウントのロールに付け、そのロールでEC2の起動などを試して操作範囲を確かめます。
組織を離れてもアカウント間の共有を保つ設定とTerraformでの管理例
組織再編でアカウントの移籍が決まっている場合は、移籍するアカウントへの共有だけを、次のように作り直しておきます。ResourceShareConfigurationのAPIリファレンスに定義されている設定で、既存の共有に後から付けることはできません。
# 移籍予定のアカウント 333333333333 へTransit Gatewayを個別に共有し、
# 組織を離れても共有を保つ（招待が送られるので共有先で承諾が必要）
aws ram create-resource-share \
--region ap-northeast-1 \
--name tgw-share-retain-333333333333 \
--resource-arns arn:aws:ec2:ap-northeast-1:111111111111:transit-gateway/tgw-0123456789abcdef0 \
--principals 333333333333 \
--allow-external-principals \
--resource-share-configuration retainSharingOnAccountLeaveOrganization=true共有を継続的に運用するなら、コマンドの手打ちよりTerraformなどのIaCで宣言しておくと、共有先の増減がレビューを通るようになります。AWSプロバイダーでは、共有そのもの・リソースの関連付け・プリンシパルの関連付けが別リソースに分かれています。
resource "aws_ram_resource_share" "app_subnets" {
name = "shared-vpc-app-subnets"
allow_external_principals = false
}
resource "aws_ram_resource_association" "app_subnet_a" {
resource_arn = aws_subnet.app_a.arn
resource_share_arn = aws_ram_resource_share.app_subnets.arn
}
resource "aws_ram_principal_association" "app_ou" {
principal = "arn:aws:organizations::111111111111:ou/o-exampleorg1/ou-ab12-cdef3456"
resource_share_arn = aws_ram_resource_share.app_subnets.arn
}共有したリソースを削除する予定があるときは、先にリソース共有から外すか共有ごと削除してから消すのが公式の推奨です。Terraformで関連付けと本体を同じ構成に置いておけば、この順序を依存関係として表現できます。
AWS RAMを採用すべきマルチアカウント要件と、過剰になる場面
ここでは判断を言い切ります。RAM本体は無料ですが、共有の設計・権限の絞り込み・共有先での運用にはそれなりの手間がかかる点は無視できません。導入の是非は「共有機能があるか」ではなく「リソースを共用する実需が運用コストを上回っているか」で決めます。
AWS RAMを導入して効果が出るマルチアカウント要件と採用の目安
次のいずれかが恒常的に発生しているなら、RAMの採用は妥当です。とくに(1)のネットワーク共有は、アカウントごとの個別複製を続けるほど後戻りのコストが膨らみます。
- 複数アカウントを同一VPC・同一Transit Gatewayに集約し、接続とアドレス設計を1点で管理したい
- License Managerのライセンスやキャパシティ予約を組織横断で共用し、在庫とコストを平準化したい
- Route 53 ResolverルールやIPAMプールを全アカウントへ配布し、名前解決とIP割当を一貫させたい
Resolverルールの配布は、オンプレミスのDNSへ社内ドメインの問い合わせを転送する構成でよく使われます。DNSとResolverの設計そのものを扱うのは、Amazon Route 53のDNS・ルーティング設計とCLI構築手順を解説した記事です。アカウント数が数十を超え、共有VPCやガードレールを標準構成として毎回同じ形で配りたい段階になったら、RAMを個別に組むよりAWS Control Towerのランディングゾーンと導入判断を解説した記事の方式で、アカウント発行と基盤配布をまとめて自動化するほうが保守しやすくなります。
こうした共有基盤の設計は、アカウント設計やOrganizationsのOU構成と一体で決めると後戻りが減ります。マルチアカウント構成の共有ネットワーク設計や、Organizations・Control Towerを含む基盤づくりを外部に相談したい場合は、AWS環境のインフラ構築・アカウント設計の支援で、要件に沿った共有方針とガードレール設計から伴走できます。
RAMが過剰になる場面と、共有を広げすぎる失敗パターン（見送り・注意）
逆に、アカウントが1〜2個で共有したい基盤が無い段階では、RAMの導入は出番がありません。他アカウントのAPIを一時的に呼びたいだけなら、リソースの実体を渡すRAMではなくクロスアカウントロールで足ります。「共有できるから共有する」ではなく、リソースの実体を複数アカウントで持ち続ける必要が生まれてから使うのが費用対効果に合います。
導入後の典型的な失敗は、プリンシパルを組織全体に広げすぎて、本来不要なアカウントにまで共有が届くパターンです。共有はまずOUや個別アカウント単位で絞り、必要な範囲だけに配る方針で進めます。組織全体宛にすると所有アカウント自身も範囲に入り、所有アカウント内の全プリンシパルが共有リソースに触れる状態になる点も、権限設計で見落とされがちです。もう1つは、AWSマネージドのmanaged permissionをそのまま使い、共有先に想定以上の操作を許してしまうケースで、最小権限が要る場面ではカスタマー管理のmanaged permissionで操作範囲を明示的に絞ります（前述の表で「カスタマー管理」が可の種類に限る）。共有した基盤リソース（Transit Gatewayのデータ処理料など）には利用料がかかる点も、RAM本体の無料と混同しないよう設計時に見込んでおきます。
運用面では、組織外へ共有できる種類で--allow-external-principalsを既定のtrueのまま作り、あとから外部のアカウントIDが紛れ込む事故にも注意します。組織内で閉じる方針なら、共有を作るたびに--no-allow-external-principalsを付けるか、Terraformでallow_external_principals = falseを固定しておくと、レビューで逸脱に気付けます。
よくある質問
AWS RAMの導入前に実務でよく問われる論点を、簡潔に整理します。
AWS RAMの利用に料金はかかりますか？
RAM本体でリソース共有を作成・管理することに追加料金は発生しません（公式FAQに記載）。課金されるのは共有した基盤リソースの実利用分で、たとえばTransit Gatewayのアタッチメントやデータ処理料は所有・利用の区分に応じて通常どおりかかります。RAMの機能そのものは無料と考え、共有対象のリソース側の料金を別途見込むのが正確です。
RAMのリソース共有とIAMのクロスアカウントロールは何が違いますか？
RAMはリソースの実体を共有先アカウントへ渡し、共有先が自分の環境の一部として継続利用します。クロスアカウントロールは別アカウントのAPIを一時的に操作するための権限委譲で、リソースは相手アカウントに閉じたままです。「他アカウントのリソースを使う」のがRAM、「他アカウントで作業する」のがロール、という違いで使い分けます。
共有できるリソースにはどんなものがありますか？
VPCサブネット、Transit Gateway、Route 53 Resolverルール、VPC IPAMプール、License Manager設定、EC2キャパシティ予約、Amazon Auroraなど、ネットワークやライセンス系を中心に幅広く対応し、対象は順次拡大しています。ただしVPCサブネットは組織内のアカウントにしか共有できず、IAMロール／ユーザーへ共有できるのはIPAMプールやNetwork Firewallのポリシーなど一部に限られます。対象リソースと共有先の種類は導入時に公式ドキュメントの一覧で確認してください。
AWS Organizationsは必須ですか？
必須ではありません。個別のAWSアカウントIDを指定しての共有もできます。ただしOrganizationsと統合すると、組織全体やOUをプリンシパルに指定でき、招待の承諾なしで共有が届くため運用がぐっと楽になる点が利点です。統合するには管理アカウントでaws ram enable-sharing-with-aws-organizationを実行し、組織が「すべての機能」モードである必要があります。VPCサブネットの共有は組織内限定のため、共有VPCを組むならOrganizationsは実質的に前提になります。
共有をやめると共有先のリソースはどうなりますか？
共有を解除すると、共有先からそのリソースへの参照・利用ができなくなるだけで、リソースの実体は所有アカウントに残ります。コピーが配られているわけではないため、共有停止でデータやリソースが失われることはありません。ただし共有先がそのリソース上に作ったもの（共有サブネット内のEC2など）の扱いは別途整理が必要です。アカウントが組織を離れた場合も既定では共有へのアクセスを失い、例外はアカウント宛の共有でRetainSharingOnAccountLeaveOrganizationを有効にしていたときだけです。
関連記事
- AWS Organizationsとは？マルチアカウント管理・SCP/RCP・一括請求の仕組みと設計判断：RAMの共有先を組織・OU単位で制御する土台となるサービス
- AWS IAMとは？ユーザー/ロール/ポリシーの違いと権限設計のベストプラクティス：共有先での実効権限やクロスアカウントロールの前提となる権限設計
- Transit Gatewayクロスアカウント構築手順｜TerraformとRAM共有：RAMで共有したTransit Gatewayをアタッチメントとルートまで組む実装手順
- AWS PrivateLinkとは？仕組み・VPCエンドポイントとの違いと採用判断：リソース共有ではなく「接続の提供」でアカウント間をつなぐ選択肢
- AWS Control Towerとは？マルチアカウント統制の仕組みと導入判断：RAMやOrganizationsを含む共有基盤を標準構成で自動化する選択肢
- Amazon Route 53とは？DNS・ドメイン登録・ルーティング設計：RAMで共有できるResolverルールの発生源となるDNSサービス
