Protokollieren von IP-Datenverkehr mit VPC Flow Logs - Amazon Virtual Private Cloud
Grundlagen zu Flow-ProtokollenFlow-ProtokolldatensätzeEinschränkungen von Flow-ProtokollenPreisgestaltung

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Protokollieren von IP-Datenverkehr mit VPC Flow Logs

VPC Flow Logs ist ein Feature, mit der Sie Informationen über den IP-Datenverkehr zu und von Netzwerkschnittstellen in Ihrer VPC erfassen können. Flow-Protokolldaten können an den folgenden Speicherorten veröffentlicht werden: Amazon CloudWatch Logs, Amazon S3 oder Amazon Data Firehose. Nachdem Sie ein Flow-Protokoll erstellt haben, können Sie die Flow-Protokolldatensätze in der von Ihnen konfigurierten Protokollgruppe, dem Bucket oder dem Bereitstellungsstream abrufen und anzeigen.

Mit Flow-Protokollen können Sie eine Reihe von Aufgaben ausführen, z. B.:

  • Diagnose übermäßig restriktiver Sicherheitsgruppenregeln

  • Überwachen des Datenverkehrs, der auf Ihrer Instance eintrifft

  • Ermitteln der Richtung des Datenverkehrs zu und von den Netzwerkschnittstellen

Flow-Potokolldaten werden außerhalb des Pfades des Netzwerkdatenverkehrs erfasst und wirken sich daher nicht auf den Netzwerkdurchsatz oder die Latenz aus. Sie können Flow-Protokolle erstellen oder löschen, ohne dass die Netzwerkleistung beeinträchtigt wird.

Anmerkung

In diesem Abschnitt geht es nur um Flow-Logs für VPCs. Informationen zu Flow-Protokollen für Transit-Gateways, die in Version 6 eingeführt wurden, finden Sie unter Protokollieren von Netzwerkverkehr mithilfe von Transit Gateway Flow Logs im Amazon VPC Transit Gateways-Benutzerhandbuch.

Inhalt

Grundlagen zu Flow-Protokollen

Sie können Flow-Protokolle für VPCs, Subnetze oder Netzwerkschnittstellen erstellen. Wenn Sie ein Flow-Protokoll für ein Subnetz oder eine VPC erstellen, werden alle Netzwerkschnittstellen innerhalb dieses Subnetzes oder der VPC überwacht.

Flow-Protokolldaten für eine überwachte Netzwerkschnittstelle werden als Flow-Protokolldatensätze aufgezeichnet. Hierbei handelt es sich um Protokollereignisse bestehend aus Feldern, die den Datenfluss beschreiben. Weitere Informationen finden Sie unter Flow-Protokolldatensätze.

Für die Erstellung eines Flow-Protokolls geben Sie Folgendes an:

  • Die Ressource, für die das Flow-Protokoll erstellt werden soll

  • Den Typ des zu erfassenden Datenverkehrs (zulässiger Datenverkehr, abgelehnter Datenverkehr oder gesamter Datenverkehr)

  • Die Ziele, an die die Flow-Protokolldaten veröffentlicht werden sollen.

Im folgenden Beispiel erstellen Sie ein Flow-Protokoll, das den akzeptierten Datenverkehr für die Netzwerkschnittstelle einer der EC2-Instances in einem privaten Subnetz erfasst und die Flow-Protokollsätze in einem Amazon-S3-Bucket veröffentlicht.

Flow-Protokolle für eine Instance

Im folgenden Beispiel erfasst ein Flow-Protokoll den gesamten Datenverkehr für ein Subnetz und veröffentlicht die Flow-Protokolldatensätze in Amazon CloudWatch Logs. Das Flow-Protokoll erfasst den Datenverkehr für alle Netzwerkschnittstellen im Subnetz.

Flow-Protokolle für ein Subnetz

Nach dem Erstellen eines Flow-Protokolls kann es einige Minuten dauern, bis Daten erfasst und an den gewünschten Zielen veröffentlicht werden. Flow-Protokolle erfassen keine Echtzeitprotokollstreams für Ihre Netzwerkschnittstellen. Weitere Informationen finden Sie unter Erstellen eines Flow-Protokolls.

Wenn Sie eine Instance in Ihrem Subnetz starten, nachdem Sie ein Flow-Log für Ihr Subnetz oder Ihre VPC erstellt haben, erstellen wir einen Log-Stream (für CloudWatch Logs) oder ein Protokolldatei-Objekt (für Amazon S3) für die neue Netzwerkschnittstelle, sobald Netzwerkverkehr für die Netzwerkschnittstelle vorhanden ist.

