はじめに
AWSには各ネットワークを繋ぐためのサービスが色々とあります。
必要に応じて毎回調べながら導入するようなことをよくやっていますが、改めてきちんと整理してAWSのネットワーク間接続をまとめてみようと思い、今回から何回かに分けてAWSのネットワーク間接続を色々と試しつつ学んでいこうと思います。
また、仕事でTransit Gatewayを使うことも増えたことと、資格勉強も兼ねて特にTransit Gatewayに関しては深く調べてみたいと思います。
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」で判断するようにしてください。
VPC Peeringの制限
通常のIPネットワークの場合、以下のように複数ネットワークを経由したネットワークであっても、適切にルーティングを設定すれば双方向に通信できますが、VPC PeeringではVPC Peeringで繋いだVPCとしか通信できないようになっているので、VPC Peeringを経由して更に他のネットワークへ行くことはできません。
そのため、A、B、Cそれぞれ双方向で通信を行うようにするためにはA、B、CそれぞれフルメッシュでVPC Peeringを行う必要があります。
また、VPC PeeringはVPCあたり最大でも125接続しか作成できないため、拠点数が多い場合は利用できません。
全拠点双方向で通信するためには、拠点が増えるごとに毎回ピアリングの設定を行う必要があることから設定の抜け漏れも起こる可能性が高くなるので、そのような場合は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についてまとめてみたいと思います。