「Amazon Virtual Private Cloud」（VPC）間の接続、IaaS（VPC）〜PaaS／SaaS間の接続はどうすべきか：AWSで学ぶクラウド時代のネットワーク基礎知識（4）

これまであまり物理的なネットワークに触れてこなかったエンジニアを対象に、AWSを用いてネットワークの基礎知識を解説する連載。今回は、「Amazon Virtual Private Cloud」（VPC）間の接続、IaaS（VPC）〜PaaS／SaaS間の接続について解説する。

[東竜一，ネットワンシステムズ]

　これまであまり物理的なネットワークに触れられてこなかったSEやサーバ管理者、情シスなどの方を対象にネットワークの基本を「Amazon Web Services」（AWS）を用いて解説する本連載「AWSで学ぶクラウド時代のネットワーク基礎知識」。

　前回まではネットワークの基本技術の説明とAWSの環境を用いた動作紹介という形でしたが、第4回の本稿は、AWSのネットワーク間を接続する方法、サービスを紹介します。

　オンプレミス環境でネットワーク間を接続する場合、ルーターやスイッチなどのネットワーク機器を用いて接続する必要が生じますが、クラウドのネットワークは仮想的な環境なので、容易に接続できます。

　なお、本稿では次の2つのネットワーク接続を対象とします。

1. 「Amazon Virtual Private Cloud」（VPC）間の接続
2. IaaS（VPC）〜PaaS／SaaS間の接続

VPC間の接続

　まずはVPC間の接続についてです。異なるVPC上の端末間で通信する方法として、大きく分けて下記表の4つが存在します。以降でそれぞれの接続方式について説明しますが、2〜3個のVPCを接続する場合は「VPCピアリング」での接続が容易ですが、多数のVPCを接続する場合は「Transit Gateway」がお薦めです。

項目＼方式		インターネット	IPsec VPN	VPCピアリング	Transit Gateway
接続容易性	VPC2点間	◎	△	○	△
	複数VPC間	○	△ （Transit VPC）	△ （多数には不向き）	◎
通信に利用するIPアドレス		グローバル	プライベート	プライベート	プライベート
通信速度		○	△	◎	◎
リージョン間接続		◎ （考慮不要）	◎ （考慮不要）	◎	○

インターネット

　1つ目のインターネットでの接続は、VPCのインターネット接続機能を利用し、互いにインターネット上の端末として通信させるものです。実装は容易ですが、注意点としては、インターネットを経由させるので、通信する端末にElastic IPアドレスを割り当てるなどしてグローバルIPアドレスで通信させる必要があります。プライベートIPアドレスを用いた通信はできません。

　なお、「VPC間の経路はインターネット」と記載していますが、VPCのFAQページにある下記の記載から、上記の通信はAWSのネットワーク内に閉じた通信となり、AWSのネットワーク外を通ることはありません。また以降に記載の通信も全てAWSのネットワーク内に閉じた通信となります。

Q：2つのインスタンスがパブリックIPアドレスを使用して通信する場合、またはインスタンスがパブリックなAWSのサービスエンドポイントと通信する場合、トラフィックはインターネットを経由しますか？

いいえ。パブリックIPアドレスを使用する場合、AWSでホストされているインスタンスとサービス間の全ての通信はAWSのプライベートネットワークを使用します。AWSネットワークから発信され、AWSネットワーク上の送信先を持つパケットは、AWS中国リージョンとの間のトラフィックを除いて、AWSグローバルネットワークにとどまります。

IPsec VPN

　2つ目のIPsec VPNは連載第3回で紹介した機能を利用したVPC間の接続です。第3回ではオンプレミス環境とVPCを「IPsec VPN」という暗号化／カプセル化技術でプライベートに接続しましたが、本機能によってVPC間を接続します。VPN接続ができればよく、特別な対応は不要です。リージョン内だけでなく異なるリージョン間の接続もできます。

　本方式は第3回でも記載したように暗号化のためにスループットが出にくいというデメリットがあります。またIPsec VPNは、2つのネットワーク間の接続となるので複数のVPCを接続する場合は通信させたいVPC間ごとにVPNの設定が必要となります。仮に全VPC間で通信が必要な場合はフルメッシュに接続する必要があり、VPCの数に合わせて指数的にIPsec VPNの設定が必要となり、現実的ではありません。

