aws ramコマンドで複数アカウントのVPCサブネットを共有する方法｜Resource Access ManagerとOrganizations連携の設計パターン

宮崎智広 この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
ＨＯＭＥ ＞ Linux技術 リナックスマスター.JP（Linuxマスター.JP） ＞ AWS(Amazon Linux) ＞ aws ramコマンドで複数アカウントのVPCサブネットを共有する方法｜Resource Access ManagerとOrganizations連携の設計パターン
「本番環境のVPCを開発チームにも使わせたい。でも同じAWSアカウントにまとめると権限管理が複雑になる」
マルチアカウント構成でAWSを運用していると、こうした悩みが必ず出てきます。

AWS Organizations でアカウントを分けることで権限と課金を分離できますが、今度はネットワーク設計が複雑になります。アカウントごとにVPCを作って Transit Gateway で接続する方法もありますが、Attachmentの設定やルートテーブルの管理が煩雑です。

この記事では、AWS Resource Access Manager（RAM） を使って、VPCのサブネットを複数アカウント間で共有する「共有VPC設計」を解説します。中央のオーナーアカウントでVPCとサブネットを管理し、複数の参加アカウントがそのサブネットに直接リソースをデプロイできる構成です。

実行環境：Amazon Linux 2023（AWS CLI v2 インストール済み）で動作確認済みです。

この記事のポイント

・aws ram create-resource-share でサブネットを参加アカウントに公開できる
・Organizations連携を有効にすると招待承諾が不要になり運用が簡単になる
・ルートテーブル・NACLはオーナー管理、セキュリティグループは参加側が設定する役割分担が基本
・AZ冗長のためマルチAZ分のサブネットをまとめて共有するのが実務上の鉄則


「このままじゃマズい」と感じていませんか？
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

共有VPC設計が必要になる理由

AWSのベストプラクティスでは、本番・開発・ステージングといった環境ごとにAWSアカウントを分離します。AWS Organizations を使えばアカウントをOU（Organizational Unit）でグループ化し、SCP（Service Control Policy）で一括制御できます。

しかし、ネットワーク設計には課題が残ります。アカウントを分けると各アカウントに独立したVPCが生まれ、それらを接続するために Transit Gateway や VPC Peering が必要になります。

共有VPC設計（Shared VPC）は別のアプローチです。

・オーナーアカウント：VPCとサブネットを作成・管理する
・参加アカウント：オーナーのサブネットを借りてEC2などをデプロイする

この方式の利点は次のとおりです。

・ネットワーク管理がオーナー1アカウントに集約できる（ルートテーブル・NACL・NATゲートウェイを一元管理）
・参加アカウントは自分のリソースだけに権限を持ち、他アカウントのリソースには触れない
・Transit GatewayのAttachment費用が不要（小規模なマルチアカウント構成でコスト節約になる）

一方で注意点もあります。オーナーのルートテーブル変更が全参加アカウントのトラフィックに影響するため、設計前にチームで変更管理ルールを決めておくことが不可欠です。

AWS Resource Access Managerとは（共有の仕組み）

AWS Resource Access Manager（RAM）は、AWSリソースを別のAWSアカウントやOrganizationsのOU全体と共有するサービスです。共有できるリソースの種類はVPCサブネットのほか、Transit Gateway、Route 53 Resolver Rule、ライセンス設定など多岐にわたります。

共有VPC設計でのRAMの動きを整理すると以下のとおりです。

操作主体 RAMでの役割 できること
オーナーアカウント リソース共有の作成者 サブネット・ルートテーブル・NACLの管理
参加アカウント 招待の受け入れ者 共有サブネットへのEC2・RDS・ELBのデプロイ

重要な点は、参加アカウントはサブネット自体を変更できないことです。ルートテーブルの変更、NATゲートウェイの追加、サブネットの削除はすべてオーナー側でのみ実行可能です。参加アカウントは「サブネットを借りてリソースを置く」に徹します。

RAMで共有サブネットを設定する手順

1. Organizationsとの共有を有効化する

Organizations を使っている場合、まず管理アカウント（マスターアカウント）でRAMとOrganizationsの連携を有効にします。この設定で、招待メールへの承諾ステップが不要になります。

管理アカウントのAWS CLIで以下を実行します。

# aws ram enable-sharing-with-aws-organization を管理アカウントで実行する
aws ram enable-sharing-with-aws-organization
実行が成功すると何も出力されず、プロンプトに戻ります。メンバーアカウントで実行するとエラーになるため、必ず管理アカウントのIAMユーザーで実行してください。

2. オーナーアカウントで共有サブネットを登録する

