変更要約: in-scope サービス網羅: 運用/通知/ガバナンス(EventBridge/SNS/SQS/Health Dashboard/Trusted Advisor/Well-Architected/Management Console/Control Tower)を追加
5.2監視ツールと到達性の確認
状態を測る——CloudWatch メトリクス/アラーム、Reachability Analyzer、Network Access Analyzer、トラフィックミラーリング——を理解します。問いに合う道具を選びます。
ネットワークの監視には複数の道具があります。「何を知りたいか」——傾向か、到達できるか、パケットの中身か——で選びます。
5.2.1問いに合う道具
- CloudWatch メトリクス/アラーム：NAT/ELB/VPN などの指標を時系列で監視し、しきい値で通知する。
- Reachability Analyzer：構成（ルート/SG/NACL）を静的解析し「A は B に到達できるか」を判定。
- Network Access Analyzer：到達できてはいけない経路がないかを検査し、意図しない露出を見つける。
- トラフィックミラーリング：実パケットを複製して IDS/パケットキャプチャで深く解析する。
「到達できない原因を構成から特定＝Reachability Analyzer」「意図しない到達経路の検査＝Network Access Analyzer」「指標の傾向/通知＝CloudWatch」「実パケット解析＝トラフィックミラーリング」 は ANS-C01 で頻出です。実際に通すか（テスト）と構成解析（静的）の違いも意識します。
ANS-C01 では各監視ツールが「実際に通信するか／構成を解析するか」と、どの指標を見るかが問われます。Reachability Analyzer と Network Access Analyzer はパケットを流さず構成だけを解析する（料金は分析実行ごと）ため、本番に影響を与えず到達可否や露出を判定できます。Reachability は「特定の送信元→宛先が到達できるか・できないなら最初に遮断するコンポーネント」を返し、Network Access Analyzer は「インターネットや特定範囲から到達できてしまう経路」をスコープで定義して洗い出します。CloudWatch では、ネットワーク系の重要指標を覚えます——NAT ゲートウェイは ErrorPortAllocation（ポート枯渇）・BytesOutToDestination、Site-to-Site VPN は TunnelState（1=UP/0=DOWN）でトンネル断を検知、Direct Connect は ConnectionState や ConnectionBpsEgress、ELB は HTTPCode_ELB_5XX や TargetResponseTime、Transit Gateway は BytesIn/Out です。さらに踏み込んだフロー単位の傾向は CloudWatch Network Monitor や Internet Monitor（インターネット側の遅延・可用性の傾向）で見ます。トラフィックミラーリングは送信元 ENI からパケットを複製して NLB/モニタリング ENI 宛に送り、フィルタで対象を絞れますが、ミラー分の帯域とコストがかかる点に注意します。
| ツール | 実トラフィック | 答える問い |
|---|---|---|
| Reachability Analyzer | 流さない（静的解析） | A→B は到達可能か・遮断箇所は |
| Network Access Analyzer | 流さない（静的解析） | 到達できてはいけない経路はないか |
| CloudWatch | 指標を収集 | 傾向・しきい値超過の通知 |
| トラフィックミラーリング | 実パケットを複製 | ペイロードの深い検査 |
シナリオ：Site-to-Site VPN が時々切れる疑いがあり、切断を即検知して自動でオンコール通知したい。→ CloudWatch で VPN の TunnelState メトリクスにアラームを設定し、値が 0（DOWN）になったら SNS 経由で通知する。原因が構成かどうかの切り分けには、復旧後に Reachability Analyzer で経路の構成上の到達性も確認する。
FAQ：Q. Reachability Analyzer が「到達可能」と言うのに実際は通信できない? A. 静的解析は構成（ルート/SG/NACL）上の可否を見るだけで、アプリ層やインスタンス内ファイアウォール・OS 設定は対象外。実通信の問題はミラーリングやインスタンス側で確認。Q. 過剰な露出を継続的に検査したい? A. Network Access Analyzer のスコープを定期実行し、結果を Security Hub に集約する。
ひっかけ：「到達できない原因をフローログだけで特定できる」は誤り。フローログは REJECT が出た事実を示すだけで、SG/NACL/ルートのどれが原因かは断定できない。構成上の遮断箇所を正確に示すのは Reachability Analyzer。逆に「露出していないことの保証」をフローログで行うのも誤りで、それは Network Access Analyzer の役割。
5.2.2この節のまとめ
- 到達性＝Reachability/Network Access Analyzer、傾向＝CloudWatch
- パケット＝トラフィックミラーリング
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. EC2 から RDS に接続できない。ルート/SG/NACL のどこで止まっているかを構成から静的に特定したい。何を使いますか？
Q2. NAT ゲートウェイの帯域使用量や ELB のエラー数を時系列で監視し、閾値超過で通知したい。何を使いますか？
Q3. 「本来到達できてはいけないリソースに到達できる経路」が存在しないかを検査したい。何を使いますか？