　複数のVPC間の接続が難しいことへの解決策として、あるVPC上にIPsec VPNをサポートする仮想ルーターを設置し、このVPCをハブとして他のVPCと接続するハブ＆スポーク構成にし、仮想ルーターのルーティング機能で各スポークVPC間を通信させる「Transit VPC」があります。ただし、このような複数VPC間の接続は、現在では後述のTransit Gatewayを利用することが推奨されます。

• 参考：https://aws.amazon.com/jp/blogs/news/aws-solution-transit-vpc/

VPCピアリング

　3つ目のVPCピアリングはVPC間に仮想的な直接接続のパスを作成する機能です。本機能によって2つのVPC間を、帯域幅のボトルネックなしでプライベートに接続できます。冗長性について利用者が考慮する必要はありません。リージョン間ピアリング接続に対応しているリージョン限定とはなりますが、異なるリージョンのVPC間でピアリングすることも可能です。

　本方式のデメリットは、あくまでも2つのVPC間を接続する機能なので多数のVPCの接続には不向きとなることです。なお、IPsec VPN接続の項で紹介したTransit VPC構成を取ることはできず、各VPC間で個々にピアリング接続をする必要があります。

Transit Gateway

　4つ目のTransit Gatewayは「IPsec VPN接続」の項で記載した、Transit VPCの機能をAWSが公式に提供したような機能です。数千個レベルのVPC環境でも接続できます。ゲートウェイとしてルーティング機能を細かく制御でき、通信の宛先ごとに転送先のVPCを制御できるようになっています。本ゲートウェイはAWSのマネージドサービスの内部で冗長化されており、利用者が冗長性を考慮する必要はありません。

　注意事項として、あるTransit Gatewayをリージョンが異なるVPCと接続する場合は、リージョンごとにTransit Gatewayを作成し、同一リージョン内のVPCと接続した上で、Transit Gateway間をピアリングすることでリージョン間のVPC通信を実現します。

　なお、Transit Gatewayに対応しているリージョンでもTransit Gatewayのリージョン間ピアリングに対応しているとは限りません。もし対応していないリージョンでVPCをリージョン間で接続したい場合は、同一リージョンのVPC間はTransit Gatewayで接続しながら、別のリージョンの個々のVPCとリージョン間VPCピアリングで接続することになります。

コラム　AWS PrivateLink

　なお、上記の4つの方式以外に「AWS PrivateLink」という機能があります。

　これを使うと、あるVPCから別のVPCにある特定サービスのみに、プライベートにアクセスできます。その機能上、ネットワークのセグメントレベルで通信が許容されるわけではないので、本稿ではAWSネットワーク間の接続機能の対象外としています。

IaaS（VPC）〜PaaS／SaaS間の接続

　AWSのIaaS（VPC）環境とAWSのPaaS／SaaSサービスとの接続方法について説明します。

　「Amazon S3」（Simple Storage Service）をはじめとする、AWSのPaaSやSaaSはインターネット向けサービスとして展開されており、インターネット経由でのグローバルアクセスが基本的な通信方法です。そのため、VPC内からでもインターネット宛てに通信させることが基本のアクセス方法となります。ただし前述の通り、AWSサービス間の通信なのでインターネットは経由せずAWSのグローバルネットワーク内で完結する通信です。

　また、対応しているサービスが限定される手法となりますが、VPC内にゲートウェイエンドポイントを立てることで、インターネットゲートウェイを利用せずプライベートIPでアクセスすることもできます。現状対応しているサービスはS3および「Amazon DynamoDB」の2つです。

AWSネットワーク間接続の設定紹介

　ここまでAWSのネットワーク間の接続方法を紹介しました。ここからは紹介した機能の一部ですが、通信の設定を簡単に紹介します。具体的に紹介する機能は次の2つです。

• VPCピアリング
• Transit Gateway

VPCピアリング

　VPCピアリングの構成は下図のようになります。

　設定は次の3つです。

1. 2VPC間のピアリング接続
2. ピアリング接続の承諾
3. 各VPCでのルート設定

