AWS Cloud WANにおいてNetwork FirewallやNAT Gateway不調時に別AZや別リージョンにルーティングする仕組みを作ってみた
AZやリージョンレベルで不調が発生した場合は別のリソースに自動的にフェイルオーバーさせたい
こんにちは、のんピ(@non____97)です。
皆さんはAZやリージョンレベルで不調が発生した場合は別のリソースに自動的にフェイルオーバーさせたいなと思ったことはありますか? 私はあります。
Transit GatewayやCloud WANを用いてNetwork Firewall、NAT Gatewayをネットワークトポロジー内で集約して管理している場合があると思います。
集約していることによるメリットとしてはコスト削減があります。NAT Gatewayについては以下記事で詳細に説明されています。
一方で集約していることのデメリットとして、集約しているリソースがSPOFになるという点が挙げられます。
以下記事で紹介しているとおり、Firewall Endpointが不調なときのフェイルオーバーは自動では行われず、検知と切り替えを手組みする必要があります。Firewall EndpointをMulti-AZでデプロイするだけでは十分とは言えません。
また、こちらの記事で紹介した「NAT GatewayとNetwork Firewallを同一VPC内に作成する」方式では実質Regional NAT Gatewayは使用できません。Cloud WANの場合については「NAT GatewayとNetwork Firewallを別VPCにする」方式であってもRegional NAT gatewayは使用できません。このような場合はZonal NAT Gatewayを使用することとなり、1AZのNAT Gatewayが不調となった場合のケアについてもユーザー側でケアする必要があります。
さらに、Cloud WANについては以下記事で示しているとおり、単一リージョンのNetwork FirewallやNAT Gatewayの障害が、他リージョンのVPC間、VPCからインターネットへの通信時への障害に波及してしまうシナリオがあります。
影響範囲が非常に広くなってしまうため、別リージョンのNetwork FirewallやNAT Gatewayにルーティングしたいところですが、残念ながら記事執筆時点ではそのような機能はマネージドでは提供されていません。
ユーザー側でケアをするとしても可能なのであれば自動で行いたいです。
ということで、Cloud WANにおいてNetwork FirewallやNAT Gateway不調時に別AZや別リージョンにルーティングする仕組みを作ってみました。
いきなりまとめ
- Cloud WAN で NFG アタッチメントを複数リージョンに展開する構成において、Network Firewall と NAT Gateway の不調を自動検知し、別 AZ や別リージョンへ迂回させる仕組みを AWS CDK で構築した
- 3分間隔のヘルスチェックで AZ 障害と判定すると VPC ルートテーブルの書き換えで同一リージョン内の別 AZ へ、リージョン障害と判定すると Core Network Policy の書き換えで別リージョンの NFG アタッチメントへ切り替える
- 検証の結果、AZ 障害時の RTO は5分強、リージョン障害時の RTO は12分強
- リージョンの切り替え先は地理的なグループで優先度を定義しており、あるリージョンがダウンしても地理的に離れたリージョンへ飛んでレイテンシーが大幅に悪化することを防いでいる
仕組み
仕組みはシンプルと言えばシンプルです。
定期的に疎通確認をして、疎通が失敗すれば別AZや別リージョンにフェイルオーバーするように、VPCルートテーブルやCloud WANのCore Network Policyを更新します。
疎通確認の仕組みはオレゴンリージョンのStep Functionsから各リージョンのLambda関数を叩いて、Lambda関数から疎通確認先のエンドポイントにTCPコネクションを張りに行く形です。
オレゴンリージョンのStep Functionsを使用しているのはCloud WANのコントロールプレーンがオレゴンリージョンのみだからです。Cloud WANではなくTransit Gatewayを使用している環境でAZ障害時のみ注目をすれば良いのであれば、Transit Gatewayが動作しているリージョンでも良いと思います。
疎通確認先がダウンしていると元も子もないです。この仕組みの可用性が完全に疎通確認先に引っ張られてしまいます。そのため、疎通確認先は複数用意をし、そのいずれもに複数回TCPコネクションを張ることが失敗したら、その経路はダウンしたと判定します。
具体的にはamazonaws.comのNSレコードを名前解決した先と、checkip.amazonaws.comに対して疎通確認をします。それでも疎通できない場合は1.1.1.1や8.8.8.8などAWS外のインターネット上のリソースに対して接続を行います。
Network Firewall EndpointとZonal NAT GatewayはInspection VPC上に2AZ分動作させています。1AZがダウンしたらAZ障害と判断しVPCルートテーブルの更新を行い、生きているAZのNetwork FirewallとNAT Gatewayにルーティングするようにします。
2AZがダウンしたらリージョン障害と判断しCore Network Policyの更新を行い、VPC間やVPCとインターネット間の通信を別リージョンのInspection VPCにルーティングするようにします。
Step Functionsでは疎通確認結果を元にVPCルートテーブルやCloud WANのCore Network Policyを更新します。
フローを整理すると以下のようになります。
全体フロー
ブランチ A (リージョン数で並列に実行)
ブランチ B
フェイルバックは自動で行いません。下手に導入すると完全に復旧していないにも関わらず元の状態に戻し、事態をさらに混乱させてしまいます。そのため、サービスの稼働状況を人間の目で確認したり、手動で動作確認をしたりなどステップを踏んだのちに手動で元の状態に戻すことを想定しています。
なお、両AZがダウンした場合は別リージョンのNFGアタッチメントにルーティングしていますが、これはルーティング先のNetwork Firewallのルールが元々のNetwork Firewallのルールとが運用上、大きな乖離がない前提の元に行なっています。全くルールの構成が異なる場合は、自動で切り替えを行ったとしても、対応するルールがなければNetwork Firewallで通信が弾かれてしまうでしょう。残念ながら2026/7/27時点でマルチリージョンでNetwork Firewallのルールを管理するマネージドの機能はありません。対応方法を強いて挙げるならばStackSetsを使用して、各リージョンでルールグループを更新していくような形になるかと考えます。
検証環境
検証環境は以下のとおりです。
ルート情報含めたものを一つの図で表現すると、とても見れたものではありません。ルート情報については以下の図のとおりです。基本的にap-northeast-1以外のリージョンも以下のようなルート情報となっています。
使用しているリージョンと役割を整理すると以下のようになります。
| リージョン | 略称 | default priority listにおける優先度 | 役割 |
|---|---|---|---|
| us-east-1 | use1 | 1 | NFG アタッチメントあり |
| us-west-2 | usw2 | 4 | NFG アタッチメントなし オーケストレーターの実行 |
| ap-northeast-1 | apne1 | 7 | NFG アタッチメントあり |
| ap-northeast-3 | apne3 | 9 | NFG アタッチメントあり |
| ap-southeast-1 | apse1 | 11 | NFG アタッチメントなし 送信元および送信先が NFG アタッチメントがないリージョンの通信の確認用 |
一部リージョンではInspection NFG用のInspection VPCを用意し、Network FirewallおよびNAT Gatewayを動作させます。
インターネットに抜ける場合、およびVPC間の通信はInspection NFGにルーティングをして、Network Firewallで検査するようにします。
トポロジグラフは以下のとおりです。テンション上がりますね。
検証環境は全てAWS CDKで構築しました。使用したコードは以下GitHubリポジトリに保存しています。
障害パターンの整理
実際の動作確認を行う前に障害パターンの整理をします。
NFGアタッチメントがある各リージョンごとの状態を以下のように整理しました。合計27パターンあります。
その内、送信元と送信先の通信ペアごとに、あるリージョンでNFGアタッチメントの両AZがダウンしていると判定されている場合において、どのリージョンのNFGアタッチメントを使用するかを示したものは以下のとおりです。
ポイントは地理的なグループでNFGアタッチメントのリージョンの優先度を定義している点です。
デフォルトではap-southeast-1のVPC間で通信を行っている際に、ap-northeast-1のNFGアタッチメントがダウンするとdefault priority listに基づき、us-east-1のNFGアタッチメントにルーティングされてしまい、レイテンシーが大幅に悪化します。
地理的なグループでNFGアタッチメントのリージョンの優先度を定義することで、ap-northeast-1がダウンした場合は、ap-northeast-3のNFGアタッチメントを使用するようにStep Functions上でCore Network Policyを更新するようにしています。詳細な具体例は以下README.mdでも言及しています。
平常時
Cloud WANの各セグメントおよびNFGのルート情報の確認
動作確認をしていきましょう。まずは平常時です。
ルート情報は以下のとおりです。
上述した通りの設計のとおりにルート情報が登録されていることが分かります。
リソースごとのAZとIPアドレスの整理
動作確認をするにあたって、リソースごとのAZとIPアドレスの整理をします。
結果は以下のとおりです。
ap-northeast-1 の VPC 間 (同一AZ / 別AZ) の疎通確認
いくつか実際に疎通確認をします。
まず、ap-northeast-1のVPC間です。同一AZと別AZの両方で試します。
$ hostname -i
10.21.0.53
# 同一AZ
$ ping -c 4 10.23.0.70
PING 10.23.0.70 (10.23.0.70) 56(84) bytes of data.
64 bytes from 10.23.0.70: icmp_seq=1 ttl=123 time=2.96 ms
64 bytes from 10.23.0.70: icmp_seq=2 ttl=123 time=1.52 ms
64 bytes from 10.23.0.70: icmp_seq=3 ttl=123 time=1.45 ms
64 bytes from 10.23.0.70: icmp_seq=4 ttl=123 time=3.35 ms
--- 10.23.0.70 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 1.452/2.322/3.352/0.845 ms
# 別AZ
$ ping -c 4 10.23.1.203
PING 10.23.1.203 (10.23.1.203) 56(84) bytes of data.
64 bytes from 10.23.1.203: icmp_seq=1 ttl=123 time=5.16 ms
64 bytes from 10.23.1.203: icmp_seq=2 ttl=123 time=2.55 ms
64 bytes from 10.23.1.203: icmp_seq=3 ttl=123 time=2.58 ms
64 bytes from 10.23.1.203: icmp_seq=4 ttl=123 time=3.41 ms
--- 10.23.1.203 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 2.554/3.426/5.162/1.059 ms
いずれも疎通できました。
この時のNetwork Firewallのログは以下のとおりです。いずれも送信元のEC2インスタンスと同じAZのNetwork Firewall Endpointを通っています。
# 同一AZ
{
"firewall_name": "NfgFnVpcDB445E37-Nfw",
"availability_zone": "ap-northeast-1a",
"event_timestamp": "1785224578",
"event": {
"icmp_type": 8,
"aws_category": "",
"ip_v": 4,
"src_ip": "10.21.0.53",
"event_type": "alert",
"alert": {
"severity": 3,
"signature_id": 2000001,
"rev": 1,
"signature": "INSPECTED at ap-northeast-1 - ICMP",
"action": "allowed",
"category": ""
},
"flow_id": 601998522943113,
"dest_ip": "10.23.0.70",
"proto": "ICMP",
"verdict": {
"action": "pass"
},
"icmp_code": 0,
"pkt_src": "geneve encapsulation",
"timestamp": "2026-07-28T07:42:58.861059+0000",
"direction": "to_server"
}
}
# 別AZ
{
"firewall_name": "NfgFnVpcDB445E37-Nfw",
"availability_zone": "ap-northeast-1a",
"event_timestamp": "1785224598",
"event": {
"icmp_type": 8,
"aws_category": "",
"ip_v": 4,
"src_ip": "10.21.0.53",
"event_type": "alert",
"alert": {
"severity": 3,
"signature_id": 2000001,
"rev": 1,
"signature": "INSPECTED at ap-northeast-1 - ICMP",
"action": "allowed",
"category": ""
},
"flow_id": 1697923412587795,
"dest_ip": "10.23.1.203",
"proto": "ICMP",
"verdict": {
"action": "pass"
},
"icmp_code": 0,
"pkt_src": "geneve encapsulation",
"timestamp": "2026-07-28T07:43:18.067648+0000",
"direction": "to_server"
}
}
意図した挙動です。
ap-northeast-1a からインターネットへの疎通確認
次に、ap-northeast-1aのEC2インスタンスからインターネットに抜ける通信です。
$ curl http://checkip.amazonaws.com
54.178.136.55
$ for i in $(seq 20); do \
curl -s --no-keepalive http://checkip.amazonaws.com;
done | \
sort | \
uniq -c
20 54.178.136.55
返ってきたIPアドレスはap-northeast-1のInspection VPCにおける、ap-northeast-1aのNAT GatewayのEIPです。
こちらも意図した挙動です。
us-east-1 / ap-northeast-3 からインターネットへの疎通確認
他のNFGアタッチメントがあるリージョンについても同様の確認をします。
$ hostname -i
10.1.0.8
$ curl http://checkip.amazonaws.com
34.239.224.122
$ hostname -i
10.31.0.196
$ curl http://checkip.amazonaws.com
16.208.55.199
いずれも同一リージョン、同一AZのNAT GatewayのEIPが返ってきました。リージョンおよびAZにアフィニティがあることが分かりますね。
us-west-2 / ap-southeast-1 からインターネットへの疎通確認
続いて、NFGアタッチメントが存在しないリージョンのEC2インスタンスからへのインターネットへの疎通確認です。
$ hostname -i
10.11.0.57
$ while true; do
echo "$(date '+%Y/%m/%d %H:%M:%S') - $(curl -s --no-keepalive http://checkip.amazonaws.com)"
sleep 1
done
2026/07/28 07:56:29 - 100.59.128.13
2026/07/28 07:56:30 - 100.59.128.13
2026/07/28 07:56:31 - 34.239.224.122
2026/07/28 07:56:32 - 100.59.128.13
2026/07/28 07:56:33 - 100.59.128.13
2026/07/28 07:56:34 - 100.59.128.13
2026/07/28 07:56:36 - 34.239.224.122
^C
$ for i in $(seq 20); do \
curl -s --no-keepalive http://checkip.amazonaws.com;
done | \
sort | \
uniq -c
9 100.59.128.13
11 34.239.224.122
$ hostname -i
10.41.0.28
$ while true; do
echo "$(date '+%Y/%m/%d %H:%M:%S') - $(curl -s --no-keepalive http://checkip.amazonaws.com)"
sleep 1
done
2026/07/28 07:57:55 - 54.178.136.55
2026/07/28 07:57:57 - 13.115.181.227
2026/07/28 07:57:58 - 54.178.136.55
2026/07/28 07:57:59 - 13.115.181.227
2026/07/28 07:58:01 - 54.178.136.55
2026/07/28 07:58:02 - 13.115.181.227
2026/07/28 07:58:03 - 54.178.136.55
^C
$ for i in $(seq 20); do \
curl -s --no-keepalive http://checkip.amazonaws.com;
done | \
sort | \
uniq -c
7 13.115.181.227
13 54.178.136.55
us-west-2aのEC2インスタンスからの通信はus-east-1の両AZのNAT GatewayのEIP、ap-southeast-1aのEC2インスタンスからの通信は、ap-northeast-1の両AZのNAT GatewayのEIPが返ってきていることが分かります。セグメントの各リージョンで定義されているルート情報と一致していますね。
また、複数のアドレスが返ってきていることから別リージョンからルーティングされてきた通信については特にAZアフィニティはないようですね。
定期実行の起動と平常動作
ExecutionStoppedAlarm がアラーム状態であることの確認
オーケストレーターのStep Functionsの定期実行をするEventBridge Schedulerは無効化しています。
これはAWS CDKでデプロイする過程でまだ各リソースの準備が整っていない状態で実行をして、ルートテーブルやCore Network Policyが意図しない状況にならないようにしています。
とはいえ、運用中にこのEventBridge Schedulerが無効化されているとよろしくないため、専用のCloudWatch Alarmを用意しています。
CloudWatch Alarmを確認すると、確かに以下のようにアラーム状態となっています。
EventBridge Scheduler有効化
EventBridge Schedulerの有効化を行います。
有効化はマネジメントコンソールから行いました。
Step Functions の実行確認
Step Functionsが3分ごとに実行されていることを確認します。
確かに3分間隔で実行されていますね。
実行計画を確認すると、意図した通り遷移していますね。
ダッシュボードの確認
用意したCloudWatchダッシュボードを確認しましょう。
はい、良い感じに表示されていますね。インターネットへの接続確認のパネルを確認すると、全AZのLambda関数が正常に疎通できているものと判断できます。
また、何かしらの不具合が発生した場合は上部のCloudWatch Alarmおよび各種メトリクスで素早く把握できるようにしています。
他にはCore Network EdgeやNAT Gatewayごとの流量やNAT Gatewayのポート割り当て失敗、接続失敗数なども把握できるようにしています。集約する仕組みを作ると集約した箇所がサチっていないかの把握は非常に重要です。
AZ障害時の挙動 (ap-northeast-1a)
ap-northeast-1a の Cloud WAN アタッチメントサブネット Route Table の 0.0.0.0/0 のターゲットを IGWに変更
AZ障害時の挙動を確認します。
今回はap-northeast-1のInspection VPCにおいて、ap-northeast-1a の Cloud WAN アタッチメントサブネット Route Table にて 0.0.0.0/0 のターゲットを ap-northeast-1aのFirewall EndpointからIGWに変更します。
これにより、こちらのInspection VPCのap-northeast-1aのCloud WAN アタッチメントのENIに着信したトラフィックは全てIGWにルーティングされてしまい、NATもされていないためIGWでドロップします。
変更後は以下のようになります。
Step Functions の経路確認
変更をした後に定期実行されたStep Functionsを確認します。
実行結果を眺めていると、以下のように正常に実行完了しました。
グラフビューの様子から平常時と変わって、時間を空けて2回疎通確認が失敗したものからルート切り替えの処理が走っていますね。
実行完了までは2分16秒でした。3分間隔で定期実行しているのでAZ障害時のRTOは5分強とも言えます。
この時のap-northeast-1aのLambda関数は以下のようなEMFログを出力しています。
全ての接続先でタイムアウトエラーになっていますね。
ちなみに次回スケジュールで動作したStep Functionsの実行結果は以下のとおりです。
平常時と同じですね。その後の実行時は特に問題なく疎通に成功しています。つまりはフラッピングは発生していません。
ap-northeast-1a の Cloud WAN アタッチメントサブネット Route Table の確認
それでは、先ほどターゲットをIGWに変更をしたルートテーブルを確認してみましょう。
すると、以下のようにデフォルトゲートウェイがap-northeast-1cのFirewall Endpointに切り替わっています。
これにより、Inspection VPCのap-northeast-1aのCloud WAN アタッチメントのENIに着信したトラフィックは全てap-northeast-1cのFirewall Endpointにルーティングされます。
Core Network Policyが変わっていないことの確認
AZ障害レベルでGlobal Networkの挙動を更新する必要はありません。
念の為、Core Network Policyが変わっていないことを確認します。
バージョンは1つしかありませんね。
ダッシュボードの確認
この時のダッシュボードを確認してみましょう。
オーケストレーターSfnによる操作パネルにてReplaceRouteDoneのメトリクスが付いたタイミングで以下のような事象が発生しています。
unhealthy probeにて、ap-northeast-1/apne1-az4のメトリクスが常時1のところ、2を指すインターネットへの疎通結果にて、ap-northeast-1/apne1-az4のメトリクスが常時1のところ、0を指すStep Functions実行時間にて、ExecutionTimeが常時1secのところ1.2minを指す疎通レイテンシにて、ap-northeast-1/apne1-az4のメトリクスが途切れる
ap-northeast-1 の VPC 間の疎通確認 (同一AZ / 別AZ)
実際に通信をしてみましょう。
先ほどと同様にap-northeast-1aのEC2インスタンスから、同一リージョンの同一AZ / 別AZ間の通信をしてみます。
$ hostname -i
10.21.0.53
# 同一AZ
$ ping -c 4 10.23.0.70
PING 10.23.0.70 (10.23.0.70) 56(84) bytes of data.
64 bytes from 10.23.0.70: icmp_seq=1 ttl=123 time=6.34 ms
64 bytes from 10.23.0.70: icmp_seq=2 ttl=123 time=4.63 ms
64 bytes from 10.23.0.70: icmp_seq=3 ttl=123 time=4.63 ms
64 bytes from 10.23.0.70: icmp_seq=4 ttl=123 time=4.63 ms
--- 10.23.0.70 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 4.628/5.057/6.343/0.742 ms
# 別AZ
$ ping -c 4 10.23.1.203
PING 10.23.1.203 (10.23.1.203) 56(84) bytes of data.
64 bytes from 10.23.1.203: icmp_seq=1 ttl=123 time=5.77 ms
64 bytes from 10.23.1.203: icmp_seq=2 ttl=123 time=4.49 ms
64 bytes from 10.23.1.203: icmp_seq=3 ttl=123 time=4.51 ms
64 bytes from 10.23.1.203: icmp_seq=4 ttl=123 time=4.46 ms
--- 10.23.1.203 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 4.463/4.806/5.765/0.553 ms
問題なく通信できました。しかし、同一AZの際平均RTT 2.322 msだったところ、5.057となっていました。別AZのFirewall Endpointを経由する分AZ間のレイテンシーが影響しているようですね。
この時のNetwork Firewallのログは以下のとおりです。
# 同一AZ
{
"firewall_name": "NfgFnVpcDB445E37-Nfw",
"availability_zone": "ap-northeast-1c",
"event_timestamp": "1785227780",
"event": {
"icmp_type": 8,
"aws_category": "",
"ip_v": 4,
"src_ip": "10.21.0.53",
"event_type": "alert",
"alert": {
"severity": 3,
"signature_id": 2000001,
"rev": 1,
"signature": "INSPECTED at ap-northeast-1 - ICMP",
"action": "allowed",
"category": ""
},
"flow_id": 1289509730366591,
"dest_ip": "10.23.0.70",
"proto": "ICMP",
"verdict": {
"action": "pass"
},
"icmp_code": 0,
"pkt_src": "geneve encapsulation",
"timestamp": "2026-07-28T08:36:20.038093+0000",
"direction": "to_server"
}
}
# 別AZ
{
"firewall_name": "NfgFnVpcDB445E37-Nfw",
"availability_zone": "ap-northeast-1c",
"event_timestamp": "1785227790",
"event": {
"icmp_type": 8,
"aws_category": "",
"ip_v": 4,
"src_ip": "10.21.0.53",
"event_type": "alert",
"alert": {
"severity": 3,
"signature_id": 2000001,
"rev": 1,
"signature": "INSPECTED at ap-northeast-1 - ICMP",
"action": "allowed",
"category": ""
},
"flow_id": 1867314647906589,
"dest_ip": "10.23.1.203",
"proto": "ICMP",
"verdict": {
"action": "pass"
},
"icmp_code": 0,
"pkt_src": "geneve encapsulation",
"timestamp": "2026-07-28T08:36:30.762448+0000",
"direction": "to_server"
}
}
ap-northeast-1a間の通信であってもap-northeast-1cのFirewall Endpointを通っていることが分かりますね。
ap-northeast-1aからインターネットへの疎通確認
次にap-northeast-1aのEC2インスタンスからインターネットへの通信をしてみます。
$ hostname -i
10.21.0.53
$ curl http://checkip.amazonaws.com
13.115.181.227
$ for i in $(seq 20); do \
curl -s --no-keepalive http://checkip.amazonaws.com;
done | \
sort | \
uniq -c
20 13.115.181.227
はい、こちらはいずれもap-northeast-1cのNAT GatewayのEIPが返ってきました。
リージョン障害時の挙動 (ap-northeast-1)
ap-northeast-1 の両AZの Cloud WAN アタッチメントサブネット Route Table の 0.0.0.0/0 のターゲットを IGWに変更
目的: 両 AZ の検査経路を喪失させ「リージョン障害」と判定させる。両方壊すため
ReplaceRoute は発動しない (生存 AZ がない) ことも暗黙に確認される
このタイミングで不通になる
それでは、リージョン障害時の相当の挙動の確認をします。
AZ障害相当の場合と同様に、ap-northeast-1 の両AZの Cloud WAN アタッチメントサブネット Route Table の 0.0.0.0/0 のターゲットを IGWに変更します。
これにより、ap-northeast-1のInspection VPCにルーティングしたら最後、IGWでドロップしてしまいます。
ターゲットを IGWに変更したタイミングで以下のようにap-northeast-1からの通信は全て不通になりました。
$ ping -c 4 10.23.0.70
PING 10.23.0.70 (10.23.0.70) 56(84) bytes of data.
--- 10.23.0.70 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3111ms
$ ping -c 4 10.23.1.203
PING 10.23.1.203 (10.23.1.203) 56(84) bytes of data.
--- 10.23.1.203 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3156ms
$ curl http://checkip.amazonaws.com -m 2 -v
* Host checkip.amazonaws.com:80 was resolved.
* IPv6: (none)
* IPv4: 18.140.127.52, 54.251.56.155, 54.251.8.68, 47.131.179.185, 52.74.205.157, 13.250.156.183, 54.254.169.246, 18.138.193.90
* Trying 18.140.127.52:80...
* Trying 54.251.56.155:80...
* Trying 54.251.8.68:80...
* Trying 47.131.179.185:80...
* Trying 52.74.205.157:80...
* Trying 13.250.156.183:80...
* Trying 54.254.169.246:80...
* Trying 18.138.193.90:80...
* Connection timed out after 2001 milliseconds
* closing connection #0
curl: (28) Connection timed out after 2001 milliseconds
また、ap-northeast-1のInspection VPCにルーティングするようにされていた、ap-southeast-1のEC2インスタンスでも不通となりました。
$ hostname -i
10.41.0.28
$ curl http://checkip.amazonaws.com -m 2 -v
* Host checkip.amazonaws.com:80 was resolved.
* IPv6: (none)
* IPv4: 18.140.127.52, 47.131.179.185, 18.138.193.90, 13.250.156.183, 54.251.8.68, 13.229.177.142, 52.74.205.157, 54.254.169.246
* Trying 18.140.127.52:80...
* Trying 47.131.179.185:80...
* Trying 18.138.193.90:80...
* Trying 13.250.156.183:80...
* Trying 54.251.8.68:80...
* Trying 13.229.177.142:80...
* Trying 52.74.205.157:80...
* Trying 54.254.169.246:80...
* Connection timed out after 2001 milliseconds
* closing connection #0
curl: (28) Connection timed out after 2001 milliseconds
Step Functionsの動作の確認
しばらく待つとStep Functionsが動作していました。
Inspection VPCのルートの変更は発生せず、右側のCore Network Policyの更新処理が走っていることが分かります。
また、実行時間は9分16秒でした。3分間隔でこの処理は実行されるため、リージョン障害時のRTOは12分強とも言えます。
なお、9分間実行されている間もEventBridge Schedulerを元に3分ごとにStep Functionsは実行されています。
Core Network Policyの更新処理が既に走っている場合、再度更新処理をかけるのはよろしくありません。状況が混乱してしまい、意図しないポリシーを適用する可能性があります。そのため、そのような場合は新たなCore Network Policyに対する処理はスキップします。
ちなみに、前の処理でCore Network Policyの更新処理が走っている場合のStep Functionsの実行時間は2分10秒でした。
Core Network Policyと各セグメントのルートの確認
Core Network Policy更新処理後の状況を確認します。
確かにCore Network Policyの更新がなされていますね。
Core Network Policyの内容は以下のとおりです。
各セグメントのルート情報は以下のとおりです。
障害パターンの整理で紹介したものと一致していることが分かります。
具体的には以下のような変化があります。
| EDGE | CIDR | CIDR の所属リージョン | 平常時 next-hop | ap-northeast-1ダウン時 next-hop |
|---|---|---|---|---|
| ap-northeast-1 | 0.0.0.0/0 | ー | ap-northeast-1/INSPECTION | ap-northeast-3/INSPECTION |
| ap-northeast-1 | 10.11.0.0/16 | us-west-2 | ap-northeast-1/INSPECTION | us-east-1/INSPECTION |
| ap-northeast-1 | 10.13.0.0/16 | us-west-2 | ap-northeast-1/INSPECTION | us-east-1/INSPECTION |
| ap-northeast-1 | 10.21.0.0/16 | ap-northeast-1 | ap-northeast-1/INSPECTION | ap-northeast-3/INSPECTION |
| ap-northeast-1 | 10.22.0.0/16 | ap-northeast-1 | ap-northeast-1/INSPECTION | ap-northeast-3/INSPECTION |
| ap-northeast-1 | 10.23.0.0/16 | ap-northeast-1 | ap-northeast-1/INSPECTION | ap-northeast-3/INSPECTION |
| ap-northeast-1 | 10.31.0.0/16 | ap-northeast-3 | ap-northeast-1/INSPECTION | ap-northeast-3/INSPECTION |
| ap-northeast-1 | 10.32.0.0/16 | ap-northeast-3 | ap-northeast-1/INSPECTION | ap-northeast-3/INSPECTION |
| ap-northeast-1 | 10.33.0.0/16 | ap-northeast-3 | ap-northeast-1/INSPECTION | ap-northeast-3/INSPECTION |
| ap-northeast-1 | 10.41.0.0/16 | ap-southeast-1 | ap-northeast-1/INSPECTION | ap-northeast-3/INSPECTION |
| ap-northeast-1 | 10.43.0.0/16 | ap-southeast-1 | ap-northeast-1/INSPECTION | ap-northeast-3/INSPECTION |
| ap-northeast-3 | 10.21.0.0/16 | ap-northeast-1 | ap-northeast-1/INSPECTION | ap-northeast-3/INSPECTION |
| ap-northeast-3 | 10.22.0.0/16 | ap-northeast-1 | ap-northeast-1/INSPECTION | ap-northeast-3/INSPECTION |
| ap-northeast-3 | 10.23.0.0/16 | ap-northeast-1 | ap-northeast-1/INSPECTION | ap-northeast-3/INSPECTION |
| ap-southeast-1 | 0.0.0.0/0 | ー | ap-northeast-1/INSPECTION | ap-northeast-3/INSPECTION |
| ap-southeast-1 | 10.21.0.0/16 | ap-northeast-1 | ap-northeast-1/INSPECTION | ap-northeast-3/INSPECTION |
| ap-southeast-1 | 10.22.0.0/16 | ap-northeast-1 | ap-northeast-1/INSPECTION | ap-northeast-3/INSPECTION |
| ap-southeast-1 | 10.23.0.0/16 | ap-northeast-1 | ap-northeast-1/INSPECTION | ap-northeast-3/INSPECTION |
| ap-southeast-1 | 10.41.0.0/16 | ap-southeast-1 | ap-northeast-1/INSPECTION | ap-northeast-3/INSPECTION |
| ap-southeast-1 | 10.43.0.0/16 | ap-southeast-1 | ap-northeast-1/INSPECTION | ap-northeast-3/INSPECTION |
| us-west-2 | 10.21.0.0/16 | ap-northeast-1 | ap-northeast-1/INSPECTION | us-east-1/INSPECTION |
| us-west-2 | 10.22.0.0/16 | ap-northeast-1 | ap-northeast-1/INSPECTION | us-east-1/INSPECTION |
| us-west-2 | 10.23.0.0/16 | ap-northeast-1 | ap-northeast-1/INSPECTION | us-east-1/INSPECTION |
個人的にはsend-viaアクションにおいて、以下でap-northeast-1が複数のエントリでedge-setsとして指定されているような場合にどのエントリのuse-edge-locationが使用されるのか気になっていました。
考えられるパターンとしては以下です。
- どれか一つのエントリのみが適用される
- 上述の例ではap-northeast-1の通信は通信先のリージョンに関わらず、必ず us-east-1 もしくは ap-northeast-3 のどちらか一方を利用する
edge-setsの組み合わせごとに適用される- 上述の例では
edge-setsで定義されているap-northeast-1の通信先である us-east-1 もしくは ap-northeast-3 ごとに、ネクストホップを us-east-1 / ap-northeast-3 で切り替える
- 上述の例では
今回は後者になります。これはAWS公式ドキュメントでは読み取れない挙動なので明らかになってよかったです。
ダッシュボードの確認
ダッシュボードの確認をしましょう。
オーケストレーターSfnによる操作パネルにてPutPolicyのメトリクスが付いたタイミングで以下のような事象が発生しています。
tier 2接続先利用回数にて、--だったところが10を指すunhealthy probeにて、ap-northeast-1/apne1-az4のメトリクスが常時1のところ、2を指すオーケストレーターSFnの実行結果にて、stateがPutPolicyおよびFailoverDoneのログが流れる直近のPutPolicyにて、ログが表示されるインターネットへの疎通結果にて、ap-northeast-1/apne1-az4のメトリクスが常時1のところ、0を指す疎通レイテンシにて、ap-northeast-1/apne1-az4のメトリクスが途切れるPutPolicyが発生したことを知らすCloudWatch Alarmがアラーム状態になる
ap-northeast-1のヘルスチェックLambda関数の状態を確認するCloudWatch Alarmはアラーム状態になっていません。これは不通だった時間が短くアラート条件を満たしていないためです。
Cloud WANのイベントは以下の以下のとおりでCore Network Policy更新の過程でap-northeast-1においてルートがアンインストールされていることが分かります。
ap-northeast-1 の VPC 間の疎通確認 (同一AZ / 別AZ)
疎通確認をしましょう。
ap-northeast-1のVPC間通信において、同一AZおよび別AZで疎通確認をします。
$ hostname -i
10.21.0.53
# 同一AZ
$ ping -c 4 10.23.0.70
PING 10.23.0.70 (10.23.0.70) 56(84) bytes of data.
64 bytes from 10.23.0.70: icmp_seq=1 ttl=121 time=22.8 ms
64 bytes from 10.23.0.70: icmp_seq=2 ttl=121 time=21.1 ms
64 bytes from 10.23.0.70: icmp_seq=3 ttl=121 time=21.0 ms
64 bytes from 10.23.0.70: icmp_seq=4 ttl=121 time=21.1 ms
--- 10.23.0.70 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 21.042/21.531/22.826/0.748 ms
# 別AZ
$ ping -c 4 10.23.1.203
PING 10.23.1.203 (10.23.1.203) 56(84) bytes of data.
64 bytes from 10.23.1.203: icmp_seq=1 ttl=121 time=23.2 ms
64 bytes from 10.23.1.203: icmp_seq=2 ttl=121 time=20.1 ms
64 bytes from 10.23.1.203: icmp_seq=3 ttl=121 time=20.2 ms
64 bytes from 10.23.1.203: icmp_seq=4 ttl=121 time=20.3 ms
--- 10.23.1.203 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 20.129/20.929/23.166/1.291 ms
問題なく通信はできていますね。
rttの平均は同一AZ / 別AZであってもさほど変わりないですね。
Network Firewallのログを確認すると、Cloud WANのルートテーブルで確認したとおり、ap-northeast-3にルーティングされていることが分かります。
# 同一AZ
{
"firewall_name": "NfgFnVpcD061B805-Nfw",
"availability_zone": "ap-northeast-3b",
"event_timestamp": "1785229386",
"event": {
"icmp_type": 8,
"aws_category": "",
"ip_v": 4,
"src_ip": "10.21.0.53",
"event_type": "alert",
"alert": {
"severity": 3,
"signature_id": 2000001,
"rev": 1,
"signature": "INSPECTED at ap-northeast-3 - ICMP",
"action": "allowed",
"category": ""
},
"flow_id": 731717449533722,
"dest_ip": "10.23.0.70",
"proto": "ICMP",
"verdict": {
"action": "pass"
},
"icmp_code": 0,
"pkt_src": "geneve encapsulation",
"timestamp": "2026-07-28T09:03:06.235902+0000",
"direction": "to_server"
}
}
# 別AZ
{
"firewall_name": "NfgFnVpcD061B805-Nfw",
"availability_zone": "ap-northeast-3b",
"event_timestamp": "1785229392",
"event": {
"icmp_type": 8,
"aws_category": "",
"ip_v": 4,
"src_ip": "10.21.0.53",
"event_type": "alert",
"alert": {
"severity": 3,
"signature_id": 2000001,
"rev": 1,
"signature": "INSPECTED at ap-northeast-3 - ICMP",
"action": "allowed",
"category": ""
},
"flow_id": 242963522542686,
"dest_ip": "10.23.1.203",
"proto": "ICMP",
"verdict": {
"action": "pass"
},
"icmp_code": 0,
"pkt_src": "geneve encapsulation",
"timestamp": "2026-07-28T09:03:12.974073+0000",
"direction": "to_server"
}
}
ap-northeast-1からインターネットへの疎通確認
続いて、ap-northeast-1からインターネットへの疎通確認です。
ap-northeast-1aのEC2インスタンスからhttp://checkip.amazonaws.comにアクセスします。
$ for i in $(seq 20); do \
curl -s --no-keepalive http://checkip.amazonaws.com;
done | \
sort | \
uniq -c
16 15.168.232.53
4 16.208.55.199
15.168.232.53と16.208.55.199が返ってきました。こちらはap-northeast-3のInspection VPCで動作しているNAT Gatewayに割り当てられているEIPです。
Core Network Policyに従ってルーティングされていますね。
ap-southeast-1からインターネット
同様にap-southeast-1aのEC2インスタンスからhttp://checkip.amazonaws.comにアクセスします。
$ hostname -i
10.41.0.28
$ for i in $(seq 20); do \
curl -s --no-keepalive http://checkip.amazonaws.com;
done | \
sort | \
uniq -c
10 15.168.232.53
10 16.208.55.199
先ほどと同じく、ap-northeast-3のInspection VPCで動作しているNAT Gatewayに割り当てられているEIPが返ってきました。
us-west-2からインターネット
同様にus-west-2aのEC2インスタンスからhttp://checkip.amazonaws.comにアクセスします。
$ hostname -i
10.11.0.57
$ for i in $(seq 20); do \
curl -s --no-keepalive http://checkip.amazonaws.com;
done | \
sort | \
uniq -c
10 100.59.128.13
10 34.239.224.122
こちらは変わらず、us-east-1のInspection VPCで動作しているNAT Gatewayに割り当てられているEIPが返ってきました。
リージョン障害が追加で発生した場合の挙動
さらに ap-northeast-3 の両AZの Cloud WAN アタッチメントサブネット Route Table の 0.0.0.0/0 のターゲットを IGWに変更
リージョン障害が追加で発生した場合のシナリオも確認しましょう。
ap-northeast-3 の両AZの Cloud WAN アタッチメントサブネット Route Table の 0.0.0.0/0 のターゲットを IGWに変更します。
ターゲットを IGWに変更したタイミングで、Core Network Policyが変更後は通信できていたものが、以下のようにap-northeast-1からの通信は全て不通になりました。
$ ping -c 4 10.23.0.70
PING 10.23.0.70 (10.23.0.70) 56(84) bytes of data.
--- 10.23.0.70 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3131ms
$ ping -c 4 10.23.1.203
PING 10.23.1.203 (10.23.1.203) 56(84) bytes of data.
--- 10.23.1.203 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3152ms
$ curl http://checkip.amazonaws.com -m 2 -v
* Host checkip.amazonaws.com:80 was resolved.
* IPv6: (none)
* IPv4: 18.138.193.90, 54.251.56.155, 13.250.156.183, 18.140.127.52, 54.251.8.68, 54.254.169.246, 52.74.205.157, 13.229.177.142
* Trying 18.138.193.90:80...
* Trying 54.251.56.155:80...
* Trying 13.250.156.183:80...
* Trying 18.140.127.52:80...
* Trying 54.251.8.68:80...
* Trying 54.254.169.246:80...
* Trying 52.74.205.157:80...
* Trying 13.229.177.142:80...
* Connection timed out after 2001 milliseconds
* closing connection #0
curl: (28) Connection timed out after 2001 milliseconds
ap-northeast-3aのEC2インスタンスからのインターネットへの疎通も通らなくなりました。
$ hostname -i
10.31.0.196
$ curl http://checkip.amazonaws.com -m 2 -v
* Host checkip.amazonaws.com:80 was resolved.
* IPv6: (none)
* IPv4: 52.74.205.157, 18.138.193.90, 13.229.177.142, 54.251.56.155, 18.140.127.52, 13.250.156.183, 54.251.8.68, 47.131.179.185
* Trying 52.74.205.157:80...
* Trying 18.138.193.90:80...
* Trying 13.229.177.142:80...
* Trying 54.251.56.155:80...
* Trying 18.140.127.52:80...
* Trying 13.250.156.183:80...
* Trying 54.251.8.68:80...
* Trying 47.131.179.185:80...
* Connection timed out after 2001 milliseconds
* closing connection #0
curl: (28) Connection timed out after 2001 milliseconds
意図したとおり、ap-northeast-3のInspection VPCを介した通信が軒並みダウンしているようです。
Step Functionsの動作の確認
しばらく待つと定期実行されているStep Functionsで追加のリージョン障害を拾っていました。
この時の実行結果は以下のとおりです。
実行時間は8分26秒と先ほどとさほど変わりありません。
Core Network Policy更新中のStep Functionsの実行は以下のとおりです。
フラッピングのような挙動はしておらず、Core Network Policyの更新処理はスキップされています。
Core Network Policyと各セグメントのルートの確認
Core Network Policy更新処理後の状況を確認します。
Core Network Policyの更新がされています。
Core Network Policyの内容は以下のとおりです。
各セグメントのルート情報は以下のとおりです。
障害パターンの整理で紹介したものと一致していることが分かります。
簡単に言うと、全ての通信のネクストホップがus-east-1のInspection VPCになっています。こちら以外のリージョンのInspection VPCはダウンしている判定であるため、このような結果になっています。
ダッシュボードの確認
ダッシュボードを確認します。
先ほどap-northeast-1のみのリージョン障害相当のシナリオと同様の変化が発生しています。
ちなみに、NAT Gatewayへの接続を確立しているのはus-east-1のもののみです。Core Network Policyが更新されて、他リージョンのNAT Gatewayにルーティングされることはないため、当然の結果です。
関連して、疎通確認用Lambda関数が疎通確認をするときのレイテンシーがus-east-1を除いて非常に大きくなっています。これはインターネットに出る際はus-east-1のInspection VPCのNAT Gatewayを経由することによるネットワークレイテンシー増加です。
リージョン障害から12分ほどで通信復旧はできてもパフォーマンスは落ちる点には気をつけましょう。
ap-northeast-1 の VPC 間およびインターネットへの疎通確認
疎通確認をします。
まず、ap-northeast-1 の VPC 間およびインターネットへの疎通確認を行います。
ap-northeast-1aのEC2インスタンスから操作します。
$ hostname -i
10.21.0.53
# 同一AZ
$ ping -c 4 10.23.0.70
PING 10.23.0.70 (10.23.0.70) 56(84) bytes of data.
64 bytes from 10.23.0.70: icmp_seq=1 ttl=121 time=302 ms
64 bytes from 10.23.0.70: icmp_seq=2 ttl=121 time=299 ms
64 bytes from 10.23.0.70: icmp_seq=3 ttl=121 time=299 ms
64 bytes from 10.23.0.70: icmp_seq=4 ttl=121 time=299 ms
--- 10.23.0.70 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3001ms
rtt min/avg/max/mdev = 298.824/299.664/302.143/1.431 ms
# 別AZ
$ ping -c 4 10.23.1.203
PING 10.23.1.203 (10.23.1.203) 56(84) bytes of data.
64 bytes from 10.23.1.203: icmp_seq=1 ttl=121 time=307 ms
64 bytes from 10.23.1.203: icmp_seq=2 ttl=121 time=303 ms
64 bytes from 10.23.1.203: icmp_seq=3 ttl=121 time=303 ms
64 bytes from 10.23.1.203: icmp_seq=4 ttl=121 time=303 ms
--- 10.23.1.203 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 303.347/304.391/307.411/1.743 ms
# インターネット
$ for i in $(seq 20); do \
curl -s --no-keepalive http://checkip.amazonaws.com;
done | \
sort | \
uniq -c
10 100.59.128.13
10 34.239.224.122
VPC間の通信について、同一AZ / 別AZのpingのrttがap-northeast-3を経由する時がどちらも21 msほどだったのに比べ、us-east-1を経由する場合は300 msほどと大幅に悪化していることが分かります。
また、http://checkip.amazonaws.comのレスポンスのIPアドレスはいずれもus-east-1のInspection VPC上で動作しているNAT GatewayのEIPです。
us-west-2 のインターネットへの疎通確認
次にus-west-2 のインターネットへの疎通確認です。
us-west-2aのEC2インスタンスから操作をします。
$ hostname -i
10.11.0.57
$ for i in $(seq 20); do \
curl -s --no-keepalive http://checkip.amazonaws.com;
done | \
sort | \
uniq -c
11 100.59.128.13
9 34.239.224.122
こちらは変わらず、us-east-1のInspection VPC上で動作しているNAT GatewayのEIPです。
us-east-1 の VPC 間の疎通確認 (同一AZ / 別AZ)
次にus-east-1のVPC間の疎通確認をします。
us-east-1aのEC2インスタンスから同一AZ / 別AZのEC2インスタンスに対してpingを叩きます。
$ hostname -i
10.1.0.8
# 同一AZ
$ ping -c 4 10.3.0.60
PING 10.3.0.60 (10.3.0.60) 56(84) bytes of data.
64 bytes from 10.3.0.60: icmp_seq=1 ttl=123 time=4.11 ms
64 bytes from 10.3.0.60: icmp_seq=2 ttl=123 time=1.96 ms
64 bytes from 10.3.0.60: icmp_seq=3 ttl=123 time=1.98 ms
64 bytes from 10.3.0.60: icmp_seq=4 ttl=123 time=2.04 ms
--- 10.3.0.60 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 1.963/2.522/4.105/0.914 ms
# 別AZ
$ ping -c 4 10.3.1.230
PING 10.3.1.230 (10.3.1.230) 56(84) bytes of data.
64 bytes from 10.3.1.230: icmp_seq=1 ttl=123 time=4.84 ms
64 bytes from 10.3.1.230: icmp_seq=2 ttl=123 time=2.07 ms
64 bytes from 10.3.1.230: icmp_seq=3 ttl=123 time=2.07 ms
64 bytes from 10.3.1.230: icmp_seq=4 ttl=123 time=2.08 ms
--- 10.3.1.230 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 2.065/2.764/4.843/1.200 ms
試行回数が4回なので分かりづらいですが、同一AZの方がわずかながらrttが小さいですね。
この時のNetwork Firewallのアラートログは以下のとおりです。
# 同一AZ
{
"firewall_name": "NfgFnVpcB0EAED89-Nfw",
"availability_zone": "us-east-1a",
"event_timestamp": "1785232048",
"event": {
"icmp_type": 8,
"aws_category": "",
"ip_v": 4,
"src_ip": "10.1.0.8",
"event_type": "alert",
"alert": {
"severity": 3,
"signature_id": 2000001,
"rev": 1,
"signature": "INSPECTED at us-east-1 - ICMP",
"action": "allowed",
"category": ""
},
"flow_id": 10674760536434,
"dest_ip": "10.3.0.60",
"proto": "ICMP",
"verdict": {
"action": "pass"
},
"icmp_code": 0,
"pkt_src": "geneve encapsulation",
"timestamp": "2026-07-28T09:47:28.264629+0000",
"direction": "to_server"
}
}
{
"firewall_name": "NfgFnVpcB0EAED89-Nfw",
"availability_zone": "us-east-1b",
"event_timestamp": "1785232059",
"event": {
"icmp_type": 8,
"aws_category": "",
"ip_v": 4,
"src_ip": "10.1.0.8",
"event_type": "alert",
"alert": {
"severity": 3,
"signature_id": 2000001,
"rev": 1,
"signature": "INSPECTED at us-east-1 - ICMP",
"action": "allowed",
"category": ""
},
"flow_id": 1034520512569046,
"dest_ip": "10.3.1.230",
"proto": "ICMP",
"verdict": {
"action": "pass"
},
"icmp_code": 0,
"pkt_src": "geneve encapsulation",
"timestamp": "2026-07-28T09:47:39.371940+0000",
"direction": "to_server"
}
}
us-east-1 の インターネットへの疎通確認
次にus-east-1aのEC2インスタンスからインターネットへの疎通確認です。
$ hostname -i
10.1.0.8
$ for i in $(seq 20); do \
curl -s --no-keepalive http://checkip.amazonaws.com;
done | \
sort | \
uniq -c
20 34.239.224.122
us-east-1のInspection VPC上で動作しているus-east-1aのNAT GatewayのEIPです。AZアフィニティがあることが分かります。
us-east-1 の ap-northeast-1の VPC 疎通確認
クロスリージョンのVPC間の通信も試してみましょう。
us-east-1aのEc2インスタンスからap-northeast-1a / ap-northeast-1cのEC2インスタンスへpingを打ちます。
$ hostname -i
10.1.0.8
# ap-northeast-1aのEC2インスタンス間
$ ping -c 4 10.21.0.53
PING 10.21.0.53 (10.21.0.53) 56(84) bytes of data.
64 bytes from 10.21.0.53: icmp_seq=1 ttl=122 time=155 ms
64 bytes from 10.21.0.53: icmp_seq=2 ttl=122 time=152 ms
64 bytes from 10.21.0.53: icmp_seq=3 ttl=122 time=152 ms
64 bytes from 10.21.0.53: icmp_seq=4 ttl=122 time=152 ms
--- 10.21.0.53 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 151.844/152.707/155.273/1.481 ms
# ap-northeast-1cのEC2インスタンス間
$ ping -c 4 10.23.0.70
PING 10.23.0.70 (10.23.0.70) 56(84) bytes of data.
64 bytes from 10.23.0.70: icmp_seq=1 ttl=122 time=152 ms
64 bytes from 10.23.0.70: icmp_seq=2 ttl=122 time=149 ms
64 bytes from 10.23.0.70: icmp_seq=3 ttl=122 time=149 ms
64 bytes from 10.23.0.70: icmp_seq=4 ttl=122 time=149 ms
--- 10.23.0.70 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3001ms
rtt min/avg/max/mdev = 149.411/150.127/152.192/1.192 ms
はい、問題なく通信できました。
NFGアタッチメントがあるリージョンが全てダウンした場合の挙動
さらに us-east-1 の両AZの Cloud WAN アタッチメントサブネット Route Table の 0.0.0.0/0 のターゲットを IGWに変更
NFGアタッチメントがあるリージョンが全てダウンした場合の挙動を確認します。
今までと同様に、us-east-1 の両AZの Cloud WAN アタッチメントサブネット Route Table の 0.0.0.0/0 のターゲットを IGWに変更します。
Step Functionsの動作とダッシュボードの確認
変更してしばらくすると、スケジュール実行によりStep Functionsが動作しました。
この時の実行結果は以下のとおりです。
はい、Core NEtwork Policyの更新はされずFailCloseステートに遷移していますね。
全リージョンで生きているNFGアタッチメントがないと判断した場合、適切なCore Network Policyの遷移先がないためこのような挙動にしています。
自動復旧できる範疇を超えているため、管理者に素早く検知してもらえるようにFail Closeとなるとアラーム状態になるCloudWatchアラームを用意しています。
この時のダッシュボードは以下のとおりです。
インターネットへの疎通確認パネルで全てのメトリクスが0になっていることから、全てのAZのLambda関数からインターネットに出ることができていない事が分かります。
15分間疎通に失敗しているため、対応するCloudWatchアラームもアラート状態になっていました。
手動復旧
各Inspection VPCの片方のサブネットに紐づく Route Table でデフォルトゲートウェイを元のFirewall Endpointに向ける
最後に手動復旧のステップを確認しておきましょう。
復旧のステップは各リージョンのInspection VPCを本来の状態に戻した後、Core Network Policyを復元する2ステップです。
まず、各Inspection VPCの片方のサブネットに紐づく Route Table でデフォルトゲートウェイを元のFirewall Endpointに向けます。もう片方のサブネットに紐づく Route Table ではデフォルトゲートウェイはIGWのままです。
Core Network Policyが完全に適用されるまで、東京と大阪のVPCルートテーブルの修正は行われない
Core Network Policyの復元
次に Core Network Policyの復元です。
Policy version - 1のバージョンを選択して復元をクリックします。すると新たにPolicy version - 4のバージョンが作成されます。
そのまま数分待つとPolicy version - 4がLATESTでReady to executeとなりました。
こちらのバージョンを選択して変更セットの表示または適用をクリックしましょう。
差分を確認して変更セットの適用をクリックします。
変更セットの状態がExecutingになりました。
変更セット適用中のStep Functionsの動作の確認
目的: 手動のポリシー操作 (UPDATING 状態) と 3 分ごとの定期実行が衝突しない排他制御の
実機確認
期待結果: 復旧作業と重なったサイクルの出力が skipped: core-network-not-available
変更セット適用中のStep Functionsの動作の確認をします。
はい、us-east-1でデフォルトゲートウェイがIGWのままだったus-east-1bのサブネットに紐づくRoute Tableに対してルート切り替え処理が行われたことが分かります。
それ以外のap-northeast-1およびap-northeast-3についてはルート切り替え処理は行われていません。us-east-1の一つのAZが生きているため、Core Network Policyの更新も特に行われていません。
Core Network Policyの適用が完了しました。
適用完了後の初回のStep Functionsの実行結果は以下のとおりです。
Core Network Policyが復元されたことによりap-northeast-1やap-northeast-3のInspection VPCを介して通信できるようになったことにより、これらリージョンでもルート切り替え処理が発生している事が分かります。
ちなみに一連のStep Functionsの実行履歴は以下のとおりです。
ダッシュボードの確認
ダッシュボードは以下のとおりです。復旧をしたタイミングで各種メトリクスがこちらの検証を行う前と同等の値を指していることが分かります。
ただし、各リージョンのInspection VPCにおいて片方のAZのNAT Gatewayにルーティングする経路は存在しないため、以下のようにそれらAZのNAT Gatewayについては接続数が0になっています。
Cloud WANでマルチリージョンのネットワークトポロジを組む場合に
AWS Cloud WANにおいてNetwork FirewallやNAT Gateway不調時に別AZや別リージョンにルーティングする仕組みを作ってみました。
Cloud WANアタッチメントのENIが単独で不調である場合のシナリオにおいては無力ではあるのですが、Cloud WANでマルチリージョンのネットワークトポロジを組む場合に参考にしてみてください。
Transit Gatewayの利用の場合であっても、Network FirewallやZonal NAT GatewayのAZ障害時のRTOを短くできると考えます。
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!
