複数のVPC間でプライベート通信をする接続方法と要点

EC2 から 異なる VPC 上の EC2 に対してプライベートな通信をしたい場面があります。例えばシステムの要件で「インターネットを経由した通信は禁止」と言われた際には、その要件に適応する構成を検討する必要があります。

その接続方法は複数あり、要件により選択される手段は変わります。今回は EC2 から 異なる VPC 上の EC2 に対してプライベート通信をする接続方法のうち、利用頻度の高い4つのパターンについてご紹介します。

取り扱うのは以下の4パターンです。

パターン	内容
1	インターネットゲートウェイ( IGW )経由でのプライベート通信
2	VPC ピアリング経由でのプライベート通信
3	PrivateLink 経由でのプライベート通信
4	Transit Gateway 経由でのプライベート通信

1章ではパターンごとの前提条件と構築手順を説明し、2章でその内容について比較します。

1. パターン毎の前提条件と構築手順

1章はパターン毎の前提条件と構築手順について説明します。2つの VPC間でプライベート通信をすると言っても、4つのパターンでは前提条件が異なります。それぞれの条件を記した上で、その構築手順について解説します。

1.1. パターン 1 ：インターネットゲートウェイ( IGW )経由でのプライベート通信

1つ目は、IGW を経由して接続するパターンです。
以下の状況を前提としています。

項	内容
1	2つの VPC でそれぞれ EC2 が起動している。
2	EC2 の Windows OS 環境上から、別のVPCに存在する EC2 にアクセスしたい。
3	接続はインターネットを経由しないプライベートな通信を実施したい。

EC2 から AWSサービスへの通信が IGW を経由していると「通信がインターネットを通っている」と思われがちですが、AWS 公式見解として、以下の記載があります。

区分	内容
質問	2 つのインスタンスがパブリック IP アドレスを使用して通信する場合、またはインスタンスがパブリックな AWS のサービスエンドポイントと通信する場合、トラフィックはインターネットを経由しますか?
回答	いいえ。パブリック IP アドレスを使用する場合、AWS でホストされているインスタンスとサービス間のすべての通信は AWS のプライベートネットワークを使用します。AWS ネットワークから発信され、AWS ネットワーク上の送信先を持つパケットは、AWS 中国リージョンとの間のトラフィックを除いて、AWS グローバルネットワークにとどまります。

AWS グローバルネットワークに通信が留まるのでインターネットは経由していません。今回の前提が「VPC間の接続はインターネットを経由しないプライベート通信を実施したい。」なので、その要件を満たしています。もちろん仕様上「インターネットにアクセスできない環境」である必要があれば、IGW をアタッチできないので、この構成は採用できません。

次に、このパターンにおける設定の手順とポイントをご紹介します。区分「設定」は設定手順、区分「動作確認」は設定後の動作確認手順です。

項	手順	区分
1.1.1.	VPC に IGW をアタッチ	設定
1.1.2.	サブネットのルートテーブルに IGW へのルートを追記	設定
1.1.3.	EC2 にパブリック IP を付与	設定
1.1.4.	EC2 起動後に OS 上から 別の VPC の EC2 に RDP 接続	動作確認

詳細な構築手順は以下をオープンしてご確認ください。

1.1.1. VPC に IGW をアタッチ

EC2 が 異なる VPC 上の EC2 と通信するためには、EC2 が存在するVPC に接続口を作成する必要があります。今回の場合の接続口は IGW となり、IGW を作成して VPC にアタッチします。

これで VPC から外部への接続口が作成されます。

1.1.2. サブネットのルートテーブルに IGW へのルートを追記

VPC に IGW を作成したとしても、サブネットからIGWに対するルートを記載しないと利用できません。EC2 が存在するサブネットのルートテーブルに IGW へのルートを追記します。

これにより、VPC の CIDR 範囲の通信以外は IGW にルーティングされます。

1.1.3. EC2 にパブリック IP を付与

IGW 経由で通信をするためには、EC2 自体にパブリック IP を割り当てる必要があります。EC2 を起動する際に「パブリック IP の自動割り当て」を有効化することで、起動時に EC2 の ENI にパブリック IP が割り当てられます。

これで、EC2 が IGW 経由で通信可能となります。

1.1.4. EC2 起動後に OS 上から 別の VPC の EC2 に RDP 接続

EC2 起動後に Windows OS 上でリモートディスクトップ接続を選択します。接続先の EC2 のパブリック IP と 管理者ユーザ名「 Administrator 」を入力して「 Connect 」を選択します。

パスワード画面で、接続先 EC2 のパスワードを入力して「 OK 」を選択します。

「 YES 」を選択します。

接続先　EC2 への RDP 接続が問題なく実施できます。

1.2. パターン 2 ：VPC ピアリング経由でのプライベート通信

2つ目は、VPC ピアリングで接続するパターンです。
以下の状況を前提としています。

項	内容
1	2つの VPC でそれぞれ EC2 が起動している。
2	EC2 の Windows OS 環境上から、別のVPCに存在するEC2にアクセスしたい。
3	接続はインターネットを経由しないプライベートな通信を実施したい。
4	VPC に IGW をアタッチしてはいけない。

インターネット側からの接続口となる IGW を VPC にアタッチしてはいけない場面は多々あります。今回は項目4が追加されています。このパターンでは VPCピアリング接続を利用します。

