本記事は、AWS社の年次カンファレンス「AWS re:Invent 2025」のセッション「Breaking AWS networks on purpose to build resilience (DEV343)」にて、ネットワーク検証ツールベンダーForward Networksのプリンシパルソリューションアーキテクトであるクレイグ・ジョンソン氏が解説した手法を紹介する。ジョンソン氏は、CLI（コマンドラインインタフェース）や、インフラ構築をコードで自動化する「Infrastructure as Code」（IaC）を駆使し、AWSが標準で提供するツール群を活用した実践的なアプローチを提示した。

　ネットワークにカオスエンジニアリングを導入する前の第一歩は、現在のシステム構成が正常に稼働している状態（ベースライン）を正確に把握することだ。ジョンソン氏は、そのための仕組みとして、ネットワークを一元管理・可視化するツール「AWS Network Manager」の活用を推奨する。

　AWS Network Managerは、VPCや仮想ルーター「AWS Transit Gateway」の他、オンプレミスとAWSを専用線で接続する「AWS Direct Connect」、VPN（仮想プライベートネットワーク）など、AWS内外のネットワーク構成要素を動的なマップとして可視化する機能を持つ。複数アカウントにまたがるグローバルなネットワークであっても、オンプレミスのファイアウォールを含めたエンドツーエンドのトポロジーをGUI（グラフィカルユーザーインタフェース）で把握できる。変更作業の前に視覚的なベースラインを提示することで、関係者間の認識を合わせ、承認プロセスを円滑に進められる。

　一部のエンジニアはトラフィック監視に、VPC内の通信を記録する「VPC Flow Logs」を多用するが、ジョンソン氏は「VPC Flow Logsは正常時のトラフィック傾向を把握する上では優れているものの、障害発生時のトラブルシューティングには不向きだ」と指摘する。ネットワークが遮断された状態ではパケットが流れないため、どこで通信が途絶えたかの根本原因を特定できないからだ。

VPC Reachability Analyzerを用いた「インテント」の検証

　そこでトラブルシューティングと変更確認の要となるのが、ネットワークの到達性をシミュレーション検証するツール「VPC Reachability Analyzer」だ。

　従来のネットワーク変更作業では、「どのルーターの設定を変えるか」という手順に固執しがちだった。クラウドインフラにおいて重視すべき事項は、「どの送信元から、どの宛先に、どのポートとプロトコルで通信させたいか」という「インテント」（意図）だ。

　VPC Reachability Analyzerを使用すると、インスタンスや仮想ネットワークインタフェース「Elastic Network Interface」（ENI）などの送信元から宛先までのパスをシミュレーションできる。経路上のセキュリティグループ、サブネット単位の仮想ファイアウォール「ネットワークACL」、ルーティングテーブルを通過し、「到達可能」（Pass）か「到達不可」（Fail）かを判定する仕組みだ。

　ジョンソン氏が推奨する到達性シミュレーションのプロセスは以下の通りだ。

1. 変更作業前にVPC Reachability Analyzerを実行し、必須トラフィックがPassになることを確認する
2. 変更作業（あるいは意図的な障害の導入）を実行する
3. 作業直後に再度VPC Reachability Analyzerを実行する

　もし設定ミスによって通信が遮断されれば、直ちにFailとして検出され、どのコンポーネントで問題が発生したかの詳細なフォレンジックデータ（障害解析のためのデータ）が提供される。これによって、「アプリケーションは動いているか」と担当者に確認して回る手間を省き、ネットワーク起因の障害をピンポイントで特定、修正可能になる。

IaCパイプラインへの組み込みと継続的なテスト

　このインテントベースの検証は、オープンソースのIaCツール「Terraform」や、AWSリソースをテンプレートで定義・構築するサービス「AWS CloudFormation」を用いたCI/CD（継続的インテグレーション／継続的デリバリー）パイプラインに組み込むことで真価を発揮する。

　インフラ構築のコード内にVPC Reachability Analyzerの実行ステップを組み込めば、「変更前の到達性テスト実行→インフラ変更作業→変更後のテスト実行」という一連のプロセスを自動化できる。もしテストに失敗した場合は、自動的に変更をロールバックする仕組みを構築することも可能だ。

　設定すべきインテントの数が多い場合は、VPC Flow Logsや、ネットワークファイアウォールのログから「トラフィック量の多い上位の通信」（トップトーカー）を抽出し、それらを優先的にVPC Reachability Analyzerのテストケースとして登録するアプローチが有効だ。

「カオスアワー」の導入に向けて

　ジョンソン氏は、「月あるいは四半期に1回、意図的にネットワークを破壊し、復旧させる『カオスアワー』をスケジュールすること」を提案している。安全な検証環境において、ある担当者がランダムにネットワークを破壊し、別の担当者がVPC Reachability Analyzerなどを用いて原因を特定・修復する訓練を積むのだ。

　AWSでは従来のルーターにSSH接続することでの確認は難しいが、提供されているツール群を組み合わせることで、より高度で自動化されたネットワーク検証が実現する。自社のネットワークにあえてカオスを注入する訓練を重ねることで、変更作業のたびに生じる不安を払拭し、確かな回復力を備えたインフラを構築できるだろう。

本稿は、AWS社が2025年12月9日に公開した動画「AWS re:Invent 2025 - Breaking AWS networks on purpose to build resilience (DEV343)」を基に作成しました。