この記事は Nicolas Vibert 氏のブログ AWS Transit VPC の翻訳です。 翻訳の一覧はこちら。

このブログ記事では、VPC、VPC Peering、Transit VPCについて解説します。

この AWS ブログ記事 で Aarthi と私が Transit VPC をハイレベルで取り上げた後、Transit VPC の背後にあるアーキテクチャについて説明したいと思いました。

VPCの概要

まず、VPC (Virtual Private Cloud) について簡単におさらいしておきましょう。基本的には、これは AWS 上の仮想データセンターです。

VPC Logo VPC Logo

顧客は通常、1 つ（または複数）の VPC を作成し、1 つの CIDR と 1 つ（または複数）の IP サブネットを定義して、AWS サービス（EC2 インスタンスなど）が IP アドレスを取得するようにします。

訳者注: 現在は VPC に 4 つまで CIDR を割り当てることができます。 Amazon VPC のよくある質問 - IP アドレス関連 - Q:IP アドレス範囲をどのように Amazon VPC に割り当てるのですか?

VPC で実行しているサービスへのアクセスは、AWS のセキュリティ グループやネットワーク アクセスリストを利用してセキュリティを確保することができます。

VPC はリージョン（例：オレゴン、フランクフルト、シドニーなど）に縛られているが、リージョン内の複数の可用性ゾーンに分散させることも可能です。

AWS のユーザーは、セグメンテーション、管理、課金、コンプライアンスの目的で、多くの VPC を設計に使用することが多いです。

例えば、一部の顧客は以下のように作成するかもしれません:

  • VPC1 = 本番環境, VPC2 = 開発環境, VPC3 = テスト環境
  • VPC1 = 人事, VPC2 = 開発, VPC3 = 営業
  • VPC1 = ‘ビジネス部門 1’, VPC2 = ‘ビジネス部門 2’
  • VPC1 = APP1, VPC2 = APP2, VPC3 = APP3

数十、いや数百の VPCを持っているお客様に出くわすことも珍しくありません。そして、それらを監視し、特に相互接続するのは面倒なことです。

Transit VPC と AWS Transit Gateway はそのためのものです。しかし、最初に VPC ピアリングについて説明しましょう。VPC Peering に詳しい方は、次の「AWS Transit VPCとは」までスクロールしてみてください。

VPC ピアリング

複数の VPC 間の接続を確立する「従来の」方法は、VPCピアリングです。

詳細なガイドは こちら、または以下の私の要約をお読みください。

VPC ピアリング接続とは、プライベート IPv4 アドレスを使用して 2 つの VPC 間でトラフィックをルーティングできるようにするネットワーク接続です。

VPC Peering VPC Peering

VPC 内のインスタンスは、同じネットワーク内にあるかのようにお互いに通信することができます。自身が保有する VPC 間、または別の AWS アカウントが保有する VPC との間で VPC ピアリング接続を作成することができます。

VPC ピアリング接続は、2 つの VPC 間の 1 対 1 の関係です。

VPC Peering VPC Peering

上の図では、2 つの VPC ピアリング接続があります。

VPC A は、VPC B と VPC C の両方とピアリングされています。私のラボでは、上図のように VPC A (CIDR 172.16.0.0/16)、VPC B (CIDR 10.0.0.0/16)、VPC C (CIDR 192.168.0.0/16) を作成しました。

Nico’s VPCs Nico’s VPCs

続いて AWS コンソールの VPC UI で、VPC ピアリング接続を作成しました。やり方は非常に簡単です。ピアリングしたい 2 つの VPC（“Requester"と “Accepter”）を選択するだけです。異なるアカウントと異なるリージョンの VPC をピアリングすることもできますが、私のは同じアカウントとフランクフルト リージョンの VPC をピアリングしています。

Create VPC PeeringVPC Peering Creation Create VPC PeeringVPC Peering Creation

アクセプトすればいいだけです (AWSは、別のアカウントの誰かが自分とピアリングしたいと思っていて、そのアカウントでピアリングしたくなかった場合に備えてこのようにしています)。

Remember to accept the peering Remember to accept the peering

VPC A から VPC B へのピアリングと、VPC A から VPC C へのピアリングの 2 つを構築しました。

まだ終わりではありません。VPC ルーティング テーブルを編集して、VPC A が VPC B の CIDR にどうやって到達するかを VPC A に伝えたり、逆に VPC B の CIDR にどうやって到達するかを伝えたりする必要があります。私も VPC A と VPC C のためにそれをしなければなりませんでした。

