コーヒーが好きな木谷映見です。
AWS Cloud WAN が GA（一般提供）されてから早 1 か月経ちました。
本記事では、AWS Cloud WAN の概要と、簡単なセットアップを試します。
AWS Cloud WAN ドキュメント
ドキュメント類はこちらです。
- 【AWS What's New】AWS Cloud WAN の一般提供が開始
- 【サービス概要ページ】AWS Cloud WAN グローバル広域ネットワークの簡単な構築、管理、およびモニタリング
- 【AWS公式ドキュメント】What is AWS Cloud WAN? ※20220817 時点で英語のみ
AWS Cloud WAN 概要
AWS Cloud WAN はマネージド WAN サービスで、クラウドとオンプレミス環境間でリソースを接続する統合グローバルネットワークの構築、管理、および監視に使用できます。
オンプレミスの支店、データセンター、Amazon VPC を AWS グローバルネットワークで接続するためのセントラルダッシュボードを提供します。
シンプルなネットワークポリシーを使用して、ネットワーク管理とセキュリティタスクを一元管理および自動化し、グローバルネットワークの全体像を把握することができます。
イメージ図
概要の文章だけでは Cloud WAN がどのようなものなのか理解しにくいと思いますので、イメージ図をご覧ください。AWS のネットワークサービスがどのように便利になってきたか、順を追って図にします。
VPC 混雑時代
例えば、AWS 上で稼働するシステムが増え、それに伴い VPC を追加で作成するとします。
VPC 間で通信するための VPC ピアリングが増え、オンプレミス拠点からの接続も複雑になります。
AWS Transit Gateway の登場
AWS Transit Gateway は「リージョナルゲートウェイ」と言われることもあり、同じリージョンにある VPC、VPN、Direct Connect を接続することができました。複雑なネットワークが Transit Gateway という HUB のような役割のサービスによってシンプルになり、管理しやすくなりました。
さて、グローバル展開、DR 対策などをするうちに、リージョナルサービスである Transit Gateway が各リージョンに増えてきました。
AWS Cloud WAN の登場
ここに AWS Cloud WAN が登場し、VPC、VPN、SD-WAN（Transit Gateway Connect）をグローバルに接続することができるようになりました。複雑なネットワークが Cloud WAN によってシンプルになり、管理しやすくなりました。
複数リージョンに展開している VPC、VPN、SD-WAN を Cloud WAN で接続することができ、本番環境、開発環境などでセグメントを分離できます。
Cloud WAN を使ってみる
今回はシンプルに、リージョンをまたいだ VPC 間の疎通確認をやってみます。
以下の構成を作成します。
本番環境 Prod セグメントネットワークに所属する VPC 間の疎通確認と、開発環境 Dev セグメントネットワークに所属する VPC 間の疎通確認ができることをゴールとします。
準備しておくリソース
| リソース | 備考 | |
|---|---|---|
| VPC | 各リージョンに 2つ | |
| サブネット | 各 VPC にプライベートサブネット 1つずつ | |
| ルートテーブル | 各プライベートサブネットに 1 つずつ | ルートはまだ local だけ許可されていればよい |
| セキュリティグループ（VPC エンドポイント 用） | VPC エンドポイントを配置する VPC からのインバウンド HTTPS 許可、アウトバウンドはすべて許可 | 今回であれば、例えば Tokyo-vpc1 に設定する VPC エンドポイント用なら 172.16.1.0/24 インバウンド HTTPS 許可 |
| セキュリティグループ（EC2 用） | 同じ Cloud WAN セグメントネットワークに属する VPC からのインバウンド ICMP 許可、アウトバウンドはすべて許可 | 疎通確認を Ping でおこなうため許可しておく。今回の構成ではすべての VPC を含むよう、 172.16.0.0/12 からのインバウンド ICMP 許可する等でよい。 |
| VPC エンドポイント | 各プライベートサブネットに com.amazonaws.[region].ssm、com.amazonaws.[region].ec2messages、com.amazonaws.[region].ssmmessages を許可する VPC エンドポイントを作成 | セッションマネージャーへの疎通用。（参考）Systems Manager を使用してインターネットアクセスなしでプライベート EC2 インスタンスを管理できるように、VPC エンドポイントを作成するにはどうすればよいですか? |
| EC2 インスタンス | 各 VPC に 1 つずつ | セッションマネージャーでログインするため AmazonSSMManagedInstanceCore 権限がある IAM ロールを付与 |
Cloud WAN の設定
グローバルネットワークとコアネットワークの作成
グローバルネットワークとコアネットワークは、 Cloud WAN で制御するネットワークの一番大枠です。使用するリージョンを定義します。
AWS マネジメントコンソールから作成します。
Cloud WAN は VPC コンソールの中にあります。
ナビゲーションペインから Cloud WAN の [ネットワークマネージャー] を選択し、[今すぐ始める] をクリックします。
[グローバルネットワークを作成] をクリックします。
グローバルネットワークの名前を付け、[次へ] をクリックします。
コアネットワークの名前を付け、画面↓にスクロールします。
以下のように設定します。
- ASN の範囲： 64512-64520
- エッジロケーション：バージニア北部、東京
- セグメント名：Dev
- セグメントの説明：Dev
※ ASN の範囲は Cloud WAN 側で使用する BGP の ASN の範囲で、Site-to-Site VPN やConnect アタッチメントで使用します。今回は適当に設定します。
設定したら、[次へ] をクリックします。
設定内容の確認画面になります。
[グローバルネットワークを作成] をクリックします。
グローバルネットワークが正常に作成されました、と表示されます。
作成してすぐは、コアネットワークの状態が [Pending] となっています。
グローバルネットワーク ID [global-network-xxxxxxxxxx] のリンクをクリックします。
ナビゲーションペインでコアネットワークの [ポリシーのバージョン] をクリックすると、 [Policy version - 1] の変更セットの状態が [Executing] になっています。
コア ネットワーク ポリシーにより、コア ネットワークの作成とデプロイが開始されています。
変更セットの状態が「Execution succeeded」になるまで、約 15 ～ 20 分程度待ちましょう。
ナビゲーションペインで [ダッシュボード] を見ると、追加したコアネットワークに追加したリージョンがエッジロケーションとして表示されているのが分かります。
セグメントネットワークの作成
セグメントネットワークによって、例えば本番セグメントと開発セグメントを分離するなど、通信をワークロードごとに制御することができます。
セグメントネットワークの作成は、コアネットワークポリシーの設定で行います。
ナビゲーションペインでコアネットワークの [ポリシーのバージョン] - [Policy version - 1] のリンクをクリックします。
[編集] をクリックします。
[セグメント] タブを開き、[作成] をクリックします。
以下のように設定します。
- セグメント名：Prod
- セグメントの説明：Prod
- エッジロケーション：バージニア北部、東京
設定したら、[セグメントの作成] をクリックします。
Prod セグメントが作成されました。
Dev セグメントにチェックを入れ、[編集] をクリックします。
以下のように編集します。
- セグメントの説明：Dev
- エッジロケーション：バージニア北部、東京
- [承認を必須にする] のチェックを外す
設定したら、 [セグメントの編集] をクリックします。
Dev セグメントが修正されました。
アタッチメントポリシーの設定
アタッチメントポリシーの設定は、引き続きコアネットワークポリシーの設定で行います。
[アタッチメントポリシー] タブを選択し、[作成] をクリックします。
以下のように編集します。
- ルール番号：10
- 説明：Prod 用
- セグメントにアタッチする：Prod
- 条件
- タイプ：Tag Value
- オペレーター：Equals
- 条件値：key=Environment, value=Prod
その他の項目はそのままにします。
設定したら、 [アタッチメントポリシーの作成] をクリックします。
以下のように、Prod 用のアタッチメントポリシーができているのが確認できます。
再び [作成] をクリックします。
同様に、Dev セグメント用のアタッチメントポリシーを以下のように作成します。
- ルール番号：20
- 説明：Dev 用
- セグメントにアタッチする：Dev
- 条件
- タイプ：Tag Value
- オペレーター：Equals
- 条件値：key=Environment, value=Dev
その他の項目はそのままにします。
設定したら、 [セグメントの編集] をクリックします。
以下のように、アタッチメントポリシーが二つできました。
[ポリシーの作成] をクリックします。
[Policy version - 2] が作成され、変更セットの状態が「Pending generation」となっています。
数秒待つと、「Ready to execute」に変わります。
変更セットの状態が「Ready to execute」に変わったら、「Policy version - 2 」にチェックつけ、[変更セットの表示または適用] をクリックします。
「Policy version - 1 」と「Policy version - 2 」の変更箇所が変更セットとして表示されます。「変更セットの適用」をクリックします。
変更セットの状態が「Execution succeeded」になるまで、5 分程度待ちましょう。
VPC アタッチメント
作成したコアネットワークに、VPC をアタッチします。 VPC のアタッチは、アタッチメントの作成で行います。
今回は、Tokyo-vpc1 と Virg-vpc1 を Prod セグメントに、Tokyo-vpc2 と Virg-vpc2 を Dev セグメントにアタッチしたいので、アタッチメントタグに先ほどのポリシーで設定したタグをつけます。
ナビゲーションペインの [アタッチメント] を選択し、[アタッチメントの作成] をクリックします。
Tokyo-vpc1 用のアタッチメントを以下のように作成します。
- 名前：Tokyo-vpc1
- エッジロケーション：東京
- アタッチメントタイプ：VPC
- VPC ID： Tokyo-vpc1
- サブネット ID
- Avaiability Zone：ap-northeast-1a
- Subnet Id：Tokyo1PrivateSubnet
- タグ
- key：Environment
- Value：Prod
設定したら、[アタッチメントの作成] をクリックします。
アタッチメントが作成され、状態が「Creating」になります。
アタッチメントの作成時にタグを設定したので、セグメントが「Prod」になっていることが分かります。
同様に、他の VPC の分もアタッチメントを作成します。
| 名前 | エッジロケーション | アタッチメントタイプ | VPC ID | サブネット ID | タグ |
|---|---|---|---|---|---|
| Tokyo-vpc2 | 東京 | VPC | Tokyo-vpc2 | チェックをつける | key=Environment, value=Dev |
| Virg-vpc1 | バージニア北部 | VPC | Virg-vpc1 | チェックをつける | key=Environment, value=Prod |
| Virg-vpc2 | バージニア北部 | VPC | Virg-vpc2 | チェックをつける | key=Environment, value=Dev |
4 つの VPC アタッチメントの状態が「Available」になるまで、10 分程度待ちましょう。
コアネットワークのルートテーブル確認
コアネットワークのルートテーブルを確認します。
各 VPC のルートは、VPC アタッチメント作成時に自動で Cloud WAN 内のルートテーブルに伝播されます。ナビゲーションペインの [コアネットワーク] を選択し、[ルート] タブを選択します。
- セグメント：Prod
- エッジロケーション：ap-northeast-1
と設定し [ルートの検索] をクリックすると、VPC アタッチメント作成時に自動で伝播されたルートが表示されます。他のリージョンも同様にルートが表示されます。
VPC 内ルートテーブル編集
今回作成している VPC のルートを Cloud WAN のセグメントに向けます。
VPC コンソールで東京リージョンを選択します。
ナビゲーションペインの [ルートテーブル] を選択し、Tokyo1PrivateSubnet のルートテーブルにチェックをつけます。画面下部の [ルート] タブを選択し、[ルートを編集] をクリックします。
Virg-vpc1 (172.17.1.0/24) へのルートを設定します。
ターゲットにでは [コアネットワーク] を選択し、「arn:aws:networkmanager::～」で始まる ARN を選択します。
Virg-vpc1 (172.17.1.0/24) へのルートが設定できました。
同様に、その他の VPC のルートテーブルも設定します。
| ルートテーブル | 送信先 | ターゲット |
|---|---|---|
| Tokyo2RTBForPrivateSubnet（東京リージョンのコンソールで設定） | Virge-vpc2 (172.17.2.0/24) | コアネットワーク (arn:aws:networkmanager::～) |
| Virg1RTBForPrivateSubnet（バージニア北部リージョンのコンソールで設定） | Tokyo-vpc1 (172.16.1.0/24) | コアネットワーク (arn:aws:networkmanager::～) |
| Virg2RTBForPrivateSubnet（バージニア北部リージョンのコンソールで設定） | Tokyo-vpc2 (172.16.2.0/24) | コアネットワーク (arn:aws:networkmanager::～) |
疎通確認
EC2 インスタンスにセッションマネージャーでログインし、同じセグメントネットワークに属している VPC 内に存在する EC2 インスタンス同士が疎通できることを確認します。
EC2 コンソールに移動します。
東京リージョンの EC2 インスタンスから疎通確認します。
Tokyo1-ec2 を選択し、[接続] をクリックします。
セッションマネージャータブを選択し、[接続] をクリックします。
以下のコマンドで、ec2-user に変更します。
sudo su - ec2-user
以下のコマンドで、Virg1-ec2 インスタンスに ping 疎通確認します。
ping のあとは、Virg-vpc1 のプライベートサブネットに存在する EC2 インスタンスのプライベート IP を入れてください。
ping 172.17.1.4
ping コマンドを実行し、
64 bytes from 172.17.1.4: icmp_seq=1 ttl=253 time=149 ms 64 bytes from 172.17.1.4: icmp_seq=1 ttl=253 time=149 ms :
のように応答が帰ってきたら、疎通成功です。
Ctr+ C で ping 疎通が止まります。
同様に、以下の挙動も確認できます。
- Tokyo1-ec2 ⇒ Tokyo2-ec2 ping 疎通×
- Tokyo1-ec2 ⇒ Virg2-ec2 ping 疎通×
- Tokyo2-ec2 ⇒ Virg2-ec2 ping 疎通○
- Tokyo2-ec2 ⇒ Tokyo1-ec2 ping 疎通×
- Tokyo2-ec2 ⇒ Virg1-ec2 ping 疎通×
- Virg1-ec2 ⇒ Tokyo1-ec2 ping 疎通○
- Virg1-ec2 ⇒ Tokyo2-ec2 ping 疎通×
- Virg1-ec2 ⇒ Virg2-ec2 ping 疎通×
- Virg2-ec2 ⇒ Tokyo2-ec2 ping 疎通○
- Virg2-ec2 ⇒ Tokyo1-ec2 ping 疎通×
- Virg2-ec2 ⇒ Virg1-ec2 ping 疎通×
このように、同じネットワークセグメント内の EC2 インスタンス間で疎通ができていることが分かります。
コアネットワークのダッシュボードを見る
最後に、構築した Cloud WAN のコアネットワークのダッシュボードを少し見てみましょう。
Cloud WAN の Network Manager コンソールに移動します。
ナビゲーションペインで [コアネットワーク] をクリックします。
[概要] タブでは、エッジロケーションやセグメントの数を確認することができます。
[トポロジグラフ] タブでは、コアネットワーク全体の要素を見ることができます。コンポーネントがふわふわ動いてかわいいです。
[トポロジツリー] タブでは、コアネットワークのコンポーネントがツリー状に表示されます。
[論理] タブでは、疎通できるコンポーネントが論理的に表示されます。
[Filter by:] で送信元と送信先を指定すると、オレンジ色になって、どこが通信できるのか視覚的にわかりやすくなります。
個人的にはこの [論理] タブが分かりやすくて好きです。
今回の構成では、Prod セグメントと Dev セグメントがつながっていないことがすぐにわかりますね。
お片付け
コアネットワークのアタッチメントを削除します。
ナビゲーションペインから [アタッチメント] を選択すると、コアネットワークにアタッチされている VPC が 4 つありますので、一つずつ削除します。
「削除しますか？」というポップアップが出ますので、[削除] をクリックします。
状態が「Deleting」になります。1 ～ 2 分待つと、画面からアタッチメントがなくなります。
コアネットワークの [詳細] タブに削除ボタンがありますのでクリックします。
グローバルネットワーク画面に遷移します。
コアネットワークの状態が「Deleting」から「-」になるまで 10 分程度待ちます。
コアネットワークが削除されてから、グローバルネットワークを削除してください。
おわりに
今回はシンプルに、リージョンをまたいだ VPC 間の疎通確認をやってみました。
海外拠点が複数あったり、オンプレミスの拠点が多数あるような複雑なネットワークを構成している場合、Cloud WAN を利用することでネットワークを一元管理できそうです。
次は Transit Gateway のピアリングをやってみようと思います。
追記
2022/8/19 時点で、Cloud WAN は大阪リージョン未対応です。
- 2022/8/19 時点の Cloud WAN 対応リージョン
- 米国東部 (オハイオ)
- 米国東部 (バージニア北部)
- 米国西部 (北カルフォルニア)
- 米国西部 (オレゴン)
- アフリカ (ケープタウン)
- アジアパシフィック (ムンバイ)
- アジアパシフィック (シンガポール)
- アジアパシフィック (シドニー)
- アジアパシフィック (東京)
- カナダ (中部)
- 欧州 (フランクフルト)
- 欧州 (アイルランド)
- 欧州 (ロンドン)
- 欧州 (ミラノ)
- 欧州 (パリ)
- 欧州 (ストックホルム)
- 中東 (バーレーン)
参考
- 【AWS What's New】AWS Cloud WAN の一般提供が開始
- 【サービス概要ページ】AWS Cloud WAN グローバル広域ネットワークの簡単な構築、管理、およびモニタリング
- 【AWS公式ドキュメント】What is AWS Cloud WAN? ※20220817 時点で英語のみ
- 【AWS Summit 2022 動画】グローバルネットワーク展開を迅速化する AWS インフラストラクチャ活用方法(AWS-55)
emi kitani(執筆記事の一覧)
AS部LX課。2022/2入社、コーヒーとサウナが好きです。執筆活動に興味があります。AWS認定12冠。
