AWS Resource Access Manager（RAM）入門｜マルチアカウント間でVPCサブネット・ライセンスをセキュアに共有する実践ガイド

オンプレ時代、複数の部署やプロジェクトがネットワークを共用したいときは、同じVLANに入れるか、ルーティングで繋ぐかのどちらかでした。AWSのマルチアカウント環境でも同じ問題が起きます。「アプリチームのアカウントとネットワークチームのアカウント、どうやってVPCを共有すればいい？」「毎アカウントにNAT Gatewayを立てるとコストがかさむ」という悩みです。

この記事では、AWSが提供するリソース共有サービス「AWS Resource Access Manager（RAM）」を解説します。複数アカウントでVPCサブネットを共有する「共有VPCパターン」を中心に、設定手順・セキュリティの考え方・TransitGatewayとの使い分け・よくある落とし穴まで現場視点で整理します。

AWS RAMとは何か？OrganizationsやVPCピアリングとの違い

まず、混同しやすい概念を整理しておきましょう。

・AWS Organizations: 複数のAWSアカウントをまとめて管理する仕組み。組織（OU）・ポリシー（SCP）・一括請求を担う
・AWS RAM（Resource Access Manager）: 特定のリソースを別のAWSアカウントやOU・組織全体と共有する仕組み
・VPCピアリング: 2つのVPC間をPoint-to-Pointで接続するネットワーク経路。アカウントをまたいだリソース共有ではなく「経路接続」

Organizationsはアカウントをまとめるツールであってリソースを共有するツールではありません。RAMはその「リソース共有」の専門サービスです。2018年のリリース前は、アカウントをまたいでVPCを使いたい場合にVPCピアリングを何十本も張る必要があり、管理が煩雑でした。RAMはこの問題を解決するために登場しました。

RAMで共有できるリソースの種類（2026年8月時点）

実務で最もよく使われるのは「VPCサブネット」の共有です。以降は共有VPCパターンを中心に解説します。

共有VPCパターンとは何か

「共有VPC（Shared VPC）」は、ネットワーク管理アカウントがVPCとサブネットを所有し、複数のアプリケーションアカウントに特定のサブネットを貸し出す設計パターンです。

構成イメージ（東京リージョン・ap-northeast-1の例）:

・ネットワークアカウント（オーナー）: VPC（10.0.0.0/16）とサブネットを作成・管理。NAT GatewayやVPCエンドポイントもここに配置
・アプリアカウントA（参加者）: 共有サブネット（10.0.10.0/24など）にEC2やECSを配置。VPC自体の設定は変更できないがサブネットは使える
・アプリアカウントB（参加者）: 別のサブネット（10.0.20.0/24など）を共有。Aとは分離されている

このパターンのメリット:

・ネットワーク設計の一元管理: CIDRの重複やルーティングの矛盾をネットワークチームが一括管理できる
・コスト削減: NAT GatewayやVPCエンドポイントをVPC単位で共有できるため、アカウントごとに重複コストが発生しない
・セキュリティグループの分離: セキュリティグループは参加アカウントごとに独立して管理できる（アカウント間で干渉しない）
・Transit Gatewayなしで通信可能: 同じVPC内のサブネット同士なのでルーティング設定が不要

AWS VPC CIDRブロック設計入門でも解説しているように、マルチアカウント設計ではCIDRブロックの重複防止が重要です。RAMで共有する前に、各アカウント・リージョン・環境（本番/ステージング）のCIDR範囲を事前計画しておくことが必須です。

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

1. 事前準備：OrganizationsとRAMを連携させる

Organizations内のアカウントへ共有する場合、招待・承認の手間をなくせます。まずRAMとOrganizationsを統合しておきましょう。この操作は管理アカウント（組織ルート）からのみ実行できます。

# AWS CLI（管理アカウントで実行）
# RAMとOrganizationsの統合を有効化
aws ram enable-sharing-with-aws-organization --region ap-northeast-1

# 有効化されているか確認
aws organizations list-aws-service-access-for-organization \
  --query "EnabledServicePrincipals[?ServicePrincipal=='ram.amazonaws.com']"

この設定を行うと、組織内のアカウントへの共有では招待メールが不要になります。設定せずに共有すると、参加アカウントへ招待メールが飛び、承認が必要になります。

2. 共有するサブネットのARNを確認する

# AWS CLI（ネットワークアカウントで実行）
# 共有したいサブネットのARNを取得
aws ec2 describe-subnets \
  --filters "Name=tag:Env,Values=prod" \
  --query 'Subnets[*].{SubnetId:SubnetId,CIDR:CidrBlock,AZ:AvailabilityZone,ARN:SubnetArn}' \
  --output table \
  --region ap-northeast-1

3. リソース共有（Resource Share）の作成

ネットワークアカウント側でリソース共有を作成します。`–principals`にはOUのARNか特定のアカウントIDを指定します。