Sie können Flow-Protokolle für Netzwerkschnittstellen erstellen, die von anderen AWS -Services erstellt wurden, z. B.:

  • Elastic Load Balancing

  • Amazon RDS

  • Amazon ElastiCache

  • Amazon-Redshift

  • Amazon WorkSpaces

  • NAT-Gateways

  • Transit-Gateways

Unabhängig von der Art der Netzwerkschnittstelle müssen Sie die Amazon EC2-Konsole oder die Amazon EC2-API verwenden, um ein Flow-Protokoll für eine Netzwerkschnittstelle zu erstellen.

Sie können auf Ihre Flow-Protokolle Tags anwenden. Jeder Tag besteht aus einem Schlüssel und einem optionalen Wert, beides können Sie bestimmen. Tags können Ihnen dabei helfen, Ihre Flow-Protokolle zu organisieren, z. B. nach Zweck oder Besitzer.

Wenn Sie ein Flow-Protokoll nicht mehr benötigen, können Sie es löschen. Durch das Löschen eines Flow-Protokolls wird der Flow-Protokoll-Service für die Ressource deaktiviert, so dass keine neuen Flow-Protokollsätze erstellt oder veröffentlicht werden. Durch das Löschen eines Flow-Protokolls werden keine vorhandenen Flow-Protokolldaten gelöscht. Nachdem Sie ein Flow-Protokoll gelöscht haben, können Sie die Flow-Protokolldaten direkt vom Ziel löschen, wenn Sie damit fertig sind. Weitere Informationen finden Sie unter Löschen eines Flow-Protokolls.

Flow-Protokolldatensätze

Ein Flow-Protokolldatensatz repräsentiert einen Netzwerk-Flow in Ihrer VPC. Standardmäßig erfasst jeder Datensatz einen Netzwerk-Internetprotokoll-(IP)-Datenverkehrsfluss (gekennzeichnet durch ein 5-Tupel auf der Basis der einzelnen Netzwerkschnittstellen), der innerhalb eines Aggregationsintervalls auftritt, das auch als Erfassungsfenster bezeichnet wird.

Jeder Datensatz ist ein String mit durch Leerzeichen getrennten Feldern. Der Datensatz enthält Werte für die verschiedenen Komponenten des IP-Flows, zum Beispiel Quelle, Ziel und Protokoll.

Wenn Sie ein Flow-Protokoll erstellen, können Sie das Standardformat für den Flow-Protokolldatensatz verwenden oder ein benutzerdefiniertes Format angeben.

Aggregationsintervall

Das Aggregationsintervall ist der Zeitraum, in dem ein bestimmter Flow erfasst und zu einem Flow-Protokolldatensatz aggregiert wird. Standardmäßig beträgt das maximale Aggregationsintervall 10 Minuten. Wenn Sie ein Flow-Protokoll erstellen, können Sie optional ein maximales Aggregationsintervall von 1 Minute angeben. Flow-Protokolle mit einem maximalen Aggregationsintervall von 1 Minute erzeugen ein höheres Volumen an Flow-Protokoll-Datensätzen als Flow-Protokolle mit einem maximalen Aggregationsintervall von 10 Minuten.

Wenn eine Netzwerkschnittstelle einer Nitro-basierten Instance zugewiesen ist, beträgt das Aggregationsintervall immer 1 Minute oder weniger, unabhängig vom angegebenen maximalen Aggregationsintervall.

Nachdem Daten innerhalb eines Aggregationsintervalls erfasst wurden, nimmt die Verarbeitung und Veröffentlichung der Daten in CloudWatch Logs oder Amazon S3 zusätzliche Zeit in Anspruch. Der Flow Log-Service übermittelt Protokolle in der Regel in etwa 5 Minuten an CloudWatch Logs und in etwa 10 Minuten an Amazon S3. Die Protokollbereitstellung erfolgt jedoch nach bestem Bemühen, und Ihre Protokolle können über die typische Lieferzeit hinaus verzögert werden.

Standardformat

Mit dem Standardformat enthalten die Flow-Protokolldatensätze die Felder der Version 2 in der Reihenfolge, die in der Tabelle Verfügbare Felder angezeigt wird. Das Standardformat kann nicht angepasst oder geändert werden. Um zusätzliche Felder oder eine unterschiedliche Teilmenge an Feldern zu erfassen, müssen Sie stattdessen ein benutzerdefiniertes Format angeben.

Benutzerdefiniertes Format

