AWS RAM で実現するクロスアカウントリソース共有 - VPC サブネットと Transit Gateway の共有
VPC サブネットや Transit Gateway をアカウント間で共有し、IP アドレス空間の一元管理と VPC ピアリングの削減を実現する手法を紹介します。
RAM の概要
RAM (Resource Access Manager) は、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 などです。Organizations 内の共有は自動承認され、Organizations 外のアカウントとの共有は招待ベースで承認が必要です。リソース共有のアクセス許可 (RAM Managed Permissions) で、共有先アカウントの操作権限 (読み取りのみ、作成可能、関連付け可能) を細かく制御します。カスタムマネージドパーミッションを作成すれば、デフォルトより制限したアクセスレベルを定義することも可能です。
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 共有でネットワーク接続を集約できます。Organizations 統合で OU の単位の自動共有ができ、CloudFormation StackSets で設定を自動化し、CloudTrail で共有リソースのアクセスを監査できます。サブネットの CIDR のサイズの計画とリソースの棚卸しの手順を先に決めておくと、共有解除時のブロックを避けられます。
参考資料 (AWS 公式)
本ページの一次情報は AWS 公式サイトと公式ドキュメントです。最新の仕様と料金は次の公式ページで確認できます。
本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。