# AWS CLI（ネットワークアカウントで実行）
# OUを対象としたリソース共有を作成
aws ram create-resource-share \
  --name "prod-shared-subnets" \
  --resource-arns \
    "arn:aws:ec2:ap-northeast-1:111122223333:subnet/subnet-aabbccddee" \
    "arn:aws:ec2:ap-northeast-1:111122223333:subnet/subnet-ffgghhiijj" \
  --principals \
    "arn:aws:organizations::111122223333:ou/o-exampleorgid11/ou-exmp-aabbccdd" \
  --allow-external-principals false \
  --region ap-northeast-1

# 作成したリソース共有の確認
aws ram get-resource-shares \
  --resource-owner SELF \
  --query "resourceShares[*].{Name:name,Status:status,ARN:resourceShareArn}" \
  --output table \
  --region ap-northeast-1

`–allow-external-principals false`を指定することで、Organizations外のアカウントへの誤共有を防ぎます。セキュリティのデフォルト設定として推奨します。

4. 参加アカウント側での確認

# AWS CLI（参加アカウントで実行）
# 共有されたサブネットの一覧を確認
aws ram list-resources \
  --resource-owner OTHER-ACCOUNTS \
  --resource-type ec2:Subnet \
  --region ap-northeast-1

# EC2のサブネット一覧にも表示される（OwnerId列でオーナーアカウントを確認）
aws ec2 describe-subnets \
  --region ap-northeast-1 \
  --query 'Subnets[*].{SubnetId:SubnetId,OwnerId:OwnerId,CIDR:CidrBlock,AZ:AvailabilityZone}' \
  --output table

参加アカウントでは、`OwnerId`がネットワークアカウントのIDになっているサブネットが確認できます。このサブネットを指定してEC2を起動するだけで、共有VPC内にリソースを配置できます。

5. 共有サブネットにEC2を起動する（参加アカウント）

コンソール操作では「インスタンスを起動 → ネットワーク設定」でVPCとサブネットを選択すると、ネットワークアカウントが所有するサブネットが一覧に表示されます。CLIでは次のように指定します。

# AWS CLI（参加アカウントで実行）
# 共有サブネット内にEC2を起動（セキュリティグループは参加アカウントで作成したものを指定）
aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t3.micro \
  --subnet-id subnet-aabbccddee \
  --security-group-ids sg-xxxxxxxxxxxxxxxxx \
  --count 1 \
  --region ap-northeast-1

セキュリティグループ（`sg-xxx`）は参加アカウント側で事前に作成しておく必要があります。オーナーアカウントのセキュリティグループは参加アカウントから参照・利用できません。

セキュリティの設計と考え方

【重要】所有権とアクセス権の分離

RAMで共有されたリソースは、所有権はオーナーアカウントに残ります。参加アカウントは「使う」ことはできますが「変更」や「削除」はできません。

・参加アカウントができること: EC2をそのサブネットに起動する、自アカウントのセキュリティグループをアタッチする、プライベートIPを使う、VPCエンドポイントを経由して通信する
・参加アカウントができないこと: サブネットのCIDRを変更する、ルートテーブルを変更する、サブネットを削除する、オーナーのセキュリティグループを使う

この所有権分離が「ネットワーク管理はネットワークチームが一元的に責任を持つ」という設計原則を支えています。オンプレでのVLAN管理と同じ発想で捉えると理解しやすいでしょう。

Organizationsと組み合わせたガードレール設計

AWS OrganizationsのSCP（サービスコントロールポリシー）と組み合わせることで、「参加アカウントが勝手に独自VPCを作れないようにする」制御が可能です。

SCP例（アプリアカウントOUに適用：独自VPC作成を禁止する）:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNetworkResourceCreation",
      "Effect": "Deny",
      "Action": [
        "ec2:CreateVpc",
        "ec2:CreateSubnet",
        "ec2:CreateInternetGateway",
        "ec2:CreateNatGateway"
      ],
      "Resource": "*"
    }
  ]
}

このSCPをアプリアカウントのOUに適用することで、ネットワーク設計をネットワークアカウントに完全集約できます。ただし、管理アカウントにはSCPが適用されないため、管理アカウントを操作する権限の管理は別途IAMポリシーで制御してください。

AWS Control Towerを使ったLanding Zone構築では、共有VPCパターンがデフォルトのネットワーク設計として採用されており、このSCPも標準のガードレールとして提供されています。

Network ACLと共有サブネットの注意点

Network ACL（NACL）はオーナーアカウントが管理します。参加アカウントのEC2が特定のポートへ通信できない場合、まずNACLのアウトバウンド・インバウンドルールを確認してください。NACLの変更権限を持つのはネットワークチームのみなので、アプリチームからの申請フローを事前に整備しておくことを推奨します。

Transit GatewayとRAMの使い分け判断基準

マルチVPC設計で「RAMの共有VPC」と「Transit Gateway」のどちらを使うか迷うことがあります。