VPC ピアリングは IGW がアタッチせずに VPC 間の通信を可能にします。
次に、このパターンにおける設定の手順とポイントをご紹介します。区分「設定」は設定手順、区分「動作確認」は設定後の動作確認手順です。

項	手順	区分
1.2.1.	VPC ピアリング接続を作成	設定
1.2.2.	サブネットのルートテーブルに VPC ピアリング へのルートを追記	設定
1.2.3.	EC2 起動後に OS 上から 別の VPC の EC2 に RDP 接続	動作確認
1.2.4.	参考：アクセスルートの確認	動作確認

1.2.1. VPC ピアリング接続を作成

VPC ピアリング接続を作成する必要があります。
VPC サービスのピアリング接続画面から「ピアリング接続を作成」を選択します。

接続元の VPC と 接続先の VPC の両方を指定して、作成します。

接続先の VPC のあるリージョンの ピアリング接続画面に「承認の保留中」と表示されるので、「リクエストを承諾」を選択します。

「リクエストを承諾」を選択します。

ステータスが「アクティブ」になれば、作成完了です。

1.2.2. サブネットのルートテーブルに VPC ピアリング へのルートを追記

VPC に VPC ピアリング接続が作成されたとしても、その接続口に対するルートを記載しないと利用できません。EC2 が存在するサブネットのルートテーブルに お互いの VPC への経路を追記します。

1.2.3. EC2 起動後に OS 上から 別の VPC の EC2 に RDP 接続

EC2 起動後に Windows OS 上でリモートディスクトップ接続を選択します。接続先の EC2 のプライベート IP と 管理者ユーザ名「 Administrator 」を入力して「 Connect 」を選択します。

パスワード画面で、接続先 EC2 のパスワードを入力して「OK」を選択します。

「 YES 」を選択します。

接続先 EC2 への RDP 接続が問題なく実施できます。

1.2.4. 参考：アクセスルートの確認

実際に想定通りの経路で通信できているのか確認するためのサービスとして VPC の機能の１つ「Network Manager」があります。その中の「Reachability Analyzer」を利用すると、送信元と送信先の間の通信経路を可視化できます。万一、設定に問題があって疎通できない場合は、その問題解決に寄与します。

今回の構成の場合は、以下の通り送信元を接続元の EC2、送信先を 送信先の EC2 に設定して確認します。

問題なく疎通できていることが確認できます。

上記だと Reachability Analyzer の効果があまり感じにくいと思いますので、あえてエラーを起こしてみます。今回の構成でルートテーブルから IGW へのルートを削除した場合の結果が以下の通りです。

きっちりと、ルートテーブルに問題があることを突き止めてくれます。非常に有用な機能なのでご活用ください。

送信元・送信先リソース

Reachability Analyzer ですが、送信元・送信先で指定できるリソースの条件として「送信元リソースと送信先リソースは、同じ VPC 内または VPC ピアリング接続またはトランジットゲートウェイを介して接続されている VPC 内にある必要があります。」があります。パターン2～4では EC2 間の通信経路を確認できますが、パターン1のように IGWを介する必要がある場合にはIGWまでの通信経路までしか確認できません。そのため、この記事ではパターン2以降で Reachability Analyzer を利用しています。

1.3. パターン 3 ：PrivateLink 経由でのプライベート通信

3つ目は、PrivateLink で接続するパターンです。
以下の状況を前提としています。

項	内容
1	2つの VPC でそれぞれ EC2 が起動している。
2	EC2 の Windows OS 環境上から、別のVPCに存在する EC2 にアクセスしたい。
3	接続はインターネットを経由しないプライベートな通信を実施したい。
4	VPC に IGW をアタッチしてはいけない。
5	接続したい2つのVPC の CIDR範囲、EC2 のIPアドレスが重複している

項目5が追加となっていますが、パターン2で紹介した VPCピアリングは重複したCIDR範囲の VPC を接続できません。その為、この場合に利用できるのが、PrivateLink を利用した接続方法です。

AWS PrivateLink はインタフェース型VPCエンドポイントとエンドポイントサービスから構成されており、接続元の VPC にインタフェース型VPC エンドポイントを、接続先の VPC にエンドポイントサービスを設定することで利用可能となります。また、この構成の場合、接続先の VPC に NLB を作成する必要があります。

AWS PrivateLink

AWS PrivateLink は、仮想プライベートクラウド ( VPC ) とサポートされている AWS のサービス、他の AWS アカウント によってホストされているサービス、およびサポートされている AWS Marketplace のサービス間のプライベート接続を確立します。サービスと通信するのに、インターネットゲートウェイ、NAT デバイス、AWS Direct Connect 接続、および AWS Site-to-Site VPN 接続は不要です。AWS PrivateLink を使用するには、サービスの名前とサブネットを指定して、VPC で インタフェース型VPC エンドポイントを作成します。これによって Elastic Network Interface がサブネットに作成され、これがサービスへのトラフィックのエントリポイントとなります。

次に、このパターンにおける設定の手順とポイントをご紹介します。区分「設定」は設定手順、区分「動作確認」は設定後の動作確認手順です。また、この接続方法は、送信先と送信元で設定する内容が異なるため、以下の通り「送信元」「送信先」列で、どちらで設定する内容かを記載しています。

