はじめに

AWSには各ネットワークを繋ぐためのサービスが色々とあります。

必要に応じて毎回調べながら導入するようなことをよくやっていますが、改めてきちんと整理してAWSのネットワーク間接続をまとめてみようと思い、今回から何回かに分けてAWSのネットワーク間接続を色々と試しつつ学んでいこうと思います。

また、仕事でTransit Gatewayを使うことも増えたことと、資格勉強も兼ねて特にTransit Gatewayに関しては深く調べてみたいと思います。

【次】色々なネットワーク間接続を試しつつTransit Gatewayを理解する。（その２：Site-to-Site VPN）

AWSのネットワーク間接続について

TCP/IPの世界において、端末間で通信を行うためには同一ネットワークである必要があり、同一ネットワーク以外の端末などと通信を行うためにはルータなどのゲートウェイ機器が必要となります。

AWSではVPC内通信であれば、デフォルトで作られるルートテーブルに従って双方向に通信できますが、VPCを超えた通信については、色々なゲートウェイサービスを利用する必要があります。

サービス	説明	備考
Internet Gateway	インターネットと双方向通信するために必要	外→内、内→外の通信
NAT Gateway	インターネットと片方向通信するために必要	内→外の通信のみ
VPC Peering接続	VPC間を接続するために必要	VPC間の接続なので相手VPCもAWSである必要がある
VPN接続	離れたネットワークと接続するために必要	AWS以外のネットワークとも接続できる
Direct Connect	離れたネットワークと接続するために必要	オンプレのネットワークと接続するために使用
Transit Gateway	VPC間を接続したりVPNなどと連携したりするために必要	大規模のネットワークを構築するのに適している

Direct Connectも勉強として試してみたいところですが、データセンターに機器を設置したりしないといけないことから、さすがに個人で試すことは厳しいので除外します。

また、今回はVPC間や他の内部ネットワークとの接続を試すことを目的としているため、Internet GatewayとNAT Gatewayの説明も除外します。

VPC Peeringとは

VPC PeeringとはVPC間を直接接続するのに使うサービスとなります。

Transit Gatewayでも同じように接続することはできますが、自分も相手もAWS環境であれば一番手軽に接続できるサービスです。

費用も他のサービスと比べて安く、相手が別AWSアカウントのVPCとの接続だとしても、同一のアベイラビリティゾーン（AZ）への通信であれば費用はかからず、別AZの場合は1GBあたり$0.01となります。

そのため、AWS同士のネットワークを接続する場合には、まず最初に検討すべき接続方法となります。

AZ通信	費用
同一AZ内	無料
別AZ	$0.01/GB

ちなみにap-northeast-1aなどのアベイラビリティゾーンの名前ですが、この名前はAWSアカウントごとに紐づいているゾーンは変わるそうなので、別のAWSアカウントのVPCと接続する場合は以下のように「アベイラビリティゾーンID」で判断するようにしてください。

AWS リソースのアベイラビリティーゾーン ID

VPC Peeringの制限

通常のIPネットワークの場合、以下のように複数ネットワークを経由したネットワークであっても、適切にルーティングを設定すれば双方向に通信できますが、VPC PeeringではVPC Peeringで繋いだVPCとしか通信できないようになっているので、VPC Peeringを経由して更に他のネットワークへ行くことはできません。

そのため、A、B、Cそれぞれ双方向で通信を行うようにするためにはA、B、CそれぞれフルメッシュでVPC Peeringを行う必要があります。

また、VPC PeeringはVPCあたり最大でも125接続しか作成できないため、拠点数が多い場合は利用できません。

VPC ピアリング接続のクォータ

全拠点双方向で通信するためには、拠点が増えるごとに毎回ピアリングの設定を行う必要があることから設定の抜け漏れも起こる可能性が高くなるので、そのような場合はTransit Gatewayの使用を検討しましょう。

同一AWSアカウント内のVPC Peering

実際にVPC Peeringを試して見るため、AWSアカウントで適当なVPC、サブネット、EC2を作成して疎通確認を試してみます。

VPC Peering確認用VPCの作成

VPCの作成は「VPCダッシュボード」→「お使いのVPC」の「VPCを作成」から以下のような設定で行いました。

項目	VPC-A設定	VPC-B設定	備考
作成するリソース	VPCなど	VPCなど	まとめてサブネットなど作成
名前タグの自動生成	自動生成	自動生成
名前	VPC-A	VPC-B
IPv4 CIDRブロック	10.20.0.0/16	10.30.0.0/16	任意のブロックを指定
IPv6 CIDRブロック	IPv6 CIDRブロックなし	IPv6 CIDRブロックなし	今回はIPv6は作成しない
テナンシー	デフォルト	デフォルト
アベイラビリティゾーン(AZ)の数	1	1	テストなので今回は1つだけ作成
パブリックサブネットの数	1	1
プライベートサブネットの数	0	0	今回はプライベートサブネットは作成しない
NATゲートウェイ	なし	なし
VPCエンドポイント	なし	なし	目的とは異なるので今回は作成しない
DNSホスト名を有効化	有効化	有効化	デフォルトのまま
DNS解決を有効化	有効化	有効化	デフォルトのまま

