Amazon VPC Lattice のマルチアカウント設計 - RAM 共有とサービスネットワークの構成パターン
VPC Lattice をマルチアカウント環境で運用する際の RAM 共有設計、サービスネットワークの分割戦略、Auth Policy の階層設計を解説します。
マルチアカウント環境での VPC Lattice の課題
AWS のマルチアカウント戦略では、ワークロードごとにアカウントを分離してセキュリティ境界を確保します。しかし、マイクロサービス間の通信はアカウント境界を越える必要があり、従来は VPC ピアリング、Transit Gateway、PrivateLink の組み合わせで実現していました。VPC Lattice はアプリケーションレイヤーでクロスアカウント通信を確立できますが、マルチアカウント環境での設計には固有の考慮事項があります。サービスネットワークの所有権、サービスの共有範囲、Auth Policy の管理責任をどのアカウントに配置するかが設計上の重要な判断ポイントです。
RAM によるサービスネットワークの共有
VPC Lattice のクロスアカウント接続は AWS Resource Access Manager (RAM) を通じて実現します。サービスネットワークの所有者アカウントが RAM リソース共有を作成し、参加アカウントにサービスネットワークへの関連付け権限を付与します。共有先は個別のアカウント ID、Organizations の組織単位 (OU)、または組織全体を指定できます。推奨パターンは、ネットワーク管理専用アカウント (Networking Account) にサービスネットワークを集約し、OU 単位で共有する構成です。これにより、サービスネットワークのライフサイクル管理が一元化され、新しいワークロードアカウントが OU に追加された時点で自動的にサービスネットワークへのアクセス権が付与されます。RAM 共有の承認は Organizations の信頼関係を利用して自動承認にすることで、運用負荷を軽減できます。
サービスネットワークの分割戦略
サービスネットワークをどのように分割するかは、組織の規模とセキュリティ要件に依存します。小規模な組織 (アカウント数 10 未満) では、単一のサービスネットワークにすべてのサービスを登録するシンプルな構成が管理しやすいです。中規模以上の組織では、環境別 (本番・ステージング・開発) またはドメイン別 (決済・認証・通知など) にサービスネットワークを分割することを推奨します。環境別の分割は、本番環境のサービスが開発環境から呼び出されるリスクを排除します。ドメイン別の分割は、チーム間の責任境界を明確にし、Auth Policy の管理を分散できます。ただし、サービスネットワークを細かく分割しすぎると、サービス間の通信経路が複雑になり、運用負荷が増大します。1 つのサービスネットワークに 50〜100 サービス程度を目安とし、それを超える場合に分割を検討するのが実用的です。マルチアカウント設計の詳細は、専門書籍 (Amazon)が参考になります。
Auth Policy の階層設計
VPC Lattice の Auth Policy はサービスネットワークレベルとサービスレベルの 2 階層で適用されます。マルチアカウント環境では、この階層構造を活用して責任分界を設計します。サービスネットワークレベルのポリシーはネットワーク管理アカウントが管理し、「どのアカウントのプリンシパルがサービスネットワーク内のサービスにアクセスできるか」を大枠で制御します。サービスレベルのポリシーは各ワークロードアカウントが管理し、「自分のサービスに対してどのプリンシパルからのアクセスを許可するか」を細かく制御します。この分離により、ネットワーク管理者はセキュリティの大枠を統制しつつ、各チームは自分のサービスのアクセス制御を自律的に管理できます。ポリシーの評価は AND 条件で行われるため、サービスネットワークレベルで拒否されたアクセスは、サービスレベルで許可しても通りません。
まとめ
VPC Lattice のマルチアカウント設計では、RAM 共有によるサービスネットワークの集約管理、環境またはドメイン単位でのサービスネットワーク分割、Auth Policy の 2 階層による責任分界が主要な設計パターンです。ネットワーク管理アカウントにサービスネットワークを集約し、OU 単位で RAM 共有する構成を基本とし、組織の成長に合わせてサービスネットワークの分割を検討してください。