Configuración y uso de registros estándar (registros de acceso) - Amazon CloudFront
Cómo funciona el registro estándarElección de un bucket de Amazon S3 para registros estándarPermisos necesarios para configurar el registro estándar y el acceso a archivos de registroPolítica de claves necesarias para buckets de SSE-KMSFormato del nombre de archivoTiempo de entrega de archivos de registro estándarCómo se registran las solicitudes cuando la URL o los encabezados de la solicitud sobrepasan el tamaño máximoAnálisis de registros estándarEdición de configuración de registro estándarEliminación de archivos de registro estándar de un bucket de Amazon S3Formato de archivo de registro estándarCargos por registros estándar

Configuración y uso de registros estándar (registros de acceso)

Puede configurar CloudFront para crear archivos de registro que contengan información detallada sobre cada solicitud de usuario que CloudFront recibe. Estos se denominan registros estándar, también conocidos como registros de acceso. Si habilita registros estándar, también puede especificar el bucket de Amazon S3 en el que desea que CloudFront guarde los archivos.

Puede habilitar los registros estándar al crear o actualizar una distribución. Para obtener más información, consulte Registro.

CloudFront también ofrece registros en tiempo real, que le proporcionan información sobre las solicitudes realizadas a una distribución en tiempo real (los registros se envían en cuestión de segundos después de recibir las solicitudes). Puede usar registros en tiempo real para monitorear, analizar y tomar medidas en función del rendimiento de entrega de contenido. Para obtener más información, consulte Uso de registros en tiempo real.

Cómo funciona el registro estándar

En el siguiente diagrama se muestra cómo CloudFront registra información sobre solicitudes para los objetos.

Proceso básico de los registros de acceso

A continuación, se explica cómo CloudFront registra información sobre solicitudes para los objetos, tal y como se muestra en el diagrama anterior.

  1. En este diagrama se muestran dos sitios web, A y B, y sus distribuciones de CloudFront correspondientes. Los usuarios solicitan sus objetos a través de URL asociadas a las distribuciones.

  2. CloudFront dirige cada solicitud a la ubicación de borde adecuada.

  3. CloudFront escribe los datos de cada solicitud en un archivo de registro específico en esa distribución. En este ejemplo, la información acerca de las solicitudes relacionadas con la Distribución A se escriben en un archivo de registro solo para la Distribución A, y la información acerca de las solicitudes relacionadas con la Distribución B se escriben en un archivo de registro solo para la Distribución B.

  4. CloudFront periódicamente guarda el archivo de registro de la distribución en el bucket de Amazon S3 especificado al habilitar el registro. A continuación, CloudFront comienza a guardar información acerca de las solicitudes posteriores en un nuevo archivo de registro para la distribución.

Si ningún usuario obtiene acceso a su contenido durante una hora determinada, no se reciben archivos de registro de esa hora.

Cada entrada del archivo de registro ofrece información acerca de una única solicitud. Para obtener más información acerca del formato del archivo de registro, consulte Formato de archivo de registro estándar.

nota

Recomendamos utilizar los registros de acceso para comprender la naturaleza de las solicitudes hechas a su contenido y no como una relación exhaustiva de todas las solicitudes. CloudFront envía registros de acceso en la medida en que sea posible. La entrada de registro de una solicitud determinada puede entregarse mucho después de la solicitud se haya procesado realmente y, en casos contados, es probable que una entrada de registro no se entregue en absoluto. Cuando se omite una entrada de registro de los registros de acceso, la cantidad de entradas de los registros de acceso no coincide con el uso que aparece en los informes de facturación y de uso de AWS.

Elección de un bucket de Amazon S3 para registros estándar

Al habilitar el registro para una distribución, se especifica el bucket de Amazon S3 en el que desea que CloudFront almacene los archivos de registro. Si utiliza Amazon S3 como origen, le recomendamos que utilice un bucket independiente para los archivos de registro.

Puede almacenar los archivos de registro de varias distribuciones en el mismo bucket. Al habilitar el registro, puede especificar un prefijo para los nombres de archivo, para así realizar un seguimiento de que los archivos de registro que se asocian con las distribuciones.