項	手順	送信元	送信先	区分
1.3.1.	NLB にアタッチするセキュリティグループ作成		〇	設定
1.3.2.	NLB 用のターゲットグループの作成		〇	設定
1.3.3.	NLB の作成		〇	設定
1.3.4.	エンドポイントサービスの作成		〇	設定
1.3.5.	インタフェース型 VPC エンドポイントにアタッチするセキュリティグループ作成	〇		設定
1.3.6.	インタフェース型 VPC エンドポイントの作成	〇		設定
1.3.7.	EC2 起動後に OS 上から 別の VPC の EC2 に RDP 接続	〇		動作確認
1.3.8.	参考：アクセスルートの確認			動作確認

1.3.1. NLB 用のターゲットグループの作成

NLB 用のターゲットグループを作成する必要があります。
EC2 サービスのターゲットグループ画面で「ターゲットグループの作成」を選択します。

ターゲットタイプの選択では「インスタンス」を選択します。

今回は RDP接続を実施するため、プロトコルは「 TCP 」、ポートは「3389」とします。

ヘルスチェックも「TCP」にします。

ターゲットとして接続先の EC2 を選択します。

「ターゲットグループの作成」を選択すると、ターゲットグループが作成されます。

1.3.2. NLB にアタッチするセキュリティグループ作成

NLB 用のセキュリティグループを作成する必要があります。
今回はRDP接続を実施するため、インバウンドルールで「3389」ポートを許可します。

1.3.3. NLB の作成

NLB を作成する必要があります。
EC2 サービスのロードバランサー画面で「ロードバランサーの作成」を選択します。

NLB の「作成」を選択します。

プライベート IP で利用するので「内部」を選択します。

送信先 VPC のサブネットを選択します。

先ほど作成した NLB 用のセキュリティグループを選択します。

今回はRDP接続を実施するため、リスナーのプロトコル「 TCP 」、ポート「3389」を設定します。

「ロードバランサーの作成」を選択すると、ロードバランサーが作成されます。

ロードバランサーの作成後、ターゲットグループでターゲットの EC2 のヘルスステータスが「 Healthy 」になることを確認します。

1.3.4. エンドポイントサービスの作成

エンドポイントサービスを作成する必要があります。
VPCサービスのエンドポイントサービス画面で「エンドポイントサービスを作成」を選択します。

先ほど作成した NLB を選択します。

「作成」を選択します。

エンドポイントサービスが作成されます。

なお、エンドポイントサービス名は、インタフェース型 VPC エンドポイントを作成する際に必要な情報となります。

1.3.5. インタフェース型 VPC エンドポイントにアタッチするセキュリティグループ作成

インタフェース型 VPC エンドポイント用のセキュリティグループを作成する必要があります。今回はRDP接続を実施するため、インバウンドルールで「3389」ポートを許可します。

また、セキュリティ的な対策として、ソースには EC2 の ENI にアタッチされているセキュリティグループを設定します。こうすることで、対象のセキュリティグループが設定されている EC2 からの通信のみを許可して受信することができるようになります

1.3.6. インタフェース型 VPC エンドポイントの作成

インタフェース型 VPC エンドポイントを作成する必要があります。

「その他のエンドポイントサービス」を選択します。

先ほど作成したエンドポイントサービスの名前を入力して「サービスの検証」を選択します。「サービスが検証されました。」というメッセージが表示されます。

エンドポイントを作成する VPC とサブネットを選択します。

設定するリージョン・サブネットの制限

設定できるサブネットはエンドポイントサービス側で設定されているAZに存在するものだけなので、ご注意ください。もう少し具体的に言うと、エンドポイントサービスに設定されているNLBのAZ設定が前提となります。同一AZでないと設定できない仕様です。

また、エンドポイントサービスの仕様上、リージョンもエンドポイントサービスと同一である必要があります。このように、同一リージョン、同一AZが前提となるのが特徴です。

また、先ほどエンドポイント用に作成したセキュリティグループをアタッチします。そのうえで、「エンドポイントを作成」を選択します。

エンドポイントが作成されますが、ステータスが「承認の保留中」となります。

接続先のエンドポイントサービス側で、対象のエンドポイントが表示されます。

対象のエンドポイントを選択して、「エンドポイント接続リクエストの承諾」を選択する。

「承諾」を選択する。

エンドポイントの状態が「使用可能」になります。

エンドポイントの DNS 名を控えます。接続先の EC2 にアクセスする際には、プライベート IP を利用するのではなく、このエンドポイントの DNS 名を利用します。

1.3.7. EC2 起動後に OS 上から 別の VPC の EC2 に RDP 接続

EC2 起動後に Windows OS 上でリモートディスクトップ接続を選択します。
エンドポイントの DNS 名「com.amazonaws.vpce.ap-northeast-2.vpce-svc-0da78289b45087879」と管理者ユーザ名「 Administrator 」を入力して「 Connect 」を選択します。

パスワード画面で、接続先 EC2 のパスワードを入力して「 OK 」を選択します。

「 YES 」を選択します。

接続先 EC2 への RDP 接続が問題なく実施できます。

2つの EC2 環境の プライベート IP アドレスが重複していても、問題なく接続ができます。

1.3.8. 参考：アクセスルートの確認

