Standardprotokolle (Zugriffsprotokolle) konfigurieren und verwenden - Amazon CloudFront

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.

Standardprotokolle (Zugriffsprotokolle) konfigurieren und verwenden

Sie können so konfigurieren CloudFront , dass Protokolldateien erstellt werden, die detaillierte Informationen zu jeder CloudFront empfangenen Benutzeranfrage enthalten. Diese werden als Standardprotokolle, oder auch als Zugriffsprotokolle bezeichnet. Wenn Sie Standardprotokolle aktivieren, können Sie auch den Amazon S3 S3-Bucket angeben, in dem Sie Dateien speichern CloudFront möchten.

Sie können Standardprotokolle aktivieren, wenn Sie eine Verteilung erstellen oder aktualisieren. Weitere Informationen finden Sie unter Protokollierung.

CloudFront bietet auch Echtzeitprotokolle, die Ihnen Informationen über Anfragen an eine Distribution in Echtzeit liefern (Protokolle werden innerhalb von Sekunden nach Erhalt der Anfragen zugestellt). Sie können Echtzeitprotokolle verwenden, um basierend auf der Leistung der Bereitstellung von Inhalten Überwachungsaktionen und Analysen auszuführen und Maßnahmen zu ergreifen. Weitere Informationen finden Sie unter Verwenden Sie Echtzeit-Logs.

Funktionsweise der Standardprotokollierung

Das folgende Diagramm zeigt, wie Informationen über Anfragen für Ihre Objekte CloudFront protokolliert werden.

Prinzipieller Ablauf für Zugriffsprotokolle

Im Folgenden wird erklärt, wie Informationen über Anfragen für Ihre Objekte CloudFront protokolliert werden, wie im vorherigen Diagramm dargestellt.

  1. In diesem Diagramm haben Sie zwei Websites, A und B, und zwei entsprechende CloudFront Distributionen. Benutzer fragen Ihre Objekte mithilfe von URLs an, die Ihren Verteilungen zugewiesen sind.

  2. CloudFront leitet jede Anfrage an den entsprechenden Edge-Standort weiter.

  3. CloudFront schreibt Daten zu jeder Anfrage in eine Protokolldatei, die für diese Verteilung spezifisch ist. In diesem Beispiel werden Informationen zu Anfragen mit Bezug auf Verteilung A in einer Protokolldatei nur für Verteilung A gespeichert und Informationen zu Anfragen mit Bezug auf Verteilung B in einer Protokolldatei nur für Verteilung B.

  4. CloudFront speichert regelmäßig die Protokolldatei für eine Distribution im Amazon S3 S3-Bucket, den Sie bei der Aktivierung der Protokollierung angegeben haben. CloudFront beginnt dann, Informationen über nachfolgende Anfragen in einer neuen Protokolldatei für die Verteilung zu speichern.

Wenn eine Stunde lang kein Benutzer auf Ihre Inhalte zugreift, erhalten Sie für diesen Zeitraum auch keine Protokolldateien.

Jeder Eintrag in einer Protokolldatei enthält detaillierte Informationen zu den einzelnen Anfragen. Weitere Informationen zum Format der Protokolldateien finden Sie unter Dateiformat des Standardprotokolls.

Anmerkung

Wir empfehlen Ihnen, die Protokolle zu verwenden, um die Art der Anfragen nach Ihren Inhalten zu verstehen, und nicht, um alle Anfragen vollständig zu erfassen. CloudFront stellt Zugriffsprotokolle nach bestem Wissen und Gewissen bereit. Der Protokolleintrag für eine bestimmte Anfrage wird möglicherweise viel später übermittelt, als die Anfrage tatsächlich verarbeitet wurde; in seltenen Fällen kann es auch sein, dass ein Protokolleintrag gar nicht übermittelt wird. Wenn ein Protokolleintrag in den Zugriffsprotokollen weggelassen wird, entspricht die Anzahl der Einträge in den Zugriffsprotokollen nicht der Nutzung, die in den AWS Abrechnungs- und Nutzungsberichten angegeben ist.

Wählen Sie einen Amazon S3 S3-Bucket für Standardprotokolle

Wenn Sie die Protokollierung für eine Distribution aktivieren, geben Sie den Amazon S3 S3-Bucket CloudFront an, in dem Sie Protokolldateien speichern möchten. Wenn Sie Amazon S3 als Ihren Ursprung verwenden, empfehlen wir Ihnen, einen separaten Bucket für Ihre Protokolldateien zu verwenden.

Sie können Protokolldateien für mehrere Verteilungen in demselben Bucket speichern. Wenn Sie die Protokollierung aktivieren, können Sie ein optionales Präfix für den Dateinamen festlegen; so behalten Sie den Überblick darüber, welche Protokolldateien welchen Verteilungen zugeordnet sind.

Über die Auswahl eines S3-Buckets
  • In Ihrem Bucket muss die Zugriffskontrollliste (ACL) aktiviert sein. Wenn Sie in der CloudFront Konsole einen Bucket ohne aktivierte ACL auswählen, wird eine Fehlermeldung angezeigt. Siehe Für die Konfiguration der Standardprotokollierung und für den Zugriff auf Protokolldateien sind Berechtigungen erforderlich.

  • Wählen Sie keinen Amazon-S3-Bucket, wenn S3-Objekteigentümerschaft auf Bucket-Eigentümer erzwungen festgelegt ist. Diese Einstellung deaktiviert ACLs für den Bucket und die darin enthaltenen Objekte, wodurch CloudFront verhindert wird, dass Protokolldateien an den Bucket gesendet werden.

  • Wählen Sie im Folgenden keinen Amazon S3 S3-Bucket aus AWS-Regionen. CloudFront liefert keine Standardprotokolle an Buckets in diesen Regionen:

    • Afrika (Kapstadt)

    • Asien-Pazifik (Hongkong)

    • Asien-Pazifik (Hyderabad)

    • Asien-Pazifik (Jakarta)

    • Asien-Pazifik (Melbourne)

    • Kanada West (Calgary)

    • Europa (Milan)

    • Europa (Spain)

    • Europa (Zürich)

    • Israel (Tel Aviv)

    • Naher Osten (Bahrain)

    • Naher Osten (VAE)

