フローログの制限事項

フローログの作成後は、選択したネットワークインターフェイス、サブネット、VPC のアクティブなトラフィックがあるまで、フローログデータは表示されません。

ピア VPC がアカウントにない限り、VPC とピアリング接続された VPC のフローログを有効にすることはできません。

フローログを作成後に、その設定やフローログレコードの形式を変更することはできません。例えば、異なる IAM ロールをフローログに関連付けたり、フローログレコードのフィールドを追加または削除したりすることはできません。代わりにフローログを削除し、必要な設定で新しいログを作成できます。

ネットワークインターフェイスに複数の IPv4 アドレスがある場合、トラフィックがセカンダリプライベート IPv4 アドレスに送信されても、フローログの dstaddr フィールドにはプライマリプライベート IPv4 アドレスが表示されます。元の送信先 IP アドレスをキャプチャするには、pkt-dstaddr フィールドを含むフローログを作成します。

トラフィックがネットワークインターフェイスに送信され、送信先がネットワークインターフェイスの IP アドレスのいずれでもない場合、フローログの dstaddr フィールドにはプライマリプライベート IPv4 アドレスが表示されます。元の送信先 IP アドレスをキャプチャするには、pkt-dstaddr フィールドを含むフローログを作成します。

トラフィックがネットワークインターフェイスから送信され、送信元がネットワークインターフェイスの IP アドレスのいずれでもない場合、動作はフローの方向に応じて異なります。エグレスフローの場合、フローログの srcaddr フィールドにはプライマリプライベート IPv4 アドレスが表示されます。元の送信元 IP アドレスをキャプチャするには、pkt-srcaddr フィールドを含むフローログを作成します。

ログレコードがネットワークインターフェイスへの入力フロー用である場合、ネットワークインターフェイスのプライマリプライベート IP は srcaddr フィールドに表示されません。

ネットワークインターフェイスが Nitro ベースのインスタンスにアタッチされている場合、指定した最大集約間隔に関係なく、集約間隔は常に 1 分以下になります。

pkt-srcaddr と pkt-dstaddr のフィールドについては、中間レイヤーでクライアント IP アドレスの保存が有効になっている場合、このフィールドに表示されるのが中間レイヤーの IP アドレスではなく、保存されたクライアント IP になることがあります。

traffic-path フィールドについては、値は同じ VPC 内のリソースを経由するフローと、Outpost ローカルゲートウェイを経由するフローで同じです。

集計間隔中に一部のフローログレコードがスキップされることがあります (使用可能なフィールド の log-status を参照)。これは、内部の AWS キャパシティの制限または内部エラーが原因で発生する場合があります。VPC フローログの請求金額を表示するために AWS Cost Explorer を使用しており、一部のフローログがフローログの集計間隔中にスキップされた場合は、AWS Cost Explorer で報告されるフローログの数が Amazon VPC により発行されたフローログの数よりも多くなります。

VPC ブロックパブリックアクセス (BPA) を使用している場合:

VPC フローログは、アカウントごとにリソースごとに最大 250 件のサブスクリプションをサポートします。この制限に達したリソースで追加のサブスクリプションを作成するには、まず既存のサブスクリプションを削除する必要があります。

Amazon DNS サーバーに接続したときにインスタンスによって生成されるトラフィック。独自の DNS サーバーを使用する場合は、その DNS サーバーへのすべてのトラフィックが記録されます。

Amazon Windows ライセンスのアクティベーション用に Windows インスタンスによって生成されたトラフィック。

インスタンスメタデータ用に 169.254.169.254 との間を行き来するトラフィック。

Amazon Time Sync Service の 169.254.169.123 との間でやり取りされるトラフィック。

DHCP トラフィック。

トラフィックミラーリングされたソーストラフィック。トラフィックミラーリングされたターゲットトラフィックのみが表示されます。

デフォルト VPC ルーターの予約済み IP アドレスへのトラフィック。

エンドポイントのネットワークインターフェイスと Network Load Balancer のネットワークインターフェイスの間のトラフィック。

アドレス解決プロトコル (ARP) トラフィック。

有効期間が短いリージョン NAT ゲートウェイ上のトラフィック。作成後数分で削除されます。

基盤となる ECS タスクがフローログサブスクリプションの所有者によって所有されていない場合、ECS フィールドは計算されません。

例えば、サブネット (SubnetA) を別のアカウント (AccountB) と共有し、SubnetA のフローログサブスクリプションを作成するとします。AccountB が共有サブネットで ECS タスクを起動すると、サブスクリプションはそれらのタスクからトラフィックログを受け取ります。ただし、セキュリティ上の懸念により、これらのログの ECS フィールドは計算されません。

VPC / サブネットリソースレベルで ECS フィールドを使用してフローログサブスクリプションを作成すると、ECS 以外のネットワークインターフェイス用に生成されたトラフィックもサブスクリプションに対して配信されます。ECS フィールドの値は、ECS 以外の IP トラフィックでは「-」になります。例えば、サブネット (subnet-000000) があり、ECS フィールド (fl-00000000) を使用してこのサブネットのフローログサブスクリプションを作成する場合を考えてみます。subnet-000000 で、インターネットに接続され、IP トラフィックをアクティブに生成している EC2 インスタンス (i-0000000) を起動します。また、同じサブネットで実行中の ECS タスク (ECS-Task-1) を起動します。i-0000000 と ECS-Task-1 の両方が IP トラフィックを生成しているため、フローログサブスクリプション fl-00000000 は両方のエンティティのトラフィックログを配信します。ただし、logFormat に含めた ECS フィールドの実際の ECS メタデータを取得するのは ECS-Task-1 だけです。i-0000000 に関連するトラフィックの場合、これらのフィールドの値は「-」になります。