下のルーティング テーブルの「Target」は、先ほど作成したピアリング接続になります（常に pcx- で始まります）。基本的には、VPC ルータに、もし宛先 IP が 10.0.0.0.0/16 のパケットを見たら、それをピアリング接続で VPC B に送るように指示しているだけです。

VPC A Routing Table VPC A Routing Table

VPC B Routing Table VPC B Routing Table

各 VPC に EC2 インスタンスを起動し、EC2-VPC A (172.16.10.16) が EC2-VPC B (10.0.0.0.44) と話ができるようになり、EC2-VPC A が EC2-VPC C (192.168.11.190) と話ができるようになりました。

[ec2-user@ip-172-16-10-16 ~]$ ping 192.168.11.190
PING 192.168.11.190 (192.168.11.190) 56(84) bytes of data.
64 bytes from 192.168.11.190: icmp_seq=1 ttl=255 time=0.948 ms
64 bytes from 192.168.11.190: icmp_seq=2 ttl=255 time=3.94 ms
64 bytes from 192.168.11.190: icmp_seq=3 ttl=255 time=0.956 ms
64 bytes from 192.168.11.190: icmp_seq=4 ttl=255 time=1.01 ms
64 bytes from 192.168.11.190: icmp_seq=5 ttl=255 time=1.09 ms
^C
--- 192.168.11.190 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 0.948/1.592/3.948/1.179 ms
[ec2-user@ip-172-16-10-16 ~]$ ping 10.0.0.44
PING 10.0.0.44 (10.0.0.44) 56(84) bytes of data.
64 bytes from 10.0.0.44: icmp_seq=1 ttl=255 time=0.858 ms
64 bytes from 10.0.0.44: icmp_seq=2 ttl=255 time=0.898 ms
64 bytes from 10.0.0.44: icmp_seq=3 ttl=255 time=0.886 ms
64 bytes from 10.0.0.44: icmp_seq=4 ttl=255 time=0.925 ms
64 bytes from 10.0.0.44: icmp_seq=5 ttl=255 time=0.879 ms
^C
--- 10.0.0.44 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4034ms
rtt min/avg/max/mdev = 0.858/0.889/0.925/0.029 ms

EC2-VPC B と EC2-VPC C も試してみましたが…ダメでした。

Transit VPC is not transitive Transit VPC is not transitive

お気づきかもしれませんが、VPC B と VPC C はピアリングされておらず、VPC B と VPC C 間のピアリングの中継地点として VPC A を使用することはできません。

この意味での「トランジティブ」とは、VPC B から VPC A を経由して VPC C に行くことができないことを意味します。

VPC B と VPC C の間でトラフィックのルーティングを有効にしたい場合は、両者の間に独自の VPC ピアリング接続を作成する必要があります。

私はピアリングの作成を行った後、両方の VPC のルーティングテーブルを編集しました。ルータ上でどのように素早く変化が起こるかは、小さなビデオで見ることができます。VPC C ルーティングテーブルのルーティング変更を完了するとすぐに、VPC B と VPC C の間の ping が流れ始めます。

では なぜ VPC ピアリングを使わないのでしょうか?

上で見たように、すべてのVPCを相互に通信させるには、VPCピアリングのフルメッシュが必要です。上記の3つのVPCについては、それは十分に簡単でした。

しかし、5 個のVPCを持っていた場合はどうなるでしょうか？あるいは 10 個のVPC？ あるいは 30 個の VPC を持っていたら？

If I remember my maths lessons correctly: 私が数学の授業を正しく覚えているならば…:

n 個の VPC をメッシュ化するには、n * ( n - 1 ) / 2 本のピアリング接続が必要です。

これは、非常に多くの VPC ピアリング接続を大規模に維持したり設定したりすることが非常に複雑になります。例えば、以下のようになります。

  • 10 個の VPC ピアのフルメッシュは、45 個のピアリング接続を意味します。
  • 30 個の VPC ピアのフルメッシュは、435 個のピアリング接続を意味します。

これはかなり恐ろしいことです。

それだけでなく、VPC ピアリングは AWS の VPC 間でしか動作しません。“VPCピアリング"は BGP や IPSEC のような標準プロトコルに基づいているわけではありません。

