AWS Shared VPC を前提としたネットワークとセキュリティの設計の自分用メモ
前提
- マルチVPC戦略が求められている
インフラ、アプリそれぞれの責任とコストは明確に分離したい
- 現状、オンプレのような使い方で分離させていることが多い
- 大きな1つのVPCを用意して、インフラが集中管理
- SGとルーティングでセキュリティを担保
- タグを使ったリソース管理
- AWSではアカウントを分ければ容易
- リソースも互いに不可分になるため、共有する必要がある
ベストプラクティスとして標準化されたVPCを小さく使いたい
- 1サービス1VPCとしてセキュリティやコストを明確に分離する
- セキュリティに対するシンプルな解
- VPC同士をつなげてサービスが連携して１つのシステムとなる
VPCの設計
- シングルリージョン、1VPCなら Shared VPC
- サービスがアプリなら PrivateLink
- サービスがアプリ以外もあるなら TGW
Shared VPC
- 大きなVPCの中にサブネット作成、RAMを使って開発アカウントに対して共有
- サブネット間の通信はサブネットのNACLで制御する
- 既存環境がシングルリージョン、1VPCであれば検討しやすい
メリット
- インフラとアプリの責任（アカウント管理やコスト）を分離できる
- Organizationsが必須
- スケールしないため、複数リージョンや複数VPCの場合は使いづらい
費用
- 共有するための費用は不要
Private Link
- アプリケーションの共有
- 1対Nの関係
メリット
- IPアドレス重複OK
費用
- NLBとエンドポイント費用
TGW
- ネットワークの共有
- 1対Nの関係
メリット
- だいたいなんでもできる（インフラ念ジニア向け）
費用
- AZごとのエンドポイント費用
Tips
共有する際の注意点
- アカウント、VPC、インスタンスはお互いに信用できるか
- セキュリティとネットワークの責任はチームごとなのか、中央集権なのか
- アカウント、VPC、インスタンス単位でコンプライアンスやガバナンス要件はあるか
責任範囲の分け方
- 開発側はリソースに対する権限とSGを管理
- インフラ側はルートテーブルやNACLを管理
- 責任範囲を明確に分離しているとTGWでつないだときも特に問題ない
感想
- マルチVPC戦略をとるなかでどう責任を分離しつつ、VPCをつなげていくのかが分かった