こんにちは、なおにしです。
VPCフローログの最大集約間隔について挙動を細かく見てみました。
はじめに
VPCフローログはVPCフローログの最大集約間隔は「10分」と「1分」から選択できるようになっており、デフォルトは「10分」となっています。
VPCフローログの最大集約間隔が選択できるようになったのは2020年からで、粒度の細かい調査を要する場面で1分間隔のログを確認できることはありがたいことだと思います。
一方で、出力したいトラフィックを意識せず「念のため」というような目的でVPCフローログを有効にしていて、かつ送信先としてCloudWatch Logsを指定していたりすると、想像以上に料金が発生する可能性があります。
そういった場合であればログの出力量を削減する目的で最大集約間隔をあえて「10分」にするという選択肢もあり得そうですが、ドキュメントには以下の記載があります。
ネットワークインターフェイスが Nitro ベースのインスタンスにアタッチされている場合、指定した最大集約間隔に関係なく、集約間隔は常に 1 分以下になります。
Nitro(ナイトロ)は2017年11月に発表されたプラットフォームで、AWSがEC2のために独自開発した仮想化基盤です。より詳細についてはこちらの記事をご参照ください。Nitroの様々なコンポーネントを知ることができるだけではなく、「暗号化ハム」という言葉が寝る前にふと思い出されてしまうようになります。また、こちらのタグからも関連する記事を参照できます。
Nitroベースのインスタンス
前述のとおり現在ではNitroがローンチされてから6年以上経過しているので、ほとんどのインスタンスがNitroベースとなっています。具体的には本記事の公開時点で以下のインスタンスがNitroシステム上で構築されているという記載があります。
- General purpose: M5 | M5a | M5ad | M5d | M5dn | M5n | M5zn | M6a | M6g | M6gd | M6i | M6id | M6idn | M6in | M7a | M7g | M7gd | M7i | M7i-flex | T3 | T3a | T4g
- Compute optimized: C5 | C5a | C5ad | C5d | C5n | C6a | C6g | C6gd | C6gn | C6i | C6id | C6in | C7a | C7g | C7gd | C7gn | C7i
- Memory optimized: R5 | R5a | R5ad | R5b | R5d | R5dn | R5n | R6a | R6g | R6gd | R6i | R6idn | R6in | R6id | R7a | R7g | R7gd | R7i | R7iz | U-3tb1 | U-6tb1 | U-9tb1 | U-12tb1 | U-18tb1 | U-24tb1 | X2gd | X2idn | X2iedn | X2iezn | z1d
- Storage optimized: D3 | D3en | I3en | I4g | I4i | Im4gn | Is4gen
- Accelerated computing: DL1 | DL2q | G4ad | G4dn | G5 | G5g | G6 | Gr6 | Inf1 | Inf2 | P3dn | P4d | P4de | P5 | Trn1 | Trn1n | VT1
- High-performance computing: Hpc6a | Hpc6id | Hpc7a | Hpc7g
- Previous generation: A1
VPCフローログで出力されるログはEC2にアタッチされているネットワークインターフェースでキャプチャされたものに限られるわけではありませんが、最大集約間隔の制限が上記のとおりであれば、少なくともEC2に関しては最大集約間隔を「10分間」と指定していてもほとんどが実際には1分以下ということになります。実際のところどうなのでしょうか。
やってみた
前提
以下の構成で実際にVPCフローログとしてどのように出力されるのか確認します。
VPCにはCloudWatch Logsを送信先として最大集約間隔が異なる2つのVPCフローログを設定しました。
| 最大集約間隔 | 送信先のロググループ名 |
|---|---|
| 10分間 | test-10min-logs |
| 1分間 | test-1min-logs |
Pingはデフォルトで毎秒送信なので、今回は以下のコマンドで30分間実行し続けてみました。
# nohup ping -c 1800 172.31.34.177 > ./ping_result.log &
セッションが切れても継続できるようにnohupを追加しています。
Pingを実行し終えた後のログを確認すると、以下のとおり1800パケットが問題なく送信されていることが分かります。
上記のPing実行と並行して対向のEC2では以下のコマンドでtcpdumpを実行しました。
# nohup timeout 2000 tcpdump -l 'icmp[0] == 0' > ./tcpdump_result.log &
30分間のPing実行を終えた後に同様にログを確認すると、以下のとおり対向のEC2でも1800パケットを受信できています。
VPCフローログの出力結果
結果をCloudWatch Logs Insights で確認します。
最大集約間隔：10分間、t3.micro(Nitroベース)にアタッチされたENIの場合
対象のパケットを検索するように設定したクエリを実行した結果、「32件」のログが出力されていることが確認できます。内容は以下のとおりです。
パケット数が概ね60弱でログ出力されています。したがって、マニュアルに記載されているとおり最大集約間隔を10分間にしていても実際には約1分間隔でログが出力されていることが分かります。なお、パケット数の合計は1800に一致します。
最大集約間隔：10分間、t2.micro(非Nitroベース)にアタッチされたENIの場合
対象のパケットを検索するように設定したクエリを実行した結果、「7件」のログが出力されていることが確認できます。内容は以下のとおりです。
多少ばらつきはありますが、パケット数が概ね290弱でログ出力されています。したがって、実際には約5分間隔でログが出力されていることが分かります。なお、パケット数の合計は1800に一致します。
最大集約間隔：1分間、t3.micro(Nitroベース)にアタッチされたENIの場合
対象のパケットを検索するように設定したクエリを実行した結果、「32件」のログが出力されていることが確認できます。内容は以下のとおりです。
パケット数が概ね60弱でログ出力されています。最大集約間隔が10分間の場合でも同様の頻度でログが出力されていましたが、1分間に変更したからといってより高頻度でログが出力されるわけではないようです。なお、パケット数の合計は1800に一致します。
最大集約間隔：1分間、t2.micro(非Nitroベース)にアタッチされたENIの場合
対象のパケットを検索するように設定したクエリを実行した結果、「32件」のログが出力されていることが確認できます。内容は以下のとおりです。
パケット数が概ね60弱でログ出力されています。t3.microのインスタンスと同様の出力頻度になったため、こちらのパターンでは最大集約間隔「1分間」の設定が機能しているといえます。なお、パケット数の合計は1800に一致します。
まとめ
マニュアルに記載のとおり、NitroベースのインスタンスにアタッチされているENIではVPCフローログの最大集約間隔を10分間で指定していても実際には1分間を指定した場合と同じ頻度でログ出力されることが確認できました。
また、「最大」集約間隔という設定名のとおり、非NitroベースのインスタンスにアタッチされているENIで最大集約間隔を10分間に指定していても、10分ごとに集約されたログが出力されるわけではないことも分かりました。
この記事がどなたかのお役に立てれば幸いです。
31
