Configurar e usar logs padrão (logs de acesso)

Você pode configurar CloudFront para criar arquivos de log que contenham informações detalhadas sobre cada solicitação de usuário CloudFront recebida. Esses são chamados de logs padrão, também conhecidos como logs de acesso. Se você habilitar os registros padrão, também poderá especificar o bucket do Amazon S3 no qual CloudFront deseja salvar os arquivos.

É possível habilitar os logs padrão ao criar ou atualizar uma distribuição. Para ter mais informações, consulte Valores especificados ao criar ou atualizar uma distribuição.

CloudFront também oferece registros em tempo real, que fornecem informações sobre solicitações feitas a uma distribuição em tempo real (os registros são entregues segundos após o recebimento das solicitações). É possível usar os logs em tempo real para monitorar, analisar e tomar ações com base na performance da entrega de conteúdo. Para obter mais informações, consulte Logs em tempo real.

Como funciona o registro em log padrão

O diagrama a seguir mostra como CloudFront registra informações sobre solicitações de seus objetos.

A seguir, explicamos como CloudFront registra informações sobre solicitações de seus objetos, conforme ilustrado no diagrama anterior.

1. Neste diagrama, você tem dois sites, A e B, e duas CloudFront distribuições correspondentes. Os usuários solicitam seus objetos usando URLs associados a suas distribuições.

2. CloudFront encaminha cada solicitação para a localização de borda apropriada.

3. CloudFront grava dados sobre cada solicitação em um arquivo de log específico dessa distribuição. Neste exemplo, informações sobre as solicitações relacionadas à Distribuição A são registradas em um arquivo de log exclusivo para ela. Da mesma forma, informações sobre as solicitações relacionadas à Distribuição B são registradas em um arquivo de log exclusivo para ela.

4. CloudFront salva periodicamente o arquivo de log para uma distribuição no bucket do Amazon S3 que você especificou ao habilitar o registro em log. CloudFront em seguida, começa a salvar informações sobre solicitações subsequentes em um novo arquivo de log para a distribuição.

Se nenhum usuário acessar seu conteúdo em uma hora específica, você não receberá arquivos de log referentes a essa hora.

Cada entrada em um arquivo de log fornece detalhes sobre uma única solicitação. Para obter mais informações sobre o formato do arquivo de log, consulte Formato de arquivo de log padrão.

nota

Recomendamos que você use os registros para entender a natureza das solicitações de seu conteúdo, não como uma contabilidade completa de todas as solicitações. CloudFront fornece registros de acesso com base no melhor esforço. A entrada do log de uma solicitação específica pode ser entregue muito depois do processamento da solicitação e, raramente, nunca ser entregue. Quando uma entrada de log for omitida dos logs de acesso, o número de entradas nos logs não corresponderá ao uso exibido nos relatórios de uso e faturamento da AWS.

Escolher um bucket do Amazon S3 para seus logs padrão

Ao ativar o registro em log para uma distribuição, você especifica o bucket do Amazon S3 no qual CloudFront deseja armazenar os arquivos de log. Se você estiver usando o Amazon S3 como origem, recomendamos que não use o mesmo bucket para os arquivos de log. O uso de um bucket separado simplifica a manutenção.

Importante

Não escolha um bucket do Amazon S3 com Propriedade do objeto do S3 configurado como imposto pelo proprietário do bucket. Essa configuração desativa as ACLs para o bucket e os objetos nele contidos, o que CloudFront impede a entrega de arquivos de log para o bucket.

Importante

Não escolha um bucket do Amazon S3 em nenhuma das seguintes regiões, porque CloudFront não entrega registros padrão para buckets nessas regiões:

• Africa (Cape Town)

• Ásia-Pacífico (Hong Kong)

• Ásia-Pacífico (Hyderabad)

• Ásia-Pacífico (Jacarta)

• Ásia-Pacífico (Melbourne)

• Canadá (Central)

• Europa (Milão)

• Europa (Espanha)

• Europa (Zurique)

• Israel (Tel Aviv)

• Oriente Médio (Barém)

• Oriente Médio (Emirados Árabes Unidos)

