ある企業のネットワークエンジニアは、VPC内のEC2インスタンス間の通信において断続的なパケットドロップが発生している問題をトラブルシューティングしています。標準のVPCフローログをCloudWatch Logsに出力して確認しましたが、送信元・宛先IPと許可/拒否ステータスしか分からず、パケットがTCP再送（Retransmission）によるものなのか、あるいは接続の確立（SYN）自体が失敗しているのかを特定できません。より詳細なネットワークレベルの診断を行うための最適な対応はどれですか。
標準のVPCフローログ（デフォルトフォーマット）には、送信元/宛先IPアドレス、ポート、プロトコル、パケット数、アクション（ACCEPT/REJECT）などの基本情報が含まれますが、TCPフラグは含まれません。カスタムフォーマットでtcp_flags属性を追加することで、SYN・ACK・FIN・RSTなどのTCPフラグが設定されたパケットを識別でき、ハンドシェイク失敗やパケット再送の区別が可能になります。アプリケーション層に到達する前のネットワークトランスポート層での詳細なトラブルシューティングが実現できます。 選択肢Bが提示するOSレベルの「VPCフローエージェント」はAWSのサービスとして存在しません。EC2インスタンス内でのパケットキャプチャはtcpdumpなどのOSツールで実施できますが、VPCレベルの全通信を一元管理するフローログの代替にはなりません。 選択肢Cのルートテーブルには「詳細モニタリング」機能はありません。EC2の詳細モニタリングはCPUやネットワーク転送量などのCloudWatchメトリクスを収集するものであり、TCPフラグやセッション状態の分析はできません。 選択肢DのNLBをインスタンス間に追加する手法はアーキテクチャを大幅に変更するため診断コストが高く、根本的な分析アプローチとして不適切です。NLBのアクセスログにはTCPフラグの詳細は記録されず、必要な診断情報の取得には不十分です。