「 Network Manager 」の「 Reachability Analyzer 」を利用して、疎通経路と問題がないかのチェックを実施します。今回の構成の場合は、以下の通り送信元を 接続元 EC2、送信先を 送信先 EC2 に設定して確認します。

問題なく疎通できていることが確認できます。

1.4. パターン 4 ：Transit Gateway 経由でのプライベート通信

4つ目は、Transit Gateway 経由で接続するパターンです。
以下の状況を前提としています。

項	内容
1	2つの VPC でそれぞれ EC2 が起動している。
2	EC2 の Windows OS 環境上から、別のVPCに存在する EC2 にアクセスしたい。
3	接続はインターネットを経由しないプライベートな通信を実施したい。
4	VPC に IGW をアタッチしてはいけない。
5	3つ以上の VPC間で通信する必要がある。

パターン2で紹介した VPC ピアリングは VPC 間で1対1の設定しかできませんが、3つ以上の VPC間でのアクセスが必要な場合もあります。上記の項目5の条件がそれにあたります。
このパターンでは Transit Gateway 接続を利用します。

Transit Gateway は最大で5,000個のVPC間での相互通信が可能なサービスです。

次に、このパターンにおける設定の手順とポイントをご紹介します。区分「設定」は設定手順、区分「動作確認」は設定後の動作確認手順です。

項	手順	区分
1.4.1.	Transit Gateway の作成	設定
1.4.2.	Transit Gateway ルートテーブルの作成	設定
1.4.3.	Transit Gateway アタッチメントの作成	設定
1.4.4.	Transit Gateway ルートテーブルに対するアタッチメントの関連付け	設定
1.4.5.	Transit Gateway ルートテーブルに対する伝播の作成	設定
1.4.6.	サブネットのルートテーブルにTransit Gateway へのルート追加	設定
1.4.7.	EC2 起動後に OS 上から 別の VPC の EC2 に RDP 接続	動作確認
1.4.8.	参考：アクセスルートの確認	動作確認
1.4.9.	参考：別リージョンとのアクセス	動作確認
1.4.10.	参考：別アカウントとのアクセス	動作確認

1.4.1. Transit Gateway の作成

Transit Gateway を作成する必要があります。
VPC サービスの Transit Gateway 画面から「Transit Gateway を作成」を選択します。

「デフォルトルートテーブルの関連付け」と「デフォルトルートテーブル伝播」のチェックを外します。

「Transit Gateway を作成」を選択して、作成します。

1～2分くらい経過して状態が「 Available 」になれば作成完了です。

1.4.2. Transit Gateway ルートテーブルの作成

Transit Gateway ルートテーブルを作成する必要があります。
VPC サービスの Transit Gateway ルートテーブル画面から「Transit Gateway ルートテーブルを作成」を選択します。

先ほど作成した Transit Gateway を選択して、「Transit Gateway ルートテーブルを作成」を選択します。

1～2分くらい経過して状態が「 Available 」になれば作成完了です。

1.4.3. Transit Gateway アタッチメントの作成

Transit Gateway アタッチメントを作成する必要があります。
VPC サービスの Transit Gateway アタッチメント画面から「Transit Gateway アタッチメントを作成」を選択します。

先ほど作成した Transit Gateway を選択します。
また、VPC を対象とするため、アタッチメントタイプを「 VPC 」とします。

対象の VPC と サブネット を選択して、「Transit Gateway アタッチメントを作成」を選択します。

1～2分くらい経過して状態が「 Available 」になれば作成完了です。

この作業は接続する VPC の数分実施する必要があります。
3つの VPC を接続する場合には、3回実施する必要があります。

1.4.4. Transit Gateway ルートテーブルに対するアタッチメントの関連付け

Transit Gateway ルートテーブルに対してアタッチメントを関連付けする必要があります。
VPC サービスの Transit Gateway ルートテーブル画面から作成したルートテーブルを選択し、関連付け画面で「関連付けを作成」を選択します。

先ほど作成したアタッチメントを選択して、「関連付けを作成」を選択します。

1～2分くらい経過して状態が「 Associated 」になれば作成完了です。

この作業は接続する アタッチメント の数分実施する必要があります。
3つの VPC を接続する場合には、3回実施する必要があります。

1.4.5. Transit Gateway ルートテーブルに対する伝播の作成

Transit Gateway ルートテーブルに対して伝播を作成する必要があります。
VPC サービスのTransit Gateway ルートテーブル画面から作成したルートテーブルを選択し、伝播画面で「伝播を作成」を選択します。

伝播するアタッチメントを選択して、「伝播を作成」を選択します。

1～2分くらい経過して状態が「 Enabled 」になれば作成完了です。

この作業は接続する アタッチメント の数分実施する必要があります。
3つのVPCを接続する場合には、3回実施する必要があります。

この結果、Transit Gateway ルートテーブルのルート画面で確認すると、以下のようにルートタイプが「伝播済み」と表示されます。

1.4.6. サブネットのルートテーブルにTransit Gateway へのルート追加

EC2 の存在するサブネットのルートテーブルに Transit Gateway へのルートを追加する必要があります。VPC サービスのルートテーブル画面から作成したルートテーブルを選択し、ルート画面で「ルートを編集」を選択します。