Você pode armazenar os arquivos de log de várias distribuições no mesmo bucket. Ao habilitar o registro, você pode especificar um prefixo opcional para os nomes dos arquivos, a fim de diferenciar quais arquivos de log são associados a quais distribuições.

Permissões necessárias para configurar o registro em log padrão e acessar os arquivos de log

Importante

A partir de abril de 2023, você precisará habilitar as listas de controle de acesso (ACLs) do S3 para novos buckets do S3 usados para registros padrão. CloudFront As ACLs podem ser habilitadas durante as etapas de criação do bucket ou após a criação de um bucket.

Para obter mais informações sobre as alterações, consulte Perguntas frequentes sobre configurações padrão para novos buckets do S3 no Guia do usuário do Amazon Simple Storage Service e em Alerta: Alterações na segurança do Amazon S3 chegarão em abril de 2023 no blog de notícias da AWS.

Sua conta da AWS deve ter as seguintes permissões para o bucket especificado para os arquivos de log:

• A lista de controle de acesso (ACL) do S3 do bucket deve conceder a você FULL_CONTROL. Se você for o proprietário do bucket, sua conta terá essa permissão por padrão. Em caso negativo, o proprietário do bucket deverá atualizar a ACL do bucket.

• s3:GetBucketAcl

• s3:PutBucketAcl

Observe o seguinte:

ACL do bucket

Quando você cria ou atualiza uma distribuição e ativa o registro em log, CloudFront usa essas permissões para atualizar a ACL do bucket para dar FULL_CONTROL permissão à awslogsdelivery conta. A conta awslogsdelivery grava arquivos de log no bucket. Caso sua conta não tenha as permissões necessárias para atualizar a ACL, ocorrerá uma falha na criação ou atualização da distribuição.

Em alguns casos, se você enviar, de forma programática, uma solicitação para criar um bucket, mas já existir um bucket com o nome especificado, o S3 redefinirá as permissões do bucket para o valor padrão. Se você configurou CloudFront para salvar registros de acesso em um bucket do S3 e parar de receber registros nesse bucket, verifique as permissões no bucket para garantir que ele CloudFront tenha as permissões necessárias.

Restauração da ACL do bucket

Se você remover as permissões da conta awslogsdelivery, o CloudFront não poderá salvar os logs no bucket do S3. CloudFront Para permitir que você comece a salvar registros para sua distribuição novamente, restaure a permissão da ACL fazendo o seguinte:

• Desative o login para sua distribuição e CloudFront, em seguida, ative-o novamente. Para ter mais informações, consulte Valores especificados ao criar ou atualizar uma distribuição.

• Adicione a permissão da ACL para awslogsdelivery manualmente navegando até o bucket do S3 no console do Amazon S3 e adicionando a permissão. Para adicionar a ACL para awslogsdelivery, você deve fornecer o ID canônico da conta, que é o seguinte:

  c4c1ede66af53448b93c283ce9448c4ba468c9432aa01d700d3878632f77d2d0

  Para obter mais informações sobre como adicionar ACLs a buckets do S3, consulte Como definir permissões para buckets da ACL? no Manual do usuário do Amazon Simple Storage Service.

ACL para cada arquivo de log

Além da ACL no bucket, há uma ACL em cada arquivo de log. O proprietário do bucket tem permissão FULL_CONTROL em cada arquivo de log, o proprietário da distribuição (se não for o proprietário do bucket) não tem permissão e a conta awslogsdelivery tem permissões de leitura e de gravação.

Como desabilitar o registro

Se você desativar o registro em log, CloudFront não excluirá as ACLs do bucket nem dos arquivos de log. Se desejar, você mesmo pode fazer isso.

Política de chaves obrigatória para buckets do SSE-KMS

Se o bucket do S3 para seus logs padrão usar criptografia no lado do servidor com AWS KMS keys (SSE-KMS) usando uma chave gerenciada pelo cliente, você deverá adicionar a seguinte instrução à política de chaves para sua chave gerenciada pelo cliente. Isso permite CloudFront gravar arquivos de log no bucket. (Você não pode usar o SSE-KMS com o Chave gerenciada pela AWS porque CloudFront não conseguirá gravar arquivos de log no bucket.)

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