Für die Konfiguration der Standardprotokollierung und für den Zugriff auf Protokolldateien sind Berechtigungen erforderlich

Wichtig

Ab April 2023 müssen Sie S3-ACLs für neue S3-Buckets aktivieren, die für CloudFront Standardprotokolle verwendet werden. Sie können ACLs aktivieren, wenn Sie einen Bucket erstellen, oder ACLs für einen vorhandenen Bucket aktivieren.

Weitere Informationen zu den Änderungen finden Sie unter Häufig gestellte Fragen zu Standardeinstellungen für neue S3-Buckets im Benutzerhandbuch zu Amazon Simple Storage Service und unter Achtung: Sicherheitsänderungen in Amazon S3 im April 2023 im AWS News-Blog.

Sie AWS-Konto müssen über die folgenden Berechtigungen für den Bucket verfügen, den Sie für Protokolldateien angeben:

  • Die ACL für den Bucket muss Ihnen gewährenFULL_CONTROL. Wenn Sie der Bucket-Eigentümer sind, verfügt Ihr Konto standardmäßig über diese Berechtigung. Sind Sie das nicht, muss der Bucket-Eigentümer die ACL für den Bucket aktualisieren.

  • s3:GetBucketAcl

  • s3:PutBucketAcl

ACL für den Bucket

Wenn Sie eine Distribution erstellen oder aktualisieren und die Protokollierung aktivieren, CloudFront verwendet diese Berechtigungen, um die ACL für den Bucket zu aktualisieren, um dem awslogsdelivery Konto die entsprechenden Berechtigungen zu FULL_CONTROL erteilen. Das awslogsdelivery-Konto schreibt Protokolldateien in den Bucket. Wenn Ihr Konto nicht über die erforderlichen Berechtigungen zum Aktualisieren der ACL verfügt, schlägt das Erstellen oder Aktualisieren der Verteilung fehl.

Wenn Sie programmgesteuert eine Anfrage senden, um einen Bucket zu erstellen, aber ein Bucket mit dem angegebenen Namen bereits vorhanden ist, setzt S3 in einigen Fällen die Berechtigungen für den Bucket auf den Standardwert zurück. Wenn Sie das Speichern von Zugriffsprotokollen in einem S3-Bucket konfiguriert CloudFront haben und Sie keine Protokolle mehr in diesem Bucket abrufen, überprüfen Sie die Berechtigungen für den Bucket, um sicherzustellen, dass dieser CloudFront über die erforderlichen Berechtigungen verfügt.

Wiederherstellung der ACL für den Bucket

Wenn Sie die Berechtigungen für das awslogsdelivery Konto entfernen, können CloudFront keine Logs im S3-Bucket gespeichert werden. Um wieder mit dem Speichern von Protokollen für Ihre Distribution beginnen CloudFront zu können, stellen Sie die ACL-Berechtigung wieder her, indem Sie einen der folgenden Schritte ausführen:

  • Deaktivieren Sie die Protokollierung für Ihre Distribution und aktivieren Sie sie dann erneut. CloudFront Weitere Informationen finden Sie unter Protokollierung.

  • Fügen Sie die ACL-Berechtigung für awslogsdelivery manuell hinzu, indem Sie in der Amazon S3-Konsole zu dem S3-Bucket gehen und die Berechtigung hinzufügen. Um die ACL für awslogsdelivery hinzuzufügen, müssen Sie die kanonische ID für das Konto angeben, nämlich:

    c4c1ede66af53448b93c283ce9448c4ba468c9432aa01d700d3878632f77d2d0

    Weitere Informationen zum Hinzufügen von ACLs zu S3-Buckets finden Sie unter Configuring ACLs im Amazon Simple Storage Service User Guide.

ACL für jede Protokolldatei

Neben der ACL für den Bucket gibt es auch ACLs für jede einzelne Protokolldatei. Der Bucket-Eigentümer verfügt für jede Protokolldatei über die Berechtigung FULL_CONTROL, der Eigentümer der Verteilung (wenn dieser vom Bucket-Eigentümer abweicht) hat keine Berechtigung und das awslogsdelivery-Konto verfügt über Lese- und Schreibberechtigungen.

Deaktivieren der Protokollierung

Wenn Sie die Protokollierung deaktivieren, CloudFront werden die ACLs weder für den Bucket noch für die Protokolldateien gelöscht. Sie können die ACLs bei Bedarf löschen.

Erforderliche Schlüsselrichtlinie für SSE-KMS Buckets

Wenn der S3-Bucket für Ihre Standardprotokolle serverseitige Verschlüsselung mit AWS KMS keys (SSE-KMS) unter Verwendung eines kundenverwalteten Schlüssels verwendet, müssen Sie der Schlüsselrichtlinie für Ihren kundenverwalteten Schlüssel die folgende Anweisung hinzufügen: Dies ermöglicht CloudFront das Schreiben von Protokolldateien in den Bucket. Sie können SSE-KMS nicht mit dem verwenden Von AWS verwalteter Schlüssel , da CloudFront dann keine Protokolldateien in den Bucket geschrieben werden können.

{ "Sid": "Allow CloudFront to use the key to deliver logs", "Effect": "Allow", "Principal": { "Service": "delivery.logs.amazonaws.com" }, "Action": "kms:GenerateDataKey*", "Resource": "*" }

Wenn der S3-Bucket für Ihre Standardprotokolle SSE-KMS mit einem S3-Bucket-Schlüssel verwendet, müssen Sie auch die kms:Decrypt-Berechtigung zur Richtlinienanweisung hinzufügen. In diesem Fall sieht die vollständige Richtlinienanweisung wie folgt aus.

{ "Sid": "Allow CloudFront to use the key to deliver logs", "Effect": "Allow", "Principal": { "Service": "delivery.logs.amazonaws.com" }, "Action": [ "kms:GenerateDataKey*", "kms:Decrypt" ], "Resource": "*" }