同じ組織内で複数チームが同じ環境（本番・ステージング）を使う場合はRAMの共有VPCが効率的です。一方、事業部ごとに完全に独立したVPCを持ちつつ相互通信が必要な場合はTransit Gatewayが適しています。両者を組み合わせることも一般的です（中央ネットワークアカウントがTGWでオンプレ接続を集約し、各アプリ環境はRAMの共有サブネットを使う構成）。

よくある失敗と対処法

失敗1：共有後にCIDRを変更しようとした

共有後にサブネットのCIDRを変更することはできません。事前にOrganizations全体のCIDR計画を立てておくことが必須です。10.0.0.0/8や172.16.0.0/12の範囲をアカウント・リージョン・環境（本番/ステージング）で切り分ける計画を先に立ててください。後からCIDRを変更したい場合は新しいサブネットを作り、リソースを移行するしか方法がありません。

失敗2：Organizationsとの統合を有効化し忘れた

Organizations統合を有効化していない状態で別アカウントに共有すると、相手アカウントへ招待メールが飛び、承認が必要になります。管理アカウントで`aws ram enable-sharing-with-aws-organization`を実行してから共有するのが現場の標準手順です。既存の共有に対してもこの設定は有効です。

失敗3：参加アカウント側でセキュリティグループを正しく作れない

共有サブネット内にEC2を起動しようとしたとき「適切なセキュリティグループが見つからない」エラーが出るケースがあります。セキュリティグループは参加アカウント側から共有VPCのVPC IDを指定して作成する必要があります。

# AWS CLI（参加アカウントで実行）
# 共有VPCのVPC IDを指定してセキュリティグループを作成
aws ec2 create-security-group \
  --group-name "app-server-sg" \
  --description "Security group for app server in shared VPC" \
  --vpc-id vpc-xxxxxxxxxxxxxxx \
  --region ap-northeast-1

# 作成したSGにインバウンドルールを追加
aws ec2 authorize-security-group-ingress \
  --group-id sg-yyyyyyyyy \
  --protocol tcp \
  --port 8080 \
  --cidr 10.0.0.0/16 \
  --region ap-northeast-1

失敗4：参加アカウントのリソースを削除せずに共有を解除しようとした

共有を解除したい場合、参加アカウントで起動中のEC2インスタンスや関連リソースを先に削除しないとリソース共有を解除できません。「UseConstraintException」エラーが出たら、参加アカウント側のリソースを確認してください。削除順序は「参加アカウントのEC2 → ELB → 共有解除 → （必要なら）サブネット削除」の順です。

失敗5：コスト配賦が不透明になった

NAT GatewayやVPCエンドポイントはネットワークアカウントに課金されるため、複数の参加アカウントが使った場合の費用がネットワークアカウントに集中します。AWSコスト配分タグを活用し、「どのアプリアカウントからのトラフィックか」を識別するタグ設計を事前に整備しておくと、月末の費用按分が楽になります。

RAMの料金体系

AWS RAM自体の利用料金は無料です。ただし、共有されたリソースに対しての料金は引き続き発生します。

・共有サブネットに起動したEC2: 参加アカウントへの課金（リソースを使ったアカウントに課金）
・NAT Gateway: オーナーアカウントへの課金。共有VPCのメリットとして複数アカウントで共有できるが、費用はオーナーに集中するため按分ルールが必要
・Transit Gateway（RAMで共有した場合）: アタッチメントを作成したアカウントへアタッチメント料金が課金
・Route 53 Resolverルール: エンドポイント料金はオーナーアカウント、クエリ料金は参加アカウントに課金

本記事のまとめ

AWS Resource Access Manager（RAM）は、マルチアカウント環境でのリソース共有を安全・効率的に実現するサービスです。

・RAMとは: リソースを別のAWSアカウント・OU・組織全体と共有するサービス。RAM自体は無料
・最も使われるユースケース: 共有VPCパターン（ネットワークアカウントがVPCを所有し、アプリアカウントにサブネットを貸し出す）
・所有権の分離: 共有されたリソースはオーナーアカウントの所有。参加アカウントは使用のみ可能（変更・削除不可）
・Organizations連携が前提: 管理アカウントで`enable-sharing-with-aws-organization`を事前実行し、招待・承認なしで組織内共有を可能にする
・コストメリット: NAT GatewayやVPCエンドポイントをVPC単位で共有でき、アカウントごとの重複コストを削減
・Transit Gatewayとの使い分け: 同一VPC内でのチーム間共有はRAM、異なるVPCをまたいだ接続はTransit Gateway
・SCPと組み合わせた設計: アプリアカウントに独自VPC作成を禁止するSCPを適用することで、ネットワーク管理を完全に集中化できる

AWS Control Towerを使ったLanding Zone構築では、RAMによる共有VPCがデフォルトのネットワーク設計として採用されています。マルチアカウント運用を始める際は、Organizations・Control Tower・IAM Identity Center・RAMを組み合わせた設計を検討してください。