Mit einem benutzerdefinierten Format geben Sie an, welche Felder in den Flow-Protokolldatensätzen in welcher Reihenfolge enthalten sind. Auf diese Weise können Sie spezifische Flow-Protokolle für Ihre Anforderungen erstellen und Felder auslassen, die nicht relevant sind. Ein benutzerdefiniertes Format kann dazu beitragen, dass weniger separate Prozesse erforderlich sind, um spezifische Informationen aus veröffentlichten Flow-Protokollen zu extrahieren. Sie können eine beliebige Anzahl an verfügbaren Flow-Protokollfeldern angeben, Sie müssen jedoch mindestens eins angeben.

Verfügbare Felder

Die folgende Tabelle beschreibt alle verfügbaren Felder für einen Flow-Protokolldatensatz. In der Spalte Version wird die Version des VPC-Flow-Protokolls angegeben, in der das Feld eingeführt wurde. Das Standardformat enthält alle Felder der Version 2 in der Reihenfolge, in der sie in der Tabelle angezeigt werden.

Beim Veröffentlichen von Flow-Protokoll-Daten in Amazon S3 hängt der Datentyp für die Felder vom Flow-Protokoll-Format ab. Wenn das Format reiner Text ist, sind alle Felder vom Typ STRING. Wenn das Format Parquet ist, lesen Sie die Tabelle für die Felddatentypen.

Wenn ein Feld für einen bestimmten Datensatz nicht anwendbar ist oder nicht verarbeitet werden konnte, wird für diesen Eintrag „-“ angezeigt. Metadatenfelder, die nicht direkt aus dem Paket-Header stammen, sind Best-Effort-Annäherungen, und ihre Werte können fehlen oder ungenau sein.

Feld Beschreibung Version

version

Die Version des VPC-Flow-Protokolls. Wenn Sie das Standardformat verwenden, lautet die Version 2. Wenn Sie ein benutzerdefiniertes Format verwenden, ist die Version die höchste Version unter den angegebenen Feldern. Wenn Sie beispielsweise nur Felder aus Version 2 angeben, lautet die Version 2. Wenn Sie eine Mischung aus Feldern aus den Versionen 2, 3 und 4 angeben, lautet die Version 4.

Parquet-Datentyp: INT_32

 2

account-id

Die AWS Konto-ID des Besitzers der Quellnetzwerkschnittstelle, für die der Datenverkehr aufgezeichnet wird. Wenn die Netzwerkschnittstelle von einem AWS Dienst erstellt wird, z. B. beim Erstellen eines VPC-Endpunkts oder eines Network Load Balancer, wird der Datensatz möglicherweise unknown für dieses Feld angezeigt.

Parquet-Datentyp: STRING

 2

interface-id

Die ID der Netzwerkschnittstelle, für die der Datenverkehr aufgezeichnet wird.

Parquet-Datentyp: SCHNUR

 2

srcaddr

Die Quelladresse für eingehenden Datenverkehr oder die IPv4- oder IPv6-Adresse der Netzwerkschnittstelle für ausgehenden Datenverkehr an der Netzwerkschnittstelle. Die IPv4-Adresse der Netzwerkschnittstelle ist immer deren private IPv4-Adresse. Weitere Informationen finden Sie auch unter pkt-srcaddr.

Parquet-Datentyp: SCHNUR

 2

dstaddr

Die Zieladresse für ausgehenden Datenverkehr oder die IPv4- oder IPv6-Adresse der Netzwerkschnittstelle für eingehenden Datenverkehr an der Netzwerkschnittstelle. Die IPv4-Adresse der Netzwerkschnittstelle ist immer deren private IPv4-Adresse. Weitere Informationen finden Sie auch unter pkt-dstaddr.

Parquet-Datentyp: SCHNUR

 2

srcport

Der Quellport des Datenverkehrs

Parquet-Datentyp: INT_32

 2

dstport

Der Zielport des Datenverkehrs

Parquet-Datentyp: INT_32

 2

protocol

Die IANA-Protokollnummer des Datenverkehrs. Weitere Informationen finden Sie unter Zugewiesene IP-Nummern.

Parquet-Datentyp: INT_32

 2

packets

Die Anzahl der Pakete, die während des Flows übertragen wurden

Parquet-Datentyp: INT_64

 2

bytes

Die Anzahl der Bytes, die während des Flows übertragen wurden

Parquet-Datentyp: INT_64

 2

start

Die Zeit, in Unix-Sekunden, in der das erste Paket des Flows innerhalb des Aggregationsintervalls empfangen wurde. Dies kann bis zu 60 Sekunden dauern, nachdem das Paket auf der Netzwerkschnittstelle übertragen oder empfangen wurde.

Parquet-Datentyp: INT_64

 2

