Configuration et utilisation de journaux standard (journaux d'accès) - Amazon CloudFront
Fonctionnement de la journalisation standardChoisissez un compartiment Amazon S3 pour les journaux standardAutorisations requises pour configurer la journalisation standard et accéder aux fichiers journauxPolitique de clé requise pour les compartiments SSE-KMSFormat de nom de fichierDélai de distribution des fichiers journaux standardComment les demandes sont consignées lorsque l’URL de la demande ou les en-têtes dépassent la taille maximaleAnalyser les journaux standardModifier les paramètres de journalisation standardSupprimer les fichiers journaux standard d'un compartiment Amazon S3Format de fichier journal standardFrais pour les journaux standard

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Configuration et utilisation de journaux standard (journaux d'accès)

Vous pouvez configurer CloudFront pour créer des fichiers journaux contenant des informations détaillées sur chaque demande utilisateur CloudFront reçue. Ceux-ci sont appelés journaux standard, également nommés journaux d’accès. Si vous activez les journaux standard, vous pouvez également spécifier le compartiment Amazon S3 dans lequel vous CloudFront souhaitez enregistrer les fichiers.

Vous pouvez activer les journaux standard lorsque vous créez ou mettez à jour une distribution. Pour plus d’informations, consultez Journalisation.

CloudFront propose également des journaux en temps réel, qui vous fournissent des informations sur les demandes adressées à une distribution en temps réel (les journaux sont livrés quelques secondes après réception des demandes). Vous pouvez utiliser des journaux en temps réel pour surveiller, analyser et prendre des mesures en fonction de la performance de diffusion de contenu. Pour de plus amples informations, veuillez consulter Utilisez des journaux en temps réel.

Fonctionnement de la journalisation standard

Le schéma suivant montre comment CloudFront enregistre les informations relatives aux demandes relatives à vos objets.

Flux de base pour les journaux d’accès

Ce qui suit explique comment CloudFront enregistre les informations relatives aux demandes relatives à vos objets, comme illustré dans le schéma précédent.

  1. Dans ce diagramme, vous avez deux sites Web, A et B, et deux CloudFront distributions correspondantes. Les utilisateurs demandent vos objets à l’aide des URL associées à vos distributions.

  2. CloudFront achemine chaque demande vers l'emplacement périphérique approprié.

  3. CloudFront écrit les données relatives à chaque demande dans un fichier journal spécifique à cette distribution. Dans cet exemple, les informations sur les demandes associées à Distribution A vont dans un fichier journal réservé à Distribution A et celles sur les demandes associées à Distribution B dans un fichier journal réservé à Distribution B.

  4. CloudFront enregistre régulièrement le fichier journal d'une distribution dans le compartiment Amazon S3 que vous avez spécifié lorsque vous avez activé la journalisation. CloudFront commence ensuite à enregistrer les informations relatives aux demandes suivantes dans un nouveau fichier journal pour la distribution.

Si aucun utilisateur n’accède à votre contenu pendant une heure donnée, vous ne recevez aucun fichier journal pour cette heure.

Chaque entrée d’un fichier journal fournit des informations détaillées sur une seule demande. Pour plus d’informations sur le format du fichier journal, consultez Format de fichier journal standard.

Note

Nous vous recommandons d'utiliser les journaux pour comprendre la nature des demandes concernant votre contenu, et non comme un compte rendu complet de toutes les demandes. CloudFront fournit des journaux d'accès dans les meilleures conditions. L’entrée du journal pour une demande particulière peut être fournie bien après le traitement réel de la demande et, dans de rares cas, une entrée du journal peut ne pas être fournie du tout. Lorsqu'une entrée de journal est omise des journaux d'accès, le nombre d'entrées dans les journaux d'accès ne correspond pas à l'utilisation indiquée dans les rapports AWS de facturation et d'utilisation.

Choisissez un compartiment Amazon S3 pour les journaux standard

Lorsque vous activez la journalisation pour une distribution, vous spécifiez le compartiment Amazon S3 dans lequel vous CloudFront souhaitez stocker les fichiers journaux. Si vous utilisez Amazon S3 comme origine, nous vous recommandons d'utiliser un compartiment distinct pour vos fichiers journaux.

Vous pouvez stocker les fichiers journaux de plusieurs distributions dans le même compartiment. Lorsque vous activez la journalisation, vous pouvez spécifier un préfixe facultatif pour les noms de fichier et vous pouvez ainsi savoir quels fichiers journaux sont associés à quelles distributions.

À propos du choix d'un compartiment S3

  • La liste de contrôle d'accès (ACL) doit être activée pour votre bucket. Si vous choisissez un bucket sans ACL activé depuis la CloudFront console, un message d'erreur s'affiche. veuillez consulter Autorisations requises pour configurer la journalisation standard et accéder aux fichiers journaux.

  • Ne choisissez pas un compartiment Amazon S3 avec l’option S3 Object Ownership (Propriété de l’objet S3) définie sur bucket owner enforced (appliqué par le propriétaire du compartiment). Ce paramètre désactive les ACL pour le compartiment et les objets qu'il contient, ce qui CloudFront empêche de fournir des fichiers journaux au compartiment.

  • Ne choisissez pas de compartiment Amazon S3 dans les cas suivants Régions AWS. CloudFront ne fournit pas de journaux standard aux compartiments dans les régions suivantes :

    • Afrique (Le Cap)

    • Asie-Pacifique (Hong Kong)

    • Asie-Pacifique (Hyderabad)

    • Asie-Pacifique (Jakarta)

    • Asie-Pacifique (Melbourne)

    • Canada Ouest (Calgary)

    • Europe (Milan)

    • Europe (Espagne)

    • Europe (Zurich)

    • Israël (Tel Aviv)

    • Moyen-Orient (Bahreïn)

    • Moyen-Orient (EAU)

Autorisations requises pour configurer la journalisation standard et accéder aux fichiers journaux

Important

À compter d'avril 2023, vous devez activer les ACL S3 pour les nouveaux compartiments S3 utilisés pour les journaux CloudFront standard. Vous pouvez activer les ACL lorsque vous créez un bucket ou activer les ACL pour un bucket existant.

Pour plus d'informations sur ces modifications, consultez Paramètres par défaut pour les nouveaux compartiments S3 FAQ dans le Guide de l'utilisateur d'Amazon Simple Storage Service et Attention : des modifications de sécurité seront apportées à Amazon S3 en avril 2023 dans le Blog d'actualités AWS .

Vous Compte AWS devez disposer des autorisations suivantes pour le compartiment que vous spécifiez pour les fichiers journaux :

  • L'ACL du bucket doit vous accorderFULL_CONTROL. Si vous êtes le propriétaire du compartiment, votre compte dispose de cette autorisation par défaut. Si vous ne l’êtes pas, le propriétaire du compartiment doit mettre à jour l’ACL de ce compartiment.

  • s3:GetBucketAcl

  • s3:PutBucketAcl

Liste ACL pour le compartiment

Lorsque vous créez ou mettez à jour une distribution et que vous activez la CloudFront journalisation, utilisez ces autorisations pour mettre à jour l'ACL du bucket afin d'FULL_CONTROLautoriser le awslogsdelivery compte. Le compte awslogsdelivery écrit les fichiers journaux dans le compartiment. Si votre compte ne dispose pas des autorisations requises pour mettre à jour la liste ACL, la création ou la mise à jour de la distribution échouera.

Dans certaines circonstances, si vous envoyez par programmation une demande pour créer un compartiment, mais qu’un compartiment avec le nom spécifié existe déjà, S3 réinitialise les autorisations sur le compartiment à la valeur par défaut. Si vous avez configuré CloudFront pour enregistrer les journaux d'accès dans un compartiment S3 et que vous ne recevez plus de journaux dans ce compartiment, vérifiez les autorisations sur le compartiment pour vous assurer qu'il CloudFront dispose des autorisations nécessaires.

Restauration de la liste ACL pour le compartiment

Si vous supprimez les autorisations pour le awslogsdelivery compte, vous CloudFront ne pourrez pas enregistrer les journaux dans le compartiment S3. Pour permettre CloudFront de recommencer à enregistrer les journaux pour votre distribution, restaurez l'autorisation ACL en effectuant l'une des opérations suivantes :

  • Désactivez la connexion à votre distribution CloudFront, puis réactivez-la. Pour plus d’informations, consultez Journalisation.

  • Ajoutez manuellement l’autorisation de la liste ACL pour le compte awslogsdelivery en accédant au compartiment S3 dans la console Amazon S3 et en ajoutant l’autorisation. Afin d’ajouter la liste ACL pour le compte awslogsdelivery, vous devez fournir l’ID canonique suivant pour le compte :

    c4c1ede66af53448b93c283ce9448c4ba468c9432aa01d700d3878632f77d2d0

    Pour plus d'informations sur l'ajout d'ACL aux compartiments S3, consultez la section Configuration des ACL dans le guide de l'utilisateur d'Amazon Simple Storage Service.

Liste ACL pour chaque fichier journal

En plus de la liste ACL sur le compartiment, il existe une ACL sur chaque fichier journal. Le propriétaire du compartiment dispose de l’autorisation FULL_CONTROL sur chaque fichier journal, le propriétaire de la distribution (s’il est différent du propriétaire du compartiment) n’a aucune autorisation et le compte awslogsdelivery a les autorisations en lecture et écriture.

Désactivation de la journalisation

Si vous désactivez la journalisation, les ACL du bucket ou des fichiers journaux CloudFront ne sont pas supprimées. Vous pouvez supprimer les ACL si nécessaire.

Politique de clé requise pour les compartiments SSE-KMS

Si le compartiment S3 de vos journaux standard utilise le chiffrement côté serveur avec AWS KMS keys (SSE-KMS) utilisant une clé gérée par le client, vous devez ajouter l’instruction suivante à la politique de clé pour la clé gérée par votre client. Cela permet CloudFront d'écrire des fichiers journaux dans le compartiment. Vous ne pouvez pas utiliser SSE-KMS avec le Clé gérée par AWS car vous CloudFront ne pourrez pas écrire de fichiers journaux dans le compartiment.

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

Si le compartiment S3 de vos journaux standard utilise SSE-KMS avec une clé de compartiment S3, vous devez également ajouter l’autorisation kms:Decrypt à l’instruction de politique. Dans ce cas, l’énoncé de stratégie complet ressemble à ce qui suit.

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

Format de nom de fichier

Le nom de chaque fichier journal enregistré CloudFront dans votre compartiment Amazon S3 utilise le format de nom de fichier suivant :

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

Les dates et heures sont exprimées en heure UTC (temps universel coordonné).

Par exemple, si vous utilisez example-prefix comme préfixe et que votre ID de distribution est EMLARXS9EXAMPLE, les noms de fichiers ressemblent à ceci :

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

Lorsque vous activez la journalisation pour une distribution, vous pouvez spécifier un préfixe facultatif pour les noms de fichier et vous pouvez ainsi savoir quels fichiers journaux sont associés à quelles distributions. Si vous incluez une valeur pour le préfixe du fichier journal et que celui-ci ne se termine pas par une barre oblique (/), il en CloudFront ajoute une automatiquement. Si votre préfixe se termine par une barre oblique, CloudFront il n'en ajoute pas un autre.

Le nom .gz à la fin du fichier indique que le fichier journal CloudFront a été compressé à l'aide de gzip.

Délai de distribution des fichiers journaux standard

CloudFront fournit des journaux standard pour une distribution jusqu'à plusieurs fois par heure. En général, un fichier journal contient des informations sur les demandes CloudFront reçues au cours d'une période donnée. CloudFront fournit généralement le fichier journal pour cette période à votre compartiment Amazon S3 dans l'heure qui suit l'apparition des événements dans le journal. Notez, cependant, que tout ou partie des entrées d’un fichier journal d’une période peut parfois être retardé de 24 heures au plus. Lorsque les entrées du journal sont retardées, les CloudFront enregistre dans un fichier journal dont le nom inclut la date et l'heure de la période au cours de laquelle les demandes ont été effectuées, et non la date et l'heure de livraison du fichier.

Lorsque vous créez un fichier journal, CloudFront consolide les informations relatives à votre distribution provenant de tous les emplacements périphériques ayant reçu des demandes pour vos objets pendant la période couverte par le fichier journal.

CloudFront peut enregistrer plusieurs fichiers pendant une période en fonction du nombre de demandes CloudFront reçues pour les objets associés à une distribution.

CloudFront commence à fournir des journaux d'accès de manière fiable environ quatre heures après l'activation de la journalisation. Vous pourriez obtenir quelques journaux d’accès avant ce moment-là.

Note

Si aucun utilisateur ne demande vos objets pendant la période, vous ne recevez aucun fichier journal pour cette dernière.

CloudFront propose également des journaux en temps réel, qui vous fournissent des informations sur les demandes adressées à une distribution en temps réel (les journaux sont livrés quelques secondes après réception des demandes). Vous pouvez utiliser des journaux en temps réel pour surveiller, analyser et prendre des mesures en fonction de la performance de diffusion de contenu. Pour de plus amples informations, veuillez consulter Utilisez des journaux en temps réel.

Comment les demandes sont consignées lorsque l’URL de la demande ou les en-têtes dépassent la taille maximale

Si la taille totale de tous les en-têtes de demande, y compris les cookies, dépasse 20 Ko, ou si l'URL dépasse 8 192 octets, CloudFront vous ne pouvez pas analyser complètement la demande ni l'enregistrer. Étant donné que la demande n’est pas consignée, vous ne verrez pas dans les fichiers journaux le code de statut d’erreur HTTP renvoyé.

Si le corps de la demande dépasse la taille maximale, la demande est consignée, y compris le code de statut d’erreur HTTP.

Analyser les journaux standard

Comme vous pouvez recevoir plusieurs journaux d’accès par heure, nous vous recommandons de combiner tous les fichiers journaux que vous avez reçus pour une période donnée en un seul fichier. Vous pouvez alors analyser les données de cette période plus précisément et plus complètement.

Pour analyser vos journaux d’accès, une solution possible consiste à utiliser Amazon Athena. Athena est un service de requêtes interactif qui peut vous aider à analyser les données pour les AWS services, notamment. CloudFront Pour en savoir plus, consultez la section Interrogation d'Amazon CloudFront Logs dans le guide de l'utilisateur d'Amazon Athena.

En outre, les articles de AWS blog suivants décrivent certaines méthodes d'analyse des journaux d'accès.

Important

Nous vous recommandons d'utiliser les journaux pour comprendre la nature des demandes concernant votre contenu, et non comme un compte rendu complet de toutes les demandes. CloudFront fournit des journaux d'accès dans les meilleures conditions. L’entrée du journal pour une demande particulière peut être fournie bien après le traitement réel de la demande et, dans de rares cas, une entrée du journal peut ne pas être fournie du tout. Lorsqu'une entrée de journal est omise des journaux d'accès, le nombre d'entrées dans les journaux d'accès ne correspond pas à l'utilisation indiquée dans les rapports AWS d'utilisation et de facturation.

Modifier les paramètres de journalisation standard

Vous pouvez activer ou désactiver la journalisation, modifier le compartiment Amazon S3 dans lequel vos journaux sont stockés et modifier le préfixe des fichiers journaux à l'aide de la CloudFront console ou de l' CloudFront API. Les modifications apportées aux paramètres de journalisation prennent effet dans les 12 heures.

Pour plus d’informations, consultez les rubriques suivantes :

  • Pour mettre à jour une distribution à l'aide de la CloudFront console, consultezMettre à jour une distribution.

  • Pour mettre à jour une distribution à l'aide de l' CloudFront API, consultez UpdateDistributionle Amazon CloudFront API Reference.

Supprimer les fichiers journaux standard d'un compartiment Amazon S3

CloudFront ne supprime pas automatiquement les fichiers journaux de votre compartiment Amazon S3. Pour plus d’informations sur la suppression des fichiers journaux à partir d’un compartiment Amazon S3, consultez les rubriques suivantes :

  • Utilisation de la console Amazon S3 : Suppression d’objets dans le Guide de l’utilisateur Amazon Simple Storage Service.

  • Utilisation de l'API REST : DeleteObjectdans le manuel Amazon Simple Storage Service API Reference.

Format de fichier journal standard

Chaque entrée d’un fichier journal fournit des informations détaillées sur une seule demande utilisateur. Les fichiers journaux présentent les caractéristiques suivantes :

  • Utilisez le format de fichier journal étendu W3C.

  • Contiennent des valeurs séparées par des virgules.

  • Contiennent des enregistrements qui ne sont pas nécessairement dans l’ordre chronologique.

  • Contiennent deux lignes d’en-tête : l’une avec la version fichier-format et l’autre qui répertorie les champs W3C inclus dans chaque enregistrement.

  • Contiennent des équivalents encodés en URL pour des espaces et certains autres caractères dans les valeurs de champ.

    Les équivalents encodés en URL sont utilisés pour les caractères suivants :

    • Codes de caractères ASCII 0 à 32 inclus

    • Codes de caractères ASCII 127 et suivants

    • Tous les caractères du tableau suivant

    La norme d’encodage d’URL est définie dans la norme RFC 1738.

Valeur codée par URL

Caractère

%3C

<

%3E

>

%22

"

%23

#

%25

%

%7B

{

%7D

}

%7C

|

%5C

\

%5E

^

%7E

~

%5B

[

%5D

]

%60

`

%27

'

%20

espace

Champs d’un fichier journal standard

Le fichier journal d’une distribution contient 33 champs. La liste suivante contient chaque nom de champ, dans l’ordre, ainsi qu’une description des informations contenues dans ce champ.

  1. date

    Date à laquelle l’événement s’est produit au format YYYY-MM-DD. Par exemple, 2019-06-30. Les dates et heures sont exprimées en heure UTC (temps universel coordonné). Pour WebSocket les connexions, il s'agit de la date de fermeture de la connexion.

  2. time

    Heure à laquelle le CloudFront serveur a fini de répondre à la demande (en UTC), par exemple,01:42:39. Pour WebSocket les connexions, il s'agit de l'heure à laquelle la connexion est fermée.

  3. x-edge-location

    Emplacement périphérique ayant servi la demande. Chaque emplacement périphérique est identifié par un code à trois lettres et un numéro attribué arbitrairement (par exemple, DFW3). Le code à trois lettres correspond généralement au code IATA (International Air Transport Association) d’un aéroport proche de l’emplacement périphérique. (Ces abréviations peuvent changer à l’avenir.)

  4. sc-bytes

    Nombre total d’octets envoyés par le serveur à l’utilisateur en réponse à la demande, en-têtes inclus. Pour WebSocket les connexions, il s'agit du nombre total d'octets envoyés par le serveur au client via la connexion.

  5. c-ip

    Adresse IP de la visionneuse qui a émis la demande, par exemple, 192.0.2.183 ou 2001:0db8:85a3::8a2e:0370:7334. Si l’utilisateur a utilisé un proxy HTTP ou un équilibreur de charge pour envoyer la demande, la valeur de ce champ est l’adresse IP du proxy ou de l’équilibreur de charge. Voir aussi le champ x-forwarded-for.

  6. cs-method

    Méthode de demande HTTP reçue de l’utilisateur.

  7. cs(Host)

    Le nom de domaine de la CloudFront distribution (par exemple, d111111abcdef8.cloudfront.net).

  8. cs-uri-stem

    Partie de l’URL de la requête qui identifie le chemin d’accès et l’objet (par exemple, /images/cat.jpg). Les points d’interrogation (?) des URL et des chaînes de requête ne sont pas inclus dans le journal.

  9. sc-status

    Contient une des valeurs suivantes :

    • Code de statut HTTP de la réponse du serveur (par exemple, 200).

    • 000, ce qui indique que l’utilisateur a fermé la connexion avant que le serveur puisse répondre à la demande. Si l’utilisateur ferme la connexion après que le serveur a commencé à envoyer la réponse, ce champ contient le code de statut HTTP de la réponse que le serveur a commencé à envoyer.

  10. cs(Referer)

    Valeur de l’en-tête Referer dans la demande. Nom du domaine à l’origine de la demande. Les référents courants incluent des moteurs de recherche, d’autres sites Web contenant des liens directs vers vos objets ou encore votre propre site web.

  11. cs(User-Agent)

    Valeur de l’en-tête User-Agent dans la demande. L’en-tête User-Agent identifie la source de la demande, comme le type d’appareil et le navigateur ayant envoyé la demande et, si la demande provenait d’un moteur de recherche, le moteur utilisé.

  12. cs-uri-query

    Partie de la chaîne de requête de l’URL de la demande, le cas échéant.

    Quand un URL ne contient pas de chaîne de requête, la valeur de ce champ est un trait d’union (-). Pour plus d’informations, consultez Contenu du cache basé sur les paramètres de chaîne de requête.

  13. cs(Cookie)

    En-tête Cookie de la demande, y compris les paires nom-valeur et les attributs associés.

    Si vous activez l'enregistrement des cookies, les CloudFront enregistre dans toutes les demandes, quels que soient les cookies que vous choisissez de transférer à l'origine. Quand une demande n'inclut pas un en-tête de cookie, la valeur de ce champ est un trait d'union (-). Pour plus d’informations sur les cookies, consultez Contenu du cache basé sur les cookies.

  14. x-edge-result-type

    Comment le serveur a classé la réponse après que le dernier octet a quitté le serveur. Dans certains cas, le type de résultat peut changer entre le moment où le serveur est prêt à envoyer la réponse et celui où il a fini d’envoyer celle-ci. Voir aussi le champ x-edge-response-result-type.

    Par exemple, dans le streaming HTTP, supposons que le serveur trouve un segment du flux dans le cache. Dans ce scénario, la valeur de ce champ est normalement Hit. Cependant, si l’utilisateur ferme la connexion avant que le serveur ait livré la totalité du segment, le type de résultat final (et donc la valeur de ce champ) est Error.

    WebSocket les connexions auront une valeur égale à Miss pour ce champ car le contenu ne peut pas être mis en cache et est directement transmis par proxy à l'origine.

    Les valeurs possibles incluent :

    • Hit – Le serveur a servi l’objet à l’utilisateur depuis le cache.

    • RefreshHit – Le serveur a trouvé l’objet dans le cache, mais l’objet avait expiré. Le serveur a donc contacté l’origine pour vérifier que le cache possédait la dernière version de l’objet.

    • Miss – La demande n’ayant pas pu être satisfaite par un objet du cache, le serveur a transmis la demande à l’origine et retourné le résultat à l’utilisateur.

    • LimitExceeded— La demande a été refusée car un CloudFront quota (anciennement appelé limite) a été dépassé.

    • CapacityExceeded : le serveur a renvoyé un code d’erreur HTTP 503, car la capacité était insuffisante pour servir l’objet au moment de la demande.

    • Error – Généralement, cela signifie que la demande a entraîné une erreur client (la valeur du champ sc-status est dans la plage 4xx) ou une erreur serveur (la valeur du champ sc-status est dans la plage 5xx). Si la valeur du champ sc-status est 200, ou si la valeur de ce champ est Error et que la valeur du champ x-edge-response-result-type est différente de Error, cela signifie que la demande HTTP a réussi mais que le client a été déconnecté avant de recevoir tous les octets.

    • Redirect – Le serveur a redirigé l’utilisateur depuis HTTP vers HTTPS en fonction des paramètres de distribution.

  15. x-edge-request-id

    Chaîne opaque qui identifie une demande de manière unique. CloudFront envoie également cette chaîne dans l'en-tête de x-amz-cf-id réponse.

  16. x-host-header

    Valeur que l’utilisateur a incluse dans l’en-tête Host de la demande. Si vous utilisez le nom de CloudFront domaine dans les URL de vos objets (par exemple d111111abcdef8.cloudfront.net), ce champ contient ce nom de domaine. Si vous utilisez des noms de domaine alternatifs (CNAMES) dans vos URL d’objet (tels que www.example.com), ce champ contient l’autre nom de domaine.

    Si vous utilisez des noms de domaine alternatifs, consultez cs(Host) dans le champ 7 pour connaître le nom de domaine associé à votre distribution.

  17. cs-protocol

    Protocole de la demande de l’utilisateur (http, https, ws ou wss).

  18. cs-bytes

    Nombre total d’octets de données que l’utilisateur a inclus dans la demande, en-têtes inclus. Pour WebSocket les connexions, il s'agit du nombre total d'octets envoyés par le client au serveur lors de la connexion.

  19. time-taken

    Nombre de secondes (au millième de seconde, par exemple 0,082) entre le moment où le serveur reçoit la demande de l’utilisateur et le moment où le serveur écrit le dernier octet de la réponse à la file d’attente de sortie, tel que mesuré sur le serveur. Du point de vue de l’utilisateur, le temps total pour obtenir la réponse complète sera plus long que cette valeur en raison de la latence réseau et de la mise en tampon TCP.

  20. x-forwarded-for

    Si l’utilisateur a utilisé un proxy HTTP ou un équilibreur de charge pour envoyer la demande, la valeur du champ c-ip est l’adresse IP du proxy ou de l’équilibreur de charge. Dans ce cas, ce champ est l’adresse IP de l’utilisateur à l’origine de la demande. Ce champ peut contenir plusieurs adresses IP séparées par des virgules. Chaque adresse IP peut être une adresse IPv4 (par exemple192.0.2.183) ou une adresse IPv6 (par exemple,2001:0db8:85a3::8a2e:0370:7334).

    Si l’utilisateur n’a pas utilisé de proxy HTTP ou d’équilibreur de charge, la valeur de ce champ est un trait d’union (-).

  21. ssl-protocol

    Lorsque la demande a utilisé HTTPS, ce champ contient le protocole SSL/TLS que l’utilisateur et le serveur ont négocié pour transmettre la demande et la réponse. Pour obtenir la liste des valeurs possibles, consultez les chiffrements SSL/TLS pris en charge dans Protocoles et chiffrements pris en charge entre les utilisateurs et CloudFront.

    Quand cs-protocol dans le champ 17 est http, la valeur de ce champ est un trait d’union (-).

  22. ssl-cipher

    Lorsque la demande utilise HTTPS, ce champ contient le chiffrement SSL/TLS que l’utilisateur et le serveur ont négocié pour chiffrer la demande et la réponse. Pour obtenir la liste des valeurs possibles, consultez les chiffrements SSL/TLS pris en charge dans Protocoles et chiffrements pris en charge entre les utilisateurs et CloudFront.

    Quand cs-protocol dans le champ 17 est http, la valeur de ce champ est un trait d’union (-).

  23. x-edge-response-result-type

    Comment le serveur a classé la réponse juste avant de la retourner à l’utilisateur. Voir aussi le champ x-edge-result-type. Les valeurs possibles incluent :

    • Hit – Le serveur a servi l’objet à l’utilisateur depuis le cache.

    • RefreshHit – Le serveur a trouvé l’objet dans le cache, mais l’objet avait expiré. Le serveur a donc contacté l’origine pour vérifier que le cache possédait la dernière version de l’objet.

    • Miss – La demande n’a pas pu être satisfaite par un objet du cache, c’est pourquoi le serveur a transmis la demande au serveur d’origine et a renvoyé le résultat à l’utilisateur.

    • LimitExceeded— La demande a été refusée car un CloudFront quota (anciennement appelé limite) a été dépassé.

    • CapacityExceeded : le serveur a renvoyé une erreur 503 car il n’avait pas suffisamment de capacité au moment de la demande pour servir l’objet.

    • Error – Généralement, cela signifie que la demande a entraîné une erreur client (la valeur du champ sc-status est dans la plage 4xx) ou une erreur serveur (la valeur du champ sc-status est dans la plage 5xx).

      Si la valeur du champ x-edge-result-type est Error et que la valeur de ce champ n’est pas Error, le client s’est déconnecté avant d’avoir fini le téléchargement.

    • Redirect – Le serveur a redirigé l’utilisateur depuis HTTP vers HTTPS en fonction des paramètres de distribution.

  24. cs-protocol-version

    Version de HTTP que l’utilisateur a spécifiée dans la requête. Les valeurs possibles incluent HTTP/0.9, HTTP/1.0, HTTP/1.1, HTTP/2.0 et HTTP/3.0.

  25. fle-status

    Lorsque le chiffrement au niveau du champ est configuré pour une distribution, ce champ contient un code indiquant si le corps de la demande a bien été traité. Quand le serveur traite le corps de la demande, chiffre les valeurs dans les champs spécifiés et transfère la demande à l’origine correctement, la valeur de ce champ est Processed. La valeur x-edge-result-type peut toujours indiquer une erreur côté client ou côté serveur dans ce cas.

    Les valeurs possibles pour ce champ sont les suivantes :

    • ForwardedByContentType – Le serveur a réacheminé la demande vers l’origine sans analyse ou chiffrement, car aucun type de contenu n’était configuré.

    • ForwardedByQueryArgs : le serveur a réacheminé la demande vers l’origine sans analyse ou chiffrement, car la demande contient un argument de requête qui n’était pas dans la configuration du chiffrement au niveau du champ.

    • ForwardedDueToNoProfile – Le serveur a réacheminé la demande vers l’origine sans analyse ou chiffrement, car aucun profil n’était spécifié dans la configuration du chiffrement au niveau du champ.

    • MalformedContentTypeClientError – Le serveur a rejeté la demande et a renvoyé le code de statut HTTP 400 à l’utilisateur, car le format de la valeur de l’en-tête Content-Type n’était pas valide.

    • MalformedInputClientError – Le serveur a rejeté la demande et a renvoyé le code de statut HTTP 400 à l’utilisateur, car le format du corps de la requête n’était pas valide.

    • MalformedQueryArgsClientError – Le serveur a rejeté la demande et a renvoyé le code de statut HTTP 400 à l’utilisateur, car un argument de requête était vide ou son format n’était pas valide.

    • RejectedByContentType – Le serveur a rejeté la demande et a renvoyé le code de statut HTTP 400 à l’utilisateur, car aucun type de contenu n’était spécifié dans la configuration du chiffrement au niveau du champ.

    • RejectedByQueryArgs – Le serveur a rejeté la demande et a renvoyé le code de statut HTTP 400 à l’utilisateur, car aucun argument de requête n’était spécifié dans la configuration du chiffrement au niveau du champ.

    • ServerError – Le serveur d’origine a renvoyé une erreur.

    Si la demande dépasse un quota de chiffrement au niveau du champ (précédemment appelé limite), ce champ contient l’un des codes d’erreur suivants, et le serveur renvoie le code d’état HTTP 400 à l’utilisateur. Pour obtenir une liste des quotas actuels de chiffrement au niveau du champ, consultez Quotas sur le chiffrement au niveau du champ.

    • FieldLengthLimitClientError – Un champ configuré pour être chiffré a dépassé la longueur maximale autorisée.

    • FieldNumberLimitClientError – Une demande de configuration de la distribution pour le chiffrement contient un nombre de champs supérieur à celui autorisé.

    • RequestLengthLimitClientError – La longueur du corps de la demande dépasse la longueur maximale autorisée lorsque le chiffrement au niveau du champ est configuré.

    Si le chiffrement au niveau du champ n’est pas configuré pour la distribution, la valeur de ce champ est un trait d’union (-).

  26. fle-encrypted-fields

    Nombre de champs de chiffrement au niveau des champs que le serveur a chiffrés et transmis à l'origine. CloudFront les serveurs transmettent la demande traitée à l'origine au fur et à mesure qu'ils chiffrent les données. Ce champ peut donc avoir une valeur même si la valeur de fle-status est une erreur.

    Si le chiffrement au niveau du champ n’est pas configuré pour la distribution, la valeur de ce champ est un trait d’union (-).

  27. c-port

    Numéro de port de la demande depuis l’utilisateur.

  28. time-to-first-byte

    Nombre de secondes entre la réception de la demande et l’écriture du premier octet de la réponse, tel que mesuré sur le serveur.

  29. x-edge-detailed-result-type

    Ce champ contient la même valeur que le champ x-edge-result-type, sauf dans les cas suivants :

    • Lorsque l’objet a été servi à l’utilisateur à partir de la couche Origin Shield, ce champ contient OriginShieldHit.

    • Lorsque l'objet n'était pas dans le CloudFront cache et que la réponse a été générée par une fonction Lambda @Edge de demande d'origine, ce champ contient. MissGeneratedResponse

    • Lorsque la valeur du champ x-edge-result-type est Error, ce champ contient l'une des valeurs suivantes et présente des informations supplémentaires sur l'erreur :

      • AbortedOrigin – Le serveur a rencontré un problème avec l’origine.

      • ClientCommError – La réponse à l’utilisateur a été interrompue en raison d’un problème de communication entre le serveur et l’utilisateur.

      • ClientGeoBlocked : la distribution est configurée de manière à refuser les demandes en provenance de l’emplacement géographique de l’utilisateur.

      • ClientHungUpRequest – La visionneuse s’est arrêtée prématurément lors de l’envoi de la demande.

      • Error : une erreur s’est produite pour laquelle le type d’erreur ne correspond à aucune des autres catégories. Ce type d’erreur peut se produire lorsque le serveur sert une réponse d’erreur à partir du cache.

      • InvalidRequest – Le serveur a reçu une demande non valide de la part de l’utilisateur.

      • InvalidRequestBlocked – L’accès à la ressource demandée est bloqué.

      • InvalidRequestCertificate : la distribution ne correspond pas au certificat SSL/TLS pour lequel la connexion HTTPS a été établie.

      • InvalidRequestHeader – La demande contenait un en-tête non valide.

      • InvalidRequestMethod – La distribution n’est pas configurée pour gérer la méthode de demande HTTP utilisée. Cela peut se produire lorsque la distribution prend en charge uniquement les demandes pouvant être mises en cache.

      • OriginCommError – La demande a expiré lors de la connexion à l'origine ou lors de la lecture de données à partir de l'origine.

      • OriginConnectError : le serveur n’a pas pu se connecter à l’origine.

      • OriginContentRangeLengthError : l’en-tête Content-Length de la réponse de l’origine ne correspond pas à la longueur de l’en-tête Content-Range.

      • OriginDnsError : le serveur n’a pas pu résoudre le nom de domaine de l’origine.

      • OriginError — L’origine a renvoyé une réponse incorrecte.

      • OriginHeaderTooBigError – Un en-tête renvoyé par l’origine est trop volumineux pour être traité.

      • OriginInvalidResponseError — L’origine a renvoyé une réponse non valide.

      • OriginReadError : le serveur n’a pas pu lire à partir de l’origine.

      • OriginWriteError : le serveur n’a pas pu écrire à l’origine.

      • OriginZeroSizeObjectError — Un objet de taille zéro envoyé depuis l’origine a provoqué une erreur.

      • SlowReaderOriginError — La visionneuse a été lente à lire le message qui a provoqué l’erreur d’origine.

  30. sc-content-type

    Valeur de l’en-tête Content-Type HTTP de la réponse.

  31. sc-content-len

    Valeur de l’en-tête Content-Length HTTP de la réponse.

  32. sc-range-start

    Lorsque la réponse contient l’en-tête Content-Range HTTP, ce champ contient la valeur de début de plage.

  33. sc-range-end

    Lorsque la réponse contient l’en-tête Content-Range HTTP, ce champ contient la valeur de fin de plage.

L’exemple suivant est celui d’un fichier journal pour une distribution :

#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	-	-

Frais pour les journaux standard

La journalisation standard est une fonctionnalité facultative de CloudFront. L’activation de la journalisation standard n’entraîne pas de frais supplémentaires. Cependant, les frais Amazon S3 usuels sont facturés pour stocker les fichiers et y accéder sur Amazon S3 (notez que vous pouvez supprimer ces fichiers à tout moment).

Pour plus d’informations sur la tarification Amazon S3, consultez Tarification Amazon S3.

Pour plus d'informations sur la CloudFront tarification, consultez la section CloudFront Tarification.