Dateinamenformat

Der Name jeder Protokolldatei, die in Ihrem Amazon S3 S3-Bucket CloudFront gespeichert wird, verwendet das folgende Dateinamenformat:

<optional prefix>/<distribution ID>.YYYY-MM-DD-HH.unique-ID.gz

Datum und Uhrzeit entsprechen der Zeitzone UTC (Coordinated Universal Time).

Wenn Sie beispielsweise example-prefix als Präfix verwenden und Ihre Verteilungs-ID EMLARXS9EXAMPLE lautet, sehen Ihre Dateinamen folgendermaßen aus:

example-prefix/EMLARXS9EXAMPLE.2019-11-14-20.RT4KCN4SGK9.gz

Wenn Sie die Protokollierung für eine Verteilung aktivieren, können Sie ein optionales Präfix für den Dateinamen festlegen; so behalten Sie den Überblick darüber, welche Protokolldateien welchen Verteilungen zugeordnet sind. Wenn Sie einen Wert für das Präfix der Protokolldatei angeben und Ihr Präfix nicht mit einem Schrägstrich (/) CloudFront endet, wird automatisch einer angehängt. Wenn Ihr Präfix mit einem Schrägstrich endet, wird CloudFront kein weiterer hinzugefügt.

Das .gz Ende des Dateinamens weist darauf hin, dass die Protokolldatei mit gzip komprimiert CloudFront wurde.

Zeitplan der Dateizustellung von Standardprotokollen

CloudFront liefert Standardprotokolle für eine Verteilung bis zu mehrmals pro Stunde. Im Allgemeinen enthält eine Protokolldatei Informationen über die Anfragen, die während eines bestimmten Zeitraums CloudFront eingegangen sind. CloudFront übermittelt die Protokolldatei für diesen Zeitraum normalerweise innerhalb einer Stunde nach den Ereignissen, die im Protokoll erscheinen, an Ihren Amazon S3 S3-Bucket. Beachten Sie jedoch, dass einige oder auch alle Protokolldateieinträge für einen bestimmten Zeitraum manchmal mit einer Verzögerung von bis zu 24 Stunden übermittelt werden können. Wenn Protokolleinträge verzögert werden, werden sie in einer Protokolldatei CloudFront gespeichert, deren Dateiname das Datum und die Uhrzeit des Zeitraums enthält, in dem die Anfragen aufgetreten sind, nicht das Datum und die Uhrzeit der Zustellung der Datei.

Bei der Erstellung einer Protokolldatei werden Informationen für Ihre Verteilung von allen Edge-Standorten CloudFront konsolidiert, die während des Zeitraums, den die Protokolldatei abdeckt, Anfragen für Ihre Objekte erhalten haben.

CloudFront kann mehr als eine Datei für einen bestimmten Zeitraum speichern, je nachdem, wie viele Anfragen für CloudFront die mit einer Verteilung verknüpften Objekte eingehen.

CloudFront beginnt etwa vier Stunden, nachdem Sie die Protokollierung aktiviert haben, mit der zuverlässigen Bereitstellung von Zugriffsprotokollen. Möglicherweisen erhalten Sie ein paar Zugriffsprotokolle auch schon vorher.

Anmerkung

Wenn während eines bestimmten Zeitraums Ihre Objekte nicht von Benutzern angefordert werden, erhalten Sie keine Protokolldateien für diesen Zeitraum.

CloudFront bietet außerdem Echtzeitprotokolle, die Ihnen Informationen über Anfragen an eine Distribution in Echtzeit liefern (Protokolle werden innerhalb von Sekunden nach Eingang der Anfragen zugestellt). Sie können Echtzeitprotokolle verwenden, um basierend auf der Leistung der Bereitstellung von Inhalten Überwachungsaktionen und Analysen auszuführen und Maßnahmen zu ergreifen. Weitere Informationen finden Sie unter Verwenden Sie Echtzeit-Logs.

Protokollierung von Anforderungen, wenn Anforderungs-URL oder Header die maximale Größe überschreiten

Wenn die Gesamtgröße aller Anforderungsheader, einschließlich Cookies, 20 KB überschreitet oder wenn die URL 8192 Byte überschreitet, CloudFront kann die Anfrage nicht vollständig analysiert und die Anfrage nicht protokolliert werden. Da die Anfrage nicht protokolliert wird, wird in den Protokolldateien der HTTP-Fehler-Statuscode nicht zurückgegeben.

Wenn der Anfragetext die maximale Größe überschreitet, wird die Anfrage einschließlich des HTTP-Fehlerstatuscodes protokolliert.

Analysieren Sie Standardprotokolle

Da Sie mehrere Zugriffsprotokolle pro Stunde erhalten können, empfehlen wir, alle für einen bestimmten Zeitraum erhaltenen Protokolldateien in einer Datei zusammenzufassen. Sie können die Daten für diesen Zeitraum dann genauer und vollständig analysieren.

Eine Möglichkeit, Ihre Zugriffsprotokolle zu analysieren, ist die Verwendung von Amazon Athena;. Athena ist ein interaktiver Abfragedienst, mit dem Sie Daten für AWS Dienste analysieren können, darunter CloudFront. Weitere Informationen finden Sie unter Abfragen von CloudFront Amazon-Protokollen im Amazon Athena-Benutzerhandbuch.

Darüber hinaus werden in den folgenden AWS Blogbeiträgen einige Möglichkeiten zur Analyse von Zugriffsprotokollen erörtert.

Wichtig

Wir empfehlen Ihnen, die Protokolle zu verwenden, um die Art der Anfragen nach Ihren Inhalten nachzuvollziehen, und nicht, um alle Anfragen vollständig zu erfassen. CloudFront stellt Zugriffsprotokolle nach bestem Wissen und Gewissen bereit. Der Protokolleintrag für eine bestimmte Anfrage wird möglicherweise viel später übermittelt, als die Anfrage tatsächlich verarbeitet wurde; in seltenen Fällen kann es auch sein, dass ein Protokolleintrag gar nicht übermittelt wird. Wenn ein Protokolleintrag in den Zugriffsprotokollen weggelassen wird, entspricht die Anzahl der Einträge in den Zugriffsprotokollen nicht der Nutzung, die in den AWS Nutzungs- und Abrechnungsberichten angegeben ist.