end

Die Zeit, in Unix-Sekunden, in der das letzte Paket des Flows innerhalb des Aggregationsintervalls empfangen wurde. Dies kann bis zu 60 Sekunden dauern, nachdem das Paket auf der Netzwerkschnittstelle übertragen oder empfangen wurde.

Parquet-Datentyp: INT_64

 2

action

Die mit dem Datenverkehr verknüpfte Aktion:

  • ACCEPT – Der Verkehr wurde akzeptiert.

  • REJECT – Der Verkehr wurde abgelehnt. Beispielsweise wurde der Datenverkehr von den Sicherheitsgruppen oder Netzwerk-ACLs nicht zugelassen, oder Pakete kamen an, nachdem die Verbindung geschlossen wurde.

Parquet-Datentyp: STRING

 2

log-status

Der Protokollstatus des Flow-Protokolls:

  • OK – Daten werden normal auf den ausgewählten Zielen protokolliert.

  • NODATA – Es gab während des Aggregationsintervalls keinen Datenverkehr von oder zur Netzwerkschnittstelle.

  • SKIPDATA – Einige Flow-Protokolldatensätze wurden während des Aggregationsintervalls übersprungen. Dies kann an internen Kapazitätsbeschränkungen oder einem internen Fehler liegen.

Parquet-Datentyp: STRING

 2

vpc-id

Die ID der VPC mit der Netzwerkschnittstelle, für die der Datenverkehr aufgezeichnet wird.

Parquet-Datentyp: SCHNUR

 3

subnet-id

Die ID des Subnetzes mit der Netzwerkschnittstelle, für die der Datenverkehr aufgezeichnet wird.

Parquet-Datentyp: SCHNUR

 3

instance-id

Die ID der Instance, die mit der Netzwerkschnittstelle verbunden ist, für die der Datenverkehr aufgezeichnet wird, sofern die Instance Ihnen gehört. Gibt das Symbol '-' für eine vom Anforderer verwaltete Netzwerkschnittstelle zurück, wie beispielsweise die Netzwerkschnittstelle für ein NAT-Gateway.

Parquet-Datentyp: SCHNUR

 3

tcp-flags

Der Bitmasken-Wert für die folgenden TCP-Flags:

  • FIN — 1

  • SYN — 2

  • RST — 4

  • SYN-ACK — 18

Wenn keine unterstützten Flags aufgezeichnet werden, ist der TCP-Flag-Wert 0. Da tcp-flags beispielsweise die Protokollierung von ACK- oder PSH-Flags nicht unterstützt, führen Datensätze für Datenverkehr mit diesen nicht unterstützten Flags zu einem tcp-flags-Wert von 0. Wenn jedoch ein nicht unterstütztes Flag von einem unterstützten Flag begleitet wird, geben wir den Wert des unterstützten Flags an. Wenn ACK beispielsweise Teil von SYN-ACK ist, wird 18 angegeben. Und wenn es einen Datensatz wie SYN+ECE gibt, ist der TCP-Flaggenwert 2, da SYN ein unterstütztes Flag ist und ECE nicht. Wenn die Flag-Kombination aus irgendeinem Grund ungültig ist und der Wert nicht berechnet werden kann, lautet der Wert '-'. Wenn keine Flags gesendet werden, ist der TCP-Flag-Wert 0.

TCP-Flags können während des Aggregationsintervalls ODER-verknüpft werden. Für kurze Verbindungen können die Flags in derselben Zeile im Flow-Protokolldatensatz festgelegt werden, wie beispielsweise 19 für SYN-ACK und FIN und 3 für SYN und FIN. Ein Beispiel finden Sie unter TCP-Flag-Sequenz.

Allgemeine Informationen zu TCP-Flags (z. B. die Bedeutung von Flags wie FIN, SYN und ACK) finden Sie unter TCP-Segmentstruktur auf Wikipedia.

Parquet-Datentyp: INT_32

 3

type

Der Typ des Datenverkehrs. Die möglichen Werte sind: IPv4 | IPv6 | EFA. Weitere Informationen finden Sie unter Elastic Fabric Adapter.

Parquet-Datentyp: STRING

 3

pkt-srcaddr

Die (ursprüngliche) Quell-IP-Adresse des Datenverkehrs auf Paketebene. Verwenden Sie dieses Feld mit dem Feld srcaddr, um zwischen der IP-Adresse einer Zwischenebene, durch die Datenverkehr fließt, und der ursprünglichen Quell-IP-Adresse des Datenverkehrs zu unterscheiden. Beispiel: Wenn Datenverkehr durch eine Netzwerkschnittstelle für ein NAT-Gateway fließt oder wenn die IP-Adresse eines Pods in Amazon EKS von der IP-Adresse der Netzwerkschnittstelle des Instance-Knotens abweicht, auf dem der Pod (für die Kommunikation innerhalb der VPC) ausgeführt wird.

