運用管理

AWS RAM で実現するクロスアカウントリソース共有 - VPC サブネットと Transit Gateway の共有

VPC サブネットや Transit Gateway をアカウント間で共有し、IP アドレス空間の一元管理と VPC ピアリングの削減を実現する手法を紹介します。

約 1 分で読めます

RAM の概要

RAM は 30 種類以上の AWS リソースを複数のアカウント間で安全に共有するサービスです。マルチアカウント環境では各アカウントが独自のリソースを持ちますが、ネットワークリソース (VPC サブネット、Transit Gateway) や DNS リソース (Route 53 Resolver ルール) は共有した方が効率的です。RAM で共有することで、リソースの重複を排除しコストを削減します。

VPC サブネット共有

VPC サブネット共有はネットワークアカウントが VPC とサブネットを所有し、ワークロードアカウントが共有サブネット内にリソース (EC2、RDS、Lambda) を作成するパターンです。各アカウントが独自の VPC を持つ必要がなくなり、IP アドレス空間の断片化を防止します。セキュリティグループはアカウントごとに独立しているため、共有サブネット内でもアカウント間のネットワーク分離は維持されます。Transit Gateway の共有では、ネットワークアカウントが Transit Gateway を所有し、各アカウントが VPC をアタッチします。

共有可能なリソースと設計パターン

RAM で共有可能なリソースは VPC サブネット、 Transit Gateway 、 Route 53 Resolver ルール、 License Manager 設定、 Aurora DB クラスター、 CodeBuild プロジェクトなど 30 種類以上です。 VPC サブネット共有では、ネットワークアカウントが VPC を所有し、ワークロードアカウントが共有サブネット内にリソースを作成します。 IP アドレス空間の一元管理と、 VPC ピアリングの削減が主なメリットです。 Organizations 内の共有は自動承認され、 Organizations 外のアカウントとの共有は招待ベースで承認が必要です。リソース共有のアクセス許可で、共有先アカウントの操作権限 (読み取りのみ、作成可能) を制御します。 RAM の管理手法を網羅的に学ぶなら、技術書 (Amazon)を参照してください。

RAM の料金

RAM 自体に追加料金は発生しません。コストは共有されたリソースの利用料金 (共有先アカウントでの使用分) に依存します。VPC サブネット共有では、共有先アカウントが作成したリソース (EC2、RDS) の料金は共有先アカウントに課金されます。Transit Gateway の共有では、アタッチメント料金とデータ処理料金が共有先アカウントに課金されます。リソース共有の棚卸しを定期的に実施し、不要になった共有を削除してセキュリティリスクを低減します。

まとめ

RAM はマルチアカウント環境でリソースを効率的に共有するサービスです。VPC サブネット共有で IP アドレス空間を一元管理し、VPC ピアリングの数を削減します。Transit Gateway 共有でネットワーク接続を集約し、30 種類以上のリソースタイプに対応します。Organizations 内の共有は自動承認され、リソース共有のアクセス許可で操作権限を細かく制御します。

関連するサービス

AWS Resource Access ManagerAWS リソースを組織内の他のアカウントと安全に共有するサービスAWS Organizations複数の AWS アカウントを一元管理するサービスAmazon VPCAWS 上に論理的に分離された仮想ネットワークを構築するサービス

関連する記事

AWS Organizations で実現するマルチアカウント管理 - OU 設計と SCP によるガバナンスOU 階層の設計と SCP によるアクセス制御でマルチアカウント環境のガバナンスを確立する。一括請求によるコスト管理も紹介します。AWS Transit Gateway で構築するハブ&スポークネットワーク - マルチ VPC 接続の設計ハブ&スポーク型で複数 VPC とオンプレミスを集約し、ルートテーブル分離でセキュリティ境界を確立する。ピアリングによるマルチリージョン接続も紹介します。マルチアカウント管理 - AWS Organizations と RAM で実現する組織全体のガバナンスOrganizations の委任管理者モデルで CloudTrail・Config・GuardDuty・Security Hub を全アカウントに一括展開し、セキュリティとコンプライアンスの統合管理を実現する方法を解説します。

同じテーマの記事

AWS の内部時刻同期の仕組み - Amazon Time Sync Service とうるう秒スミアリングの設計AWS が独自に運用する Amazon Time Sync Service の仕組み、GPS と原子時計による高精度時刻源、うるう秒をスミアリングで吸収する設計判断、分散システムにおける時刻同期の重要性を解説します。AWS AppFabric で SaaS 監査ログを集約 - OCSF 標準化と Security Lake 統合AppFabric による SaaS アプリケーションの監査ログ収集、OCSF 形式への標準化、分析パイプラインの構築を解説します。AWS AppConfig で実装するフィーチャーフラグ - 安全な設定デプロイとロールバックコードデプロイとは独立した設定変更を、Linear・Exponential 戦略で段階的にロールアウトする。CloudWatch アラーム連動の自動ロールバックで安全性を確保します。アーキテクチャレビュー - AWS Well-Architected Tool でワークロードを体系的に評価するAWS Well-Architected Tool を使ったワークロードのアーキテクチャレビューを解説。6 つの柱に基づく評価、改善計画の策定、カスタムレンズの活用を紹介します。監査ログの設計と運用 - CloudTrail による API アクティビティの完全記録AWS CloudTrail を活用した監査ログの設計手法を解説し、API アクティビティの記録、S3 への長期保存、Config との連携によるコンプライアンス対応を紹介します。AWS の障害報告書 (COE) から学ぶ分散システムの教訓 - 過去の大規模障害が変えた設計原則AWS が公開した Correction of Errors (COE) と障害報告書から、S3 障害、us-east-1 の DNS 障害、Kinesis 障害など過去の大規模インシデントの根本原因と、それが AWS の設計原則をどう変えたかを解説します。タグの設計が運用を決める - AWS リソースタグ戦略の雑学と実践的な命名規則AWS リソースタグが単なるラベルではなくコスト配分、アクセス制御、自動化の基盤である理由、タグキーの命名規則、タグの上限 50 個の使い方、タグポリシーによるガバナンスを解説します。AWS のサービスクォータはなぜ存在するのか - 共有インフラを守るマルチテナント設計AWS のサービスクォータ (旧サービス制限) が単なる制約ではなく、マルチテナント環境で他の顧客を守るための設計であることを、ノイジーネイバー問題、ソフトリミットとハードリミットの違い、引き上げ申請の裏側から解説します。

内容が近い記事・サービス

AWS Resource Access ManagerAWS アカウント間や Organizations 内でリソースを安全に共有するサービスで、重複リソースの作成を排除しコストと運用負荷を削減するリソース共有管理 - AWS RAM で実現するマルチアカウント環境の効率的なリソース活用AWS RAM (Resource Access Manager) によるマルチアカウント環境でのリソース共有と、AWS Organizations との連携による組織全体のリソース管理を解説します。VPC サブネット共有やトランジットゲートウェイ共有の実践パターンを紹介します。マルチアカウント管理 - AWS Organizations と RAM で実現する組織全体のガバナンスOrganizations の委任管理者モデルで CloudTrail・Config・GuardDuty・Security Hub を全アカウントに一括展開し、セキュリティとコンプライアンスの統合管理を実現する方法を解説します。Amazon VPC Lattice のマルチアカウント設計 - RAM 共有とサービスネットワークの構成パターンVPC Lattice をマルチアカウント環境で運用する際の RAM 共有設計、サービスネットワークの分割戦略、Auth Policy の階層設計を解説します。