Bearbeiten Sie die Standardprotokollierungseinstellungen

Sie können die Protokollierung aktivieren oder deaktivieren, den Amazon S3 S3-Bucket ändern, in dem Ihre Protokolle gespeichert sind, und das Präfix für Protokolldateien ändern, indem Sie die CloudFront Konsole oder die CloudFront API verwenden. Ihre Änderungen der Protokollierungseinstellungen werden innerhalb von 12 Stunden wirksam.

Weitere Informationen finden Sie unter den folgenden Themen:

  • Informationen zum Aktualisieren einer Distribution mithilfe der CloudFront Konsole finden Sie unterEine Verteilung aktualisieren.

  • Informationen zum Aktualisieren einer Distribution mithilfe der CloudFront API finden Sie UpdateDistributionin der Amazon CloudFront API-Referenz.

Löschen Sie Standardprotokolldateien aus einem Amazon S3 S3-Bucket

CloudFront löscht Protokolldateien nicht automatisch aus Ihrem Amazon S3 S3-Bucket. Weitere Informationen zum Löschen von Protokolldateien in einem Amazon S3-Bucket finden Sie in den folgenden Themen:

  • Verwenden der Amazon S3-Konsole: Löschen von Objekten im Amazon Simple Storage Service-Konsole-Benutzerhandbuch.

  • Verwendung der REST-API: DeleteObjectin der Amazon Simple Storage Service API-Referenz.

Dateiformat des Standardprotokolls

Jeder Eintrag in einer Protokolldatei enthält detaillierte Informationen zu den einzelnen Viewer-Anfragen. Die Protokolldateien weisen folgende Merkmale auf:

  • Sie verwenden das erweiterte W3C-Format für Protokolldateien.

  • Sie enthalten tabulatorgetrennte Werte.

  • Sie enthalten Datensätze in nicht unbedingt chronologischer Reihenfolge.

  • Sie enthalten zwei Headerzeilen: eine mit der Version des Dateiformats und eine andere mit den W3C-Feldern für jeden einzelnen Datensatz.

  • Sie enthalten URL-codierte Äquivalente für Leerzeichen und bestimmte andere Zeichen in Feldwerten.

    URL-kodierte Äquivalente werden für die folgenden Zeichen verwendet:

    • ASCII-Zeichencodes 0 bis 32, inklusive

    • ASCII-Zeichencodes 127 und höher

    • Alle Zeichen in der folgenden Tabelle

    Der URL-Codierungsstandard ist in RFC 1738 definiert.

URL-codierter Wert

Zeichen

%3C

<

%3E

>

%22

"

%23

#

%25

%

%7B

{

%7D

}

%7C

|

%5C

\

%5E

^

%7E

~

%5B

[

%5D

]

%60

