Konfigurieren und Verwenden von Standardprotokollen (Zugriffsprotokolle) - Amazon CloudFront
Funktionsweise der StandardprotokollierungAuswählen eines Amazon S3-Buckets für Ihre StandardprotokolleFür die Konfiguration der Protokollierung und den Zugriff auf Ihre Protokolldateien erforderliche BerechtigungenErforderliche Schlüsselrichtlinie für SSE-KMS BucketsDateinamenformatZeitplan der Dateizustellung von StandardprotokollenProtokollierung von Anforderungen, wenn Anforderungs-URL oder Header die maximale Größe überschreitenAnalysieren von StandardprotokollenBearbeiten der Einstellungen der StandardprotokollierungLöschen von Standardprotokolldateien aus einem Amazon S3-BucketDateiformat des StandardprotokollsGebühren für Standardprotokolle

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.

Konfigurieren und Verwenden von Standardprotokollen (Zugriffsprotokolle)

Sie können CloudFront so konfigurieren, dass Protokolldateien erstellt werden, die detaillierte Informationen zu jeder Benutzeranforderung enthalten, die CloudFront empfängt. Diese werden als Standardprotokolle, oder auch als Zugriffsprotokolle bezeichnet. Wenn Sie Standardprotokolle aktivieren, können Sie auch den Amazon 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 Werte, die Sie beim Erstellen oder Aktualisieren einer Verteilung angeben.