Parquet-Datentyp: SCHNUR

 3

pkt-dstaddr

Die (ursprüngliche) Ziel-IP-Adresse für den Datenverkehr auf Paketebene. Verwenden Sie dieses Feld mit dem Feld dstaddr, um zwischen der IP-Adresse einer Zwischenebene, durch die Datenverkehr fließt, und der endgültigen Ziel-IP-Adresse des Datenverkehrs zu unterscheiden. Beispiel: Wenn Datenverkehr durch eine Netzwerkschnittstelle für ein NAT-Gateway fließt oder wenn die IP-Adresse eines Pods in Amazon EKS von der IP-Adresse der Netzwerkschnittstelle des Instance-Knotens abweicht, auf dem der Pod (für die Kommunikation innerhalb der VPC) ausgeführt wird.

Parquet-Datentyp: SCHNUR

 3

region

Die Region, die die Netzwerkschnittstelle enthält, für die der Datenverkehr aufgezeichnet wird.

Parquet-Datentyp: SCHNUR

4

az-id

Die ID der Availability Zone, die die Netzwerkschnittstelle enthält, für die der Datenverkehr aufgezeichnet wird. Wenn der Datenverkehr von einem untergeordneten Standort stammt, zeigt der Datensatz das Symbol „-“ für dieses Feld an.

Parquet-Datentyp: SCHNUR

4

sublocation-type

Der Typ des untergeordneten Standorts, der im Feld sublocation-id zurückgegeben wird. Die möglichen Werte sind: wavelength | outpost | localzone. Wenn der Datenverkehr nicht von einem untergeordneten Standort stammt, zeigt der Datensatz das Symbol „-“ für dieses Feld an.

Parquet-Datentyp: SCHNUR

4

sublocation-id

Die ID des untergeordneten Standorts mit der Netzwerkschnittstelle, für die der Datenverkehr aufgezeichnet wird. Wenn der Datenverkehr nicht von einem untergeordneten Standort stammt, zeigt der Datensatz das Symbol „-“ für dieses Feld an.

Parquet-Datentyp: SCHNUR

4

pkt-src-aws-service

Der Name der Teilmenge der IP-Adressbereiche für das pkt-srcaddr Feld, wenn die Quell-IP-Adresse für einen AWS Dienst bestimmt ist. Wenn pkt-srcaddr zu einem überlappenden Bereich gehört, pkt-src-aws-service wird nur einer der Dienstcodes angezeigt. AWS Die möglichen Werte sind: AMAZON | AMAZON_APPFLOW | AMAZON_CONNECT | API_GATEWAY | CHIME_MEETINGS | CHIME_VOICECONNECTOR | CLOUD9 | CLOUDFRONT | CODEBUILD | DYNAMODB | EBS | EC2 | EC2_INSTANCE_CONNECT | GLOBALACCELERATOR | KINESIS_VIDEO_STREAMS | ROUTE53 | ROUTE53_HEALTHCHECKS | ROUTE53_HEALTHCHECKS_PUBLISHING | ROUTE53_RESOLVER | S3 | WORKSPACES_GATEWAYS.

Parquet-Datentyp: SCHNUR

5

pkt-dst-aws-service

Der Name der Teilmenge der IP-Adressbereiche für das pkt-dstaddr Feld, wenn die Ziel-IP-Adresse für einen Dienst bestimmt ist. AWS Eine Liste möglicher Werte finden Sie im Feld pkt-src-aws-service.

Parquet-Datentyp: SCHNUR

5

flow-direction

Die Richtung des Flusses in Bezug auf die Schnittstelle, an der der Verkehr erfasst wird. Die möglichen Werte sind: ingress | egress.

Parquet-Datentyp: SCHNUR

5

traffic-path

Der Weg, der ausgehenden Verkehr zum Ziel führt. Um festzustellen, ob es sich bei dem Verkehr um einen ausgehenden Verkehr handelt, überprüfen Sie die Feld flow-direction. Die möglichen Werte lauten wie folgt: Wenn keiner der Werte zutrifft, wird für das Feld „-“ angezeigt.

  • 1 – Über eine andere Ressource in derselben VPC, einschließlich Ressourcen, die eine Netzwerkschnittstelle in der VPC erstellen

  • 2 – Über ein Internet-Gateway oder einen Gateway-VPC-Endpunkt

  • 3 – Über ein Virtual Private Gateway

  • 4– Über eine VPC-Peering-Verbindung innerhalb von Regionen

  • 5 – Über eine VPC-Peering-Verbindung zwischen Regionen

  • 6 – Über ein lokales Gateway

  • 7 – Über einen Gateway-VPC-Endpunkt (nur auf Nitro-basierte Instances)

  • 8 – Über ein Internet-Gateway (nur auf Nitro-basierte Instances)