`

%27

'

%20

Leerzeichen

Felder der Standardprotokolldatei

Die Protokolldatei für eine Verteilung enthält 33 Felder. Die folgende Liste enthält jeden Feldnamen in der Reihenfolge sowie eine Beschreibung der Informationen in diesem Feld.

  1. date

    Das Datum, an dem das Ereignis aufgetreten ist, im Format YYYY-MM-DD. Beispiel, 2019-06-30. Datum und Uhrzeit entsprechen der Zeitzone UTC (Coordinated Universal Time). Bei WebSocket Verbindungen ist dies das Datum, an dem die Verbindung geschlossen wurde.

  2. time

    Die Uhrzeit, zu der der CloudFront Server die Anfrage nicht mehr beantwortet hat (in UTC), 01:42:39 z. B. Bei WebSocket Verbindungen ist dies der Zeitpunkt, zu dem die Verbindung geschlossen wird.

  3. x-edge-location

    Der Edge-Standort, an dem die Anfrage verarbeitet wurde. Jeder Edge-Standort wird anhand eines Codes aus drei Buchstaben und einer willkürlich zugewiesenen Zahl identifiziert, z. B. DFW3. Der Code aus drei Buchstaben entspricht in der Regel dem Code der International Air Transport Association (IATA) für einen Flughafen in der Nähe des Edge-Standorts. (Diese Abkürzungen ändern sich möglicherweise in der Zukunft.)

  4. sc-bytes

    Die Gesamtzahl der Bytes, die der Server als Antwort auf die Anforderung an den Viewer übermittelt hat, einschließlich Headern. Bei WebSocket Verbindungen ist dies die Gesamtzahl der Byte, die über die Verbindung vom Server an den Client gesendet werden.

  5. c-ip

    Die IP-Adresse des Betrachters, die der Anfrage gestellt hat, z. B. 192.0.2.183 oder 2001:0db8:85a3::8a2e:0370:7334. Wenn der Viewer einen HTTP-Proxy oder eine Load Balancer verwendet hat, um die Anforderung zu senden, entspricht der Wert dieses Feldes der IP-Adresse des Proxys bzw. des Load Balancers. Siehe auch das Feld x-forwarded-for.

  6. cs-method

    Die vom Viewer empfangene HTTP-Anforderungsmethode.

  7. cs(Host)

    Der Domainname der CloudFront Distribution (z. B. d111111abcdef8.cloudfront.net).

  8. cs-uri-stem

    Der Teil der Anforderungs-URL, der den Pfad und das Objekt identifiziert (z. B, /images/cat.jpg). Fragezeichen (?) in URLs und Abfragezeichenfolgen sind nicht im Protokoll enthalten.

  9. sc-status

    Enthält einen der folgenden Werte:

    • Den HTTP-Statuscode der Antwort des Servers (z. B. 200).

    • 000, was anzeigt, dass der Viewer die Verbindung geschlossen hat, bevor der Server auf die Anforderung antworten konnte. Wenn der Viewer die Verbindung schließt, nachdem der Server mit dem Senden der Antwort begonnen hat, enthält dieses Feld den HTTP-Statuscode der Antwort, mit deren Senden der Server begonnen hatte.

  10. cs(Referer)

    Der Wert für den Referer-Header in der Anfrage. Der Name der Domäne, von der die Anforderung ausgegangen ist. Häufig vorkommende Referrer sind Suchmaschinen, andere Websites, die direkt auf Ihre Objekte verlinken, und Ihre eigene Website.

  11. cs(User-Agent)

    Der Wert für den User-Agent-Header in der Anfrage. Der User-Agent-Header bezeichnet die Quelle für die Anforderung, z. B. den Gerätetyp und den Browser, der die Anforderung abgesendet hat, oder die Suchmaschine, wenn die Anforderung von einer Suchmaschine stammt.

  12. cs-uri-query

    Der Teil der Anforderungs-URL mit der Abfragezeichenfolge, wenn vorhanden.

    Wenn eine URL keine Abfragezeichenfolge enthält, ist der Wert dieses Felds ein Bindestrich (-). Weitere Informationen finden Sie unter Cache-Inhalt auf der Grundlage von Abfragezeichenfolgenparametern.

  13. cs(Cookie)

    Der Cookie-Header in der Anforderung einschließlich der Name-Wert-Paaren und zugehörigen Attributen.

    Wenn Sie die Cookie-Protokollierung aktivieren, werden die Cookies bei allen Anfragen CloudFront protokolliert, unabhängig davon, welche Cookies Sie an den Ursprung weiterleiten. Wenn eine Anforderung keinen Cookie-Header enthält, ist der Wert dieses Felds ein Bindestrich (-). Weitere Informationen zu Cookies finden Sie unter Auf Cookies basierender Inhalt zwischenspeichern.

  14. x-edge-result-type

    Art der Klassifizierung der Antwort durch den Server, nachdem das letzte Byte den Server verlassen hat. Manchmal wird der Ergebnistyp zwischen dem Zeitpunkt, an dem Server zum Senden der Antwort bereit ist, und dem Zeitpunkt, an dem er das Senden der Antwort abgeschlossen hat, geändert. Siehe auch das Feld x-edge-response-result-type.

    Angenommen, im HTTP-Streaming findet der Server ein Segment des Streams im Cache. In diesem Szenario würde der Wert dieses Feldes normalerweise sei Hit. Wenn der Viewer jedoch die Verbindung schließt, bevor der Server das ganze Segment übermittelt hat, ist der endgültige Ergebnistyp (und damit der Wert dieses Felds) Error.

    WebSocket Verbindungen haben Miss für dieses Feld den Wert von, da der Inhalt nicht zwischengespeichert werden kann und direkt an den Ursprung weitergeleitet wird.

    Mögliche Werte sind:

    • Hit – Der Server hat das Objekt aus dem Cache für den Betrachter bereitgestellt.

    • RefreshHit – Der Server hat das Objekt im Edge-Zwischenspeicher gefunden, es war jedoch abgelaufen. Daher nahm der Server Kontakt mit dem Ursprung auf, um zu überprüfen, ob der Zwischenspeicher die neueste Version des Objekts enthalten hatte.

    • Miss – Die Anforderung konnte nicht durch ein Objekt im Zwischenspeicher bedient werden. Daher hat der Server die Anforderung an den Ursprung weitergeleitet und das Ergebnis an den Betrachter ausgegeben.

    • LimitExceeded— Die Anfrage wurde abgelehnt, weil ein CloudFront Kontingent (früher als Limit bezeichnet) überschritten wurde.

    • CapacityExceeded – Der Server hat den HTTP-Statuscode 503 zurückgegeben, da er zum Zeitpunkt der Anforderung nicht über genügend Kapazitäten für die Bereitstellung des Objekts verfügte.

    • Error – In der Regel bedeutet dies, dass die Anforderung zu einem Client-Fehler (d. h. der Wert des Felds sc-status liegt im 4xx-Bereich) oder zu einem Serverfehler geführt hat (d. h. der Wert des Felds sc-status liegt im 5xx-Bereich). Wenn der Wert des Felds sc-status 200 oder wenn der Wert dieses Felds Error ist und der Wert des Felds x-edge-response-result-type nicht Error ist, war die HTTP-Anforderung erfolgreich. Die Client-Verbindung wurde jedoch getrennt, bevor alle Bytes empfangen wurden.

    • Redirect – Der Server hat den Betrachter entsprechend den Verteilungseinstellungen von HTTP zu HTTPS umgeleitet.

  15. x-edge-request-id

    Eine undurchsichtige Zeichenfolge, die eine Anfrage eindeutig identifiziert. CloudFront sendet diese Zeichenfolge auch im x-amz-cf-id Antwort-Header.

  16. x-host-header

    Der Wert, den der Viewer in den Host-Header der Anforderung eingefügt hat. Wenn Sie den CloudFront Domainnamen in Ihren Objekt-URLs verwenden (z. B. d111111abcdef8.cloudfront.net), enthält dieses Feld diesen Domainnamen. Wenn Sie alternative Domänennamen (CNAMEs) in Ihren Objekt-URLs verwenden (z. B. www.example.com), enthält dieses Feld den alternativen Domänennamen.

    Wenn Sie alternative Domain-Namen verwenden, finden Sie unter cs(Host) in Feld 7 den Namen der Domain, die Ihrer Verteilung zugewiesen ist.

  17. cs-protocol

    Das Protokoll der Viewer-Anforderung (http, https, ws oder wss).

  18. cs-bytes

    Die Gesamtzahl der Bytes an Daten, die in der Anforderung des Viewers einschließlich Headern enthalten sind. Bei WebSocket Verbindungen ist dies die Gesamtzahl der Byte, die über die Verbindung vom Client an den Server gesendet wurden.

  19. time-taken

    Die Anzahl der Sekunden (auf die Tausendstelsekunde genau, z. B. 0,082) ab dem Zeitpunkt, an dem der Server die Anforderung des Viewers empfängt, bis zu dem Zeitpunkt, an dem der Server das letzte Byte der Antwort in die Ausgabewarteschlange schreibt, wie auf dem Server gemessen. Aus der Perspektive der Viewers vergeht bis zum Empfang der gesamten Antwort aufgrund der Netzwerklatenz und des TCP-Puffervorgangs insgesamt mehr Zeit, als mit diesem Wert angegeben wird.

  20. x-forwarded-for

    Wenn der Viewer einen HTTP-Proxy oder Load Balancer verwendet hat, um die Anforderung zu senden, entspricht der Wert des Felds c-ip der IP-Adresse des Proxys oder Load Balancers. In diesem Fall stellt dieses Feld die IP-Adresse des Viewers dar, von dem die Anfrage stammt. Dieses Feld kann mehrere durch Kommas getrennte IP-Adressen enthalten. Jede IP-Adresse kann eine IPv4-Adresse (zum Beispiel192.0.2.183) oder eine IPv6-Adresse (zum Beispiel) sein. 2001:0db8:85a3::8a2e:0370:7334

    Wenn der Viewer keinen HTTP-Proxy oder Load Balancer verwendet hat, ist der Wert dieses Feldes ein Bindestrich (-).

  21. ssl-protocol

    Wenn die Anforderung HTTPS verwendet hat, enthält dieses Feld das SSL/TLS-Protokoll, das Viewer und Server für die Übertragung von Anforderung und Antwort ausgehandelt haben. Eine Liste der möglichen Werte finden Sie in den unterstützten SSL/TLS-Protokollen in Unterstützte Protokolle und Chiffren zwischen Zuschauern und CloudFront.

    Wenn als cs-protocol in Feld 17 http angegeben ist, ist der Wert für dieses Feld ein Bindestrich (-).

  22. ssl-cipher

    Wenn die Anforderung HTTPS verwendet hat, enthält dieses Feld die SSL/TLS-Verschlüsselung, die Viewer und Server für die Verschlüsselung von Anforderung und Antwort ausgehandelt haben. Die Liste der möglichen Werte finden Sie in den unterstützten SSL/TLS-Verschlüsselungen in Unterstützte Protokolle und Chiffren zwischen Zuschauern und CloudFront.

    Wenn als cs-protocol in Feld 17 http angegeben ist, ist der Wert für dieses Feld ein Bindestrich (-).

  23. x-edge-response-result-type

    Die Art, wie der Server die Antwort direkt vor der Rücksendung der Antwort an den Viewer klassifiziert hat. Siehe auch das Feld x-edge-result-type. Mögliche Werte sind:

    • Hit – Der Server hat das Objekt aus dem Cache für den Betrachter bereitgestellt.

    • RefreshHit – Der Server hat das Objekt im Edge-Zwischenspeicher gefunden, es war jedoch abgelaufen. Daher nahm der Server Kontakt mit dem Ursprung auf, um zu überprüfen, ob der Zwischenspeicher die neueste Version des Objekts enthalten hatte.

    • Miss – Die Anforderung konnte nicht durch ein Objekt im Zwischenspeicher bedient werden. Daher hat der Server die Anforderung an den Ursprungs-Server weitergeleitet und das Ergebnis an den Betrachter ausgegeben.

    • LimitExceeded— Die Anfrage wurde abgelehnt, weil ein CloudFront Kontingent (früher als Limit bezeichnet) überschritten wurde.

    • CapacityExceeded – Der Server hat den Fehler 503 zurückgegeben, da er zum Zeitpunkt der Anforderung nicht über genügend Kapazitäten verfügte, um das Objekt bereitzustellen.

    • Error – In der Regel bedeutet dies, dass die Anforderung zu einem Client-Fehler (d. h. der Wert des Felds sc-status liegt im 4xx-Bereich) oder zu einem Serverfehler geführt hat (d. h. der Wert des Felds sc-status liegt im 5xx-Bereich).

      Wenn der Wert des Felds x-edge-result-type Error ist und der Wert dieses Felds nicht Error ist, wurde die Verbindung vor dem Abschluss des Downloads durch den Client getrennt.

    • Redirect – Der Server hat den Betrachter entsprechend den Verteilungseinstellungen von HTTP zu HTTPS umgeleitet.

  24. cs-protocol-version

    Die HTTP-Version, die der Viewer in der Anfrage angegeben hat: Mögliche Werte sind HTTP/0.9, HTTP/1.0, HTTP/1.1, HTTP/2.0 und HTTP/3.0.

  25. fle-status

    Wenn die Verschlüsselung auf Feldebene für eine Verteilung konfiguriert ist, enthält dieses Feld einen Code, der angibt, ob der Anforderungstext erfolgreich verarbeitet wurde. Wenn der Server den Anforderungstext erfolgreich verarbeitet, Werte in den angegebenen Feldern verschlüsselt und die Anforderung an den Ursprung weiterleitet, ist der Wert dieses Felds Processed. Der Wert von x-edge-result-type kann in diesem Fall immer noch auf einen clientseitigen oder serverseitigen Fehler hinweisen.

    Mögliche Werte für dieses Feld sind:

    • ForwardedByContentType – Der Server hat die Anforderung ohne Parsing oder Verschlüsselung an den Ursprung weitergeleitet, da kein Content-Typ konfiguriert wurde.

    • ForwardedByQueryArgs – Der Server hat die Anforderung ohne Parsing oder Verschlüsselung an den Ursprung weitergeleitet, da die Anforderung ein Abfrageargument enthält, das nicht in der Konfiguration für die Verschlüsselung auf Feldebene enthalten war.

    • ForwardedDueToNoProfile – Der Server hat die Anforderung ohne Parsing oder Verschlüsselung an den Ursprung weitergeleitet, da in der Konfiguration für die Verschlüsselung auf Feldebene kein Profil angegeben wurde.

    • MalformedContentTypeClientError – Der Server hat die Anforderung zurückgewiesen und einen HTTP-400-Statuscode an den Betrachter zurückgegeben, da der Wert des Content-Type-Headers ein ungültiges Format hatte.

    • MalformedInputClientError – Der Server hat die Anforderung zurückgewiesen und einen HTTP 400-Statuscode an den Betrachter zurückgegeben, da der Anforderungstext ein ungültiges Format hatte.

    • MalformedQueryArgsClientError – Der Server hat die Anforderung zurückgewiesen und einen HTTP-400-Statuscode an den Betrachter zurückgegeben, weil ein Abfrageargument leer war oder ein ungültiges Format hatte.

    • RejectedByContentType – Der Server hat die Anforderung zurückgewiesen und einen HTTP-400-Statuscode an den Betrachter zurückgegeben, da in der Konfiguration für die Verschlüsselung auf Feldebene kein Content-Typ angegeben wurde.

    • RejectedByQueryArgs – Der Server hat die Anforderung zurückgewiesen und einen HTTP-400-Statuscode an den Betrachter zurückgegeben, da in der Konfiguration für die Verschlüsselung auf Feldebene kein Abfrageargument angegeben wurde.

    • ServerError – Der Ursprungs-Server hat einen Fehler zurückgegeben.

    Wenn die Anforderung das Kontingent für die Verschlüsselung auf Feldebene überschreitet (früher als Limit bezeichnet), enthält dieses Feld einen der folgenden Fehlercodes und der Server gibt dem Viewer den HTTP-Statuscode 400 zurück. Eine Liste der aktuellen Kontingente für die Verschlüsselung auf Feldebene finden Sie unter Kontingente für Verschlüsselung auf Feldebene.

    • FieldLengthLimitClientError – Ein Feld, das für die Verschlüsselung konfiguriert ist, hat die maximal zulässige Länge überschritten.

    • FieldNumberLimitClientError – Eine Anforderung, die die Verteilung verschlüsseln soll, enthält mehr Felder als zulässig.

    • RequestLengthLimitClientError – Die Länge des Anfragetexts hat die maximal zulässige Länge, wenn die Verschlüsselung auf Feldebene konfiguriert ist, überschritten.

    Wenn die Verschlüsselung auf Feldebene nicht für die Verteilung konfiguriert ist, ist der Wert dieses Feldes ein Bindestrich (-).

  26. fle-encrypted-fields

    Die Anzahl der Felder für die Verschlüsselung auf Feldebene, die der Server verschlüsselt und an den Ursprung weitergeleitet hat. CloudFront Server streamen die verarbeitete Anfrage an den Ursprung, während sie Daten verschlüsseln, sodass dieses Feld auch dann einen Wert haben kann, wenn der Wert von ein Fehler fle-status ist.

    Wenn die Verschlüsselung auf Feldebene nicht für die Verteilung konfiguriert ist, ist der Wert dieses Feldes ein Bindestrich (-).

  27. c-port

    Die Portnummer der Anforderung des Viewers.

  28. time-to-first-byte

    Die Anzahl der Sekunden zwischen dem Empfangen der Anforderung und dem Schreiben des ersten Bytes der Antwort, gemessen auf dem Server.

  29. x-edge-detailed-result-type

    Dieses Feld enthält den gleichen Wert wie der Wert für das x-edge-result-type-Feld, außer in den folgenden Fällen:

    • Wenn das Objekt dem Viewer aus der Origin-Shield-Ebene bereitgestellt wurde, enthält dieses Feld OriginShieldHit.

    • Wenn sich das Objekt nicht im CloudFront Cache befand und die Antwort von einer Lambda @Edge -Funktion für die ursprüngliche Anfrage generiert wurde, enthält MissGeneratedResponse dieses Feld.

    • Wenn der Wert des x-edge-result-type-Felds Error lautet, enthält dieses Feld einen der folgenden Werte mit weiteren Informationen zum Fehler:

      • AbortedOrigin – Der Server hat ein Problem mit dem Ursprung festgestellt.

      • ClientCommError – Die Antwort auf den Betrachter wurde aufgrund eines Kommunikationsproblems zwischen dem Server und dem Betrachter unterbrochen.

      • ClientGeoBlocked – Die Verteilung ist so konfiguriert, dass Anforderungen vom geografischen Standort des Viewers abgelehnt werden.

      • ClientHungUpRequest — Der Betrachter wurde beim Senden der Anfrage vorzeitig gestoppt.

      • Error – Es ist ein Fehler aufgetreten, dessen Fehlertyp zu keiner der anderen Kategorien passt. Dieser Fehlertyp kann auftreten, wenn der Server eine Fehlerantwort aus dem Cache ausgibt.

      • InvalidRequest – Der Server hat eine ungültige Anforderung vom Betrachter erhalten.

      • InvalidRequestBlocked — Der Zugriff auf die angeforderte Ressource ist blockiert.

      • InvalidRequestCertificate – Die Verteilung stimmt nicht mit dem SSL/TLS-Zertifikat überein, für das die HTTPS-Verbindung hergestellt wurde.

      • InvalidRequestHeader – Die Anforderung enthielt einen ungültigen Header.

      • InvalidRequestMethod — Die Verteilung ist nicht für eine Verarbeitung der verwendeten HTTP-Anforderungsmethode konfiguriert. Dies kann vorkommen, wenn die Verteilung nur Anforderungen unterstützt, die zwischengespeichert werden können.

      • OriginCommError – Bei der Anforderung ist eine Zeitüberschreitung aufgetreten, während eine Verbindung mit dem Ursprung hergestellt wurde oder Daten aus dem Ursprung gelesen wurden.

      • OriginConnectError – Der Server konnte keine Verbindung zum Ursprung herstellen.

      • OriginContentRangeLengthError – Der Content-Length-Header in der Antwort des Ursprungs stimmt nicht mit der Länge im Content-Range-Header überein.

      • OriginDnsError – Der Server konnte den Domänennamen des Ursprungs nicht auflösen.

      • OriginError — Der Ursprung gab eine falsche Antwort zurück.

      • OriginHeaderTooBigError – Ein vom Ursprung zurückgegebener Header ist für eine Verarbeitung durch den Edge-Server zu groß.

      • OriginInvalidResponseError — Der Ursprung gab eine ungültige Antwort zurück.

      • OriginReadError – Der Server konnte nicht vom Ursprung lesen.

      • OriginWriteError – Der Server konnte nicht in den Ursprung schreiben.

      • OriginZeroSizeObjectError — Ein Nullgrößenobjekt, das vom Ursprung gesendet wurde, führte zu einem Fehler.

      • SlowReaderOriginError — Der Betrachter hat die Nachricht, die den Ursprungsfehler verursacht hat, nur langsam gelesen.

  30. sc-content-type

    Der Wert des HTTP Content-Type-Headers der Antwort.

  31. sc-content-len

    Der Wert des HTTP Content-Length-Headers der Antwort.

  32. sc-range-start

    Wenn die Antwort den HTTP Content-Range-Header enthält, enthält dieses Feld den Bereichsstartwert.

  33. sc-range-end

    Wenn die Antwort den HTTP Content-Range-Header enthält, enthält dieses Feld den Bereichsendwert.

Es folgt ein Beispiel für die Protokolldatei für eine Verteilung:

#Version: 1.0 #Fields: date time x-edge-location sc-bytes c-ip cs-method cs(Host) cs-uri-stem sc-status cs(Referer) cs(User-Agent) cs-uri-query cs(Cookie) x-edge-result-type x-edge-request-id x-host-header cs-protocol cs-bytes time-taken x-forwarded-for ssl-protocol ssl-cipher x-edge-response-result-type cs-protocol-version fle-status fle-encrypted-fields c-port time-to-first-byte x-edge-detailed-result-type sc-content-type sc-content-len sc-range-start sc-range-end 2019-12-04 21:02:31 LAX1 392 192.0.2.100 GET d111111abcdef8.cloudfront.net /index.html 200 - Mozilla/5.0%20(Windows%20NT%2010.0;%20Win64;%20x64)%20AppleWebKit/537.36%20(KHTML,%20like%20Gecko)%20Chrome/78.0.3904.108%20Safari/537.36 - - Hit SOX4xwn4XV6Q4rgb7XiVGOHms_BGlTAC4KyHmureZmBNrjGdRLiNIQ== d111111abcdef8.cloudfront.net https 23 0.001 - TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 Hit HTTP/2.0 - - 11040 0.001 Hit text/html 78 - - 2019-12-04 21:02:31 LAX1 392 192.0.2.100 GET d111111abcdef8.cloudfront.net /index.html 200 - Mozilla/5.0%20(Windows%20NT%2010.0;%20Win64;%20x64)%20AppleWebKit/537.36%20(KHTML,%20like%20Gecko)%20Chrome/78.0.3904.108%20Safari/537.36 - - Hit k6WGMNkEzR5BEM_SaF47gjtX9zBDO2m349OY2an0QPEaUum1ZOLrow== d111111abcdef8.cloudfront.net https 23 0.000 - TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 Hit HTTP/2.0 - - 11040 0.000 Hit text/html 78 - - 2019-12-04 21:02:31 LAX1 392 192.0.2.100 GET d111111abcdef8.cloudfront.net /index.html 200 - Mozilla/5.0%20(Windows%20NT%2010.0;%20Win64;%20x64)%20AppleWebKit/537.36%20(KHTML,%20like%20Gecko)%20Chrome/78.0.3904.108%20Safari/537.36 - - Hit f37nTMVvnKvV2ZSvEsivup_c2kZ7VXzYdjC-GUQZ5qNs-89BlWazbw== d111111abcdef8.cloudfront.net https 23 0.001 - TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 Hit HTTP/2.0 - - 11040 0.001 Hit text/html 78 - - 2019-12-13 22:36:27 SEA19-C1 900 192.0.2.200 GET d111111abcdef8.cloudfront.net /favicon.ico 502 http://www.example.com/ Mozilla/5.0%20(Windows%20NT%2010.0;%20Win64;%20x64)%20AppleWebKit/537.36%20(KHTML,%20like%20Gecko)%20Chrome/78.0.3904.108%20Safari/537.36 - - Error 1pkpNfBQ39sYMnjjUQjmH2w1wdJnbHYTbag21o_3OfcQgPzdL2RSSQ== www.example.com http 675 0.102 - - - Error HTTP/1.1 - - 25260 0.102 OriginDnsError text/html 507 - - 2019-12-13 22:36:26 SEA19-C1 900 192.0.2.200 GET d111111abcdef8.cloudfront.net / 502 - Mozilla/5.0%20(Windows%20NT%2010.0;%20Win64;%20x64)%20AppleWebKit/537.36%20(KHTML,%20like%20Gecko)%20Chrome/78.0.3904.108%20Safari/537.36 - - Error 3AqrZGCnF_g0-5KOvfA7c9XLcf4YGvMFSeFdIetR1N_2y8jSis8Zxg== www.example.com http 735 0.107 - - - Error HTTP/1.1 - - 3802 0.107 OriginDnsError text/html 507 - - 2019-12-13 22:37:02 SEA19-C2 900 192.0.2.200 GET d111111abcdef8.cloudfront.net / 502 - curl/7.55.1 - - Error kBkDzGnceVtWHqSCqBUqtA_cEs2T3tFUBbnBNkB9El_uVRhHgcZfcw== www.example.com http 387 0.103 - - - Error HTTP/1.1 - - 12644 0.103 OriginDnsError text/html 507 - -

Gebühren für Standardprotokolle

Die Standardprotokollierung ist eine optionale Funktion von. CloudFront Für die Aktivierung der Standardprotokollierung fallen keine zusätzlichen Kosten an. Sie müssen jedoch die normalen Amazon S3-Gebühren für das Speichern und den Zugriff auf die Dateien in Amazon S3 entrichten (Sie können diese jederzeit löschen).

Weitere Informationen zu Preisen finden Sie unter Amazon S3-Preise.

Weitere Informationen zur CloudFront Preisgestaltung finden Sie unter CloudFront Preisgestaltung.