AWSでCIDR重複したVPC間の通信方法4選を比較してみた

クラウドインテグレーション事業部の小倉です。
以前はオンプレのSIなどをやっていましたが、ここ数年はAWS基盤を運用しております。

サービスやOA環境などのITシステムを構築するにあたって、基盤のネットワーク設計というものは非常に重要ですよね。その中でもIPアドレスの設計は後からの変更にとても弱いです。はじめは十分に考慮して設計したはずでも、後から想定になかった拡張や部署・システムの統廃合、もしくはIP空間の枯渇などを背景に重複CIDRが発生してしまうことはよくあるのではないでしょうか。

私がAWS基盤を運用していく中でも、他環境からの移行の受け入れやIP節約などの事情によって、CIDR重複したVPC間の通信方法を考える機会がよくあり、「なぜこの方法を選んだんだっけ？」や、「あの方法だとなんでいけないんだっけ？」など迷う場面がありました。

そのため、今回はもう二度と迷わないよう、CIDR重複したVPC間の通信方法の代表的な解決ソリューション4選を比較してみました。

対象の構成

比較するにあたり下記のシンプルな構成を基準にして、それぞれの通信方法を導入するとどういった構成になるかを当てはめて見ていきます。自社組織内で重複したCIDRを持つVPC AとVPC Bがあり、そこに配置されたサービス間で通信したい場合で考えていきます。

VPC間で通信したいリソース

EC2	フロントのアプリを提供しているインスタンスを想定しています。各VPCのEC2 AとBでサービス連携のための双方向通信要件があるものとします。

VPC間では通信しなくてもよいリソース

RDS	アプリのデータ保管を行うDBを想定しています。VPC間での接続はできなくてよいものとします。
ECS	データ処理などでスケールするコンテナを想定しています。RDSに処理したデータを読み書きできればよいものとします。

各通信要件の構成と検討ポイント

対象の構成を基準に、CIDR重複したVPC間の通信方法の代表的な解決ソリューション4選を比較していきます。

アドレス再設計、AWS PrivateLink、バックエンドサブネット、プライベートNAT Gatewayにおいて、以下のポイントをまとめました。

• 構成：対象とする構成に当てはめたらどういう構成になるか
• 対象の構成上で採用するケース：冒頭の「対象の構成」で考えたとき、どのようなケースで採用するか
• 検討ポイント：検討時に考慮に入れたいポイントや特徴など
• 導入に適する場合
• 導入に適さない場合

なお、方法の選定にあたり今回は下記については除外しました。

• インターネット（AWS基盤外NW）を経由するもの
• サードパーティ製のツールを利用するもの（AWS主要サービスのみで実現できないもの）

1. アドレス再設計

そもそものアドレス設計を見直し、IPを振りなおす方法です。

CIDR重複の解決方法に関して考える時多くの場合、この方法が難しいが故に悩むことになるかと思いますが、構成の複雑化を防ぐためにまず検討すべき方法です。

構成

この方法では制限なく構成パターンが考えられるため、詳細な構成については割愛します。

• VPCの統合
• VPCピアリング
• Transit Gateway

など、それぞれの要件に適した方法を実装可能です。

対象の構成で採用するケース

今回対象とする構成上で採用するケースとしては、「サービス停止影響が少なく、十分にコストがかけられる」場合、この「アドレス再設計」を採用します。理由は、他の方法で発生する通信制限事項を考慮する必要がなく、今後の拡張にも柔軟に対応できるためです。

再設計はサービス規模によって大規模な移行プロジェクトとなる可能性もあるため、かけるコストやリソースが十分に釣り合っているか慎重に検討する必要があります。

また、再設計を見送ったとしても今後再び検討する可能性がある場合、後になればなるほど拡張を繰り返して複雑な要件の移行となることもあるため、できるだけ早めの段階で前向きに検討してみてもいいかもしれません。特にネットワーク周りは後付けの要件に弱いです......。

検討ポイント

• 再設計にかかるコストと、長期的な運用・管理コストがつり合うか
• 今後環境の拡張の見込みがあるか

導入に適する場合