Elección de un bucket de S3

  • El bucket debe tener una lista de control de acceso (ACL) habilitada. Si elige un bucket sin ACL habilitada desde la consola de CloudFront, aparecerá un mensaje de error. Consulte Permisos necesarios para configurar el registro estándar y el acceso a archivos de registro.

  • No elija un bucket de Amazon S3 con Propiedad de objetos de S3 configurado como propietario del bucket forzado. Esta configuración desactiva las ACL para el bucket y los objetos que contiene, lo que evita que CloudFront entregue archivos de registro al bucket.

  • No elija un bucket de Amazon S3 en las siguientes Regiones de AWS. CloudFront no entrega registros estándar a buckets en estas regiones:

    • África (Ciudad del Cabo)

    • Asia-Pacífico (Hong Kong)

    • Asia-Pacífico (Hyderabad)

    • Asia-Pacífico (Yakarta)

    • Asia-Pacífico (Melbourne)

    • Oeste de Canadá (Calgary)

    • Europa (Milán)

    • Europa (España)

    • Europa (Zúrich)

    • Israel (Tel Aviv)

    • Medio Oriente (Baréin)

    • Medio Oriente (EAU)

Permisos necesarios para configurar el registro estándar y el acceso a archivos de registro

importante

A partir de abril de 2023, debe habilitar ACL de S3 para los nuevos buckets de S3 que se utilicen para los registros estándar de CloudFront. Puede habilitar las ACL cuando cree un bucket o habilitar ACL para un bucket existente.

Para obtener más información sobre los cambios, consulte Configuración predeterminada para preguntas frecuentes de buckets de S3 nuevos en la Guía del usuario de Amazon Simple Storage Service y Aviso: Los cambios en la seguridad de Amazon S3 llegarán en abril de 2023 en el Blog de novedades de AWS.

La Cuenta de AWS debe tener los siguientes permisos para el bucket que especifique para los archivos de registro:

  • La ACL del bucket debe concederle FULL_CONTROL. Si es el propietario del bucket, su cuenta tiene este permiso de forma predeterminada. Si no está, el propietario del bucket debe actualizar la ACL del bucket.

  • s3:GetBucketAcl

  • s3:PutBucketAcl

ACL para el bucket

Al crear o actualizar una distribución y habilitar el registro, CloudFront utiliza estos permisos para actualizar ACL para que el bucket le conceda a la cuenta awslogsdelivery permiso FULL_CONTROL. La cuenta awslogsdelivery escribe archivos de registro en el bucket. Si su cuenta no tiene los permisos necesarios para actualizar la ACL, se producirá un error al crear o actualizar la distribución.

En determinadas circunstancias, si envía una solicitud de forma programada para crear un bucket con un nombre específico, pero ya existe uno con ese nombre, S3 restablece los permisos del bucket a sus valores predeterminados. Si configura CloudFront para guardar los registros de acceso en un bucket de S3 y los registros dejan de guardarse en ese bucket, compruebe los permisos del bucket para asegurarse de que CloudFront dispone de los permisos necesarios.

Restauración de la ACL para el bucket

Si elimina permisos para la cuenta awslogsdelivery, CloudFront no podrá guardar registros en el bucket de S3. Para permitir que CloudFront comience a guardar los registros de la distribución de nuevo, restaure el permiso de ACL realizando una de las siguientes acciones:

  • Desactive el registro de la distribución en CloudFront y, a continuación, habilítelo de nuevo. Para obtener más información, consulte Registro.

  • Agregue el permiso de ACL para awslogsdelivery manualmente mediante el acceso al bucket de S3 en la consola de Amazon S3 y agregando permiso. Para añadir la ACL para awslogsdelivery, debe proporcionar el ID canónico de la cuenta, que es el siguiente:

    c4c1ede66af53448b93c283ce9448c4ba468c9432aa01d700d3878632f77d2d0

    Para obtener más información acerca de cómo agregar ACL a buckets de S3, consulte Configuración de ACL en la Guía del usuario de Amazon Simple Storage Service.

ACL para cada archivo de registro

Además de la ACL del bucket, hay una ACL en cada archivo de registro. El propietario del bucket tiene permisos FULL_CONTROL en cada archivo de registro, el propietario de la distribución (si no es el mismo que el del bucket) no tiene permiso, y la cuenta awslogsdelivery tiene permisos de lectura y escritura.

Deshabilitar los registros

Si desactiva el registro, CloudFront no elimina las ACL del bucket ni de los archivos de registro. Puede eliminar las ACL si es necesario.