リソースマップ的にはこんな感じ。

VPC-A
VPC-B

疎通確認用EC2の作成

疎通確認用のEC2もそれぞれのVPCに作成しておきます。

基本的にはデフォルト設定ですが、疎通確認するためにEC2にログインするため、セッションマネージャ接続用のロールを新規作成＆アタッチします。

EC2作成時の「高度な詳細」から「新しいIAMプロファイルの作成」でロールを作成できます。

項目	設定	備考
信頼されたエンティティタイプ	AWSのサービス
サービスまたはユースケース	EC2
ユースケース	EC2 Role for AWS Systems Manager	セッションマネージャ接続のため選択
ロール名	SessionManager-Role	任意の名前を指定

その他EC2の設定は以下で設定しました。

項目	VPC-A用EC2設定	VPC-B用EC2設定	備考
名前	VPC-A-EC2	VPC-B-EC2	任意の名前を指定
AMI	Amazon Linux 2023 AMI	Amazon Linux 2023 AMI
アーキテクチャ	64ビット(x86)	64ビット(x86)
インスタンスタイプ	t2.micro	t2.micro
キーペア名	キーペアなしで続行	キーペアなしで続行	セッションマネージャで繋ぐため無しで作成
VPC	VPC-A-vpc	VPC-B-vpc	先程作成したVPCを指定
サブネット	VPC-A-subnet-public1-ap-northeast-1a	VPC-B-subnet-public1-ap-northeast-1a	先程作成したサブネットを指定
パブリックIPの自動割り当て	有効化	有効化	セッションマネージャを使用するため有効化
セキュリティグループ名	VPC-A-sg	VPC-B-sg	任意の名前を指定
説明	デフォルトのまま	デフォルトのまま
タイプ	すべてのICMP - IPv4	すべてのICMP - IPv4	Ping疎通確認用
プロトコル	ICMP	ICMP
ポート範囲	すべて	すべて
ソースタイプ	任意の場所	任意の場所
ソース	0.0.0.0/0	0.0.0.0/0
説明	空欄	空欄
IAMインスタンスプロフィール	SessionManager-Role	SessionManager-Role	先程作成したロールを指定

なお、「高度な詳細」の設定は「IAMインスタンスプロフィール」設定のみ行い、他の設定は全てデフォルトの値とします。

VPC Peeringの作成

準備ができたので、VPC PeeringでVPC同士を接続します。

VPC Peeringは「VPCダッシュボード」の「仮想プライベートクラウド」→「ピアリング接続」から「ピアリング接続を作成」より作成します。

今回は同じアカウント内での接続となるため、以下のように設定します。

ピアリングを行う場合、接続のリクエストを行う側（リクエスタ）から接続のリクエストを受け付ける側（アクセプタ）に接続のリクエストを行い、相手側から承認されればVPC Peeringで繋がるようになります。

アクセプタ側で1週間承認されないとリクエスト自体がキャンセルされるため、注意してください。

今回はリクエスタ、アクセプタ共に自分のアカウントなので「アクション」→「リクエストを承認」を行うと承認できます。

承認後、以下のようなインフォメッセージが表示されるため、「ルートテーブルを今すぐ変更」を選択してルートテーブルの追加を行います。

ルートテーブルの追加

先程の設定でVPC PeeringでVPC-AとVPC-Bが繋がったので、それぞれのサブネットに付与されているルートテーブルに相手側VPCへ行くためのルーティングを設定します。

「VPCダッシュボード」の「仮想プライベートクラウド」→「ルートテーブル」からVPC-A、VPC-Cのルートテーブルを選択して「ルート」タブ→「ルートを編集」でルーティングを追加します。

送信先を相手先ネットワーク、ターゲットで「ピアリング接続」を選び、先程作成したピアリングIDを指定すればOKです。

今回はそれぞれ以下のように設定しました。

VPC-A用ルートテーブル設定

VPC-B用ルートテーブル設定

今回は相手先VPCのアドレスレンジ全てを対象とするため、「10.xx.0.0/16」と指定していますが、特定のセグメント宛の通信のみVPC Peeringで転送したい場合はセグメントに合わせて指定してください。

疎通確認

ネットワークの準備ができたので、先程作成したEC2インスタンスを使い、VPC Peering経由で疎通できるか確認してみます。

EC2インスタンスにはセッションマネージャー経由で接続できるように設定しているので、「EC2ダッシュボード」から「インスタンス」で先程作成したEC2インスタンスを選択→「接続」から「セッションマネージャー」タブの「接続」で作成したインスタンスに接続します。

今回はVPC-A側のEC2インスタンスは「10.20.0.207」、VPC-B側のEC2インスタンスは「10.30.4.69」のアドレスが振られたため、VPC-A側のEC2インスタンスからVPC-B側のEC2インスタンスにpingを実行した結果、以下のように疎通できました。

別AWSアカウントとのVPC Peering