• IPアドレスの変更にかかる時間とコストが確保できる
• IPアドレスの変更にかかるダウンタイムやサービスの中断を許容できる
• 今後環境に拡張の見込みがあり、構成を複雑化させたくない

導入に適さない場合

• IPアドレスの変更にかかる時間とコストが確保できない
• IPアドレスの変更にかかるダウンタイムやサービスの中断を許容できない

2. AWS PrivateLink

重複CIDRを持つVPC同士を直接接続せず、通信が必要な個所だけAWS PriveteLinkを用いて通信する方法です。

AWS PriveteLinkは、VPC内に設置したVPC Endpointと外部のサービスを繋いで通信を確立するサービスです。

構成

VPC Endpoint	プライベートな接続の入口となるのがVPC Endpoint。 接続元のVPC内に設置し、接続元となるクライアントはこのエンドポイントを宛先として通信を行います。 マルチAZ対応。
Network Load Balancer（以下、NLB）	接続先をターゲットとしたNLB。 Endpointを宛先としたアクセスがPrivatelinkによってNLBに転送されます。 Privatelinkに対応しているのはNLBのみのため、ALB（Application Load Balancer）を使いたい場合はNLB⇒ALBと二段構えにする必要があります。
PrivateLink	接続の入口となる"VPC Endpoint"と外部のサービスを繋ぐのがPrivateLinkです。 接続できるサービスは各種AWSマネージドサービスとNLBに対応しており、独自サービスを繋ぐ場合はNLBを利用します。

対象の構成で採用するケース

今回対象とする構成上で採用するケースとしては、「単一ポートのTCP通信要件がある」などの場合、この「AWS PrivateLink」を採用します。採用理由は、VPC構成を一切変更する必要がなく最も手軽な方法だからです。

通信箇所が限定的であればまず頭に思い浮かぶのがこの方法です。

検討ポイント

• ネットワーク的に直接疎通しないことに注意
• インバウンド/アウトバウンド両方向の通信要件は、片方向ごとにPrivateLinkを実装する必要がある
• 対応サービスはNLBのみのため、ALBなどを使用しているサービスの場合は前段にNLBを追加する必要がある
• PrivateLink非対応の要件がある（UDP対応不可、複数のTCPポートを持つアプリケーションに対応不可など）
• PrivateLink料金が発生する

導入に適する場合

• 通信箇所が特定のサービスのみに限定できる
• ネットワーク構成を変更したくない
• 完全重複を許容し、できるだけIPアドレスを節約したい

導入に適さない場合

• VPC全体で相互通信が必要
• サービス要件がPrivateLinkに対応していない
• PrivateLinkにかかる料金が許容できない

参考ドキュメント

• AWS PrivateLink の概要 - Amazon Virtual Private Cloud

3. バックエンドサブネット

VPC間通信を行うサブネットと行わないサブネットを仕分け、VPC間通信を行うサブネットのみTransit Gatewayでルーティングする方法です。

スケールするDBや内部のデータ処理インスタンスなど、外部と通信しないリソースが多くを占める場合に有効な方法です。

構成

Frontend Subnet	VPC間通信を行うサブネットで、他と重複しないIPを割り当てます。 VPC間通信が必要なリソースはこのサブネット内に移行します。
Backend Subnet	VPC間通信を行わないサブネットで、IP重複を許容します。 重複しているもともとのサブネットをBackend Subnetとします。
Transit Gateway（以下、TGW）	VPC同士を接続しルーティングします。 Frontend Subnetのみルーティングするため、ルート伝播の機能はオフにして静的ルートの設定が必要です。

対象の構成で採用するケース

今回対象とする構成上で採用するケースとしては、「UDP、または複数TCPポートの通信要件がある」などの場合、この「バックエンドサブネット」を採用します。

採用理由は、このように他の方法で解決できない特殊な通信要件でも、Frontend Subnetに置くことでネットワーク的に直接疎通が可能となるためです。

検討ポイント

• サービスがFrontend SubnetとBackend Subnetに仕分けられる構成となっているか
• Frontend Subnetの追加設計・IP割り当てを考慮する必要がある
• EC2 A,BをFrontend Subnetへ移行する必要がある
• Backend Subnet側リソースが追加の要件により外部接続が必要になった場合、対応が難しい
• TGWの料金が発生する