Parquet-Datentyp: INT_32

5

ecs-cluster-arn

AWS Ressourcenname (ARN) des ECS-Clusters, wenn der Datenverkehr von einer laufenden ECS-Task stammt. Um dieses Feld in Ihr Abonnement aufzunehmen, benötigen Sie die Erlaubnis, ecs: aufzurufenListClusters.

Parquet-Datentyp: STRING

7

ecs-Clustername

Name des ECS-Clusters, wenn der Datenverkehr von einer laufenden ECS-Task stammt. Um dieses Feld in Ihr Abonnement aufzunehmen, benötigen Sie die Erlaubnis, ecs: aufzurufenListClusters.

Parquet-Datentyp: STRING

7

ecs-container-instance-arn

ARN der ECS-Container-Instance, wenn der Datenverkehr von einer laufenden ECS-Task auf einer EC2-Instance stammt. Wenn es sich bei dem Kapazitätsanbieter um einen AWS Fargate solchen handelt, lautet dieses Feld '-'. Um dieses Feld in Ihr Abonnement aufzunehmen, benötigen Sie die Erlaubnis, ecs: - ListClusters und ecs: ListContainer -Instances aufzurufen.

Parquet-Datentyp: STRING

7

ecs-container-instance-id

ID der ECS-Container-Instance, wenn der Datenverkehr von einer laufenden ECS-Task auf einer EC2-Instance stammt. Wenn es sich bei dem Kapazitätsanbieter um einen AWS Fargate solchen handelt, lautet dieses Feld '-'. Um dieses Feld in Ihr Abonnement aufzunehmen, benötigen Sie die Erlaubnis, ecs: - ListClusters und ecs: ListContainer -Instances aufzurufen.

Parquet-Datentyp: STRING

7

ecs-container-id

Docker-Laufzeit-ID des Containers, wenn der Datenverkehr von einer laufenden ECS-Task stammt. Wenn die ECS-Aufgabe einen oder mehrere Container enthält, ist dies die Docker-Laufzeit-ID des ersten Containers. Um dieses Feld in Ihr Abonnement aufzunehmen, benötigen Sie die Erlaubnis, ecs: ListClusters aufzurufen.

Parquet-Datentyp: STRING

7

ecs-second container-id

Docker-Laufzeit-ID des Containers, wenn der Datenverkehr von einer laufenden ECS-Task stammt. Wenn die ECS-Aufgabe mehr als einen Container enthält, ist dies die Docker-Runtime-ID des zweiten Containers. Um dieses Feld in Ihr Abonnement aufzunehmen, benötigen Sie die Erlaubnis, ecs: ListClusters aufzurufen.

Parquet-Datentyp: STRING

7

ecs-Dienstname

Name des ECS-Dienstes, wenn der Datenverkehr von einer laufenden ECS-Task stammt und die ECS-Task von einem ECS-Service gestartet wird. Wenn die ECS-Aufgabe nicht von einem ECS-Service gestartet wird, lautet dieses Feld '-'. Um dieses Feld in Ihr Abonnement aufzunehmen, benötigen Sie die Erlaubnis, ecs: ListClusters und ecs: ListServices aufzurufen.

Parquet-Datentyp: STRING

7

ecs-task-definition-arn

ARN der ECS-Aufgabendefinition, wenn der Datenverkehr von einer laufenden ECS-Task stammt. Um dieses Feld in Ihr Abonnement aufzunehmen, benötigen Sie die Erlaubnis, ecs: ListClusters und ecs aufzurufen: ListTaskDefinitions

Parquet-Datentyp: STRING

7

ecs-task-arn

ARN der ECS-Task, wenn der Datenverkehr von einer laufenden ECS-Task stammt. Um dieses Feld in Ihr Abonnement aufzunehmen, benötigen Sie die Erlaubnis, ecs: ListClusters und ecs: aufzurufenListTasks.

Parquet-Datentyp: STRING

7

ecs-task-id

ID der ECS-Task, wenn der Datenverkehr von einer laufenden ECS-Task stammt. Um dieses Feld in Ihr Abonnement aufzunehmen, benötigen Sie die Erlaubnis, ecs: ListClusters und ecs: aufzurufenListTasks.