次に、共有したいサブネットが存在するオーナーアカウントでRAMのリソース共有を作成します。共有先はOrganizationsのOU全体、または個別のアカウントIDで指定できます。

まず、共有対象のサブネットIDを確認します。

# 共有対象のサブネットIDを確認する
aws ec2 describe-subnets   --filters "Name=tag:Name,Values=shared-private-1a"   --query "Subnets[*].[SubnetId,CidrBlock,AvailabilityZone]"   --output table
コマンド実行結果の例：

----------------------------------------------------
|                  DescribeSubnets                 |
+------------------+--------------+----------------+
|  subnet-0a1b2c3d | 10.1.10.0/24 | ap-northeast-1a|
+------------------+--------------+----------------+
続いて、RAMのリソース共有を作成します。--principals に共有先のOUのARNを指定します。

# リソース共有を作成し、共有するサブネットとOU（共有先）を指定する
aws ram create-resource-share   --name "shared-private-subnets"   --resource-arns "arn:aws:ec2:ap-northeast-1:111122223333:subnet/subnet-0a1b2c3d"   --principals "arn:aws:organizations::111122223333:ou/o-xxxx/ou-xxxx-xxxxxxxx"   --allow-external-principals false
コマンド実行結果の例：

{
    "resourceShare": {
        "resourceShareArn": "arn:aws:ram:ap-northeast-1:111122223333:resource-share/xxxxxxxx-xxxx-...",
        "name": "shared-private-subnets",
        "owningAccountId": "111122223333",
        "allowExternalPrincipals": false,
        "status": "ACTIVE",
        "creationTime": "2026-09-01T10:00:00.000000+09:00"
    }
}
--allow-external-principals false を指定することで、Organizations外部のアカウントとの共有を禁止します。セキュリティ上、必ず false を指定してください。

3. 複数サブネット（マルチAZ）をまとめて共有する

AZ冗長のために複数のサブネットを共有するケースがほとんどです。--resource-arns にカンマ区切りで複数のARNを指定できます。

# 2つのサブネット（ap-northeast-1a と ap-northeast-1c）をまとめて共有する
aws ram create-resource-share   --name "shared-private-subnets-multiaz"   --resource-arns     "arn:aws:ec2:ap-northeast-1:111122223333:subnet/subnet-0a1b2c3d","arn:aws:ec2:ap-northeast-1:111122223333:subnet/subnet-0e4f5g6h"   --principals "arn:aws:organizations::111122223333:ou/o-xxxx/ou-xxxx-xxxxxxxx"   --allow-external-principals false
参加アカウントがマルチAZ構成のEC2やRDSをデプロイできるようにするには、AZをまたいで2つ以上のサブネットを共有しておく必要があります。1つのサブネットだけ共有した場合、参加アカウントはそのAZ固定のリソースしか起動できません。

4. 参加アカウント側で共有サブネットを確認する

Organizationsとの統合が有効な場合、参加アカウントへの招待は自動的に承諾されます。参加アカウントで以下を確認します。

# 参加アカウントで共有サブネットを確認する（OwnerId が自アカウントと異なるもの）
aws ec2 describe-subnets   --query 'Subnets[?OwnerId!=`'"$(aws sts get-caller-identity --query Account --output text)"'`].[SubnetId,CidrBlock,AvailabilityZone,OwnerId]'   --output table
コマンド実行結果の例（参加アカウントから見た場合）：

---------------------------------------------------------------------------
|                          DescribeSubnets                                |
+------------------+--------------+-----------------+------------------+
|  subnet-0a1b2c3d | 10.1.10.0/24 | ap-northeast-1a | 111122223333     |
|  subnet-0e4f5g6h | 10.1.20.0/24 | ap-northeast-1c | 111122223333     |
+------------------+--------------+-----------------+------------------+
OwnerId がオーナーアカウントのIDになっているサブネットが共有されたサブネットです。このサブネットを指定してEC2やRDSを起動できます。

共有VPC設計の責任分担とベストプラクティス

共有VPC設計では、オーナーと参加者の責任境界を明確にしておくことが重要です。設計前にチームで以下の役割分担を確認してください。

管理対象 管理アカウント 変更の影響範囲
VPC CIDR・サブネットCIDR オーナー 全参加アカウントに影響
ルートテーブル・インターネットゲートウェイ オーナー 全参加アカウントの通信に影響
NATゲートウェイ オーナー プライベートサブネットの外部通信に影響
ネットワークACL（NACL） オーナー サブネット単位で全アカウントに影響
セキュリティグループ 参加アカウント（自アカウント内のみ） 自アカウントのリソースのみ
EC2・RDS・ELBなどのリソース 参加アカウント 自アカウントのリソースのみ

