AWS RAM で実現するクロスアカウントリソース共有 - VPC サブネットと Transit Gateway の共有
VPC サブネットや Transit Gateway をアカウント間で共有し、IP アドレス空間の一元管理と VPC ピアリングの削減を実現する手法を紹介します。
RAM の概要
RAM (Resource Access Manager) は 30 種類以上の AWS リソースを複数のアカウント間で安全に共有するサービスです。マルチアカウント環境では各アカウントが独自のリソースを持ちますが、ネットワークリソース (VPC サブネット、Transit Gateway)、DNS リソース (Route 53 Resolver ルール)、セキュリティリソース (Network Firewall ポリシー) は共有した方が効率的です。RAM で共有することで、リソースの重複を排除しコストを削減します。共有されたリソースは消費側アカウントから直接参照・利用でき、クロスアカウントの IAM ロール切り替えや API 呼び出しの中継なしに、ネイティブな操作感で利用できます。リソースの所有権は共有元アカウントに残り、共有先アカウントは利用権限のみを付与されるため、ガバナンスを維持しながら効率的なリソース活用が可能です。
VPC サブネット共有
VPC サブネット共有はネットワークアカウントが VPC とサブネットを所有し、ワークロードアカウントが共有サブネット内にリソース (EC2、RDS、Lambda、ECS タスク) を作成するパターンです。各アカウントが独自の VPC を持つ必要がなくなり、IP アドレス空間の断片化を防止します。ネットワークアカウントが CIDR ブロックを一括管理するため、IPAM (IP Address Manager) との組み合わせで重複なく効率的にアドレスを配分できます。セキュリティグループはアカウントごとに独立しているため、共有サブネット内でもアカウント間のネットワーク分離は維持されます。ただし NACL (Network ACL) はサブネット単位のためオーナーアカウントのみが管理する点に注意が必要です。共有サブネット内のリソースは同一 VPC 内の他のリソースとプライベート IP で直接通信でき、VPC ピアリングや Transit Gateway を経由する必要がありません。
共有可能なリソースと設計パターン
RAM で共有可能なリソースは VPC サブネット、Transit Gateway、Route 53 Resolver ルール、License Manager 設定、Aurora DB クラスター、CodeBuild プロジェクト、AWS Network Firewall ポリシー、Verified Access グループ、IPAM プール、Capacity Reservations、Outposts など 30 種類以上です。Organizations 内の共有は自動承認され、Organizations 外のアカウントとの共有は招待ベースで承認が必要です。リソース共有のアクセス許可 (RAM Managed Permissions) で、共有先アカウントの操作権限 (読み取りのみ、作成可能、関連付け可能) を細かく制御します。カスタムマネージドパーミッションを作成すれば、デフォルトより制限したアクセスレベルを定義することも可能です。 RAM の管理手法を網羅的に学ぶなら、技術書 (Amazon)を参照してください。
Organizations 統合と自動化
RAM は AWS Organizations と統合することで、組織単位 (OU) レベルでのリソース共有を自動化できます。Organizations 内での共有を有効化すると、共有先アカウントは招待の承認なしに自動的にリソースにアクセスできるようになります。新しいアカウントが OU に追加された時点で、その OU に共有されているリソースへのアクセスが自動的に付与されます。CloudFormation StackSets と組み合わせることで、新規アカウントの作成、OU への配置、リソース共有の設定、初期リソースのデプロイを完全に自動化できます。Service Control Policies (SCP) と RAM の共有ポリシーを組み合わせることで、どのリソースをどの OU に共有するかを組織レベルで制御できます。RAM の共有リソースの利用状況は CloudTrail で監査でき、誰がどのリソースにアクセスしたかを追跡できます。
設計のベストプラクティスと落とし穴
VPC サブネット共有の設計では、サブネットの CIDR サイズを余裕を持って確保することが重要です。複数アカウントが同一サブネットにリソースを作成するため、IP アドレスの枯渇が全アカウントに波及します。/24 (256 アドレス) では不十分なケースが多く、ワークロード規模に応じて /20〜/22 程度を確保するのが推奨です。落とし穴として、サブネット共有を解除してもそのサブネット内に消費側アカウントが作成したリソース (ENI 等) が残っている場合、共有解除がブロックされる点があります。共有解除前にリソースの棚卸しが必須です。Transit Gateway 共有では、ルートテーブルの設計が重要です。ワークロードアカウント間の通信を許可するか遮断するかをルートテーブルの関連付けで制御するため、セグメンテーション要件を事前に整理しておく必要があります。また、RAM 共有はリージョン単位で設定されるため、マルチリージョン展開では各リージョンに個別の Resource Share を作成する点を見落としがちです。
VPC ピアリングとの比較
VPC サブネット共有と VPC ピアリングはどちらもアカウント間のネットワーク接続を実現しますが、アーキテクチャの思想が異なります。VPC ピアリングは各アカウントが独自の VPC を持ち、ピアリング接続で相互にルーティングする方式です。10 アカウントでフルメッシュ接続すると 45 本のピアリングが必要になり、ルートテーブルの管理負荷が急激に増大します。一方、VPC サブネット共有は VPC 自体を 1 つに集約するため、アカウント間通信のためのピアリングが不要です。ただし、VPC サブネット共有ではサブネットレベルの NACL が全アカウント共通になるため、アカウント間で異なるネットワーク ACL を適用したい場合は VPC ピアリングまたは Transit Gateway が必要です。Transit Gateway との比較では、RAM 共有の Transit Gateway はハブ&スポーク型接続を低コストで実現しますが、Transit Gateway のデータ処理料金 (GB あたり課金) がアカウント横断のトラフィック量に応じて発生するため、大量通信がある場合は VPC サブネット共有の方がコスト効率に優れます。
RAM の料金
RAM 自体に追加料金は発生しません。コストは共有されたリソースの利用料金 (共有先アカウントでの使用分) に依存します。VPC サブネット共有では、共有先アカウントが作成したリソース (EC2、RDS) の料金は共有先アカウントに課金されます。Transit Gateway の共有では、アタッチメント料金 (1 アタッチメントあたり時間課金) とデータ処理料金 (GB あたり課金) が共有先アカウントに課金されます。Route 53 Resolver ルールの共有では、ルール自体の共有は無料ですが、Resolver エンドポイントの ENI 料金はオーナーアカウントに課金されます。リソース共有の棚卸しを定期的に実施し、不要になった共有を削除してセキュリティリスクを低減します。
まとめ
RAM はマルチアカウント環境でリソースを効率的に共有するサービスです。VPC サブネット共有で IP アドレス空間を一元管理し、VPC ピアリングの数を削減します。Transit Gateway 共有でネットワーク接続を集約し、30 種類以上のリソースタイプに対応します。Organizations 統合により OU レベルの自動共有と CloudFormation StackSets による完全自動化が実現でき、CloudTrail で共有リソースのアクセスを監査できます。サブネットの CIDR サイズ計画とリソース棚卸しの運用ルールを事前に確立し、共有解除時のブロックを回避することが安定運用の鍵です。