Transit Gateway で接続先として追加した VPC の CIDR を追加して、ターゲットとして作成した Transit Gateway を選択して、「変更を保存」を選択します。

Transit Gateway に対するルートが追加されます。

この作業は接続する VPC の数分実施する必要があります。
3つの VPC を接続する場合には、3回実施する必要があります。

1.4.7. EC2 起動後に OS 上から 別の VPC の EC2 に RDP 接続

EC2 起動後に Windows OS 上でリモートディスクトップ接続を選択します。接続先の EC2 のプライベート IP と 管理者ユーザ名「Administrator」を入力して「Connect」を選択します。

パスワード画面で、接続先 EC2 のパスワードを入力して「OK」を選択します。

「 YES 」を選択します。

接続先　EC2 への RDP 接続が問題なく実施できます。

さらに、複数の VPC に存在する EC2 へのアクセスも実施できます。

1.4.8. 参考：アクセスルートの確認

「 Network Manager 」の「 Reachability Analyzer 」を利用して、疎通経路と問題がないかのチェックを実施します。今回の構成の場合は、以下の通り送信元を 接続元の EC2、送信先を 送信先のEC2 に設定して確認します。

TransitGateway 経由で問題なく疎通できていることが確認できます。

2.　パターン毎の特徴の比較

1章では複数の VPC間 でプライベートな通信をする4つの接続方法をご紹介しました。2章では、信頼性・セキュリティ・コスト・機能面に関してパターン毎に比較して説明することで、それぞれの特徴を掴んで頂きたいと思います。

2.1. 信頼性に関する比較

信頼性に関する比較です。信頼性は「意図した機能を期待どおりに正しく一貫して実行するワークロードの能力」を指します。

2.1.1. パターン1：インターネットゲートウェイ経由

IGW は冗長性と可用性を備えており、単一障害点になりません。
VPC にアタッチしており、AZ障害にも耐えることができます。

機能	内容
インターネットゲートウェイ	インターネットゲートウェイは、VPC とインターネットとの間の通信を可能にする VPC コンポーネントであり、冗長性と高い可用性を備えており、水平スケーリングが可能です。IPv4 トラフィックおよび IPv6 トラフィックをサポートしています。ネットワークトラフィックに可用性のリスクや帯域幅の制約が発生することはありません。

2.1.2. パターン2：VPCピアリング経由

VPC ピアリングは冗長性と可用性を備えており、単一障害点になりません。
VPC にアタッチしており、AZ障害にも耐えることができます。

機能	内容
VPC ピアリング	AWS では VPC の既存のインフラストラクチャを使用して VPC ピアリング接続を作成しています。これはゲートウェイでも VPN 接続でもなく、個別の物理ハードウェアに依存するものではありません。通信の単一障害点や帯域幅のボトルネックは存在しません。

2.1.3. パターン3：PrivateLink 経由

PrivateLink のうち、VPC エンドポイントはサブネット内に作成されます。
そのサブネットの AZ で障害が発生すると利用できなくなるため、可用性を確保するためには複数のAZのサブネットでVPCエンドポイントを作成する必要があります。VPCエンドポイントが増えればその分コストが増大するので、可用性とコストがトレードオフの関係にあります。また、NLB 側も同様に複数 AZ を設定することで可用性を確保できます。

また、他の3つのパターンが双方向での通信が可能なのに対して、この構成は一方向の通信が前提となっています。双方向にするには、逆のルートも作成する必必要があり、以下のような構成となります。

双方向で可用性を維持する設計を実施する必要があります。

2.1.4. パターン4：Transit Gateway 経由

アタッチメントを作成した際に VPC 内のサブネットに ENI が作成されます。そのサブネットの AZ で障害が発生すると利用できなくなるため、可用性を確保するためには複数の AZ のサブネットで ENI を作成する必要があります。

機能	内容
Transit Gateway	Transit Gateway は、仮想プライベートクラウド ( VPC ) とオンプレミスネットワークの間を流れるトラフィック用のリージョン仮想ルーターとして機能します。Transit Gateway は、ネットワークトラフィックの量に基づいて伸縮自在にスケーリングされます。

2.1.5. 信頼性に関する比較まとめ

上記の各パターンをまとめた内容は以下となります。
パターン3やパターン4のように、VPCのサブネット内にリソースが作成されるサービスについては、複数AZ で設定する対策が必要です。

区分	内容	パターン1： インターネットゲートウェイ経由	パターン2： VPCピアリング経由	パターン3： PrivateLink 経由	パターン4： Transit Gateway経由
信頼性	AZ障害影響	無	無	有	有

2.2. セキュリティに関する比較

セキュリティに関する比較です。セキュリティは「データ、システム、資産を保護して、クラウドテクノロジーを活用してセキュリティを強化する能力」を指します。

2.2.1. パターン1：インターネットゲートウェイ経由

IGW を VPC にアタッチすることにより、インターネット側から攻撃されるリスクが発生します。VPC に IGW をアタッチした場合、インターネット側からの脅威に対応する必要があります。AWS には脅威に対応するためのサービスが幾つかありますが、コスト面や設計工数の増大に繋がります。今回の場合、対象の EC2 にインターネットアクセスが必須な要件な場合はこの構成となりますが、その要件が無い場合は敢えて IGW を利用する構成でアクセスさせる必要はありません。

