AWS Resource Access Manager
AWS アカウント間や Organizations 内でリソースを安全に共有するサービスで、重複リソースの作成を排除しコストと運用負荷を削減する
概要
AWS Resource Access Manager (RAM) は、VPC サブネット、Transit Gateway、Route 53 Resolver ルールなどの AWS リソースを、複数のアカウントや組織単位 (OU) と共有するためのサービスです。リソースの所有権は共有元アカウントに残り、共有先は利用権限のみを取得するため、ガバナンスを維持しながらマルチアカウント環境の効率化を実現します。Organizations との統合により、組織内の共有は招待承認なしで即座に有効化できます。
マルチアカウント戦略における RAM の位置づけと共有モデル
AWS のマルチアカウント戦略では、環境分離やセキュリティ境界のためにアカウントを分割しますが、ネットワーク基盤やDNS ルールなど共通インフラまで各アカウントに複製すると、コストと管理工数が膨れ上がります。RAM はこの問題を「リソース共有」という形で解決します。共有元アカウントがリソースシェアを作成し、共有先のアカウント ID、OU、または組織全体を指定するだけで、共有先からそのリソースを自分のアカウントのリソースと同様に参照・利用できるようになります。重要なのは、共有されたリソースの変更・削除権限は共有元にのみ残る点です。共有先は利用はできても設定変更はできないため、中央集権的なガバナンスが自然に維持されます。Organizations の信頼されたアクセスを有効にすると、組織内の共有は招待の承認ステップが不要になり、新規アカウント追加時にも自動的にリソースが利用可能になります。Azure では類似の概念として Azure Lighthouse がクロステナントのリソース管理を提供していますが、RAM はアカウント間の個別リソース共有に特化しており、設定がシンプルです。
VPC サブネット共有で実現するネットワーク集約の実務
RAM の最も一般的なユースケースは VPC サブネットの共有です。ネットワークアカウントが VPC とサブネットを所有し、アプリケーションアカウントに共有することで、全アカウントのワークロードが同一 VPC 内で通信できます。各アカウントは共有されたサブネットに EC2 インスタンスや Lambda 関数を配置できますが、ルートテーブルやセキュリティグループの管理はネットワークアカウントが一元的に行います。この設計により、IP アドレス空間の効率的な利用、VPC Peering の削減、ネットワークポリシーの一貫性が同時に達成できます。AWS ネットワークの関連書籍 (Amazon) では、サブネット共有を活用したハブ & スポーク構成の設計パターンが詳しく解説されています。注意点として、共有サブネットに配置されたリソースのセキュリティグループは各アカウントが独自に管理するため、ネットワーク ACL による共通制御とセキュリティグループによる個別制御の二層構造で設計するのが実務上のベストプラクティスです。
Transit Gateway 共有とリソースシェアの運用設計
Transit Gateway の共有も RAM の主要ユースケースです。ネットワークアカウントが Transit Gateway を所有し、各アカウントに共有することで、アカウントごとに Transit Gateway を作成する必要がなくなります。共有先アカウントは自分の VPC を Transit Gateway にアタッチでき、ルーティングはネットワークアカウントが集中管理します。この構成は、数十から数百のアカウントを持つ大規模組織で特に効果的です。リソースシェアの運用設計では、共有の粒度を適切に設計することが重要です。1 つのリソースシェアに複数のリソースタイプをまとめることも、リソースタイプごとに分けることも可能ですが、実務ではネットワーク系 (サブネット、Transit Gateway) とセキュリティ系 (Resolver ルール、Firewall ポリシー) でリソースシェアを分離し、共有先の範囲を独立に制御する設計が推奨されます。CloudFormation での RAM リソースシェア定義は AWS::RAM::ResourceShare リソースタイプで宣言的に管理でき、IaC による一貫した共有設定の維持が可能です。RAM 自体の利用に追加料金は発生せず、共有されたリソースの利用料のみが各アカウントに課金されます。