構成変更のたびにおびえない AWSネットワークに「カオス」が必要な理由：意図的な“破壊”がもたらす恩恵

ネットワーク構成の変更作業はシステム障害を引き起こすリスクを抱えている。AWSのインフラにおいて、標準ツールと「意図的な破壊」を組み合わせることで不安を払拭する方法とは。

[TechTargetジャパン]

　「システムがつながらない。ネットワークのせいではないか」――。ITインフラ全体を接着する役割を担うネットワークエンジニアにとって、他部門からのこうした疑いを晴らす作業は日常茶飯事だ。しかし、Amazon Web Services（AWS）などのクラウドサービスにシステムが移行したことで、この作業は困難になった。オンプレミスシステムのようにルーターにSSH（Secure Shell）接続してルーティングテーブルを確認するといった従来の手法は、AWSでは通用しない。

　仮想ネットワーク空間VPC（Virtual Private Cloud）、インスタンス単位の仮想ファイアウォール「セキュリティグループ」、アクセス分散装置「ロードバランサー」など、AWS内のインフラは複数のコンポーネントが絡み合っている。こうしたインフラでネットワーク構成の変更作業による影響を正確に予測することは困難だ。

　この課題を克服し、「ネットワークを壊さない変更作業」を実現する手法が、意図的なシステム障害を起こして耐障害性を検証する「カオスエンジニアリング」だ。クラウドインフラのネットワーク管理において、どのように「破壊」をテストに組み込み、レジリエンス（回復力）を構築すればよいのか。その具体的なステップを紹介する。

AWS Network Managerによる「ベースライン」の可視化

併せて読みたいお薦め記事

さまざまなネットワーク管理手法

• 手作業の障害対応は限界　AIでネットワーク復旧時間の半減を目指すドコモの挑戦
• いまさら聞けない「AWS」「Azure」のネットワーク基礎用語

　本記事は、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)」を基に作成しました。