2.2.2. パターン2：VPCピアリング経由

IGW を利用することなく2つの異なる VPC 間の通信が可能です。
インターネット側から攻撃されるリスクがありません。

また、VPCピアリングには推移的なピアリングがサポートされていません。

これは一見不便に思えるかもしれませんが、VPCピアリングでの接続先VPC 跨ぎで侵入されるリスクを軽減できるので、セキュリティ的にはプラスの面があります。

2.2.3. パターン3：PrivateLink 経由

IGW を利用することなく2つの異なる VPC 間の通信が可能です。
インターネット側から攻撃されるリスクがありません。

VPC エンドポイント経由でアクセスする場合にはセキュリティに関する複数の定義が可能です。VPC エンドポイントのセキュリティグループと VPC エンドポイントポリシーを利用して、アクセス許可対象や通信内容を定義することができます。また、NLB のセキュリティグループでもトラフィック制御が可能です。多段防御により許可のないアクセスを抑止できます。

2.2.4. パターン4：Transit Gateway 経由

IGW を利用することなく2つの異なる VPC 間の通信が可能です。
インターネット側から攻撃されるリスクがありません。

Transit Gateway は Transit Gateway route table により各アタッチメントの通信ルートを制御できます。それによりアクセスさせたい VPC 間のみ通信させる設定が可能です。

2.2.5. セキュリティに関する比較まとめ

上記の各パターンをまとめた内容は以下となります。

区分	内容	パターン1： インターネットゲートウェイ経由	パターン2： VPCピアリング経由	パターン3： VPCエンドポイント経由	パターン4： Transit Gateway経由
セキュリティ	インターネット側からの影響有無	有	無	無	無

2.3. コストの比較

コストに関する比較です。コストは「最低価格でビジネス価値を実現するシステムを実行できる能力」が求められます。

比較するにあたり、条件を明確にする必要があるため、以下の条件を４つのパターンの共通条件とします。リージョンや AZ が異なる場合、個別にコストが発生する構成もあり、今回は説明の対象外としています。また、料金体系や条件は2024年6月時点の東京リージョンを前提としていますが、変更されることも多いため、最新の情報は公式サイトでご確認ください。