CloudFront bietet auch Echtzeitprotokolle, die Ihnen Informationen über Anforderungen an eine Verteilung in Echtzeit liefern (Protokolle werden innerhalb von Sekunden nach Erhalt der Anforderungen 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 Echtzeit-Protokolle.

Funktionsweise der Standardprotokollierung

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

Prinzipieller Ablauf für Zugriffsprotokolle

Im Folgenden wird erläutert, wie Informationen zu Anfragen für Ihre Objekte CloudFront protokolliert, wie im vorherigen Diagramm dargestellt.

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

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

  3. CloudFront schreibt Daten über jede Anforderung 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 die Protokolldatei für eine Verteilung regelmäßig in dem Amazon S3-Bucket, den Sie beim Aktivieren der Protokollierung angegeben haben. CloudFront beginnt dann mit dem Speichern von Informationen über nachfolgende Anforderungen in einer neuen Protokolldatei für die Verteilung.

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 für Ihre Inhalte zu verstehen, nicht als vollständige Abrechnung aller Anfragen. CloudFront liefert Zugriffsprotokolle nach bestem Wissen und Gewissen. 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 nicht in den Zugriffsprotokollen enthalten ist, stimmt die Anzahl der Einträge in den Zugriffsprotokollen nicht mit deren Anzahl in den Abrechnungs- und Nutzungsberichten für AWS überein.

Auswählen eines Amazon S3-Buckets für Ihre Standardprotokolle

Wenn Sie die Protokollierung für eine Verteilung aktivieren, geben Sie den Amazon S3-Bucket an, in dem Sie Protokolldateien speichern möchten CloudFront. Wenn Sie Amazon S3 als Ursprung verwenden, empfehlen wir, die Protokolldateien nicht in demselben Bucket zu speichern; durch Verwenden eines separaten Buckets wird die Wartung erleichtert.

Wichtig

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 verhindert CloudFront wird, dass Protokolldateien an den Bucket übermittelt.

Wichtig

Wählen Sie keinen Amazon S3-Bucket in einer der folgenden Regionen aus, da CloudFront keine Standardprotokolle an Buckets in diesen Regionen übermittelt:

  • Afrika (Kapstadt)

  • Asien-Pazifik (Hongkong)

  • Asien-Pazifik (Hyderabad)

  • Asien-Pazifik (Jakarta)

  • Asien-Pazifik (Melbourne)

  • Kanada (Zentral)

  • Europa (Milan)

  • Europa (Spain)

  • Europa (Zürich)

  • Israel (Tel Aviv)

  • Naher Osten (Bahrain)

  • Naher Osten (VAE)

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.

Für die Konfiguration der Protokollierung und den Zugriff auf Ihre Protokolldateien erforderliche Berechtigungen

Wichtig

Ab April 2023 müssen Sie S3-Zugriffskontrolllisten (ACLs) für neue S3-Buckets aktivieren, die für CloudFront Standardprotokolle verwendet werden. ACLs können während der Schritte zur Bucket-Erstellung oder nach der Erstellung eines Buckets aktiviert werden.

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.

Ihr AWS-Konto muss über die folgenden Berechtigungen für den Bucket verfügen, den Sie für die Protokolldateien angegeben haben:

  • Die S3-ACLs (Zugriffskontrolllisten) müssen Ihnen für den Bucket gewähre FULL_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

Beachten Sie Folgendes:

ACL für den Bucket

Wenn Sie eine Verteilung erstellen oder aktualisieren und die Protokollierung aktivieren, CloudFront verwendet diese Berechtigungen, um die ACL für den Bucket zu aktualisieren und dem awslogsdelivery Konto die FULL_CONTROL Berechtigung zu 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 so konfiguriert haben CloudFront , dass Zugriffsprotokolle in einem S3-Bucket gespeichert werden, und Sie keine Protokolle mehr in diesem Bucket erhalten, überprüfen Sie die Berechtigungen für den Bucket, um sicherzustellen, dass über die erforderlichen Berechtigungen CloudFront verfügt.

Wiederherstellung der ACL für den Bucket

Wenn Sie Berechtigungen für das awslogsdelivery-Konto aufheben, kann CloudFront keine Protokolle in dem S3-Bucket speichern. Um zu aktivieren CloudFront , dass erneut mit dem Speichern von Protokollen für Ihre Verteilung beginnt, stellen Sie die ACL-Berechtigung wieder her, indem Sie einen der folgenden Schritte ausführen:

  • Deaktivieren Sie die Protokollierung für Ihre Verteilung in CloudFrontund aktivieren Sie sie dann erneut. Weitere Informationen finden Sie unter Werte, die Sie beim Erstellen oder Aktualisieren einer Verteilung angeben.

  • 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 Wie lege ich ACL-Bucket-Berechtigungen fest? im Benutzerhandbuch zu Amazon Simple Storage Service.

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 löscht weder die ACLs für den Bucket noch die Protokolldateien. Wenn Sie möchten, können Sie dies selbst tun.

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: Auf diese Weise kann CloudFront Protokolldateien in den Bucket schreiben. (Sie können SSE-KMS nicht mit dem verwenden, Von AWS verwalteter Schlüssel da CloudFront keine Protokolldateien in den Bucket schreiben kann.)

{
    "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-Bucket CloudFront speichert, 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 Protokolldateipräfix angeben und Ihr Präfix nicht mit einem Schrägstrich (/) endet, CloudFront hängt automatisch einen an. Wenn Ihr Präfix mit einem Schrägstrich endet, fügt CloudFront keinen weiteren hinzu.

.gz am Ende des Dateinamens gibt an, dass die Protokolldatei mit gzip komprimiert CloudFront hat.

Zeitplan der Dateizustellung von Standardprotokollen

CloudFront stellt Standardprotokolle für eine Verteilung bis zu mehrmals pro Stunde bereit. Im Allgemeinen enthält eine Protokolldatei Informationen über die Anforderungen, die während eines bestimmten Zeitraums CloudFront erhalten hat. stellt die Protokolldatei für diesen Zeitraum CloudFront normalerweise innerhalb einer Stunde nach den Ereignissen, die im Protokoll angezeigt werden, in Ihrem Amazon S3-Bucket bereit. 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 es zu so einer Verzögerung kommt, speichert CloudFront die Protokolleinträge in einer Protokolldatei, in der die Dateinamen das Datum und die Uhrzeit des Zeitraums enthalten, in dem die Anfragen aufgetreten sind, und nicht die Daten des Zeitraums, in dem die Datei übermittelt wurde.

CloudFront Konsolidiert beim Erstellen einer Protokolldatei Informationen für Ihre Verteilung von allen Edge-Standorten, die während des von der Protokolldatei abgedeckten Zeitraums Anforderungen für Ihre Objekte erhalten haben.

CloudFront kann mehr als eine Datei für einen bestimmten Zeitraum speichern, je nachdem, wie viele Anforderungen für die Objekte CloudFront erhalten, die einer Verteilung zugeordnet sind.

CloudFront beginnt etwa vier Stunden nach der Aktivierung der Protokollierung zuverlässig Zugriffsprotokolle bereitzustellen. 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 auch Echtzeitprotokolle, die Ihnen Informationen über Anforderungen an eine Verteilung in Echtzeit liefern (Protokolle werden innerhalb von Sekunden nach Erhalt der Anforderungen 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 Echtzeit-Protokolle.

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

Wenn die Gesamtgröße aller Anfrage-Header, einschließlich Cookies, 20 KB überschreitet oder wenn die URL die Größe von 8.192 Byte überschreitet, kann CloudFront die Anforderung nicht vollständig analysieren und die Anforderung nicht protokollieren. 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 von Standardprotokollen

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 Abfrageservice, der Sie bei der Analyse von Daten für -AWSServices unterstützen kann, einschließlich CloudFront. Weitere Informationen finden Sie unter Abfragen von Amazon CloudFront Logs im Amazon Athena-Benutzerhandbuch.

Darüber hinaus beschreiben die folgenden AWS-Blogbeiträge verschiedene Möglichkeiten, Zugriffsprotokolle zu analysieren.

Wichtig

Wir empfehlen Ihnen, die Protokolle zu verwenden, um die Art der Anfragen für Ihre Inhalte zu verstehen, nicht als vollständige Abrechnung aller Anfragen. CloudFront liefert Zugriffsprotokolle nach bestem Wissen und Gewissen. 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 nicht in den Zugriffsprotokollen enthalten ist, stimmt die Anzahl der Einträge in den Zugriffsprotokollen nicht mit deren Anzahl in den Nutzungs- und Abrechnungsberichten für AWS überein.

Bearbeiten der Einstellungen der Standardprotokollierung

Sie können die Protokollierung aktivieren oder deaktivieren, den Amazon 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 Verteilung mithilfe der CloudFront Konsole finden Sie unter Aktualisieren einer Verteilung.

  • Informationen zum Aktualisieren einer Verteilung mithilfe der CloudFront API finden Sie unter UpdateDistribution in der Amazon CloudFront -API-Referenz .

Löschen von Standardprotokolldateien aus einem Amazon S3-Bucket

CloudFront löscht Protokolldateien nicht automatisch aus Ihrem Amazon 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.

  • Verwenden der REST-API: DeleteObject in der API-Referenz zu Amazon Simple Storage Service.

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

    Der Zeitpunkt, zu dem der CloudFront Server die Antwort auf die Anforderung abgeschlossen hat (in UTC), z. B. 01:42:39. 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 Bytes, 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 Domänenname der CloudFront Verteilung (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 Zwischenspeichern von Inhalten auf der Grundlage von Abfragezeichenfolgeparametern.

  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, CloudFront protokolliert die Cookies in allen Anforderungen, unabhängig davon, welche Cookies Sie an den Ursprung weiterleiten möchten. Wenn eine Anforderung keinen Cookie-Header enthält, ist der Wert dieses Felds ein Bindestrich (-). Weitere Informationen zu Cookies finden Sie unter Zwischenspeichern von Inhalten auf der Grundlage von Cookies.

  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 den Wert Miss für dieses Feld, 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 Anforderung 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 Anforderung eindeutig identifiziert. sendet diese Zeichenfolge CloudFront 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 Domänennamen in Ihren Objekt-URLs verwenden (z. B. d111111abcdef8.cloudfront.net), enthält dieses Feld diesen Domänennamen. 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 Bytes, die vom Client an den Server auf der Verbindung gesendet werden.

  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 enthält eine IPv4-Adresse (z. B. 192.0.2.183) oder eine IPv6-Adresse (z. B. 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 Verschlüsselungsverfahren zwischen Viewern 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 Verschlüsselungsverfahren zwischen Viewern 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 Anforderung 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 Verschlüsselungsfelder auf Feldebene, die der Server verschlüsselt und an den Ursprung weitergeleitet hat. CloudFront servers streamen die verarbeitete Anforderung an den Ursprung, während sie Daten verschlüsseln, sodass dieses Feld einen Wert haben kann, auch 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 Ursprungsanfragen generiert wurde, enthält dieses Feld MissGeneratedResponse.

    • 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 zu CloudFront Preisen finden Sie unter -CloudFront Preise.