　1.についてですが、VPCのページの「ピアリング接続」でVPCピアリングを設定します。下図はその設定画面で、接続依頼元を「リクエスタ」、接続依頼先を「アクセプタ」といいます。リクエスタVPCに「VPC01」、アクセプタVPCに「VPC02」を指定することで、この2つのVPC間を接続します。アクセプタVPCは別のアカウント、別のリージョンのVPCを指定することもできます。

　2.のピアリング接続の承諾は、アクセプタVPCに接続の承諾が依頼されるので、承諾することでVPCピアリングが行われます。

　3.については、各VPCのルートテーブルにルートを設定します。1.の設定で2つのVPC間に仮想の接続が作成されていますが、そのままではルートテーブルにルートがないので、宛先不明で通信できません。そこで下記のように、対向にあるVPCのセグメントのターゲットを「ピアリング接続（pcx-〜）」とするルートを設定します。この設定は両VPCで必要です。

　この状態で通信を確認した結果、下図のようになります。プライベートIPアドレスでVPC間の通信が問題なくできていることを確認できます。

Transit Gateway

　Transit Gatewayの設定の構成は、下図のようになります。

　Transit Gatewayの設定は単純に接続するだけなら、次の3つです。

1. Transit Gatewayの作成
2. 各VPCと接続する「Transit Gatewayアタッチメント」の作成
3. 各VPCでルートの設定

　1.のTransit Gatewayの作成の設定画面は下図のようになります。

　パラメーターは名前以外デフォルトのまま作成していますが、「デフォルトルートテーブルの関連付け」「デフォルトルートテーブル伝播」によって、2.を設定することで自動的に各VPCと通信できるようになり、Transit Gatewayのルートテーブルに各VPCのルートが学習されます。

　3.については、VPCピアリングと同様に各VPCのルートテーブルへのルートを設定します。対向にあるVPCのセグメントのターゲットを「Transit Gateway（tgw-〜）」とするルートを設定します。この設定は両VPCで必要です。

　この状態で通信を確認すると、下図のようになります。

　プライベートIPアドレスでVPC間を問題なく通信できていることを確認できます。Tracerouteで1ホップ目の返答がありませんが、Transit Gatewayが間に入っているからです。VPCピアリングの場合は1ホップで到達しているので、異なる接続方法だと分かります。

まとめ

　本稿はAWSのネットワーク間の接続として、VPC間およびIaaS（VPC）〜PaaS／SaaS間の接続方法を紹介しました。VPC間は接続するVPC数によってVPCピアリングかTransit Gatewayでの接続が推奨されます。

　次回第5回は、サーバ公開で利用するネットワーク機能について説明する予定です。

Appendix

　ここからは、本稿の環境の作成手順について、第1回で作成した「VPC01」の構成に追加する形で記載します。AWSの環境を作って動作を確認してみたい方は本手順を参考に試していただければと思います。

　本稿で説明する構成は下図の通りです。「VPC02」は、VPC01とCIDR（Classless Inter-Domain Routing）のパラメーターが異なる以外は、VPC01と同様の設定のVPCです。これらのVPC間でVPCピアリングおよびTransit Gatewayで接続します。

VPCピアリングでVPC間を接続

　まずは下図のようにVPCピアリングでVPC間を接続し、通信できるようにします。

　VPCの設定画面の「ピアリング接続」の項で画面右上の「ピアリング接続を作成」ボタンをクリックします。

　表示される画面でVPCピアリングの設定を行います。リクエスタとして接続依頼元のVPC、アクセプタとして接続依頼先のVPCを指定します。下図で確認できますが、別のアカウントやリージョンのVPCとも接続可能です。今回は同一アカウント、リージョンのVPC間で接続しています。必要なパラメーターを設定し、表示される各VPCのCIDRの値に問題がなければ「ピアリング接続を作成」ボタンをクリックします。

　上記の操作の結果、接続依頼先のVPCのアカウント所有者に対して接続リクエストが投げられたことを下図から確認できます。注意点として、本リクエストの承諾期限は1週間となっており、それまでに承諾が必要です。