ecs-container-id と ecs-second-container-id の順序は、VPC フローログサービスが ECS イベントストリームからそれらを受信したときに基づきます。ECS コンソールまたは DescribeTask API コールで表示されるのと同じ順序であるとは限りません。タスクがまだ実行しているときにコンテナが STOPPED ステータスになると、このコンテナが引き続きログに表示されることがあります。

ECS メタデータと IP トラフィックログは、2 つの異なるソースからのものです。アップストリームの依存関係から必要な情報をすべて取得すると、ECS トラフィックの計算がすぐに開始されます。

新しいタスクを開始した後、ECS フィールドの計算は、基盤となるネットワークインターフェイスの IP トラフィックの受信、およびタスクが現在実行中であることを示す ECS タスクのメタデータを含む ECS イベントの受信という 2 つの条件が両方とも満たされたときに開始されます。

タスクを停止した後、ECS フィールドの計算は、基盤となるネットワークインターフェイスの IP トラフィックが受信されなくなる (または 1 日以上遅延した IP トラフィックを受信する)、およびタスクがもう実行中でなくなったことを示す ECS タスクのメタデータを含む ECS イベントが受信されるという 2 つの条件が両方とも満たされたときに停止します。

サポートされるのは、awsvpc ネットワークモードで起動した ECS タスクのみです。

一部のネットワークアプライアンスが暗号化ステータスを報告する制限があるため、一部のフローでは暗号化ステータスが「-」(使用不可) になる場合があります。ユーザーは分析でこれらのフローを無視できます。

モニターモードで暗号化として表示されても、フローが強制モードで許可されるわけではありません。逆も同様です。

リソースのタグがフローログサブスクリプションの所有者によって所有されていない場合、タグフィールドは計算されません。

例えば、サブネット (SubnetA) を別のアカウント (AccountB) と共有し、ネットワークインターフェイス上のタグフィールドで SubnetA のフローログサブスクリプションを作成するとします。設定したキーを使用してタグ付けされたネットワークインターフェイスが AccountB によって起動すると、サブスクリプションは AccountB によって起動されたネットワークインターフェイスのトラフィックログを受信しますが、サブスクリプションによって設定されたタグフィールドはセキュリティ上の懸念により計算されません。必要に応じて、AccountB によって起動されたネットワークインターフェイスにタグを付けることでタグを表示できます。

VPC/サブネットリソースレベルでタグフィールドを使用してフローログサブスクリプションを作成すると、タグ付けされていないネットワークインターフェイス用に生成されたトラフィックも、サブスクリプションに対して配信されます。タグフィールドの値は、タグ付けされていないリソースでは「-」になります。

Auto Scaling グループは、「-」という名前のタグを表示できません。これは、値が欠落/欠落していることを示す予約文字であるためです。

タグフィールドを使用してフローログサブスクリプションを作成すると、お客様に代わっていくつかのリソースが作成されます。タグ値の更新を消費するために、EventBridge マネージドルールが作成され、フローログサービスにタグの変更が送信されます。これらの EventBridge マネージドルールは、タグフィールドを使用するすべてのサブスクリプションが削除されると、自動的にクリーンアップされます。これらの EventBridge マネージドルールを手動で削除しないでください。手動で削除した場合、タグ値の更新に大幅な遅延が発生します。この作成/クリーンアップを制御し、タグ値へのアクセスを提供するために、サービスリンクロールがアカウントに作成されます。詳細については、「VPC フローログのサービスリンクロールの使用」を参照してください。

Amazon CloudWatch Logs の解析と Athena の解析の制約により、タグ値のすべての特殊文字は UTF-8 パーセントエンコードを使用してエンコードされます。これは、url_decode を使用して Athena でネイティブにデコードすることも、任意の URL または URI デコーダーでデコードすることもできます。

新しいサブスクリプションが作成されてから最初の 1 時間は、タグ値が欠落しているか不正確である可能性があります。この最初の 1 時間の後、タグ値はタグ付けされたリソースの値を 1 分単位で正確に反映できるようになります。

同じリソースで同じ 1 秒以内に複数のタグが変更された場合、更新が失われ、最大 1 時間の古いタグ値が発生する可能性があります。

Auto Scaling グループタグフィールドの場合、アカウントで 1 つ以上の有効な CloudTrail 証跡が必要です。有効な証跡がないと、Auto Scaling グループのタグ値が古くなったり不正確になったりする可能性があります。

ネクストホップネットワークインターフェイスが next-hop-az-id 以外のフローログサブスクリプションの所有者によって所有されていない場合、ネクストホップフィールドは計算されません。

ネクストホップフィールドにネットワークインターフェイス (インターネットゲートウェイへのトラフィックなど) がない場合、ネクストホップフィールドは使用できません。

ネクストホップフィールドは、クロスリージョントラフィックでは使用できません。

ネクストホップフィールドは、一部のネットワークサービス (トランジットゲートウェイや Network Load Balancer など) からの入力トラフィックには使用できません。

トラフィックがミドルボックス (トランジットゲートウェイや Network Load Balancer など) を通過する場合、ネクストホップネットワークインターフェイスは、トラフィックの最終送信先ではなく、ミドルボックス (Transit Gateway アタッチメントなど) に関連付けられたネットワークインターフェイスです。