ネットワークトラフィックの可視化とトラブルシューティング

1. トラブルシューティングで求められる判断

ネットワーク障害では、到達性・実際のトラフィック・DNS・セキュリティ制御を分け、適切な観測手段で原因領域を絞る必要があります。ソリューションアーキテクトとして重要なのはログ解析手順を暗記することではなく、何を確認したいかに応じて観測手段を選ぶことです。

2. 最初に「設定」と「観測」を分ける

通信障害で最初に分けるのは次の2つです。

Reachability Analyzer
→ 設定モデルを分析

VPCフローログ
→ 実際に観測されたIPフローを記録

トラブルシューティングでは、この2つを最初に分けます。

3. Reachability Analyzer：設定上の到達性

Reachability Analyzer

Reachability Analyzerは、送信元と宛先を指定し、現在のAWSネットワーク設定を分析して到達可能かを判定します。ルートテーブル、セキュリティグループ、ネットワークACL、Transit Gatewayなどの構成をモデル化して分析し、実パケットは送信しません。

現行仕様の制約：Reachability AnalyzerはTransit Gatewayを含むネットワーク経路を分析できますが、Transit Gatewayポリシーテーブル（PBR）の分析には対応していません。PBRを使う経路では、ポリシーテーブルの関連付け・ルールと実トラフィックの観測を別途確認します。

本番投入前に
EC2-A → EC2-B:443 が到達可能？
↓
Reachability Analyzer

到達可能でもアプリケーション正常とは限らない

到達可能
= ネットワーク設定上は到達可能

≠ ウェブ サーバーが起動している
≠ TLSが正常
≠ IAM認可が成功する

Reachability Analyzerで到達可能なのに接続できない場合は、リスナー、プロセス、アプリケーション、認可など、ネットワークより上位の層へ調査範囲を移します。

4. VPC フローログ：実際のIP フロー

フローログ

VPCフローログは、VPC内のネットワークインターフェイスへ出入りするIPトラフィックについて、送信元・宛先・ポート・プロトコル・ACCEPT / REJECTなどの情報を記録します。

昨日 14:00 に通信障害
↓
その時間帯にTCP 443が来ていた？
ACCEPT / REJECTだった？
↓
VPCフローログ

ACCEPT / REJECTが示す範囲

ACCEPTは対象フローがネットワーク制御上許可されたことを示しますが、アプリケーション処理の成功までは証明しません。REJECTならセキュリティグループやネットワークACLなどが原因候補になりますが、ログだけで阻害箇所を断定せず設定分析と組み合わせます。

5. ルートテーブル：正しい経路を選んでいるか

通信障害では、宛先CIDRへのルートが存在するかだけでなく、対象サブネットがどのルートテーブルを実際に使用しているかを確認します。

正しいルートを作成済み
↓
しかし別ルートテーブルに存在
↓
対象サブネットには適用されない

ハイブリッドネットワークやTransit Gatewayでは往路だけでなく戻り経路も必要です。

6. セキュリティグループとネットワークACLを分ける

要求だけ到達し応答だけ失敗する場合、セキュリティグループが正しければネットワークACLや戻りルートが有力な確認対象になります。

7. DNSはVPC フローログだけで判断しない

Amazon提供DNSへの一部トラフィックはVPCフローログの対象外です。したがって、フローログにDNS トラフィックがない = DNS クエリが発生していないとは判断できません。

DNSのクエリを確認したい場合はAmazon Route 53 VPC Resolverのクエリログを利用します。

IPへの接続は成功
名前では失敗
↓
DNSを分離して調査
↓
Resolverクエリログ

8. 必要に応じて使う補助分析

Network Access Analyzer

Network Access Analyzerは、個別のA→B通信だけではなく、定義したネットワークアクセス範囲に基づいて潜在的なネットワーク経路がセキュリティ要件に違反していないかを分析する用途に向きます。

インターネットゲートウェイから
プライベート DBへ到達可能な経路が
存在してはいけない
↓
Network Access Analyzer

個別通信の到達性ではなく、ネットワーク全体で意図しない経路が存在しないかを確認するときに使い分けます。

トラフィックミラーリング

VPCフローログはフローメタデータであり、パケットペイロードを見る仕組みではありません。IDSなどでパケットレベルの分析が必要な場合はトラフィックミラーリングを検討します。

フローの証拠で十分
→ VPCフローログ

パケット内容まで必要
→ トラフィックミラーリング

最初から最も重い観測手段を選ばず、必要な粒度から選択します。

9. トラブルシューティングの確認領域

すべての障害で同じ順序を機械的に実行する必要はありません。ただし原因領域を絞るときは、次の確認領域を意識すると判断しやすくなります。

DNS名を使う？
↓ はい
DNS名前解決

通信経路は存在？
↓
ルート / TGW / VPN / DX

ネットワーク制御は許可？
↓
セキュリティグループ / ネットワークACL

戻り経路はある？
↓
戻り経路

ネットワークが成立
↓
アプリケーション / TLS / 認可

10. ツールを「何を証明できるか」で比較する

11. 混同ポイント

• Reachability Analyzer = 実通信テスト：設定モデルの分析です。
• 到達可能 = アプリケーション正常：ネットワーク設定上の到達性までです。
• ACCEPT = アプリケーション成功：ネットワーク側で許可されたことまでです。
• フローログ = パケットキャプチャ：パケットペイロードは記録しません。
• セキュリティグループとNACLは同じ：ステートフル / ステートレスで責任が異なります。
• 往路ルートがあれば通信成立：戻り経路も必要です。
• フローログにDNSがない = DNS クエリなし：Amazon提供DNSなどの制限を考慮します。

12. SAP-C02判断フロー

通信障害 / 設計検証
        │
        ▼
何を知りたい？
        │
        ├─ 設定上到達できる？
        │     → Reachability Analyzer
        │
        ├─ 実際にトラフィックが流れた？
        │     → VPCフローログ
        │
        ├─ DNS クエリは？
        │     → Resolverクエリログ
        │
        ├─ 潜在的な禁止経路がある？
        │     → Network Access Analyzer
        │
        └─ パケット内容まで必要？
              → トラフィックミラーリング

必要なレイヤーへ絞る
↓
ルート
↓
セキュリティグループ / ネットワークACL
↓
戻り経路
↓
アプリケーション / 認可

13. まとめ

設定上の到達性
→ Reachability Analyzer

実際のIP フロー
→ VPCフローログ

DNS クエリ
→ Resolverクエリログ

潜在的なネットワーク経路ポリシー
→ Network Access Analyzer

パケット内容
→ トラフィックミラーリング

ルート
→ 経路

セキュリティグループ
→ ステートフル

ネットワークACL
→ ステートレス

最重要ポイント：ネットワーク障害では「設定」「実トラフィック」「DNS」「パケット」を同じものとして扱わず、知りたい事実に対応する観測手段を選びます。

主要AWS公式資料

• SAP-C02 ドメイン 1 タスク1.1
• Reachability Analyzer
• Reachability Analyzerの動作と制限
• VPCフローログ
• VPCフローログの制限
• Amazon Route 53 VPC Resolverクエリログ
• ネットワークACL
• Network Access Analyzer
• トラフィックミラーリング