次は、別のAWSアカウントに存在するVPCとVPC Peeringを行い、アカウント跨ぎのVPCとも接続できるかを確認してみようと思います。

別AWSアカウント側VPC Peering確認用VPCの作成

別のAWSアカウントと接続確認を行うため、別のAWSアカウントで以下VPCの作成を行いました。

項目	VPC-C設定	備考
作成するリソース	VPCなど	まとめてサブネットなど作成
名前タグの自動生成	自動生成
名前	VPC-C
IPv4 CIDRブロック	10.120.0.0/16	任意のブロックを指定
IPv6 CIDRブロック	IPv6 CIDRブロックなし	今回はIPv6は作成しない
テナンシー	デフォルト
アベイラビリティゾーン(AZ)の数	1	テストなので今回は1つだけ作成
パブリックサブネットの数	1
プライベートサブネットの数	0	今回はプライベートサブネットは作成しない
NATゲートウェイ	なし
VPCエンドポイント	なし	目的とは異なるので今回は作成しない
DNSホスト名を有効化	有効化	デフォルトのまま
DNS解決を有効化	有効化	デフォルトのまま

同様に疎通確認用のEC2インスタンスも作成しておきます。

合わせてセッションマネージャ接続用IAMロールは先程と同様作成しておいてください。

項目	VPC-C用EC2設定	備考
名前	VPC-C-EC2	任意の名前を指定
AMI	Amazon Linux 2023 AMI
アーキテクチャ	64ビット(x86)
インスタンスタイプ	t2.micro
キーペア名	キーペアなしで続行	セッションマネージャで繋ぐため無しで作成
VPC	VPC-C-vpc	先程作成したVPCを指定
サブネット	VPC-C-subnet-public1-ap-northeast-1a	先程作成したサブネットを指定
パブリックIPの自動割り当て	有効化	セッションマネージャを使用するため有効化
セキュリティグループ名	VPC-C-sg	任意の名前を指定
説明	デフォルトのまま
タイプ	すべてのICMP - IPv4	Ping疎通確認用
プロトコル	ICMP
ポート範囲	すべて
ソースタイプ	任意の場所
ソース	0.0.0.0/0
説明	空欄
IAMインスタンスプロフィール	SessionManager-Role	先程作成したロールを指定

AWSアカウントID、VPC IDの確認

別AWSアカウントのVPCとVPC Peeringを行うためにはAWSアカウントIDと接続するVPCのVPC IDが必要となります。

今回は最初に操作したAWSアカウントで作成したVPC-Aと別アカウントで作成したVPC-CをVPC Peeringで接続しようと思うので、VPC-C側のAWSアカウントIDとVPC-CのVPC IDを確認します。

「VPCダッシュボード」より該当のVPCの詳細からVPC IDとAWSアカウント（所有者ID）を確認できるのでこちらを確認しておきます。

別AWSアカウントとのVPC Peeringの設定

同AWSアカウントで設定する場合と同様、VPC Peeringの設定を行います。

今回はVPC-Aと、別AWSアカウント上のVPCとなるVPC-CをVPC Peeringで接続しようと思います。

VPC Peeringの作成はどちらのアカウントで作成しても良いですが、今回はVPC-A側のアカウントで以下のように設定します。

アカウントIDとVPC IDは先程確認したアカウントIDとVPC IDを入力します。

VPC-A側アカウントでピアリングを行うと、VPC-C側アカウントに以下のようなリクエストが届くため、VPC-C側アカウントで「リクエストを承諾」を行います。

ルートテーブルの追加

VPC PeeringでVPC-AとVPC-Cを接続したので、ルートテーブルを追加していきます。

VPC-A用ルートテーブル設定

VPC-C用ルートテーブル設定

疎通確認

一通り設定できたので同一アカウント内のVPC Peeringを行ったときと同様、セッションマネージャでEC2に接続してpingで確認を行います。

今回もVPC-A側のEC2インスタンスからVPC-C側EC2インスタンスにpingを行ったところ、以下のように無事疎通できました。

本当にVPC Peeringを経由した通信はできないのか？

VPC Peeringを経由した通信はできないと書きましたが、本当にできないのか確認してみたいと思います。

先程までの手順でVPC-AからVPC-B、VPC-CともにVPC Peeringで接続できています。

そのため、ネットワーク的にはルーティングさえ行ってしまえばVPC-BからVPC-Cに通信ができそうなので、VPC-BにはVPC-C向けルートテーブル、VPC-CにはVPC-B向けルートテーブルをそれぞれ設定します。

VPC-B用ルートテーブル設定

VPC-C用ルートテーブル設定

ルーティング的にはVPC-B、VPC-C間でpingが届きそうですが、結果はドキュメントの通り、通信できませんでした。

おわりに

今回は色々あるAWSのネットワーク間通信サービスのうち、VPC Peeringの設定を行ってみました。

同一アカウント内であっても別アカウントであっても簡単な手順でVPC同士を接続できるのでお手軽に接続できますが、同一AZ同士でなければ費用がかかってしまうため、その点は注意して設定する必要があると感じました。

次回はSite to Site VPNについてまとめてみたいと思います。