項	対象	内容
1	対象リージョン	接続元EC2 と接続先EC2 の VPC は同一リージョンに存在する
2	AZ	接続元EC2 と接続先EC2 のサブネットは同一AZに存在する
3	接続前提	接続元EC2 から接続先EC2 にアクセスする構成とする(逆の接続は対象外）
4	対象外	EC2 自体の利用料等は対象外とする
5	料金	金額は2024年6月時点の東京リージョンを前提とする

2.3.1. パターン1：インターネットゲートウェイ経由

IGW 経由で通信をする場合、EC2 にパブリックIPが付与されている必要があり、この利用料が継続的に発生します。2台の EC2 で通信させるにはそれぞれの EC2 にパブリック IP が付与されている必要があり、2つ分のパブリックIP利用料が必要です。

区分	内容	USD/時間	USD/月額	必要数	USD/月額(総額)
パブリック IP の料金	EC2が起動している間、課金される	0.005	3.6	2	7.2

データ転送に関しては、今回は同一リージョン、同一 AZ を前提としているので、データ転送料は発生しません。同じアAZ内の Amazon EC2、Amazon RDS、Amazon Redshift、Amazon ElastiCache インスタンス、および Elastic Network Interfaces 間のデータ転送は無料です。

区分	内容	USD/GB
データ転送( IN )	同一リージョン・同一 AZ に存在する EC2 間でのデータ転送	0
データ転送( OUT )	同一リージョン・同一 AZ に存在する EC2 間でのデータ転送	0

2.3.2. パターン2：VPC ピアリング経由

VPC ピアリング経由で通信をする場合、VPC ピアリング自体の利用料は無料です。

区分	内容	USD/時間	USD/月額	必要数	USD/月額(総額)
VPC ピアリングの料金	VPC ピアリング設定中に発生する料金	0	0	1	0

データ転送に関しては、今回は同一リージョン、同一 AZ を前提としているので、データ転送料は発生しません。同じAZ内の Amazon EC2、Amazon RDS、Amazon Redshift、Amazon ElastiCache インスタンス、および Elastic Network Interfaces 間のデータ転送は無料です。

区分	内容	USD/GB
データ転送( IN )	同一リージョン・同一 AZ に存在する EC2 間でのデータ転送	0
データ転送( OUT )	同一リージョン・同一 AZ に存在する EC2 間でのデータ転送	0

VPC 間の接続を実施する際は、最も安価な方法と言えます。

2.3.3. パターン3：PrivateLink 経由

PrivateLink 経由で通信をする場合、接続元EC2 の存在するサブネットに VPC エンドポイントを作成する必要があります。また、接続先EC2 の存在するサブネットにNLBを作成する必要があります。この2つの利用料が継続的に発生します。

区分	内容	USD/時間	USD/月額	必要数	USD/月額(総額)
インターフェイスエンドポイントの料金	エンドポイント存在中に発生する費用	0.014	10.08	1	10.08
ELB （NLB） の料金	NLBの利用料	0.0243	17.496	1	17.496
合計		0.0383	27.576		27.576

このパターンの場合、エンドポイントサービスを利用するためには、同一リージョン・同一 AZ である必要があるので、必然的にその前提となります。エンドポイントを経由したデータ処理には以下のデータ処理料が発生するので、データ量に比例して料金が加算されます。

区分	内容	USD/GB
データ処理料	AWS リージョン内のすべてのインターフェイスエンドポイントが処理するデータの合計に適用（最初の 1 PBに適用される料金帯）	0.01
NLCU の料金	3つのディメンションのうち処理バイト数のよる NLCU が最も多かった場合を想定	0.006

また、他の3つのパターンが双方向での通信が可能なのに対して、この構成は一方向の通信が前提となっています。双方向にするには、逆のルートも作成する必要があり、金額的には2倍の必要が必要です。

双方向通信が必要な場合の費用は以下のようになります。

区分	内容	USD/時間	USD/月額	必要数	USD/月額(総額)
インターフェイスエンドポイントの料金	エンドポイント存在中に発生する費用	0.014	10.08	2	20.16
ELB （NLB） の料金	NLBの利用料	0.0243	17.496	2	34.992
合計		0.0383	27.576		55.152

複数のサービスを組み合わせる必要があることから、金額的には高めの構成となります。

2.3.4. パターン4：Transit Gateway 経由

Transit Gateway 経由で通信をする場合、Transit Gateway において接続するVPCのアタッチメントを作成する必要があり、この利用料が発生します。2つの VPC が対象の場合は、2個分のアタッチメント料金が発生します。

区分	内容	USD/時間	USD/月額	必要数	USD/月額(総額)
AWS Transit Gateway のアタッチメントごとの料金	エンドポイント存在中に発生する費用	0.07	50.4	2	100.8

Transit Gateway を経由したデータ処理には以下のデータ処理料が発生するので、データ量に比例して料金が加算されます。

区分	内容	USD/GB
データ処理料	処理データ 1 GB あたりの料金 (USD)	0.02

2.3.5. コスト面に関する比較まとめ

上記の各パターンをまとめた内容は以下となります。

ただしコスト面のみで判断できるものではなく、要件と合わせて判断する必要があります。

区分	内容	パターン1： インターネットゲートウェイ経由	パターン2： VPC ピアリング経由	パターン3： PrivateLink 経由	パターン4： Transit Gateway 経由
コスト	発生する固定費（USD/月） ※同一リージョン・同一AZ間での通信が前提	7.2 ※双方向	0 ※双方向	27.576 ※片方向	100.8 ※双方向
コスト	発生する変動費 ※同一リージョン・同一AZ間での通信が前提	無	無	有	有

2.4. 機能面に関する比較

機能面の比較は、以下の区分に関する比較となります。
今回のタイトルにある前提上、項1はすべて〇になります。

項	対象	内容
1	プライベート通信	プライベート通信が可能か
2	プライベート空間	プライベート空間内での設定が可能か
3	3つ以上の VPC 対応	3つ以上の VPC 対応は可能か
4	プライベート IP の CIDR 範囲重複	接続する VPC の CIDR 範囲が重複している場合に対応可能か
5	双方向通信	双方向での通信が可能か
6	アカウント間対応	アカウントが異なる EC2 間での通信が可能か
7	リージョン間対応	リージョンが異なる EC2 間での通信が可能か

2.4.1. パターン1：インターネットゲートウェイ経由

項	対象	内容
1	プライベート通信	〇
2	プライベート空間	×
3	3つ以上の VPC 対応	〇
4	プライベート IP の CIDR 範囲重複	〇
5	双方向通信	〇
6	アカウント間対応	〇
7	リージョン間対応	〇

この構成の場合は、IGW がアタッチされており VPC 内がプライベート空間ではなくなることがポイントです。EC2にインターネット経由の通信が必要な場合に利用される構成となります。

本構成の特徴として、項4にある通りEC2 自体のプライベートIPアドレスが重複している場合も通信が可能なことです。理由としては IGW 経由の通信にはパブリックIPアドレス経由で通信されるためです。

RDP接続を実施すると、以下のようにアクセスできます。

2.4.2. パターン2：VPC ピアリング経由

項	対象	内容
1	プライベート通信	〇
2	プライベート空間	〇
3	3つ以上の VPC 対応	△
4	プライベート IP の CIDR 範囲重複	×
5	双方向通信	〇
6	アカウント間対応	〇
7	リージョン間対応	〇

この構成の場合は、完全なプライベート空間で通信が実施できます。ただし、CIDR 範囲が重複しない VPC 間でしか設定できないという制限が特徴です。また、複数VPCにも対応ができますが、こちらは△としています。設定として3つ以上の複数VPCで多対多メッシュ型の構成も可能ですが、AWS の推奨するベストプラクティスとしては「3 つ以上のネットワークアドレス空間が VPC ピア接続、AWS Direct Connect、または VPN 経由で接続されている場合は、AWS Transit Gateway が提供するようなハブアンドスポークモデルを使用します。」とされており、AWS Transit Gateway の利用が推奨されます。

区分	内容
フレームワークの柱	セキュリティの柱
ID	REL02-BP04 多対多メッシュよりもハブアンドスポークトポロジを優先する
内容	3 つ以上のネットワークアドレス空間 (VPC およびオンプレミスネットワークなど) が VPC ピア接続、AWS Direct Connect、または VPN 経由で接続されている場合は、AWS Transit Gateway が提供するようなハブアンドスポークモデルを使用します。そのようなネットワークが 2 つしかない場合は、それらを互いに接続するだけで済みますが、ネットワークの数が増えるにつれて、そのようなメッシュ接続の複雑さは維持できないものになります。

その他の VPC ピアリングの制限事項については「 VPC ピアリングの制限事項」を参照ください。

2.4.3. パターン3：PrivateLink 経由

項	対象	内容
1	プライベート通信	〇
2	プライベート空間	〇
3	3つ以上の VPC 対応	△
4	プライベート IP の CIDR 範囲重複	〇
5	双方向通信	△
6	アカウント間対応	〇
7	リージョン間対応	×

この構成の場合は、項2と項4を同時に満たせるのが大きな特徴です。プライベート空間で接続したい VPC のCIDR重複がある場合に利用されることが多いです。エンドポイント型ということで複数の VPC からエンドポイント経由のアクセスが可能となります。ただし双方向通信のためにはお互いの環境にエンドポイントと NLB を作成する必要があり、コスト面の課題があります。その為、項3と項5は△としています。項6のアカウント間対応は、エンドポイントサービスでプリンシパルの許可設定を実施することで可能です。また、エンドポイントはリージョンに依存する為、項7のリージョン間での設定を実施することができません。

2.4.4. パターン4：Transit Gateway 経由

項	対象	内容
1	プライベート通信	〇
2	プライベート空間	〇
3	3つ以上の VPC 対応	〇
4	プライベート IP の CIDR 範囲重複	×
5	双方向通信	〇
6	アカウント間対応	〇
7	リージョン間対応	〇

この構成の場合は、項4の CIDR 範囲重複以外に関しては、すべての条件を満たせていることが特徴です。項3の複数VPC対応では、AWSのベストプラクティスとして Transit Gateway を利用することが推奨されています。それ以外のベストプラクティスも含めて、「Transit Gateway の設計のベストプラクティス」をご確認ください。例えば本来はTransit Gateway VPC アタッチメントには個別のサブネットを使用することが推奨されています。今回はパターン比較のためシンプルな構成としましたが、本番ワークロードを構築する際にはベストプラクティスに沿った設計を実施ください。

また、今回詳細に説明していませんが、Transit Gateway の大きな特徴として、アタッチメントとして VPC だけではなく DirectConnect や VPN を設定することができます。これによりオンプレ環境とのアクセスも一元的に制御することが可能なため、オンプレとクラウドのハイブリッド環境を利用している場合は選択肢にあがることが多くなります。

2.4.5. 機能面に関する比較まとめ

上記の各パターンをまとめた内容は以下となります。〇△×についての根拠については、それぞれのパターンの説明内容をご確認ください。

区分	内容	パターン1： インターネットゲートウェイ経由	パターン2： VPC ピアリング経由	パターン3： PrivateLink 経由	パターン4： Transit Gateway 経由
機能面	プライベート通信	〇	〇	〇	〇
機能面	プライベート空間	×	〇	〇	〇
機能面	3つ以上の VPC 対応	〇	△	△	〇
機能面	プライベート IP の CIDR 範囲重複	〇	×	〇	×
機能面	双方向通信	〇	〇	△	〇
機能面	アカウント間対応	〇	〇	〇	〇
機能面	リージョン間対応	〇	〇	×	〇

2.5. 比較のまとめ

信頼性、セキュリティ、コスト、機能面でそれぞれ比較してきましたが、最後に纏めて掲載します。〇△×についての根拠については、それぞれのパターンの説明内容をご確認ください。特段比較する際にポイントになる部分を赤文字にしています。

区分	内容	パターン1： インターネットゲートウェイ経由	パターン2： VPC ピアリング経由	パターン3： PrivateLink 経由	パターン4： Transit Gateway 経由
信頼性	AZ障害影響	無	無	有	有
セキュリティ	インターネット側からの影響有無	有	無	無	無
コスト	発生する固定費（USD/月） ※同一リージョン・同一AZ間での通信が前提	7.2 ※双方向	0 ※双方向	27.576 ※片方向	100.8 ※双方向
コスト	発生する変動費 ※同一リージョン・同一AZ間での通信が前提	無	無	有	有
機能面	プライベート通信	〇	〇	〇	〇
機能面	プライベート空間	×	〇	〇	〇
機能面	3つ以上の VPC 対応	〇	△	△	〇
機能面	プライベートIP の CIDR 範囲重複	〇	×	〇	×
機能面	双方向通信	〇	〇	△	〇
機能面	アカウント間対応	〇	〇	〇	〇
機能面	リージョン間対応	〇	〇	×	〇

3．まとめ

複数の VPC間 でプライベート通信をする方法と比較内容について記載しました。今回説明した接続方法は利用頻度が高い内容ですが、AWS には多くのサービスがあるため、これ以外の方法で VPC 間のプライベート通信を実現することも可能です。どのサービスを利用するかは、求められる要件を満たすことはもちろんですが、コスト面、信頼性面、セキュリティ面といった各項目でも、その違いを認識した上で、構成を作成する必要があります。違いを認識した上で、設計構築にお役立てください。

今回の記事がご参考になれば幸いです。