これは AWS ネットワークの魔法使いがダンジョンで編み出したものです（まともな人が AWS ネットワークを考え出すことはできません - 私がこれまでのキャリアで学んだネットワークのルールの多くを壊しています）。

VPC ピアリングを使ってオンプレミスの DC や他のクラウドと通信することはできません。

以上のことから、AWS では複数の VPC 間の通信をサポートするために「Transit VPC」、その後「Transit Gateway」という概念が導入されました。

AWS Transit VPC とは？

AWS サービスの一覧やコンソールのどこにも「Transit VPC」は見当たりません。実際には製品ではなく、どちらかというとリファレンス アーキテクチャです。

最初に Transit VPC がアナウンスされたのは 2016 年 8 月ですが、ある意味ではすでに AWS Transit Gateway に取って代わられています（それはまた別の日のブログ記事になります）。しかし、Transit VPC は広く展開されており、まだまだ素晴らしいユースケースがたくさんあります。

Transit VPC Architecture Transit VPC Architecture

Transit VPC は、ハブとスポークのアーキテクチャに基づいています。

Transit VPC は中央にあり、追加の「スポーク」VPC、企業DC、その他のネットワークに囲まれています。

従来の IPSec VPN トンネルを利用して（VPC ピアリングの代わりに）サイト同士を相互接続し、さらにはダイナミック・ルーティング・プロトコル（一般的には BGP）も利用できます。

主な利点の一つは、IDS/IPS/NGFWを利用してセキュリティを強化できることです。

Transit VPC は、他にも以下のような利点をもたらします:

  • より高いスケール
  • 知名度と互換性（既存のファイアウォールベンダーを利用できるので)
  • ファイアウォールの挿入 (VPC ピアリングと TGW はルータであり、トラフィックを検査しない)
  • どこでも暗号化 (暗号化されていない状態で送信される VPC ピアリング トラフィックとは異なります)

AWS Transit VPC アーキテクチャ

この記事では Palo Alto Networks の次世代ファイアウォールを使用しますが、Cisco CSR や vASA、CheckPoint、Juniper、Fortigate などの他の仮想ファイアウォールにも同じ原理が適用されます。

Transit VPC Architecture Transit VPC Architecture

Transit VPC 内には、Palo Alto Firewall を実行している EC2 インスタンスがあります。複数の PAN EC2 インスタンスを実行することができます（おそらく実行すべきです）。

青いボックスは Spoke VPC です。複数の VPC を Spoke VPC とすることができます。Spoke VPC VGW（仮想ゲートウェイ）とPalo Alto FW の間には、1 つ以上の VPN があります。

Transit VPC にはインターネット ゲートウェイ (IGW) が接続されています。すべての Spoke VPC は、この IGW を介してインターネットに通信します。Palo Alto FW はインターネット ゲートウェイへのデフォルト ルートを持っています。Palo Alto はこのルートを Spoke にして（BGP ルート再分配を通じて）アドバタイズします。

下の図では、Transit VPC に 1 本の Spoke が接続されています。Spoke VPC は Transit VPC にそのローカル CIDR をアドバタイズします。

Transit VPC は、デフォルト ルート、そのローカル CIDR、および他の Spoke から学習した他のすべてのネットワークをアドバタイズします。

Transit VPC with 1 Spoke Transit VPC with 1 Spoke

Spoke 1 は AWS Virtual Gateway (VGW) から Palo Alto への VPN を 1 つ設定するだけです。Spoke の VPC の中で Palo Alto の FW を実行する必要はありません。

別の Spoke (下の写真のような別の VPC、リモートサイト、VMware Cloud on AWS SDDCなど) に接続する場合は、Spoke からSpoke へのトラフィックは Transit VPC を経由するという、非常にシンプルなアーキテクチャになります。

Transit VPC with 2 Spoke Transit VPC with 2 Spoke

多くの VPC 間の接続を確立するために設定しなければならなかった多くの VPC ピアリングと比較すると、このアーキテクチャがいかに物事を大幅に簡素化しているかがわかります。 新しい VPC がオンラインになるたびに、VPN トンネルを経由して Transit VPC に接続すれば準備完了です。常にフル VPC ピアリング メッシュを設定して維持する必要はありません。

次の記事では、Transit VPC を完全に設定した場合の実際の設定とルーティング テーブル、そして VMware Cloud on AWS に接続した場合にどのように見えるかを見ていきたいと思います。

最後までお読みいただきありがとうございました。