色々なネットワーク間接続を試しつつTransit Gatewayを理解する。（その１：VPC Peering）

Last updated at 2024-01-21Posted at 2023-12-24

はじめに

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	先程作成したロールを指定