VPC Flow Logsの全体像と前提
VPC Flow Logsは「VPC内のどこを、どんな粒度で観測しているか」を押さえると一気に理解が楽になります。
VPC Flow Logsは、VPC内のネットワークインターフェイス（ENI）に出入りするIPトラフィック情報を記録する仕組みです。パケットの中身を覗くのではなく、通信のメタ情報を集約してログとして出します。公式ドキュメントでも、VPC Flow Logsは「ネットワークインターフェイスとの間で行き来するIPトラフィックに関する情報をキャプチャ」する機能だと説明されています。
出力先は次の3つが基本です。
- Amazon CloudWatch Logs
- Amazon S3
- Amazon Data Firehose
これも公式に明記されています。
ここでまず試験で混乱しやすい前提を2つだけ決めます。
- 観測点はENI単位（VPC/サブネット/ENIを指定して作れるが、実際に記録されるのはENIに関するフロー）
- 記録はフロー（5タプル）単位で、集約されて出力される
フローは、送信元IP・送信先IP・送信元ポート・送信先ポート・プロトコルといった情報で特徴付けられます。
また、フローログはリアルタイムの1パケットずつではありません。**集約間隔（aggregation interval）**でまとめられ、デフォルトは最大10分、必要なら最大1分にできます。
「細かくすれば観測精度が上がるが、ログ量も増える」ので、コストや運用とトレードオフになります。
SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇
できること 何をどこまで記録できるのか
VPC Flow Logsで“できること”は、言い換えると「ENIに出入りしたIP通信を、後から説明できる状態にすること」です。
どんなトラフィックを記録できるか
作成時に、**ACCEPT（許可）／REJECT（拒否）／ALL（両方）**のどれを記録するか選べます。
ここはよく出る勘違いポイントで、「拒否された通信も取れるの？」に対しては、設定しだいで取れます（REJECT もしくは ALL）。
たとえばこんな用途にハマります。
- あるEC2に到達しない通信が、セキュリティグループ／NACLで落ちているのかの当たりをつける
- 想定外の送信先へ出ている通信（外向き）を、宛先IP・ポートから洗い出す
- 複数AZ・複数サブネットで、どの経路に通信が寄っているかの状況把握
これらは公式ドキュメントでも、セキュリティグループが厳しすぎる診断や到達トラフィック監視などに有用と説明されています。
ログの中身は何が入るか
フローログレコードは、スペース区切りのフィールド列で、送信元／送信先／プロトコル等が入ります。
加えて、状況判断に効く代表フィールドがこれです。
- action（ACCEPT / REJECT）：許可されたか拒否されたか
- log-status（OK / NODATA / SKIPDATA）：ログとして正しく出たか、そもそも通信がないか、欠落したか
ここは試験でも実務でも重要で、SKIPDATAがある＝その時間帯の通信が少ないとは限りません。内部都合で一部スキップされる場合がある、と公式が明記しています。
つまり「ログがない＝通信がなかった」と短絡しないのがコツです。
出力先ごとの“使いどころ”
出力先は同じフローログでも、運用が変わります。
- CloudWatch Logs：すぐ検索したい、インシデント初動に強い（Logs Insights等）
- S3：長期保管・Athena等で分析しやすい（ファイル化して蓄積）
- Data Firehose：配信して別サービスへ流し、分析基盤につなげやすい
「どれが正解」ではなく、初動の調査か、長期の可視化かで選ぶのが事故りません。
できないこと 取れない通信と誤解されやすいポイント
VPC Flow Logsは便利ですが、万能ではありません。試験のひっかけは、ここを「できる風に見せる」形で出やすいです。
パケットの中身は見えない
VPC Flow Logsは、通信のメタ情報を記録します。
つまり、HTTPのパス、リクエストボディ、TLSのSNI、DNSクエリ名のような“中身”は分かりません。中身が必要なら別のログ（例：ALBアクセスログ、CloudFrontログ、アプリログ）や、深い解析ならTraffic Mirroring等の領域になります。
そもそも記録されないトラフィックがある
公式の「制限事項」ページに、記録されないトラフィックが明確に列挙されています。代表例はこれです。
- インスタンスがAmazon DNSサーバーに問い合わせるトラフィックは記録されない（自前DNSに向けるなら記録される）
- Windowsのライセンスアクティベーションに関するトラフィックが記録されない
「DNSの名前解決で詰まってるのに、Flow LogsにDNSが出てこない」みたいな現象は、ここが原因になります。
試験でも「DNSの通信もFlow Logsで追える」と誤解していると引っかかります。
ログは欠落しうる
これも大事な落とし穴です。ログが必ず完全に出るとは限りません。
集約間隔内の一部レコードがスキップされることがあり、log-statusに SKIPDATA として表れる場合があります。
設計としては「Flow Logsは監査ログではあるが、絶対に欠落しない“完全な証跡”として過信しない」というスタンスが安全です。
時刻は厳密なリアルタイムではない
集約間隔でまとめる仕様なので、「この瞬間の1パケット」を追う用途には向きません。最大集約間隔は10分、必要なら1分にできます。
試験では「リアルタイム監視」の言葉に釣られて誤答しがちなので、“後から観測”が基本と覚えると安定します。
ひっかけ回避の考え方 似たサービスとの使い分け
迷ったときは、「何を知りたいか」を一段具体に落とすと、Flow Logsが適役かどうか判定できます。
判断軸はたった3つ
- 知りたいのは到達可否か
- 知りたいのは通信の中身か
- 知りたいのは誰が何をしたかか
この3つで切ると、試験の選択肢に強くなります。
到達可否を知りたいなら
Flow Logsは強いです。ACCEPT/REJECTと送受信先が分かるので、SG/NACLの当たりがつきます。
ただし、Flow Logs単体で“ルールのどれに当たったか”までは分かりません。あくまで推理材料です。
通信の中身を知りたいなら
Flow Logsでは無理です。選択肢としては、目的に応じて次のように分かれます。
- L7のアクセス内容：ALBアクセスログ、CloudFrontログ、アプリログ
- パケット内容まで：Traffic Mirroring や IDS/IPS、プロキシログ
Flow Logsは「L3/L4の足跡」だと割り切るのがコツです。
誰が何を変更したかを知りたいなら
Flow Logsではなく、CloudTrailの領域です。
たとえば「セキュリティグループのインバウンドルールを誰が変更したか」はFlow Logsでは追えません。ネットワークの症状（REJECTが増えた等）は見えても、変更者やAPIコールは別物です。
出題で混ざりやすい Transit Gateway Flow Logs
余裕があれば、Transit GatewayにもFlow Logsがある点だけ押さえておくと混乱が減ります。Transit Gatewayにもフローログがあり、TGW上のネットワークフローを記録します。
VPCのENIに対するFlow Logsと、観測点が違うイメージです。
実務でも試験でも使える読み方と分析の型 Udemyでの学び方
最後に、SAA-C03学習として「暗記せずに解ける」ための読み方の型を置いておきます。
まずは5つだけ見て当たりをつける
フローログを眺めるとき、最初から全フィールドを追わなくて大丈夫です。まずはこの5点で状況が見えます。
- srcaddr / dstaddr
- srcport / dstport
- protocol
- action（ACCEPT/REJECT）
- log-status（OK/NODATA/SKIPDATA）
例として「疎通できない」系の切り分けは、次の順で考えるとスムーズです。
- REJECTが出ている → SG/NACL/ルート/到達経路のどこかで落ちている可能性
- ACCEPTだけ出ているのにアプリが動かない → L7（アプリ側）や名前解決、証明書など別レイヤの疑い
- そもそもログが出ない → 取れないトラフィック（DNSなど）や、log-status、対象ENIの取り違えを疑う
DNSで詰まったら Flow Logsに頼りすぎない
DNSの問い合わせがFlow Logsに出ないのは仕様です。
このときは、VPCのDNS設定、名前解決先（自前DNSか）、アプリログやリゾルバ周りのログで確認するほうが近道です。
集約間隔は設計の問題として考える
最大集約間隔を10分にするか1分にするかは、「検知の早さ」と「ログ量」のトレードオフです。デフォルト最大10分で、必要なら1分にできるのが公式仕様です。
試験では“1分にするとログ量が増える”という当たり前の話を、選択肢として混ぜてくることがあります。仕組みから納得しておくと迷いません。
Udemyで学ぶなら 体系化された一講座を軸にする
Flow Logsは単体暗記より、VPC・ルーティング・SG/NACL・NAT・エンドポイントなどネットワーク全体の理解とセットで効きます。
Udemyは講座内でハンズオン→ログ確認→原因切り分けまで一気通貫で触れられるものが多いので、「体系的に学べる教材の一例」として、SAA-C03向けのネットワーク分野に強い講座を1本決めて周回するのがおすすめです（講座の例は、VPC設計・セキュリティ・監視をまとめて扱うタイプが相性がいいです）。
SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇
まとめ
VPC Flow Logsは、ENIに出入りするIP通信のメタ情報を集約して記録する仕組みです。出力先はCloudWatch Logs、S3、Data Firehoseが基本で、運用目的に合わせて選びます。
一方で、Flow Logsは万能ではありません。パケットの中身は見えず、さらにAmazon DNSへの問い合わせなど記録されない通信がある点が重要です。 また、ログは常に完全とは限らず、SKIPDATAのように欠落しうることも公式に説明されています。
試験でのひっかけを避けるコツは、「到達可否を知りたいのか」「中身を知りたいのか」「誰が変更したのか」を切り分けることです。Flow LogsはL3/L4の足跡として強力ですが、目的が違えば別のログやサービスに役割を渡すのが正解になります。講座やハンズオンでVPC全体の流れと一緒に学ぶと、暗記に寄らずに判断できるようになります。
