ソリューションアーキテクトの安川 (@thekentiest)です。
先日Amazon Virtual Private Cloud (VPC)に、複数のVPC間をPeeringする機能がリリースされました。ネットワークで遊ぶのが好きな人（私含め）には心躍る新機能ですよね！
これまで何らかの理由で複数のVPC間をつなぐ必要がある場合には、一方のVPCにVPNクライアントを立てたり、AWS DirectConnectの接続拠点のルータから折り返すヘアピンDXパターンなどが必要だったため、可用性・冗長性の確保やコストの部分で悩まれていた方も多いと思います。それがVPC Peeringの登場により、簡単なPeering設定とRouting Tableの変更だけで実現でき、コストや単一故障点の排除に悩む必要性から開放されるということで、たくさんのお客様から喜びの声を頂いております！
他にも、既存のVPCサブネットが既にVPCの全アドレスレンジを使い切っていて、新規サブネットが作れず困っているようなお客様（結構耳にすることがあります）にも、新VPCを作ってPeeringしてシステムの一部としたり、新VPCを一時退避場所にしながらVPCサブネットをリサイズするなんていう使い方が出来るので朗報ではないでしょうか。
VPC間のスター型接続
AWSブログでも触れられていましたが、VPCを繋ぎたいというご要望を頂いた時に最も多いご要望の1つが監視サーバやログの中継サーバなど、異なるシステム間で共通に利用されるサービスを提供するVPCへの接続だというのは私自身も実感として感じています。これは組織内の複数の異なるシステムやプロジェクトである場合もありますし、異なる組織間で必要となるケース（運用監視サービスや、プライベート接続によって提供されるSaaSなど）の場合もあります。
特に、VPCがデフォルトになって以降、新規のアカウントを作るとVPCを指定しないリソースはデフォルトVPCにプロビジョニングされるため、EC2-Classicで行っていたような、Security Group間の参照だけで共通サービスへのアクセス制限を行えるケースは減ってきました。そのため、上記のようなユースケースでは、EIPをインスタンスに割り当て、それをアクセス元/先として限定したSecurity GroupやNetwork Access Control Listを用いることでアクセス制限を行うよう工夫したり、VPC間をVPN等で接続したりすることで共通サービスの提供をするのが一般的でした。
冒頭でも書きましたが、VPC Peeringを使えば、共通サービスを集めたVPCに対して、各プロジェクトや組織の個別VPCからPeeringを行うことで、シンプルかつより柔軟なシステム設計が可能になります。
そこで本日はVPC Peeringで同様の目的を実現するために利用する際に考慮すべき事柄や注意点などを見て行きたいと思います。
考慮すべきこと1: IPアドレスの重複回避
VPC Peeringを行う時、注意して避ける必要があるのがIPアドレスレンジの重複です。現状、IPアドレスレンジに重複があるVPC同士をPeeringすることは出来ません。（例え出来たとしても、現状のVPCのRouting Tableの仕様では、VPCのIPアドレスレンジの一部に対して新たなRoutingルールを設定することは出来ないため、Routing Tableを正しく設定することは出来ないはずです。）
つまり、共通サービスを提供するVPCについては、そのサービスを必要とするクライアントが属するVPCとの間でIPアドレスレンジが重複しないように予め考慮しておく必要があります。
これについて万能な解はありませんが、一般にあまり選ばれにくいレンジを共通サービス向けVPCに割り当てるようにすると、少しでも重複が起きる可能性を下げられるかと思います。例えば、10.0.0.0/16や192.168.0.0/16など、よく使われがちなPrivateアドレスブロックの末端を避けるというのもありますし、100.64.0.0/10 (RFC6598)や198.18.0.0/15 (RFC2544)のようなプライベートな環境で使う目的で特別に割り当てられたIPアドレスレンジから切り出して使うなどするとより一層重複の可能性は下げられるのではないかと思います。
また、各VPCが/16ほどの大きさのレンジを必要としないようであれば、/17, /18...などもう少し小さなアドレスレンジをそれぞれ使うようにすることでより重複を避けやすくするなるかもしれません。（但し、将来のシステムのスケールについても十分考慮は必要です。VPCの大きさが理由でシステムがスケール出来ないという自体にならないように注意しましょう）
考慮すべきこと2: Routing Table内の重複経路排除
上記のIPアドレスレンジの重複への考慮はあくまでPeeringに参加する2つのVPCの間での制限となります。3つ以上のVPCが存在してPeeringによって接続される場合でも、直接Peeringを行う2者間にさえ重複がなければ、IPアドレスレンジが重複した2つ以上のVPCがPeering接続のグラフに含まれても問題はありません。例えば、下記のような構成もPeeringの設定としては問題なく可能です。
上記のような状況は極端な例に思えるかもしれませんが、実際に例えばデフォルトVPCを利用する複数のアカウントに対して監視やその他共通サービスを提供するような場合に起こりえます。その場合、VPC Peering上は問題ありませんが、Routingの観点では工夫が必要です。というのも、同じIPアドレスレンジを宛先とした経路情報を複数持つRouting Tableは設定できないためです。
1つの方法としては、通信を行うIPアドレスレンジが重複した各VPCについて、他のVPCとは重ならないようにIPアドレスレンジをずらしたサブネットを用意し、共通サービスを提供するVPCとの通信に利用する方法があります。
下記の例では、172.31.0.0/16が割り当てられた2つのVPC B, Cに対して、VPC Aとの通信を行うためのIPアドレスレンジとして、172.31.128.0/24と172.31.129.0/24をそれぞれ割り当てています。その上で、VPC AのRouting Tableに、先述の通信用サブネットへの経路としてVPC B, CとのPeering Connectionを設定していますので、VPC B, C内に割り当てられたIPアドレスレンジを持つ通信用サブネットを設けることで、そのサブネットとVPC Aとの間であれば双方向に通信が可能となります。
実際に通信を行うには、VPC Aとの通信用サブネットにNATやプロキシ/踏み台などの機能を持つインスタンスを配置するか（VPC Bはその前提）、VPC Aと通信を行う必要があるインスタンスと同数のENIを通信用サブネットに用意して、通信を行う必要のあるインスタンスにアタッチするという方法（VPC Cはその前提）が考えられます。
前者はNATやプロキシ/踏み台が必要となる点がデメリットですが、通信用サブネットを小さく保つことが出来て、より多くの重複するIPアドレスレンジを持つVPCを接続できます。後者はNATやプロキシ/踏み台などが不要なのは明らかな利点ですが、通信用サブネットの大きさがVPC内のインスタンス数分以上は必要になるため、同時接続可能な重複するIPアドレスレンジを持つVPCの数は前者より定性的に小さくなる点がデメリットです。PeeringするVPCの数や、重複するIPアドレスレンジを持つVPCの数によって使い分けて頂くと良いかと思います。
その他VPC Peeringで考慮・注意すべき事項
リージョンを越えたVPC間プライベート通信は未サポート
現状のVPC Peeringはリージョン内で閉じている必要があります。リージョンを越えてプライベート通信を行う必要がある場合は従来同様、VPNを利用するのが現実解かと思います。（詳細はこちら）
2ホップ以上先のネットワークへのRoutingは未サポート
VPC Peeringが提供するのはあくまでPeeringで、複数VPC間のRoutingではありません。3つ以上のVPCをPeeringしたり、AWS外の拠点とVPNやDirectConnectで接続したりした場合に、Routing Tableをそれぞれ適切に設定したとしても2ホップ以上先のネットワークへのIPレイヤでのRoutingは行われません。プロキシや踏み台を使うなどのワークアラウンドが従来同様必要です。
Peering先のインスタンスのDNS解決名を解決して返ってくるのはGlobal IPアドレス
EIPや動的Public IPなど、Global IPアドレスをアサインされたEC2インスタンスのPublic DNS名を解決すると、同一VPC内からの問い合わせであればPrivate IPアドレスが返って来ます。PeeringしたVPC同士だと、Peering先のインスタンスのDNS名解決をした際に同じ挙動になることを期待されるかもしれませんが、そこはやはり異なるVPCですので、現状は少なくともVPC外から問い合わせたのと同じくGlobal IPアドレスが返されます。Peering先とPrivate IPアドレスで通信するには明示的にPrivate DNS名かIPアドレスを指定する必要があるのでご注意下さい。
なお、Internal ELBについてはVPC内外問わず、DNSの解決時にはPrivate IPアドレスが返りますので、Peering Connectionを通した場合でも安心して利用可能です！
その他のシナリオや各種制限等
本記事で取り上げた以外のシナリオやコンフィグ例についてこちらのドキュメントにまとまっています。また、Peering Connectionの数の上限などを含む各種制限についてはこちらのページをご参照下さい。
まとめ
VPC間接続のユースケースの中でも特によく見かけるスター型接続について取り上げて、考慮すべき事柄や注意点、複雑なケースでのRouting Table設定Tipsなど見てきました。VPC Peeringを使えばより自由で柔軟なシステム設計が可能になりますので、ぜひぜひ使いこなして下さい！
また、もし「こんな面白い使い方をしてます」という事例や、「ここがもうちょっとこうだといいな」みたいなご要望などありましたら、是非我々ソリューションアーキテクトにお聞かせ下さい。事例についてはこのブログで取り上げたり、どこかで発表して頂いたりする機会もあるかもしれませんし、たくさん頂くご要望についてはVPCの開発チームにフィードバック出来るかと思います。皆様の声を聞いて進化するのがAWS流ですので、皆様の声を是非お聞かせ下さい！
