VPC Flow Logs難易度 標準無料
異なるサブネットに配置された2台のEC2インスタンス間の通信が突然失敗するようになった。セキュリティグループ設定は変更していないと開発チームは主張している。SysOps管理者は、実際にどの通信が拒否（REJECT）されているかを、直近数分の範囲で素早く特定したい。最も適切な方法を選べ。（単一選択）
- A対象VPCでVPC Flow LogsをCloudWatch Logsへ配信するよう設定（既に有効なら既存のロググループ）し、CloudWatch Logs Insightsで
action = "REJECT"かつ該当ENI/IPに絞り込んだクエリを直近数分の範囲で実行する - B開発チームの「設定変更していない」という申告を信頼し、Flow Logsの確認はスキップしてセキュリティグループのコンソール画面だけを目視確認する
- CVPC Flow LogsをS3へ配信するよう新規設定し、Amazon Athenaでテーブルとパーティションを一から定義してからクエリする
- DCloudTrailで両方のEC2インスタンスへの
RunInstances/ModifyInstanceAttribute呼び出し履歴を確認する
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
VPC Flow Logsは、ENI単位で発生する通信のACCEPT/REJECTの記録（送信元/宛先IP・ポート・プロトコル・パケット数等）を出力する機能である。
配信先をCloudWatch Logsに設定しておけば、CloudWatch Logs Insightsで
filter action = "REJECT" のようなクエリを即座に実行し、直近数分間の拒否パターンを素早く洗い出せる。
- REJECTの記録から、どのセキュリティグループ／ネットワークACLの設定変更が影響したかを絞り込む手がかりが得られる （Flow Logs自体はどのルールが拒否したかまでは明示しないが、拒否された通信の特定には直結する）。
- 配信先をS3にした場合はAthenaでの分析が定石だが、Athenaはテーブル定義・パーティション設定が前提となり、 「今すぐ数分単位で確認したい」という即時性の要件には、CloudWatch Logs Insightsの方が適している。
- B申告と実際の通信状況が食い違う可能性があるため、実際の通信結果（Flow Logsの記録）で事実を確認せずに判断するのはトラブルシュートとして不十分。
- Cテーブル・パーティションの定義に時間がかかり、「直近数分の範囲で素早く特定したい」という即時性の要件に合わない。S3+Athenaは長期集計向き。
- DCloudTrailはAWS API呼び出しの履歴であり、インスタンス間のネットワークパケットレベルの通信可否（ACCEPT/REJECT）は記録しない。今回の調査対象と噛み合わない。
ひっかけ： 「セキュリティグループの設定画面を目視確認するだけで十分（B）」は、設定変更していないと主張されている状況では実際の通信結果（Flow Logs）
を見て事実を確認すべきという運用者視点が問われている。「調べずに推測で判断しない」という基本姿勢を押さえる。
公式ドキュメント・関連Amazon VPC User Guide ― VPC Flow Logs↗Amazon CloudWatch Logs User Guide ― Analyzing log data with CloudWatch Logs Insights↗
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）