Política de claves necesarias para buckets de SSE-KMS

Si el bucket de S3 de los registros estándar utiliza cifrado del lado del servidor con AWS KMS keys (SSE-KMS) empleando una clave administrada por el cliente, se debe agregar la siguiente instrucción a la política de claves para la clave administrada por el cliente. Esto permite a CloudFront escribir archivos de registro en el bucket. No puede utilizar SSE-KMS con la Clave administrada de AWS, porque CloudFront no podrá escribir los archivos de registro en el bucket.

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

Si el bucket de S3 para sus registros estándar utiliza SSE-KMS con una clave de bucket de S3, también debe agregar el permiso kms:Decrypt a la instrucción de la política. En ese caso, la instrucción total de la política se ve del siguiente modo.

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

Formato del nombre de archivo

El nombre de cada archivo de registro que CloudFront guarda en el bucket de Amazon S3 utiliza el formato de nombre de archivo siguiente:

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

La fecha y la hora se muestran según la hora universal coordinada (UTC).

Por ejemplo, si utiliza example-prefix como prefijo y el ID de distribución es EMLARXS9EXAMPLE, los nombres de archivo tendrán el siguiente aspecto:

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

Al habilitar el registro para una distribución, puede especificar un prefijo para los nombres de archivo, para así realizar un seguimiento de que los archivos de registro que se asocian a las distribuciones. Si incluye un valor para el prefijo del archivo de registro y el prefijo no termina con una barra inclinada (/), CloudFront agrega una automáticamente. Si el prefijo termina con una barra inclinada, CloudFront no agrega otra.

.gz al final del nombre del archivo indica que CloudFront ha comprimido el archivo de registro con gzip.

Tiempo de entrega de archivos de registro estándar

CloudFront proporciona registros estándar para una distribución varias veces cada hora. En general, un archivo de registro contiene información acerca de las solicitudes que CloudFront ha recibido durante un periodo determinado. Normalmente, CloudFront envía el archivo de registro de ese periodo al bucket de Amazon S3 una hora después de que se produzcan los eventos reflejados en el registro. Tenga en cuenta, sin embargo, que algunas o todas las entradas de los archivos de registro de un periodo a veces pueden retrasarse hasta 24 horas. Cuando se retrasan entradas de registro, CloudFront las guarda en un archivo de registro cuyo nombre de archivo incluye la fecha y la hora del periodo en el que se realizaron las solicitudes en lugar de incluir la fecha y la hora de envío del archivo.

Al crear un archivo de registro, CloudFront consolida información para la distribución desde todas las ubicaciones de borde que recibieron solicitudes de los objetos durante el periodo que abarca dicho archivo de registro.

CloudFront puede guardar más de un archivo por periodo en función de la cantidad de solicitudes de objetos asociados con una distribución que recibe CloudFront.

CloudFront comienza a enviar de forma fiable los registros de acceso unas cuatro horas después de habilitar los registros. Es posible obtener algunos registros de acceso antes del momento de envío.

nota

Si ningún usuario solicita sus objetos durante un periodo, no recibirá archivos de registro para ese periodo.

CloudFront también ofrece registros en tiempo real, que le proporcionan información sobre las solicitudes realizadas a una distribución en tiempo real (los registros se envían en cuestión de segundos después de recibir las solicitudes). Puede usar registros en tiempo real para monitorear, analizar y tomar medidas en función del rendimiento de entrega de contenido. Para obtener más información, consulte Uso de registros en tiempo real.

Cómo se registran las solicitudes cuando la URL o los encabezados de la solicitud sobrepasan el tamaño máximo

Si el tamaño total de todos los encabezados de solicitud, incluidas las cookies, supera los 20 KB o si la URL supera los 8192 bytes, CloudFront no puede analizar la solicitud por completo y no puede registrar la solicitud. Dado que la solicitud no se registra, el código de estado que se devuelve no se verá en los archivos de registro de error de HTTP.

Si el cuerpo de la solicitud supera el tamaño máximo, se registra la solicitud, incluido el código de estado de error de HTTP.

Análisis de registros estándar

Dado que puede recibir varios registros de acceso por hora, le recomendamos que combine en un mismo archivo todos los archivos de registro que reciba para un periodo determinado. Así podrá analizar los datos de ese periodo de forma más completa y precisa.