　再度「ピアリング接続」の画面に移動すると、先ほど作成したピアリング接続が表示されます。今回の環境では同一アカウント、リージョンなので本ピアリングを選択し、画面右上の「アクション」ボタンクリックで表示されるメニューから「リクエストを承諾」をクリックします。

　表示されるピアリング接続のリクエスト内容を確認し、問題がなければ、「リクエストを承諾」ボタンをクリックします。

　本設定によってVPCピアリングが確立されました。ただし赤枠の注意書きにある通り、ルートテーブルにルートを追加する設定が必要です。これは、VPCピアリングを設定して通信経路ができたものの、それだけでは各VPCにおいてルーティング上、対向のVPCの宛先やネクストホップが分からず通信できないからです。画面右上の「ルートテーブルを今すぐ変更」は「ルートテーブル」のページに遷移するボタンです。

　「ルートテーブル」ページでルートを設定します。まずは「VPC01」のルートテーブル「RouteTable01」を選択し、下のペインで「ルート」タブを表示します。そこで、登録されているルートとしてひも付いている「VPC01」自身のCIDRとインターネットアクセス用に設定しているデフォルトルートのみで、「VPC02」向けのルートがないことを確認した上で「ルートを編集」ボタンをクリックします。

　表示される画面で、「ルートを追加」ボタンをクリックし、追加されたエントリで送信先を「VPC02」のCIDR「192.168.1.0/24」、ターゲットとして設定したピアリング接続を指定します。なお、送信先のセグメントは今回対向のVPCのCIDRを指定していますが、個別のサブネットや特定の端末とだけ通信したい場合はそのセグメントだけを記載します。

　この操作によって、ルートテーブル「RouteTable01」に「VPC02」のCIDR「192.168.1.0/24」が、ターゲット「pcx-〜（ピアリング接続）」で設定されました。なお、デフォルトルートもありますが、「VPC02」宛ての通信はロンゲストマッチの規則によってピアリング接続を通して「VPC02」に転送されることになります。

　これで「VPC01」から「VPC02」宛てにルーティングできるようになりましたが、「VPC02」のルーティングが設定されていないので、戻り通信がうまくできず、まだ通信できない状態です。そこで「VPC02」にも同様に設定し、下図のように、「VPC01」のCIDR「192.168.0.0/24」宛ての通信をターゲット「ピアリング接続」にして双方向通信できるようにします。

　以上の設定によって、VPCピアリングでVPC間が通信できるようになります。その確認をしてみましょう。「AWS CloudShell」を利用し、「VPC01」に属している「Instance01」（IPアドレス: 192.168.0.62）から「VPC02」に属している「Instance02」（IPアドレス: 192.168.1.22）にPing、Traceroute、SSH接続を試してみると、プライベートIPアドレスで問題なくアクセスできていることを確認できると思います。つながらない場合は「Instance02」にひも付いているセキュリティグループによって通信がはじかれている可能性があるので、設定を確認してみてください。

Transit GatewayでVPC間の接続

　次に、Transit GatewayでVPC間を接続します。その前に、VPCピアリングの接続を無効化するために両VPCのルートテーブルから対向のVPCへのルートを削除しておいてください。

　Transit Gatewayの構成はベストプラクティスに従う場合、下図のようにVPCアタッチメントを個別のサブネットに適用します。

• 参考：https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/tgw-best-design-practices.html

　本稿では、構成の簡単化のために下図のように各VPCにサブネットを1つだけ作成します。

　Transit GatewayでVPC間の接続を実現する手順は次の通りです。

1. Transit Gatewayを作成する
2. 各VPCと接続する、Transit Gateway アタッチメントを作成する
3. 各VPCでルートを設定する

・1.Transit Gatewayを作成する

　VPCのページの「Transit Gateway」の項の右上の「Transit Gatewayを作成」ボタンをクリックします。

　表示される画面で、名前を「TransitGateway」、それ以外のパラメーターはデフォルトのまま「Transit Gatewayを作成」ボタンをクリックします。