Se o bucket do S3 para seus logs padrão usar SSE-KMS com uma Chave de bucket do S3, você também precisará adicionar a permissão kms:Decrypt à instrução de política. Nesse caso, a declaração de política completa se parece com a seguinte.

{
    "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 do nome do arquivo

O nome de cada arquivo de log CloudFront salvo em seu bucket do Amazon S3 usa o seguinte formato de nome de arquivo:

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

A data e a hora estão em Tempo Universal Coordenado (UTC).

Por exemplo, se você usar example-prefix como prefixo e seu ID de distribuição for EMLARXS9EXAMPLE, seus nomes de arquivo serão semelhantes a este:

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

Ao habilitar o registro para uma distribuição, você pode especificar um prefixo opcional para os nomes dos arquivos, a fim de diferenciar quais arquivos de log são associados a quais distribuições. Se você incluir um valor para o prefixo do arquivo de log e seu prefixo não terminar com uma barra (/), adicionará um automaticamente CloudFront . Se seu prefixo terminar com uma barra, CloudFront não adicione outra.

O .gz no final do nome do arquivo indica que o arquivo de log CloudFront foi compactado usando gzip.

Tempo de entrega do arquivo de log padrão

CloudFront fornece registros padrão para uma distribuição até várias vezes por hora. Em geral, um arquivo de log contém informações sobre as solicitações CloudFront recebidas durante um determinado período. CloudFront geralmente entrega o arquivo de log desse período ao seu bucket do Amazon S3 dentro de uma hora após os eventos que aparecem no log. No entanto, observe que algumas ou todas as entradas do arquivo de log referentes a um período podem demorar até 24 horas. Quando entradas de log atrasam, o CloudFront as salva em um arquivo de log no qual o nome do arquivo inclui a data e a hora do período de ocorrência das solicitações, não de entrega do arquivo.

Ao criar um arquivo de log, CloudFront consolida as informações para sua distribuição de todos os pontos de presença que receberam solicitações de seus objetos durante o período abrangido pelo arquivo de log.

CloudFront pode salvar mais de um arquivo por um período de tempo, dependendo de quantas solicitações CloudFront recebidas para os objetos associados a uma distribuição.

CloudFront começa a entregar registros de acesso de forma confiável cerca de quatro horas após a ativação do registro. É possível que você receba alguns logs de acesso antes disso.

nota

Se nenhum usuário solicitar seus objetos nesse período, você não receberá arquivos de log referentes a ele.

CloudFront também oferece registros em tempo real, que fornecem informações sobre solicitações feitas a uma distribuição em tempo real (os registros são entregues segundos após o recebimento das solicitações). É possível usar os logs em tempo real para monitorar, analisar e tomar ações com base na performance da entrega de conteúdo. Para obter mais informações, consulte Logs em tempo real.

Como as solicitações são registradas em log quando os cabeçalhos ou o URL de solicitação excedem o tamanho máximo

Se o tamanho total de todos os cabeçalhos de solicitação, incluindo cookies, exceder 20 KB, ou se o URL exceder 8.192 bytes, o CloudFront não poderá analisar a solicitação completamente e não poderá registrá-la. Como a solicitação não está conectada, você não verá no log os arquivos que o código de status de erro HTTP retornou.

Se o corpo da solicitação exceder o tamanho máximo, a solicitação será registrada, incluindo o código de status de erro HTTP.

Analisar logs padrão

Como você pode receber vários logs de acesso por hora, recomendamos que combine todos os arquivos de log recebidos em um determinado período em um único arquivo. Assim você poderá analisar os dados desse período de forma mais precisa e completa.

Uma forma de analisar seus logs de acesso é usar o Amazon Athena. O Athena é um serviço de consulta interativo que pode ajudar você a analisar dados para AWS serviços, inclusive. CloudFront Para saber mais, consulte Consultar CloudFront registros da Amazon no Guia do usuário do Amazon Athena.

Além disso, as seguintes postagens de blog da AWS discutem algumas maneiras de analisar os logs de acesso.

• Amazon CloudFront Request Logging (para conteúdo entregue via HTTP)

• Logs avançados do CloudFront, agora com strings de consulta

Importante

Recomendamos que você use os registros para entender a natureza das solicitações de seu conteúdo, não como uma contabilidade completa de todas as solicitações. CloudFront fornece registros de acesso com base no melhor esforço. A entrada do log de uma solicitação específica pode ser entregue muito depois do processamento da solicitação e, raramente, nunca ser entregue. Quando uma entrada de log é omitida dos logs de acesso, o número de entradas nos logs não corresponderá ao uso exibido nos relatórios de uso e faturamento da AWS.

Editar as configurações do registro em log padrão

Você pode ativar ou desativar o registro, alterar o bucket do Amazon S3 onde seus registros são armazenados e alterar o prefixo dos arquivos de log usando o CloudFront console ou a API. CloudFront As alterações feitas nas configurações de registro são aplicadas em até 12 horas.

Para obter informações, consulte os tópicos a seguir:

• Para atualizar uma distribuição usando o CloudFront console, consulteAtualizar uma distribuição.

• Para atualizar uma distribuição usando a CloudFront API, consulte UpdateDistributionna Amazon CloudFront API Reference.

Excluir arquivos de log padrão de um bucket do Amazon S3

CloudFront não exclui automaticamente os arquivos de log do seu bucket do Amazon S3. Para obter informações sobre como excluir arquivos de log de um bucket do Amazon S3, consulte os seguintes tópicos:

• Com o console do Amazon S3: Excluir objetos no Guia do usuário do console do Amazon Simple Storage Service.

• Usando a API REST: DeleteObjectna Referência de API do Amazon Simple Storage Service.

Formato de arquivo de log padrão

Cada entrada em um arquivo de log fornece detalhes sobre uma única solicitação do visualizador. Os arquivos de log têm as seguintes características:

• Use o formato do arquivo de log estendido do W3C.

• Contêm valores separados por tabulação.

• Contêm registros não necessariamente em ordem cronológica.

• Contém duas linhas de cabeçalho: uma com a versão do formato do arquivo e outra que relaciona os campos do W3C incluídos em cada registro.

• Contém equivalentes codificados em URL para espaços e alguns outros caracteres em valores de campo.

  Equivalentes codificados em URL são usados para os seguintes caracteres:

  • Códigos de caracteres ASCII 0 a 32, inclusive

  • Códigos de caracteres ASCII 127 e posterior

  • Todos os caracteres na tabela a seguir

  O padrão de codificação de URL é definido no RFC 1738.

Valor codificado em URL	Caractere
%3C	<
%3E	>
%22	"
%23	#
%25	%
%7B	{
%7D	}
%7C	|
%5C	\
%5E	^
%7E	~
%5B	[
%5D	]
%60	`
%27	'
%20	espaço

Campos padrão de arquivo de log

O arquivo de log para uma distribuição contém 33 campos. A lista a seguir contém cada nome de campo, em ordem, juntamente com uma descrição das informações nesse campo.

1. date

   A data em que o evento ocorreu no formato YYYY-MM-DD. Por exemplo, 2019-06-30. A data e a hora estão em Tempo Universal Coordenado (UTC). Para WebSocket conexões, essa é a data em que a conexão foi fechada.

2. time

   A hora em que o CloudFront servidor terminou de responder à solicitação (em UTC), por exemplo,. 01:42:39 Para WebSocket conexões, esse é o momento em que a conexão é fechada.

3. x-edge-location

   O ponto de presença que atendeu à solicitação. Cada ponto de presença é identificado por um código de três letras e um número atribuído arbitrariamente (por exemplo, DFW3). O código de três letras normalmente corresponde ao código da Associação Internacional de Transportes Aéreos (IATA) de um aeroporto perto da localização geográfica do local da borda. (Essas abreviações podem mudar no futuro.)

4. sc-bytes

   O número total de bytes enviados pelo servidor para o visualizador em resposta à solicitação, inclusive os cabeçalhos. Para WebSocket conexões, esse é o número total de bytes enviados do servidor para o cliente por meio da conexão.

5. c-ip

   O endereço IP do visualizador que fez a solicitação, por exemplo, 192.0.2.183 ou 2001:0db8:85a3::8a2e:0370:7334. Se o visualizador usar um proxy HTTP ou um load balancer para enviar a solicitação, o valor desse campo será o endereço IP do proxy ou do load balancer. Veja também o campo x-forwarded-for.

6. cs-method

   O método de solicitação HTTP recebido do visualizador.

7. cs(Host)

   O nome de domínio da CloudFront distribuição (por exemplo, d111111abcdef8.cloudfront.net).

8. cs-uri-stem

   A parte do URL da solicitação que identifica o caminho e o objeto (por exemplo, /images/cat.jpg). Os pontos de interrogação (?) em URLs e strings de consulta não são incluídos no log.

9. sc-status

   Contém um dos seguintes valores:

   • O código de status HTTP da resposta do servidor (por exemplo, 200).

   • 000, que indica que o visualizador fechou a conexão antes que o servidor pudesse responder à solicitação. Se o visualizador fecha a conexão após o servidor começar a enviar a resposta, esse campo contém o código de status HTTP da resposta que o servidor começou a enviar.

10. cs(Referer)

    O valor do cabeçalho Referer na solicitação. Esse é o nome do domínio que originou a solicitação. Indicadores comuns incluem: mecanismos de pesquisa, outros sites vinculados diretamente aos seus objetos e seu próprio site.

11. cs(User-Agent)

    O valor do cabeçalho User-Agent na solicitação. O cabeçalho User-Agent identifica a origem da solicitação, como o tipo de dispositivo e o navegador que enviou a solicitação e, se a solicitação for proveniente de um mecanismo de pesquisa, o mecanismo de pesquisa.

12. cs-uri-query

    A parte da string de consulta do URL da solicitação, se houver.

    Quando um URL não contém uma string de consulta, o valor desse campo é um hífen (-). Para ter mais informações, consulte Armazenar em cache o conteúdo com base em parâmetros de string de consulta.

13. cs(Cookie)

    O cabeçalho Cookie na solicitação, incluindo pares de nome-valor e os atributos associados.

    Se você ativar o registro de cookies, CloudFront registrará os cookies em todas as solicitações, independentemente de quais cookies você escolher encaminhar para a origem. Quando uma solicitação não inclui um cabeçalho de cookie, o valor desse campo é um hífen (-). Para obter mais informações sobre cookies, consulte Armazenar conteúdo em cache com base em cookies.

14. x-edge-result-type

    Como o servidor classificou a resposta após o último byte sair do servidor. Em alguns casos, o tipo de resultado pode mudar entre a hora em que o servidor está pronto para enviar a resposta e a hora em que ele conclui o envio. Veja também o campo x-edge-response-result-type.

    Por exemplo, em streaming HTTP, suponha que o servidor encontre um segmento do stream no cache. Nesse cenário, o valor desse campo normalmente seria Hit. No entanto, se o visualizador encerrar a conexão antes de o servidor entregar o segmento inteiro, o tipo do resultado final (e, portanto, o valor desse campo) será Error.

    WebSocket as conexões terão um valor de Miss para esse campo porque o conteúdo não pode ser armazenado em cache e é enviado por proxy diretamente para a origem.

    Os possíveis valores incluem:

    • Hit: o servidor forneceu o objeto do cache ao visualizador.

    • RefreshHit: o servidor encontrou o objeto no cache, mas o objeto expirou, portanto, o servidor entrou em contato com a origem para verificar se o cache tinha a versão mais recente do objeto.

    • Miss: não foi possível atender à solicitação por um objeto no cache e, portanto, o servidor a encaminhou ao servidor de origem e retornou o resultado ao visualizador.

    • LimitExceeded— O pedido foi negado porque uma CloudFront cota (anteriormente chamada de limite) foi excedida.

    • CapacityExceeded: o servidor retornou um código de status HTTP 503 porque não tinha capacidade suficiente no momento da solicitação para fornecer o objeto.

    • Error: normalmente, isso significa que a solicitação resultou em um erro de cliente (o valor do campo sc-status está no intervalo 4xx) ou em um erro de servidor (o valor do campo sc-status está no intervalo 5xx). Se o valor do campo sc-status for 200 ou se o valor desse campo for Error e o valor do campo x-edge-response-result-type não for Error, isso significa que a solicitação HTTP foi bem-sucedida, mas o cliente desconectou antes de receber todos os bytes.

    • Redirect: o servidor redirecionou o visualizador de HTTP para HTTPS de acordo com as configurações de distribuição.

15. x-edge-request-id

    Uma string opaca que identifica de forma exclusiva uma solicitação. CloudFront também envia essa string no cabeçalho da x-amz-cf-id resposta.

16. x-host-header

    O valor incluído pelo visualizador no cabeçalho Host da solicitação. Se você estiver usando o nome de CloudFront domínio nos URLs do objeto (como d111111abcdef8.cloudfront.net), esse campo contém esse nome de domínio. Se você estiver usando nomes de domínio alternativos (CNAMES) nos URLs de objetos (como www.example.com), esse campo conterá o nome de domínio alternativo.

    Se você estiver usando nomes de domínio alternativos, consulte cs(Host) no campo 7 do nome de domínio associado a sua distribuição.

17. cs-protocol

    O protocolo da solicitação do visualizador (http, https, ws ou wss).

18. cs-bytes

    O número de bytes de dados que o visualizador adicionou à solicitação, incluindo cabeçalhos. Para WebSocket conexões, esse é o número total de bytes enviados do cliente para o servidor na conexão.

19. time-taken

    O número de segundos (até o milésimo de segundo, por exemplo, 0,082) de quando o servidor recebe a solicitação do visualizador até quando o servidor grava o último byte da resposta na fila de saída, conforme medido no servidor. Da perspectiva do visualizador, o tempo total para obter o objeto completo será mais longo que esse valor devido à latência da rede e o armazenamento em buffer do TCP.

20. x-forwarded-for

    Se o visualizador usar um proxy HTTP ou um load balancer para enviar a solicitação, o valor do campo c-ip será o endereço IP do proxy ou do load balancer. Nesse caso, esse campo é o endereço IP do visualizador que originou a solicitação. Este campo contém um endereço IPv4 (por exemplo, 192.0.2.183) ou um endereço IPv6 (por exemplo, 2001:0db8:85a3::8a2e:0370:7334).

    Se o visualizador não tiver usado um proxy HTTP ou um load balancer, o valor deste campo será um hífen (-).

21. ssl-protocol

    Quando a solicitação usa HTTPS, esse campo contém o protocolo SSL/TLS que o visualizador e o servidor negociaram para transmitir a solicitação e a resposta. Para obter uma lista de valores possíveis, consulte os protocolos SSL/TLS compatíveis em Protocolos e cifras suportados entre visualizadores e CloudFront.

    Quando cs-protocol no campo 17 for http, o valor desse campo será um hífen (-).

22. ssl-cipher

    Quando a solicitação usa HTTPS, esse campo contém a cifra SSL/TLS que o visualizador e o servidor negociaram para criptografar a solicitação e a resposta. Para obter uma lista de valores possíveis, consulte as cifras SSL/TLS compatíveis em Protocolos e cifras suportados entre visualizadores e CloudFront.

    Quando cs-protocol no campo 17 for http, o valor desse campo será um hífen (-).

23. x-edge-response-result-type

    Como o servidor classificou a resposta logo antes de devolvê-la para o visualizador. Veja também o campo x-edge-result-type. Os possíveis valores incluem:

    • Hit: o servidor forneceu o objeto do cache ao visualizador.

    • RefreshHit: o servidor encontrou o objeto no cache, mas o objeto expirou, portanto, o servidor entrou em contato com a origem para verificar se o cache tinha a versão mais recente do objeto.

    • Miss: não foi possível atender à solicitação por um objeto no cache, portanto, o servidor a encaminhou ao servidor de origem e retornou o resultado ao visualizador.

    • LimitExceeded— O pedido foi negado porque uma CloudFront cota (anteriormente chamada de limite) foi excedida.

    • CapacityExceeded: o servidor retornou um erro 503 porque não tinha capacidade suficiente no momento da solicitação para fornecer o objeto.

    • Error: normalmente, isso significa que a solicitação resultou em um erro de cliente (o valor do campo sc-status está no intervalo 4xx) ou em um erro de servidor (o valor do campo sc-status está no intervalo 5xx).

      Se o valor do campo x-edge-result-type for Error e o valor desse campo não for Error, o cliente desconectou antes de concluir o download.

    • Redirect: o servidor redirecionou o visualizador de HTTP para HTTPS de acordo com as configurações de distribuição.

24. cs-protocol-version

    A versão HTTP especificada pelo visualizador na solicitação. Os valores possíveis incluem HTTP/0.9, HTTP/1.0, HTTP/1.1, HTTP/2.0 e HTTP/3.0.

25. fle-status

    Quando a criptografia em nível de campo é configurada para uma distribuição, esse campo contém um código que indica se o corpo da solicitação foi processado com êxito. Quando o servidor processa o corpo da solicitação, criptografa os valores nos campos especificados e encaminha a solicitação para a origem com êxito, o valor desse campo é Processed. Nesse caso, o valor de x-edge-result-type pode indicar um erro do lado do cliente ou do lado do servidor.

    Os valores possíveis para esse campo incluem:

    • ForwardedByContentType: o servidor encaminhou a solicitação para a origem sem análise nem criptografia, pois nenhum tipo de conteúdo foi configurado.

    • ForwardedByQueryArgs: o servidor encaminhou a solicitação para a origem sem análise nem criptografia, pois a solicitação contém um argumento de consulta que não foi configurado para a criptografia em nível de campo.

    • ForwardedDueToNoProfile: o servidor encaminhou a solicitação para a origem sem análise nem criptografia, pois nenhum perfil foi especificado na configuração da criptografia em nível de campo.

    • MalformedContentTypeClientError: o servidor rejeitou a solicitação e retornou o código de status HTTP 400 para o visualizador, pois o valor do cabeçalho Content-Type estava em um formato inválido.

    • MalformedInputClientError: o servidor rejeitou a solicitação e retornou o código de status HTTP 400 para o visualizador, pois o corpo da solicitação estava em um formato inválido.

    • MalformedQueryArgsClientError: o servidor rejeitou a solicitação e retornou o código de status HTTP 400 para o visualizador, pois um argumento de consulta estava vazio ou em um formato inválido.

    • RejectedByContentType: o servidor rejeitou a solicitação e retornou o código de status HTTP 400 para o visualizador, pois nenhum tipo de conteúdo foi especificado na configuração para criptografia em nível de campo.

    • RejectedByQueryArgs: o servidor rejeitou a solicitação e retornou o código de status HTTP 400 para o visualizador, pois nenhum argumento de consulta foi especificado na configuração para criptografia em nível de campo.

    • ServerError: o servidor de origem retornou um erro.

    Se a solicitação exceder uma cota de criptografia em nível de campo (anteriormente conhecida como limite), esse campo conterá um dos seguintes códigos de erro, e o servidor retornará o código de status HTTP 400 ao visualizador. Para obter uma lista das cotas atuais de criptografia no nível de campo, consulte Cotas para criptografia no nível de campo.

    • FieldLengthLimitClientError: um campo configurado para ser criptografado excedeu o tamanho máximo permitido.

    • FieldNumberLimitClientError: uma solicitação que a distribuição está configurada para criptografar contém o número de campos maior do que o permitido.

    • RequestLengthLimitClientError: o tamanho do corpo da solicitação excedeu o tamanho máximo permitido quando a criptografia no nível de campo foi configurada.

    Se a criptografia no nível de campo não estiver configurada para a distribuição, o valor desse campo será um hífen (-).

26. fle-encrypted-fields

    O número de campos de criptografia em nível de campo que o servidor criptografou e encaminhou para a origem. CloudFront os servidores transmitem a solicitação processada para a origem à medida que criptografam os dados, portanto, esse campo pode ter um valor mesmo que o valor de fle-status seja um erro.

    Se a criptografia no nível de campo não estiver configurada para a distribuição, o valor desse campo será um hífen (-).

27. c-port

    O número da porta da solicitação do visualizador.

28. time-to-first-byte

    O número de segundos entre o recebimento da solicitação e a gravação do primeiro byte da resposta, conforme medido no servidor.

29. x-edge-detailed-result-type

    Esse campo conterá o mesmo valor que o campo x-edge-result-type, exceto nos seguintes casos:

    • Quando o objeto for enviado ao visualizador do cache da camada Origin Shield, esse campo conterá OriginShieldHit.

    • Quando o objeto não estava no CloudFront cache e a resposta foi gerada por uma função Lambda @Edge de solicitação de origem, esse campo contém. MissGeneratedResponse

    • Quando o valor do campo x-edge-result-type for Error, esse campo conterá um dos seguintes valores com mais informações sobre o erro:

      • AbortedOrigin: o servidor encontrou um problema com a origem.

      • ClientCommError: a resposta ao visualizador foi interrompida devido a um problema de comunicação entre o servidor e o visualizador.

      • ClientGeoBlocked: a distribuição é configurada para recusar solicitações da localização geográfica do visualizador.

      • ClientHungUpRequest – o visualizador parou prematuramente ao enviar a solicitação.

      • Error: ocorreu um erro para o qual o tipo de erro não se encaixa em nenhuma das outras categorias. Esse tipo de erro pode ocorrer quando o servidor fornece uma resposta de erro do cache.

      • InvalidRequest: o servidor recebeu uma solicitação inválida do visualizador.

      • InvalidRequestBlocked – o acesso ao recurso solicitado é bloqueado.

      • InvalidRequestCertificate: a distribuição não corresponde ao certificado SSL/TLS para o qual a conexão HTTPS foi estabelecida.

      • InvalidRequestHeader: a solicitação continha um cabeçalho inválido.

      • InvalidRequestMethod – a distribuição não está configurada para lidar com o método de solicitação HTTP que foi usado. Isso pode acontecer quando a distribuição oferece suporte somente a solicitações armazenáveis em cache.

      • OriginCommError: a solicitação expirou durante a conexão à origem ou a leitura de dados da origem.

      • OriginConnectError: o servidor não pôde se conectar à origem.

      • OriginContentRangeLengthError: o cabeçalho Content-Length na resposta da origem não corresponde ao tamanho no cabeçalho Content-Range.

      • OriginDnsError: o servidor não pôde resolver o nome de domínio da origem.

      • OriginError – a origem retornou uma resposta incorreta.

      • OriginHeaderTooBigError: um cabeçalho retornado pela origem é muito grande para o processamento pelo servidor de borda.

      • OriginInvalidResponseError – a origem retornou uma resposta inválida.

      • OriginReadError: o servidor não pôde ler na origem.

      • OriginWriteError: o servidor não pôde gravar na origem.

      • OriginZeroSizeObjectError – um objeto de tamanho zero enviado da origem resultou em um erro.

      • SlowReaderOriginError – o visualizador ficou lento ao ler a mensagem que causou o erro de origem.

30. sc-content-type

    O valor do cabeçalho do HTTP Content-Type da resposta.

31. sc-content-len

    O valor do cabeçalho do HTTP Content-Length da resposta.

32. sc-range-start

    Quando a resposta contém o cabeçalho do HTTP Content-Range, esse campo contém o valor inicial do intervalo.

33. sc-range-end

    Quando a resposta contém o cabeçalho do HTTP Content-Range, esse campo contém o valor final do intervalo.

Veja abaixo um exemplo de arquivo de log para uma distribuição:

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

Cobranças de logs padrão

O registro padrão é um recurso opcional do CloudFront. Não há cobrança adicional para a habilitação do registro em log padrão. No entanto, você acumula as cobranças normais do Amazon S3 para armazenar e acessar os arquivos nele (é possível excluí-los a qualquer momento).

Para mais informações sobre a definição de preço do Amazon S3, consulte Definição de preço do Amazon S3.

Para obter mais informações sobre CloudFront preços, consulte CloudFront Preços.