Una forma de analizar los registros de acceso consiste en utilizar Amazon Athena. Athena es un servicio de consultas interactivo que puede ayudarlo a analizar datos de los servicios de AWS, incluido CloudFront. Para obtener más información, consulte Consulta de los registros de Amazon CloudFront en la Guía del usuario de Amazon Athena.

Además, en las siguientes entradas del blog de AWS se explican algunas formas de analizar los registros de acceso.

importante

Recomendamos utilizar los registros de acceso para comprender la naturaleza de las solicitudes hechas a su contenido y no como una relación exhaustiva de todas las solicitudes. CloudFront envía registros de acceso en la medida en que sea posible. La entrada de registro de una solicitud determinada puede entregarse mucho después de la solicitud se haya procesado realmente y, en casos contados, es probable que una entrada de registro no se entregue en absoluto. Cuando se omite una entrada de registro de los registros de acceso, la cantidad de entradas de los registros de acceso no coincide con el uso que aparece en los informes de facturación y de uso de AWS.

Edición de configuración de registro estándar

Puede habilitar o desactivar el registro, cambiar el bucket de Amazon S3 en el que se almacenan los registros y cambiar el prefijo de los archivos de registro a través de la consola de CloudFront o la API de CloudFront. Los cambios de configuración de registro surten efecto en un plazo de 12 horas.

Para obtener más información, consulte los siguientes temas:

  • Para actualizar una distribución mediante la consola de CloudFront, consulte Actualizar una distribución.

  • Para actualizar una distribución mediante la API de CloudFront, consulte UpdateDistribution en la Referencia de la API de Amazon CloudFront.

Eliminación de archivos de registro estándar de un bucket de Amazon S3

CloudFront no elimina automáticamente los archivos de registro del bucket de Amazon S3. Para obtener información acerca de cómo eliminar archivos de registro de un bucket de Amazon S3, consulte los siguientes temas:

  • Uso de la consola de Amazon S3: Eliminación de objetos en la Guía del usuario de la consola de Amazon Simple Storage Service.

  • Uso de la API de REST: DeleteObject en la Referencia de la API de Amazon Simple Storage Service.

Formato de archivo de registro estándar

Cada entrada del archivo de registro ofrece información acerca de una única solicitud de espectador. Los archivos log tienen las siguientes características:

  • Utilice el formato de archivo de registro ampliado W3C.

  • Contienen valores separados por pestañas.

  • Contienen registros que no están necesariamente en orden cronológico.

  • Contiene dos líneas de encabezado: una con la versión de formato de archivo y otra que muestra la cantidad de campos de W3C incluidos en cada registro.

  • Contiene equivalentes codificados en URL para espacios y otros caracteres determinados en valores de campo.

    Los equivalentes codificados en URL se utilizan para los siguientes caracteres:

    • Códigos de caracteres ASCII de 0 a 32, ambos incluidos

    • Códigos de caracteres ASCII 127 y superiores

    • Todos los caracteres de la tabla siguiente

    El estándar de codificación de URL se define en RFC 1738.

Valor de URL codificada

Carácter

%3C

<

%3E

>

%22

"

%23

#

%25

%

%7B

{

%7D

}

%7C

|

%5C

\

%5E

^

%7E

~

%5B

[

%5D

]

%60