　なお、パラメーターとして、「デフォルトルートテーブルの関連付け」「デフォルトルートテーブル伝播」にチェックが入っている場合は、次の手順としてTransit Gatewayアタッチメントを作成し、各VPCにひも付けます。これによって、自動で本Transit Gatewayと関連付けられ、各VPCのセグメント情報がTransit Gatewayのデフォルトのルートテーブルに伝播（でんぱ）されるので、細かな設定なしで簡単にVPC間を接続できます。VPCごとに細かく接続や経路を制御したい場合は、これらのチェックをオフにして、「Transit Gatewayルートテーブル」を操作します。

　Transit Gatewayが作成されました。下図では状態が「Available」となっています。作成直後は「Pending」ですが数分で「Available」に切り替わります。

　また「Transit Gatewayルートテーブル」の項でTransit Gatewayルートテーブルが自動で作成されていること、画面下部の「関連付け」タブでまだVPCアタッチメントが関連付けされていないことを確認できます。

・2.各VPCと接続する、Transit Gateway アタッチメントを作成する

　「Transit Gateway接続」の項の画面右上の「Transit Gatewayアタッチメントを作成」ボタンをクリックします。

　表示される画面で、名前に「TGWAttachment01」、「Transit Gateway ID」として作成したTransit Gatewayを選択、アタッチメントタイプとして「VPC」、VPC IDとして「VPC01」、サブネットとして「Subnet01」を指定し、「Transit Gatewayアタッチメントを作成」ボタンをクリックします。

　アタッチメントタイプは、今回はVPCに接続するので「VPC」を選択していますが、それ以外に「VPN」やTGWピアリング用の「Peering Connection」などを選択できます。サブネットはアベイラビリティーゾーン単位で指定します。「Subnet01」の属するアベイラビリティーゾーンの都合で、図と異なるアベイラビリティーゾーンを指定する必要があるかもしれません。

　Transit Gateway VPCアタッチメントが正常に作成されました。

　「VPC02」を接続するためのTransit Gatewayアタッチメント「TGWAttachment02」も同様の手順で作成します（手順は割愛します）。

　Transit Gateway作成時のオプションで「デフォルトルートテーブルの関連付け」「デフォルトルートテーブル伝播」を有効にしていたので、Transit GatewayルートテーブルへのTransit Gatewayアタッチメントの関連付け、および関連付けたVPCが持つルートのTransit Gateway ルートテーブルへの伝播が自動化されていることを以降で確認します。

　まずはTransit Gatewayルートテーブルの「関連付け」タブで、2つのTransit GatewayアタッチメントがTransit Gatewayルートテーブルに関連付けられていることを確認できます。これによってTransit Gatewayと各VPCが通信できる状態になっています。

　次に「伝播」タブで2つのTransit GatewayアタッチメントからVPCのルートが伝播されている状態かどうかを確認します。

　その結果、「ルート」タブで各VPCのセグメントを学習していることを確認できます。ルートタイプが「伝達済み」なので「伝播」機能で学習されていることが分かります。

　なお、VPCアタッチメントを作成すると、VPCアタッチメントを作成する際に指定したサブネットに自動でIPアドレスが割り振られたAWS所有のElastic Network Interfaceが作成されます。

・3.各VPCでルートを設定する

　ここまでの設定によって、Transit Gatewayの設定が完了し、VPC間で通信できる状態になります。しかし各VPC自体は他のVPC宛てのルートを自動では伝達されないので通信できません。そこで通信したいVPC宛てのルートを各VPCのルートテーブルにターゲットをTransit Gatewayとして指定します（手順は割愛します。必要に応じてVPCピアリングの項の手順を参照ください）。

　ここまでの設定で、アクセスできることを確認できました。Tracerouteで1ホップ目の返答がありませんが、Transit Gatewayが間に入っているからです。VPCピアリングの場合は1ホップで到達しているので異なる接続方法だと分かります。

筆者紹介

東 竜一

ネットワンシステムズ株式会社 ビジネス開発本部 第2応用技術部

大阪大学 大学院 情報科学研究科 出身。2008年 ネットワンシステムズ入社。

学生の頃からネットワークに非常に興味を持ち同社に入社。そこから10年近くCisco Systemsのルーター／スイッチ製品担当として、製品検証、案件支援、技術問い合わせ対応などを精力的に実施。その後、同社のマルチクラウド閉域接続サービス「クラウドHUB」のメイン技術担当としてサービス開発／運用、案件対応を実施中。