Parquet-Datentyp: STRING

7

Einschränkungen von Flow-Protokollen

Machen Sie sich bei der Verwendung von Flow-Protokollen folgende Beschränkungen bewusst:

  • Es ist nicht möglich, Flow-Protokolle für VPCs zu aktivieren, die per Peering mit Ihrer VPC verbunden sind, es sei denn, die Peer-VPC befindet sich in Ihrem Konto.

  • Nachdem Sie ein Flow-Protokoll erstellt haben, können Sie seine Konfiguration und das Format des Flow-Protokolldatensatzes nicht mehr ändern. Sie können beispielsweise keine andere IAM-Rolle mit dem Flow-Protokoll verknüpfen und keine Felder zum Flow-Protokolldatensatz hinzufügen oder daraus entfernen. Sie müssen in diesem Fall das Flow-Protokoll löschen und ein neues Protokoll mit der erforderlichen Konfiguration erstellen.

  • Falls Ihre Netzwerkschnittstelle über mehrere IPv4-Adressen verfügt und Datenverkehr an eine sekundäre private IPv4-Adresse gesendet wird, zeigt das Flow-Protokoll die primäre private IPv4-Adresse im Feld dstaddr an. Erstellen Sie ein Flow-Protokoll mit dem Feld pkt-dstaddr, um die ursprüngliche Ziel-IP-Adresse zu erfassen.

  • Falls der Datenverkehr an eine Netzwerkschnittstelle gesendet wird und es sich beim Ziel um keine IP-Adresse der Netzwerkschnittstelle handelt, wird im Flow-Protokoll die primäre private IPv4-Adresse im Feld dstaddr angezeigt. Erstellen Sie ein Flow-Protokoll mit dem Feld pkt-dstaddr, um die ursprüngliche Ziel-IP-Adresse zu erfassen.

  • Falls der Datenverkehr von einer Netzwerkschnittstelle gesendet wird und es sich bei der Quelle um keine IP-Adresse der Netzwerkschnittstelle handelt, wird im Flow-Protokoll die primäre private IPv4-Adresse im Feld srcaddr angezeigt. Erstellen Sie ein Flow-Protokoll mit dem Feld pkt-srcaddr, um die ursprüngliche Quell-IP-Adresse zu erfassen.

  • Falls der Datenverkehr von oder an eine Netzwerkschnittstelle gesendet wird, zeigen die Felder srcaddr und dstaddr im Flow-Protokoll unabhängig von Paketquelle oder -ziel stets die primäre private IPv4-Adresse an. Erstellen Sie ein Flow-Protokoll mit den Feldern pkt-srcaddr und pkt-dstaddr, um Paketquelle oder -ziel zu erfassen.

  • Wenn Ihre Netzwerkschnittstelle einer Nitro-basierten Instance zugewiesen ist, beträgt das Aggregationsintervall immer 1 Minute oder weniger, unabhängig vom angegebenen maximalen Aggregationsintervall.

Flow-Protokolle erfassen nicht alle Arten von IP-Datenverkehr. Für folgende Arten von Datenverkehr werden keine Daten erfasst:

  • Datenverkehr von Instances, die den Amazon-DNS-Server kontaktieren. Wenn Sie einen eigenen DNS-Server verwenden, wird sämtlicher Datenverkehr zu diesem DNS-Server erfasst.

  • Datenverkehr von Windows-Instances zur Lizenzaktivierung von Amazon Windows

  • Datenverkehr zu und von 169.254.169.254 für Instance-Metadaten

  • Datenverkehr zu und von 169.254.169.123 für den Amazon Time Sync Service.

  • DHCP-Datenverkehr

  • Gespiegelter Datenverkehr.

  • Datenverkehr zur reservierten IP-Adresse des Standard-VPC-Routers.

  • Datenverkehr zwischen einer Endpunkt-Netzwerkschnittstelle und einer Network Load Balancer-Netzwerkschnittstelle.