NACLはオーナーが管理するため、参加アカウントがセキュリティ要件に応じてインバウンド・アウトバウンドを細かく制御したい場合は、セキュリティグループで対応します。「NACLはネットワーク基盤として全体ルールを管理し、セキュリティグループは各アプリの個別ルール」という役割分担を設計段階で決めておきましょう。

IPアドレス計画のポイント（要注意）：
共有サブネットには複数アカウントのリソースが混在するため、サブネットのCIDRブロックは余裕を持って設計します。一般的には /24（IPアドレス256個、利用可能251個）以上を確保します。参加アカウントが増えるとIPアドレスの消費が加速するため、VPCの設計段階で将来のアカウント数と各アカウントのリソース数を見積もってください。

リソース共有の確認とトラブルシュート

1. 共有の状態を確認する


# 作成したリソース共有の一覧と状態を確認する
aws ram list-resource-shares   --resource-owner SELF   --query "resourceShares[*].[name,status,resourceShareArn]"   --output table
コマンド実行結果の例：

-------------------------------------------------------------------------------------
|                           ListResourceShares                                      |
+---------------------------------+--------+----------------------------------------+
|  shared-private-subnets-multiaz | ACTIVE | arn:aws:ram:ap-northeast-1:111122...   |
+---------------------------------+--------+----------------------------------------+
status が ACTIVE であれば共有は有効です。

2. 共有しているリソースの一覧を確認する


# 共有中のサブネットリソースを確認する
aws ram list-resources   --resource-owner SELF   --resource-type "ec2:Subnet"   --query "resources[*].[arn,status]"   --output table

3. よくあるエラーと対処法

エラー1: InvalidParameter – External principals are not allowed
Organizations外のアカウントIDを --principals に指定した場合に発生します。指定先のアカウントが同一Organizations内であることを確認するか、--allow-external-principals true を明示してください。

エラー2: 参加アカウントで共有サブネットが見えない
Organizationsとの統合（enable-sharing-with-aws-organization）が有効になっていない場合、参加アカウントへの招待が pending 状態のままになります。管理アカウントで統合を有効化してから、リソース共有を再作成してください。

エラー3: 共有サブネットにEC2を起動できない（InvalidSubnetID.NotFound）
参加アカウントのIAMロールに ec2:DescribeSubnets と ec2:RunInstances の権限が必要です。また、共有サブネットのルートテーブルにインターネットゲートウェイへのルートが存在しないと、パブリックIPを持つEC2でも外部に出られません。ルートテーブルはオーナーアカウントで確認します。

エラー4: 共有を削除できない（ResourceShareAssociationError）
参加アカウントがそのサブネットにリソースをデプロイしたままリソース共有を削除しようとすると失敗します。先に参加アカウント側のEC2・RDS・ELBなどをすべて削除してから、リソース共有を削除してください。

AWSを使ったLinuxサーバー設計を体系的に学びたい方へ

AWSのマルチアカウント設計やVPC設計は、コマンドを知っているだけでは不十分。現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。

今すぐ無料でダウンロード（登録10秒） ＞＞ 図解60P『Linux入門マニュアル』を受け取る

※ 「AWSを実務レベルで使いこなしたい」という本気の方には、2日で実務レベルのスキルが身につく【ハンズオンセミナー】も開催しています。

本記事のまとめ

やりたいこと コマンド
Organizationsとの連携を有効化する aws ram enable-sharing-with-aws-organization
サブネットを共有するリソース共有を作成する aws ram create-resource-share --name xxx --resource-arns arn:... --principals arn:...
作成した共有の状態を確認する aws ram list-resource-shares --resource-owner SELF
参加アカウントで共有サブネットを確認する aws ec2 describe-subnetsでOwnerId確認
共有中のサブネットリソースを確認する aws ram list-resources --resource-owner SELF --resource-type ec2:Subnet

AWS RAMによる共有VPC設計は、Transit Gatewayを使わずにマルチアカウント間のネットワークを一元管理できる設計パターンです。オーナーアカウントがルートテーブルやNATゲートウェイを一元管理し、参加アカウントはサブネットを借りてリソースをデプロイするだけ、という役割分担で運用がシンプルになります。

AWSのサーバー設計やAmazon Linux上での実践的な運用を体系的に学びたい方は、Amazon Linux（AWS）を使ったLinuxサーバー設計の詳細もご確認ください。

関連記事

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

Linux無料マニュアル（図解60P） 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広（みやざき ともひろ）

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。