`

%27

'

%20

espacio

Campos de archivo de registro estándar

El archivo de registro de una distribución contiene 33 campos. La lista siguiente contiene el nombre de cada campo, en orden, junto con una descripción de la información de ese campo.

  1. date

    La fecha en que se produjo el evento en el formato YYYY-MM-DD. Por ejemplo, 2019-06-30. La fecha y la hora se muestran según la hora universal coordinada (UTC). Para conexiones de WebSockets, indica la fecha de cierre de la conexión.

  2. time

    La hora a la que el servidor de CloudFront terminó de responder a la solicitud (en UTC), por ejemplo, 01:42:39. Para conexiones de WebSockets, indica la hora de cierre de la conexión.

  3. x-edge-location

    La ubicación de borde que atendió la solicitud. Cada ubicación de borde se identifica mediante un código de tres letras y un número asignado arbitrariamente (por ejemplo, DFW3). El código de tres letras normalmente se corresponde con el código del aeropuerto de la Asociación de Transporte Aéreo Internacional (IATA) más cercano a la ubicación geográfica de la ubicación periférica. Estas abreviaturas pueden cambiar en el futuro.

  4. sc-bytes

    El número total de bytes que el servidor ha enviado al lector en respuesta a la solicitud, incluidos los encabezados. Para conexiones WebSockets, se trata del número total de bytes enviados desde el servidor al cliente a través de la conexión.

  5. c-ip

    La dirección IP del espectador que ha realizado la solicitud, por ejemplo, 192.0.2.183 o 2001:0db8:85a3::8a2e:0370:7334. Si el lector ha utilizado un proxy HTTP o un equilibrador de carga para enviar la solicitud, el valor de este campo es la dirección IP del proxy o del balanceador de carga. Consulte también el campo x-forwarded-for.

  6. cs-method

    El método de solicitud HTTP recibido del lector.

  7. cs(Host)

    El nombre de dominio de la distribución de CloudFront (por ejemplo, d111111abcdef8.cloudfront.net).

  8. cs-uri-stem

    La parte de la URL de solicitud que identifica la ruta y el objeto (por ejemplo, /images/cat.jpg). Los signos de interrogación (?) de las URL y las cadenas de consulta no están incluidas en el registro.

  9. sc-status

    Contiene uno de los siguientes valores:

    • El código de estado HTTP de la respuesta del servidor (por ejemplo, 200).

    • 000, que indica que el lector ha cerrado la conexión antes de que el servidor pudiese responder a la solicitud. Si el lector cierra la conexión después de que el servidor comience a enviar la respuesta, este campo contiene el código de estado HTTP de la respuesta que el servidor había comenzado a enviar.

  10. cs(Referer)

    El valor del encabezado Referer de la solicitud. Este es el nombre del dominio que ha originado la solicitud. Entre los remitentes principales se incluyen motores de búsqueda, otros sitios web que enlazan directamente con sus objetos y su propio sitio web.

  11. cs(User-Agent)

    El valor del encabezado User-Agent de la solicitud. El encabezado User-Agent identifica el origen de la solicitud, como el tipo de dispositivo y el navegador que enviaron la solicitud o, si la solicitud provino de un motor de búsqueda, de cuál.

  12. cs-uri-query

    La parte de la cadena de consulta de la URL, de haberla.

    Cuando una URL no contiene una cadena de consulta, el valor de este campo es un guion (-). Para obtener más información, consulte Almacenamiento en caché de contenido en función de parámetros de cadenas de consulta.

  13. cs(Cookie)

    El encabezado Cookie de la solicitud, incluidos los pares nombre-valor y los atributos asociados.

    Si habilita el registro de cookies, CloudFront registra las cookies de todas las solicitudes independientemente de qué cookies elija reenviar al origen. Cuando una solicitud no incluye un encabezado de cookie, el valor de este campo es un guion (-). Para obtener más información acerca de cookies, consulte Almacenamiento en caché de contenido en función de cookies.

  14. x-edge-result-type

    Cómo el servidor ha clasificado la respuesta después de que el último byte abandonara el servidor. En algunos casos, el tipo de resultado puede cambiar entre el momento en que el servidor está listo para enviar la respuesta y el momento en que termina el envío de la respuesta. Consulte también el campo x-edge-response-result-type.

    Por ejemplo, en el streaming de HTTP, se supone que el servidor encuentra un segmento de la secuencia en la caché. En esta situación, el valor de este campo sería normalmente Hit. Sin embargo, si el lector cierra la conexión antes de que el servidor haya entregado todo el segmento, el tipo de resultado final (y el valor de este campo) es Error.

    Las conexiones WebSocket tendrán un valor de Miss para este campo porque el contenido no se puede almacenar en caché y se asigna directamente al origen.

    Entre los valores posibles se incluyen:

    • Hit: el servidor ofreció el objeto al lector desde la caché.

    • RefreshHit: el servidor encontró el objeto en la caché pero el objeto había vencido, por lo que el servidor se puso en contacto con el origen para comprobar que la caché tenía la versión más reciente del objeto.

    • Miss: un objeto en la caché no ha podido satisfacer la solicitud, así que el servidor la ha reenviado al origen y ha devuelto el resultado al lector.

    • LimitExceeded: se ha denegado la solicitud porque se superó una cuota (antes denominada límite) de CloudFront.

    • CapacityExceeded: el servidor ha devuelto un código de estado HTTP 503 porque no disponía de capacidad suficiente en el momento de la solicitud para prestar servicio al objeto.

    • Error: normalmente, esto significa que la solicitud ha dado lugar a un error de cliente (el valor del campo sc-status está en el intervalo 4xx) o un error de servidor (el valor del campo sc-status está en el intervalo 5xx). Si el valor del campo sc-status es 200 o si el valor de este campo es Error y el valor del campo x-edge-response-result-type no es Error, significa que la solicitud HTTP se ha realizado correctamente pero el cliente se ha desconectado antes de recibir todos los bytes.

    • Redirect: el servidor ha redirigido al lector de HTTP a HTTPS de acuerdo con la configuración de distribución.

  15. x-edge-request-id

    Una cadena opaca que identifica una solicitud de forma única. CloudFront también envía esta cadena en el encabezado de respuesta x-amz-cf-id.

  16. x-host-header

    El valor que el lector ha incluido en el encabezado Host de la solicitud. Si utiliza el nombre de dominio CloudFront en las URL de los objetos (como d111111abcdef8.cloudfront.net), este campo contiene ese nombre de dominio. Si utiliza nombres de dominio alternativos (CNAME) en las URL de los objetos (como www.example.com), este campo contiene el nombre de dominio alternativo.

    Si está utilizando nombres de dominio alternativo, consulte cs(Host) en el campo 7 para ver el nombre de dominio asociado con su distribución.

  17. cs-protocol

    El protocolo de la solicitud del lector (http, https, ws o wss).

  18. cs-bytes

    El número total de bytes de datos que el lector ha incluido en la solicitud, incluidos los encabezados. Para conexiones WebSockets, se trata del número total de bytes enviados desde el cliente al servidor en la conexión.

  19. time-taken

    El número de segundos (hasta la milésima de segundo, por ejemplo, 0,082) desde que el servidor recibe la solicitud del lector hasta que el servidor escribe el último byte de la respuesta en la cola de salida, según se mide en el servidor. Desde el punto de vista del lector, el tiempo total para obtener la respuesta completa será superior a este valor a causa de la latencia de la red y el almacenamiento en búfer de TCP.

  20. x-forwarded-for

    Si el lector ha utilizado un proxy HTTP o un balanceador de carga para enviar la solicitud, el valor del campo c-ip es la dirección IP del proxy o del balanceador de carga. En ese caso, este campo es la dirección IP del espectador que originó la solicitud. Este campo puede contener varias direcciones IP separadas por comas. Cada dirección IP puede ser una dirección IPv4 (por ejemplo, 192.0.2.183) o una dirección IPv6 (por ejemplo, 2001:0db8:85a3::8a2e:0370:7334).

    Si el lector no utiliza un proxy HTTP o un balanceador de carga, el valor de este campo es un guion (-).

  21. ssl-protocol

    Cuando la solicitud ha utilizado HTTPS, este campo contiene el protocolo SSL/TLS que el lector y el servidor han negociado para transmitir la solicitud y la respuesta. Para obtener una lista de valores posibles, consulte los protocolos SSL/TLS compatibles en Protocolos y cifrados admitidos entre lectores y CloudFront.

    Cuando cs-protocol en el campo 17 es http, el valor de este campo es un guion (-).

  22. ssl-cipher

    Cuando la solicitud ha utilizado HTTPS, este campo contiene el cifrado SSL/TLS que el lector y el servidor han negociado para cifrar la solicitud y la respuesta. Para obtener una lista de valores posibles, consulte los cifrados SSL/TLS compatibles en Protocolos y cifrados admitidos entre lectores y CloudFront.

    Cuando cs-protocol en el campo 17 es http, el valor de este campo es un guion (-).

  23. x-edge-response-result-type

    Cómo el servidor ha clasificado la respuesta antes de devolver la respuesta al lector. Consulte también el campo x-edge-result-type. Entre los valores posibles se incluyen:

    • Hit: el servidor ofreció el objeto al lector desde la caché.

    • RefreshHit: el servidor encontró el objeto en la caché pero el objeto había vencido, por lo que el servidor se puso en contacto con el origen para comprobar que la caché tenía la versión más reciente del objeto.

    • Miss: un objeto en la caché no ha podido satisfacer la solicitud, así que el servidor ha reenviado la solicitud al servidor de origen y ha devuelto el resultado al lector.

    • LimitExceeded: se ha denegado la solicitud porque se superó una cuota (antes denominada límite) de CloudFront.

    • CapacityExceeded: el servidor ha devuelto un error 503 porque no disponía de capacidad suficiente en el momento de la solicitud para prestar servicio al objeto.

    • Error: normalmente, esto significa que la solicitud ha dado lugar a un error de cliente (el valor del campo sc-status está en el intervalo 4xx) o un error de servidor (el valor del campo sc-status está en el intervalo 5xx).

      Si el valor del campo x-edge-result-type es Error y el valor de este campo no es Error, el cliente se ha desconectado antes de finalizar la descarga.

    • Redirect: el servidor ha redirigido al lector de HTTP a HTTPS de acuerdo con la configuración de distribución.

  24. cs-protocol-version

    La versión de HTTP que el espectador especificó en la solicitud. Entre los valores posibles se incluyen HTTP/0.9, HTTP/1.0, HTTP/1.1, HTTP/2.0 y HTTP/3.0.

  25. fle-status

    Cuando se configura el cifrado en el nivel de campo para una distribución, este campo contiene un código que indica si el cuerpo de la solicitud se ha procesado correctamente. Cuando el servidor procesa correctamente el cuerpo de la solicitud, cifra los valores de los campos especificados y reenvía la solicitud al origen, el valor de este campo es Processed. El valor de x-edge-result-type todavía puede indicar un error del lado del cliente o del lado del servidor en este caso.

    Los valores posibles para este campo son:

    • ForwardedByContentType: el servidor ha reenviado la solicitud al origen sin analizar ni cifrar porque no se ha configurado ningún tipo de contenido.

    • ForwardedByQueryArgs: el servidor ha reenviado la solicitud al origen sin analizar ni cifrar porque la solicitud contiene un argumento de consulta que no estaba en la configuración de cifrado en el nivel de campo.

    • ForwardedDueToNoProfile: el servidor ha reenviado la solicitud al origen sin analizar ni cifrar porque no se ha especificado ningún perfil en la configuración de cifrado en el nivel de campo.

    • MalformedContentTypeClientError: el servidor ha rechazado la solicitud y ha devuelto un código de estado HTTP 400 al lector porque el valor del encabezado Content-Type estaba en un formato no válido.

    • MalformedInputClientError: el servidor ha rechazado la solicitud y ha devuelto un código de estado HTTP 400 al lector porque el cuerpo de la solicitud estaba en un formato no válido.

    • MalformedQueryArgsClientError: el servidor ha rechazado la solicitud y ha devuelto un código de estado HTTP 400 al lector porque un argumento de consulta estaba vacío o tenía un formato no válido.

    • RejectedByContentType: el servidor ha rechazado la solicitud y ha devuelto un código de estado HTTP 400 al lector porque no se ha especificado ningún tipo de contenido en la configuración de cifrado en el nivel de campo.

    • RejectedByQueryArgs: el servidor ha rechazado la solicitud y ha devuelto un código de estado HTTP 400 al lector porque no se ha especificado ningún argumento de consulta en la configuración de cifrado en el nivel de campo.

    • ServerError: el servidor de origen ha devuelto un error.

    Si la solicitud supera una cuota de cifrado en el nivel de campo (anteriormente denominada límite), este campo contiene uno de los siguientes códigos de error y el servidor devuelve el código de estado HTTP 400 al lector. Para obtener una lista de las cuotas actuales del cifrado en el nivel de campo, consulte Cuotas de cifrado en el nivel de campo.

    • FieldLengthLimitClientError: un campo que se ha configurado como cifrado ha superado la longitud máxima permitida.

    • FieldNumberLimitClientError: una solicitud que la distribución ha configurado para cifrar contiene un número de campos mayor del permitido.

    • RequestLengthLimitClientError: la longitud del cuerpo de la solicitud ha superado el máximo permitido cuando se ha configurado el cifrado en el nivel de campo.

    Si no se ha configurado el cifrado en el nivel de campo para la distribución, el valor de este campo es un guion (-).

  26. fle-encrypted-fields

    El número de campos de cifrado en el nivel de campo que el servidor ha cifrado y reenviado al origen. Los servidores de CloudFront transmiten la solicitud procesada al origen a medida que cifran los datos, por lo que este campo puede tener un valor incluso si el valor de fle-status es un error.

    Si no se ha configurado el cifrado en el nivel de campo para la distribución, el valor de este campo es un guion (-).

  27. c-port

    El número de puerto de la solicitud desde el espectador.

  28. time-to-first-byte

    El número de segundos entre la recepción de la solicitud y la escritura del primer byte de la respuesta, medido en el servidor.

  29. x-edge-detailed-result-type

    Este campo contiene el mismo valor que el campo x-edge-result-type, excepto en los siguientes casos:

    • Cuando el objeto se ha servido al lector desde la capa de Origin Shield, este campo contiene OriginShieldHit.

    • Cuando el objeto no estaba en la memoria caché de CloudFront y la respuesta se generó mediante una función Lambda @Edge de solicitud de origen, este campo contiene MissGeneratedResponse.

    • Cuando el valor del campo x-edge-result-type es Error, este campo contiene uno de los siguientes valores con más información sobre el error:

      • AbortedOrigin: el servidor ha encontrado un problema con el origen.

      • ClientCommError: la respuesta al lector se ha interrumpido debido a un problema de comunicación entre el servidor y el lector.

      • ClientGeoBlocked: la distribución está configurada para rechazar solicitudes desde la ubicación geográfica del lector.

      • ClientHungUpRequest: el espectador se ha detenido prematuramente mientras enviaba la solicitud.

      • Error: se ha producido un error cuyo tipo de error no se ajusta a ninguna de las otras categorías. Este tipo de error puede producirse cuando el servidor envía una respuesta de error desde la caché.

      • InvalidRequest: el servidor ha recibido una solicitud no válida desde el lector.

      • InvalidRequestBlocked: el acceso al recurso solicitado está bloqueado.

      • InvalidRequestCertificate: la distribución no coincide con el certificado SSL/TLS para el que se ha establecido la conexión HTTPS.

      • InvalidRequestHeader: la solicitud contenía un encabezado no válido.

      • InvalidRequestMethod: la distribución no está configurada para gestionar el método de solicitud HTTP que se ha utilizado. Esto puede suceder cuando la distribución solo admite solicitudes que se pueden almacenar en caché.

      • OriginCommError: se agotó el tiempo de espera de la solicitud al conectarse a un origen o al leer datos de un origen.

      • OriginConnectError: el servidor no ha podido conectarse al origen.

      • OriginContentRangeLengthError: el encabezado Content-Length de la respuesta del origen no coincide con la longitud del encabezado Content-Range.

      • OriginDnsError: el servidor no ha podido resolver el nombre de dominio del origen.

      • OriginError: el origen ha devuelto una respuesta incorrecta.

      • OriginHeaderTooBigError: un encabezado devuelto por el origen es demasiado grande para que el servidor de borde lo procese.

      • OriginInvalidResponseError: el origen ha devuelto una respuesta no válida.

      • OriginReadError: el servidor no ha podido leer desde el origen.

      • OriginWriteError: el servidor no ha podido escribir en el origen.

      • OriginZeroSizeObjectError: un objeto de tamaño cero enviado desde el origen ha provocado un error.

      • SlowReaderOriginError: el espectador ha sido al leer el mensaje que ha provocado el error de origen.

  30. sc-content-type

    El valor del encabezado HTTP Content-Type de la respuesta.

  31. sc-content-len

    El valor del encabezado HTTP Content-Length de la respuesta.

  32. sc-range-start

    Cuando la respuesta contiene el encabezado HTTP Content-Range, este campo contiene el valor inicial del intervalo.

  33. sc-range-end

    Cuando la respuesta contiene el encabezado HTTP Content-Range, este campo contiene el valor final del intervalo.

A continuación, se muestra un ejemplo de archivo de registro para una distribución:

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

Cargos por registros estándar

El registro estándar es una característica opcional de CloudFront. No se aplica ningún cargo adicional por habilitar el registro estándar. Sin embargo, se acumulan cargos de Amazon S3 usuales en concepto de almacenamiento y acceso a los archivos en Amazon S3 (se pueden eliminar en cualquier momento).

Para obtener más información acerca de los precios de Amazon S3, consulte Precios de Amazon S3.

Para obtener más información acerca de los precios de CloudFront, consulte Precios de CloudFront.