導入に適する場合

• フロントとバックエンドに役割が分かれている
• サービスがPrivateLinkに対応していない
• VPC間通信が不要なコンテナワークロードなどで大規模にスケールするリソースがある

導入に適さない場合

• VPC間通信が必要なリソースをFrontend Subnetへ移行できない
• Backend Subnet側のリソースに通信要件の追加の可能性がある
• TGWにかかる料金が許容できない

参考ドキュメント

• Connecting Networks with Overlapping IP Ranges | Networking & Content Delivery
  Option 3: Use multiple IP address ranges in VPCs参照

4. プライベートNAT Gateway

プライベートNAT Gatewayを利用してIP重複範囲を隠し、TGWを通してVPCを接続して通信を行う方法です。

バックエンドサブネットと近い構成ですが、アウトバウンド通信ができる範囲が異なっています。

構成

Routable Subnet	VPC間通信を行うサブネットで、他と重複しないIPを割り当てます。 インバウンド通信を受けるリソースを設置します。
Non-Routable Subnet	NAT Gatewayを通じたアウトバウンド通信のみを行うサブネットで、IP重複を許容します。 重複しているもともとのサブネットをNon-Routable Subnetとします。
Load Balancer	VPC間でインバウンド通信を受けるためのLoad Balancerです。 ※ 元のリソースの移行を最小限としていますが、バックエンドサブネット方式のようにLBを設置せずにEC2をRoutable Subnetに移行する構成も可能です。
Private NAT Gateway	アウトバウンド通信を行うためのPrivate NAT Gatewayを設置します。 これにより、Non-Routable Subnetのリソースでアウトバウンド通信が可能です。

対象の構成で採用するケース

今回対象とする構成上で採用するケースとしては、「ECSにアウトバウンド通信要件がある」などの場合、この「プライベートNAT Gateway」を採用します。

採用理由は、サブネット全域でNAT Gatewayを利用したアウトバウンド通信が提供可能なためです。例えばデータ処理を行うECS Aが、処理の中でEC2 Bのサービスを呼び出す、などの通信要件に対応できます。

検討ポイント

• Non-Routable Subnet側のリソースがNATを通じてアウトバウンド通信が可能
• Routable Subnetの追加設計・IP割り当てを考慮する必要がある
• インバウンド通信を受ける箇所にLoad Balancerの追加が必要
• NAT Gateway、およびTGWの料金が発生する
• 他の方法と比較するとハイコストになりがち

導入に適する場合

• Non-Routable Subnet側に設置したリソースがアウトバウンド通信を行いたい
• EC2 A,Bを別サブネットへ移行せずにVPC同士を接続したい
• VPC間でアウトバウンド通信が必要なコンテナワークロードなどで大規模にスケールするリソースがある

導入に適さない場合

• Load Balancerが利用できない要件 ※ ただしEC2をサブネット移行する場合は回避可能
• NAT Gateway、およびTGWにかかる料金が許容できない

参考ドキュメント

• How to solve Private IP exhaustion with Private NAT Solution | Networking & Content Delivery
• NAT ゲートウェイのユースケース - Amazon Virtual Private Cloud

解決ソリューション4選の比較

この記事で紹介した4つの方法の比較をまとめました。

• VPC全体の通信
  ○：VPC全体に通信を適用する場合
  △：一部アウトバウンド通信のみに制限される場合
  ×：単一の接点の通信のみに制限される場合
• 料金
  接続にかかるサービス料金の有無
• 対象の構成上で採用するケース
  冒頭の「対象の構成」で考えたとき、どのようなケースで採用するか

おわりに

今回はAWSの代表的なサービスのみで実現できるものに絞ってお伝えしました。また、各通信方法の調査・執筆にあたっては「参考ドキュメント」に記載した資料を参考にさせていただきました。

この記事で紹介した方法以外にも、サードパーティ製のサービスも含めればプロキシやVPNなどを活用する方法などもありそうです。また、AWSサービスでも今後も新サービスとして新たな選択肢が増えていくことでしょう。

この記事が、組織内でCIDR重複したVPC間の通信方法の選択肢を比較し、適切な方法を選択する際の役に立てれば幸いです。

プロフィール