Spezifische Einschränkungen für ECS-Felder, die in Version 7 verfügbar sind:

  • Um Flow-Log-Abonnements mit ECS-Feldern zu erstellen, muss Ihr Konto mindestens einen ECS-Cluster enthalten.

  • ECS-Felder werden nicht berechnet, wenn die zugrunde liegenden ECS-Aufgaben nicht dem Besitzer des Flow-Log-Abonnements gehören. Wenn Sie beispielsweise ein Subnetz (SubnetA) mit einem anderen Konto (AccountB) gemeinsam nutzen und dann ein Flow-Log-Abonnement für den Fall erstellenSubnetA, dass ECS-Aufgaben im gemeinsam genutzten Subnetz AccountB gestartet werden, empfängt Ihr Abonnement Verkehrsprotokolle von ECS-Aufgaben, die von gestartet wurden, AccountB aber die ECS-Felder für diese Protokolle werden aus Sicherheitsgründen nicht berechnet.

  • Wenn Sie Flow-Log-Abonnements mit ECS-Feldern auf VPC-/Subnetz-Ressourcenebene erstellen, wird jeglicher Datenverkehr, der für Nicht-ECS-Netzwerkschnittstellen generiert wird, auch für Ihre Abonnements bereitgestellt. Die Werte für ECS-Felder sind '-' für Nicht-ECS-IP-Verkehr. Sie haben beispielsweise ein Subnetz (subnet-000000) und Sie erstellen ein Flow-Log-Abonnement für dieses Subnetz mit ECS-Feldern (). fl-00000000 In subnet-000000 starten Sie eine EC2-Instance (i-0000000), die mit dem Internet verbunden ist und aktiv IP-Verkehr generiert. Sie starten auch eine laufende ECS-Task (ECS-Task-1) im selben Subnetz. Da i-0000000 sowohl ECS-Task-1 als auch IP-Verkehr generieren, liefert Ihr fl-00000000 Flow-Log-Abonnement Verkehrsprotokolle für beide Entitäten. Es enthält jedoch nur ECS-Task-1 die tatsächlichen ECS-Metadaten für die ECS-Felder, die Sie in Ihr LogFormat aufgenommen haben. Für i-0000000 verwandten Datenverkehr haben diese Felder den Wert '-'.

  • ecs-container-idund ecs-second-container-id werden so bestellt, wie der VPC Flow Logs-Dienst sie vom ECS-Event-Stream empfängt. Es kann nicht garantiert werden, dass sie sich in derselben Reihenfolge befinden, in der Sie sie auf der ECS-Konsole oder im DescribeTask API-Aufruf sehen. Wenn ein Container in den Status GESTOPPT übergeht, während die Aufgabe noch läuft, wird er möglicherweise weiterhin in Ihrem Protokoll angezeigt.

  • Die ECS-Metadaten und IP-Verkehrsprotokolle stammen aus zwei verschiedenen Quellen. Wir beginnen mit der Berechnung Ihres ECS-Datenverkehrs, sobald wir alle erforderlichen Informationen aus den Upstream-Abhängigkeiten erhalten haben. Nachdem Sie eine neue Aufgabe gestartet haben, beginnen wir mit der Berechnung Ihrer ECS-Felder, 1) wenn wir IP-Verkehr für die zugrunde liegende Netzwerkschnittstelle empfangen und 2) wenn wir das ECS-Ereignis erhalten, das die Metadaten für Ihre ECS-Aufgabe enthält, um anzuzeigen, dass die Aufgabe gerade läuft. Nachdem Sie eine Aufgabe beendet haben, beenden wir die Berechnung Ihrer ECS-Felder, 1) wenn wir keinen IP-Verkehr mehr für die zugrunde liegende Netzwerkschnittstelle erhalten oder wenn wir IP-Verkehr erhalten, der um mehr als einen Tag verzögert ist, und 2) wenn wir das ECS-Ereignis erhalten, das die Metadaten für Ihre ECS-Aufgabe enthält, um anzuzeigen, dass Ihre Aufgabe nicht mehr ausgeführt wird.

  • Es werden nur ECS-Aufgaben unterstützt, die im awsvpc Netzwerkmodus gestartet wurden.

Preisgestaltung

Es fallen Datenerfassungs- und Archivierungsgebühren für Verkaufsprotokolle an, wenn Sie Flow-Protokolle veröffentlichen. Weitere Informationen zu den Preisen bei der Veröffentlichung von Verkaufslogs finden Sie unter Amazon CloudWatch Pricing, wählen Sie Logs aus und suchen Sie nach Vended Logs.

Um Gebühren für die Veröffentlichung von Flow-Protokollen in CloudWatch Logs zu verfolgen, können Sie auf Ihre CloudWatch-Logs-Zielprotokollgruppe Kostenzuordnungs-Tags anwenden. Danach umfasst Ihr AWS Kostenzuordnungsbericht die Nutzung und die Kosten, die nach diesen Tags zusammengefasst sind. Sie können Tags anwenden, die geschäftliche Kategorien (wie Kostenstellen, Anwendungsnamen oder Besitzer) darstellen, um die Kosten zu organisieren. Weitere Informationen finden Sie hier: