# Armazenamento em cache e disponibilidade
<a name="ConfiguringCaching"></a>

É possível usar o CloudFront para reduzir o número de solicitações às quais o servidor de origem deve responder diretamente. Com o armazenamento em cache do CloudFront, mais objetos são fornecidos de pontos de presença do CloudFront que estão mais próximos de seus usuários. Isso reduz a carga no servidor de origem e reduz a latência.

Quanto mais solicitações de cache de borda o CloudFront puder fornecer, menos solicitações de visualizador o CloudFront deve encaminhar à origem para obter a versão mais recente ou uma versão exclusiva de um objeto. Para otimizar o CloudFront para fazer o menor número possível de solicitações para a origem, considere usar um CloudFront Origin Shield. Para obter mais informações, consulte [Usar o Amazon CloudFront Origin Shield](origin-shield.md).

A proporção de solicitações fornecidas diretamente do cache do CloudFront em comparação com todas as solicitações é chamada de *taxa de acertos do cache*. É possível visualizar a porcentagem de solicitações do visualizador atendidas, não atendidas e de erros no console do CloudFront. Para obter mais informações, consulte [Visualizar relatórios de estatísticas de cache do CloudFront](cache-statistics.md).

Vários fatores afetam a taxa de acertos do cache. É possível ajustar a configuração da distribuição do CloudFront para melhorar a taxa de acertos do cache seguindo as orientações em [Aumentar a proporção de solicitações fornecidas diretamente de caches do CloudFront (taxa de acertos do cache)](cache-hit-ratio.md).

Para saber como adicionar e remover o conteúdo que você quer que seja fornecido pelo CloudFront, consulte [Adicionar, remover ou substituir conteúdo distribuído pelo CloudFront](AddRemoveReplaceObjects.md).

**Topics**
+ [

# Aumentar a proporção de solicitações fornecidas diretamente de caches do CloudFront (taxa de acertos do cache)
](cache-hit-ratio.md)
+ [

# Usar o Amazon CloudFront Origin Shield
](origin-shield.md)
+ [

# Otimizar a alta disponibilidade com o failover de origem do CloudFront
](high_availability_origin_failover.md)
+ [

# Gerenciar o tempo de permanência do conteúdo no cache (expiração)
](Expiration.md)
+ [

# Conteúdo em cache com base em parâmetros de string de consulta
](QueryStringParameters.md)
+ [

# Conteúdo em cache com base em cookies
](Cookies.md)
+ [

# Conteúdo em cache com base nos cabeçalhos de solicitação
](header-caching.md)

# Aumentar a proporção de solicitações fornecidas diretamente de caches do CloudFront (taxa de acertos do cache)
<a name="cache-hit-ratio"></a>

É possível melhorar a performance aumentando a taxa de solicitações do visualizador fornecidas diretamente do cache do CloudFront, em vez de acessar os servidores de origem em busca de conteúdo. Isso é conhecido como melhorar a taxa de acertos de cache.

As seções a seguir explicam como melhorar sua taxa de acertos do cache.

**Topics**
+ [

## Especificar o tempo durante o qual o CloudFront armazena os objetos em cache
](#cache-hit-ratio-duration)
+ [

## Usar o Origin Shield
](#cache-hit-ratio-use-origin-shield)
+ [

## Armazenar em cache com base em parâmetros de string de consulta
](#cache-hit-ratio-query-string-parameters)
+ [

## Armazenar em cache com base nos valores dos cookies
](#cache-hit-ratio-cookies)
+ [

## Armazenar em cache com base nos cabeçalhos de solicitação
](#cache-hit-ratio-request-headers)
+ [

## Remova o cabeçalho `Accept-Encoding` quando a compactação não for necessária
](#cache-hit-ratio-remove-accept-encoding)
+ [

## Disponibilize conteúdo de mídia via HTTP
](#cache-hit-ratio-http-streaming)

## Especificar o tempo durante o qual o CloudFront armazena os objetos em cache
<a name="cache-hit-ratio-duration"></a>

Para aumentar sua taxa de acertos do cache, é possível configurar sua origem para adicionar uma diretiva [Cache-Control max-age](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control) aos seus objetos e especificar o maior valor prático para `max-age`. Quanto menor for a duração do cache, maior será a frequência com que o CloudFront enviará solicitações para a origem a fim de determinar se um objeto foi alterado e para obter a versão mais recente. Você pode complementar `max-age` com as diretivas `stale-while-revalidate` e `stale-if-error` para melhorar ainda mais a taxa de acerto do cache sob certas condições. Para obter mais informações, consulte [Gerenciar o tempo de permanência do conteúdo no cache (expiração)](Expiration.md).

## Usar o Origin Shield
<a name="cache-hit-ratio-use-origin-shield"></a>

O CloudFront Origin Shield pode ajudar a melhorar a taxa de acertos do cache da distribuição do CloudFront, pois ele fornece uma camada adicional de cache à frente da origem. Ao usar o Origin Shield, todas as solicitações de todas as camadas de cache do CloudFront para a origem são recebidas de um único local. O CloudFront pode recuperar cada objeto usando uma única solicitação do Origin Shield, e todas as outras camadas do cache do CloudFront (pontos de presença e [caches de borda regionais](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches)) podem recuperar o objeto do Origin Shield.

Para obter mais informações, consulte [Usar o Amazon CloudFront Origin Shield](origin-shield.md).

## Armazenar em cache com base em parâmetros de string de consulta
<a name="cache-hit-ratio-query-string-parameters"></a>

Configurar o CloudFront para armazenamento em cache com base nos parâmetros de string de consulta poderá melhorar o armazenamento se você fizer o seguinte:
+ Configurar o CloudFront para encaminhar somente os parâmetros de string de consulta para os quais a origem retorna objetos exclusivos.
+ Usar as mesmas letras (maiúsculas e minúsculas) para todas as instâncias do mesmo parâmetro. Por exemplo, se uma solicitação contiver `parameter1=A` e outra, `parameter1=a`, o CloudFront encaminhará solicitações separadas para sua a quando uma solicitação contiver `parameter1=A` e `parameter1=a`. Depois, o CloudFront armazena separadamente em cache os objetos correspondentes retornados pela origem, mesmo que eles sejam idênticos. Se você usar apenas `A` ou `a`, o CloudFront encaminhará menos solicitações para a origem.
+ Indique os parâmetros na mesma ordem. Assim como ocorre com diferenças nas letras, se uma solicitação de um objeto contiver a string de consulta `parameter1=a&parameter2=b` e outra solicitação do mesmo objeto contiver `parameter2=b&parameter1=a`, o CloudFront encaminhará as duas para a origem e armazenará os objetos correspondentes separadamente, mesmo que sejam idênticos. Se você sempre usar a mesma ordem para parâmetros, o CloudFront encaminhará menos solicitações para a origem.

Para obter mais informações, consulte [Conteúdo em cache com base em parâmetros de string de consulta](QueryStringParameters.md). Para revisar as strings de consulta que o CloudFront encaminha para a origem, consulte os valores na coluna `cs-uri-query` dos arquivos de log do CloudFront. Para obter mais informações, consulte [Logs de acesso (logs padrão)](AccessLogs.md).

## Armazenar em cache com base nos valores dos cookies
<a name="cache-hit-ratio-cookies"></a>

Se você configurar o CloudFront para armazenamento em cache baseado nos valores dos cookies, poderá melhorar o armazenamento em cache se:
+ Configurar o CloudFront para encaminhar apenas os cookies especificados, em vez de todos os cookies. Para os cookies configurados pelo CloudFront para serem encaminhados à origem, o CloudFront encaminha todas as combinações de nome e valor de cookie. Depois, armazenará separadamente em cache os objetos retornados pela origem, mesmo se todos forem idênticos.

  Por exemplo, imagine que os visualizadores incluam dois cookies em cada solicitação, cada cookie tenha três valores possíveis e todas as combinações de valor de cookie sejam possíveis. O CloudFront encaminha até nove solicitações diferentes à origem de cada objeto. Se a origem retornar diferentes versões de um objeto com base apenas em um dos cookies, o CloudFront encaminhará mais solicitações para a origem do que o necessário e armazenará em cache várias versões do objeto desnecessariamente.
+ Crie comportamentos de cache separados para conteúdo estático e dinâmico, e configure o CloudFront para encaminhar cookies para a origem apenas para conteúdo dinâmico.

  Por exemplo, suponha que você tenha apenas um comportamento de cache para a distribuição e que esteja usando a distribuição para conteúdo dinâmico, como arquivos `.js`, e para arquivos `.css`, que raramente são alterados. O CloudFront armazena versões separadas dos seus arquivos `.css` em cache com base nos valores de cookie, de modo que cada ponto de presença do CloudFront encaminhe uma solicitação para a origem de cada novo valor ou combinação de valores de cookie.

  Se você criar um comportamento de cache para o qual o padrão de caminho é `*.css` e que o CloudFront não armazena em cache com base nos valores de cookie, o CloudFront encaminhará solicitações de arquivos `.css` para sua origem apenas para a primeira solicitação recebida por um ponto de presença de um arquivo `.css` e para a primeira solicitação após a expiração de um arquivo `.css`.
+ Se possível, crie comportamentos de cache separados para conteúdo dinâmico quando os valores de cookie forem exclusivos para cada usuário (como um ID de usuário) e que varie com base em um número menor de valores exclusivos.2

Para obter mais informações, consulte [Conteúdo em cache com base em cookies](Cookies.md). Para revisar os cookies que o CloudFront encaminha para a origem, consulte os valores na coluna `cs(Cookie)` dos arquivos de log do CloudFront. Para obter mais informações, consulte [Logs de acesso (logs padrão)](AccessLogs.md).

## Armazenar em cache com base nos cabeçalhos de solicitação
<a name="cache-hit-ratio-request-headers"></a>

Se você configurar o CloudFront para armazenamento em cache com base nos cabeçalhos de solicitação, poderá melhorar o armazenamento se:
+ Configure o CloudFront para encaminhar e armazenar em cache com base somente em cabeçalhos específicos, não em todos. Para os cabeçalhos especificados, o CloudFront encaminhará todas as combinações de nome e valor de cabeçalho. Depois, armazenará separadamente em cache os objetos retornados pela origem, mesmo se todos forem idênticos.
**nota**  
O CloudFront sempre encaminha para sua origem os cabeçalhos especificados nos seguintes tópicos:  
Como o CloudFront processa e encaminha solicitações para o servidor de origem do Amazon S3 > [Cabeçalhos de solicitação HTTP removidos ou atualizados pelo CloudFront](RequestAndResponseBehaviorS3Origin.md#request-s3-removed-headers)
Como o CloudFront processa e encaminha solicitações para seu servidor de origem personalizado > [Cabeçalhos de solicitação HTTP e comportamento do CloudFront (origens do Amazon S3 e personalizadas)](RequestAndResponseBehaviorCustomOrigin.md#request-custom-headers-behavior)

  Ao configurar o CloudFront para armazenamento em cache com base nos cabeçalhos da solicitação, você não altera os cabeçalhos encaminhados por ele, apenas se ele armazenar os objetos com base nos valores de cabeçalho.
+ Tente evitar o armazenamento em cache com base nos cabeçalhos de solicitação com um grande número de valores exclusivos.

  Por exemplo, para fornecer diferentes tamanhos de uma imagem com base no dispositivo do usuário, não configure o CloudFront para armazenamento em cache com base no cabeçalho `User-Agent`, que tem um grande número de valores possíveis. Em vez disso, configure o CloudFront para cache com base nos cabeçalhos do tipo de dispositivo do CloudFront `CloudFront-Is-Desktop-Viewer`, `CloudFront-Is-Mobile-Viewer`, `CloudFront-Is-SmartTV-Viewer` e `CloudFront-Is-Tablet-Viewer`. Além disso, se você estiver retornando a mesma versão da imagem para tablets e desktops, encaminhe somente o cabeçalho `CloudFront-Is-Tablet-Viewer`, não o `CloudFront-Is-Desktop-Viewer`.

Para obter mais informações, consulte [Conteúdo em cache com base nos cabeçalhos de solicitação](header-caching.md).

## Remova o cabeçalho `Accept-Encoding` quando a compactação não for necessária
<a name="cache-hit-ratio-remove-accept-encoding"></a>

Se a compactação não estiver habilitada, porque a origem não é compatível, o CloudFront não é compatível ou o conteúdo não é compactável, você poderá aumentar a taxa de acertos do cache associando um comportamento de cache na distribuição a uma origem que defina o Custom Origin Header da seguinte forma:
+ **Header name (Nome do cabeçalho**: `Accept-Encoding`
+ **Header value (Valor do cabeçalho)**: (mantenha em branco)

Ao usar essa configuração, o CloudFront remove o cabeçalho `Accept-Encoding` da chave de cache e não o inclui em solicitações de origem. Essa configuração se aplica a todo o conteúdo fornecido pelo CloudFront com a distribuição dessa origem.

## Disponibilize conteúdo de mídia via HTTP
<a name="cache-hit-ratio-http-streaming"></a>

Para obter informações sobre como otimizar o conteúdo de vídeo sob demanda (VOD) e de vídeo por streaming, consulte [Vídeo sob demanda e vídeo de transmissão ao vivo com o CloudFront](on-demand-streaming-video.md).

# Usar o Amazon CloudFront Origin Shield
<a name="origin-shield"></a>

O Amazon CloudFront Origin Shield é uma camada adicional na infraestrutura de armazenamento em cache do CloudFront que ajuda a minimizar a carga da origem, melhorar a disponibilidade e reduzir os custos operacionais. O Amazon CloudFront Origin Shield fornece os seguintes benefícios:

**Melhor proporção de acertos de cache**  
O Origin Shield pode ajudar a melhorar a taxa de acertos do cache da distribuição do CloudFront pois fornece uma camada adicional de cache à frente da origem. Quando você usa o Origin Shield, todas as solicitações de todas as camadas de cache do CloudFront para a origem passam pelo Origin Shield, aumentando a probabilidade de um acerto de cache. O CloudFront pode recuperar cada objeto com uma única solicitação do Origin Shield de origem para a origem, e todas as outras camadas do cache do CloudFront (pontos de presença e [caches de borda regionais](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches)) podem recuperar o objeto do Origin Shield.

**Carga de origem reduzida**  
O Origin Shield pode reduzir ainda mais o número de [solicitações simultâneas](RequestAndResponseBehaviorCustomOrigin.md#request-custom-traffic-spikes) enviadas à sua origem para o mesmo objeto. As solicitações de um conteúdo que não está no cache do Origin Shield são consolidadas com outras solicitações para o mesmo objeto, resultando em apenas uma solicitação em direção à sua origem. Lidar com menos solicitações na sua origem pode preservar a disponibilidade dela durante picos de carga ou picos de tráfego inesperados e pode reduzir os custos de itens, como empacotamento just-in-time, transformações de imagens e DTO (transferência de dados).

**Melhor performance de rede**  
Ao habilitar o Origin Shield na região da AWS [que tem a menor latência para sua origem](#choose-origin-shield-region), é possível obter uma melhor performance de rede. Para origens em uma região da AWS, o tráfego de rede do CloudFront permanece na rede do CloudFront de alta taxa de transferência até sua origem. Para origens fora da AWS, o tráfego de rede do CloudFront permanece na rede do CloudFront até chegar ao Origin Shield, que tem uma conexão de baixa latência com a sua origem.

Você incorrerá cobranças adicionais por usar o Origin Shield. Para ter mais informações, consulte [Definição de preço do CloudFront](https://aws.amazon.com/cloudfront/pricing/).

**nota**  
O Origin Shield não é compatível com solicitações gRPC. Se uma distribuição que comporta gRPC tiver o Origin Shield habilitado, as solicitações gRPC continuarão funcionando. Entretanto, as solicitações serão encaminhadas diretamente à origem do gRPC sem passar pelo Origin Shield. Para obter mais informações, consulte [Usar gRPC com distribuições do CloudFront](distribution-using-grpc.md).

**Topics**
+ [

## Casos de uso do Origin Shield
](#origin-shield-use-cases)
+ [

## Escolher a região da AWS para o Origin Shield
](#choose-origin-shield-region)
+ [

## Habilitar o Origin Shield
](#enable-origin-shield)
+ [

## Estimar custos do Origin Shield
](#origin-shield-costs)
+ [

## Alta disponibilidade do Origin Shield
](#origin-shield-high-availability)
+ [

## Como o Origin Shield interage com outros recursos do CloudFront
](#origin-shield-and-other-features)

## Casos de uso do Origin Shield
<a name="origin-shield-use-cases"></a>

O CloudFront Origin Shield pode ser vantajoso para muitos casos de uso, incluindo os seguintes:
+ Visualizadores espalhados em diferentes regiões geográficas
+ Origens que fornecem empacotamento just-in-time para streaming ao vivo ou processamento instantâneo de imagens
+ Origens no local com restrições de capacidade ou largura de banda
+ Cargas de trabalho que usam várias redes de entrega de conteúdo (CDNs)

O Origin Shield pode não ser ideal em outros casos, como conteúdo dinâmico encaminhado por proxy para a origem, conteúdo com pouca capacidade de cache ou conteúdo que é solicitado com pouca frequência.

As seções a seguir explicam os benefícios do Origin Shield para os seguintes casos de uso.

**Topics**
+ [

### Visualizadores em diferentes regiões geográficas
](#os-use-cases-global-viewers)
+ [

### Várias CDNs
](#os-use-cases-multi-cdn)

### Visualizadores em diferentes regiões geográficas
<a name="os-use-cases-global-viewers"></a>

Com o Amazon CloudFront, você obtém uma carga reduzida que é intrínseca à origem, pois as solicitações que o CloudFront pode atender do cache não vão para a origem. Além da [rede global de pontos de presença](https://aws.amazon.com/cloudfront/features/#Amazon_CloudFront_Infrastructure) do CloudFront, [caches de borda regionais](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches) servem como uma camada intermediária de armazenamento em cache para fornecer acertos de cache e consolidar solicitações de origem para visualizadores em regiões geográficas próximas. As solicitações do visualizador são roteadas primeiro para um ponto de presença próximo do CloudFront, e, se o objeto não estiver armazenado em cache nesse local, a solicitação será enviada para um cache de borda regional.

Quando os visualizadores estão em regiões geográficas diferentes, as solicitações podem ser roteadas por diferentes caches de pontos regionais, e cada um deles pode enviar uma solicitação à sua origem para o mesmo conteúdo. Mas com o Origin Shield, você tem uma camada adicional de armazenamento em cache entre os caches de pontos regionais e sua origem. Todas as solicitações de todos os caches de pontos regionais passam pelo Origin Shield, reduzindo ainda mais a carga na sua origem. Os diagramas a seguir ilustram isso. Nos diagramas a seguir, a origem é AWS Elemental MediaPackage.

**Sem o Origin Shield**

Sem o Origin Shield, sua origem pode receber solicitações duplicadas para o mesmo conteúdo, conforme mostrado no diagrama a seguir.

![\[Sem o CloudFront Origin Shield, a origem pode receber solicitações duplicadas.\]](http://docs.aws.amazon.com/pt_br/AmazonCloudFront/latest/DeveloperGuide/images/origin-shield-without.png)


**Com o Origin Shield**

Usar o Origin Shield pode ajudar a reduzir a carga na sua origem, como mostrado no diagrama a seguir.

![\[Com o CloudFront Origin Shield, a origem pode receber menos solicitações duplicadas.\]](http://docs.aws.amazon.com/pt_br/AmazonCloudFront/latest/DeveloperGuide/images/origin-shield-with.png)


### Várias CDNs
<a name="os-use-cases-multi-cdn"></a>

Para veicular eventos de vídeo ao vivo ou conteúdo sob demanda popular, é possível usar várias redes de entrega de conteúdo (CDNs). Usar várias CDNs pode oferecer certas vantagens, mas também significa que sua origem pode receber muitas solicitações duplicadas para o mesmo conteúdo, cada uma proveniente de CDNs diferentes ou locais diferentes dentro da mesma CDN. Essas solicitações redundantes podem afetar negativamente a disponibilidade de sua origem ou causar custos operacionais adicionais para processos como empacotamento just-in-time ou transferência de dados (DTO) para a Internet.

Ao combinar o Origin Shield usando a distribuição do CloudFront como a origem para outras CDNs, é possível obter os seguintes benefícios:
+ Menos solicitações redundantes recebidas na sua origem, o que ajuda a reduzir os efeitos negativos do uso de várias CDNs.
+ Uma [chave de cache](controlling-the-cache-key.md) comum entre CDNs e gerenciamento centralizado para recursos voltados para a origem.
+ Melhor performance de rede. O tráfego de rede de outras CDNs é encerrado em um ponto de presença próximo do CloudFront, o que pode fornecer um acerto do cache local. Se o objeto solicitado não estiver no ponto de presença de cache, a solicitação para a origem permanecerá na rede do CloudFront até chegar ao Origin Shield, o que fornece alta taxa de transferência e baixa latência para a origem. Se o objeto solicitado estiver no cache do Origin Shield, a solicitação para sua origem será totalmente evitada.

**Importante**  
Se estiver interessado em usar o Origin Shield em uma arquitetura de várias CDNs e tiver preços com desconto, [entre em contato conosco](https://aws.amazon.com/contact-us/) ou com seu representante de vendas da AWS para obter mais informações. Podem se aplicar cobranças adicionais.

Os diagramas a seguir mostram como essa configuração pode ajudar a minimizar a carga em sua origem quando você fornece eventos de vídeo ao vivo populares com várias CDNs. Nos diagramas a seguir, a origem é AWS Elemental MediaPackage.

**Sem o Origin Shield (várias CDNs)**

Sem o Origin Shield, sua origem pode receber muitas solicitações duplicadas para o mesmo conteúdo, cada uma proveniente de uma CDN diferente, conforme mostrado no diagrama a seguir.

![\[Gráfico que mostra como uma origem pode receber solicitações duplicadas, cada uma proveniente de uma CDN diferente.\]](http://docs.aws.amazon.com/pt_br/AmazonCloudFront/latest/DeveloperGuide/images/origin-shield-without-multi-cdn.png)


**Com o Origin Shield (várias CDNs)**

O uso do Origin Shield, com o CloudFront como a origem para as outras CDNs, pode ajudar a reduzir a carga na origem, conforme mostrado no diagrama a seguir.

![\[Gráfico que mostra o CloudFront Origin Shield recebendo menos solicitações duplicadas.\]](http://docs.aws.amazon.com/pt_br/AmazonCloudFront/latest/DeveloperGuide/images/origin-shield-with-multi-cdn.png)


## Escolher a região da AWS para o Origin Shield
<a name="choose-origin-shield-region"></a>

O Amazon CloudFront oferece o Origin Shield nas regiões da AWS em que o CloudFront tem um [cache de borda regional](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches). Ao habilitar o Origin Shield, escolha a região da AWS para o Origin Shield. Recomendamos escolher a região da AWS que tem a menor latência para sua origem. É possível usar o Origin Shield com origens que estão em uma região da AWS e com origens que não estão na AWS.

### Para origens em uma região da AWS
<a name="choose-origin-shield-region-inside-aws"></a>

Se a sua origem estiver em uma região da AWS, primeiro determine se a origem está em uma região na qual o CloudFront oferece o Origin Shield. O CloudFront oferece o Origin Shield nas seguintes regiões da AWS.
+ US East (Ohio) – `us-east-2`
+ US East (N. Virginia) – `us-east-1`
+ US West (Oregon) – `us-west-2`
+ Asia Pacific (Mumbai) – `ap-south-1`
+ Asia Pacific (Seoul) – `ap-northeast-2`
+ Asia Pacific (Singapore) – `ap-southeast-1`
+ Asia Pacific (Sydney) – `ap-southeast-2`
+ Asia Pacific (Tokyo) – `ap-northeast-1`
+ Europe (Frankfurt) – `eu-central-1`
+ Europe (Ireland) – `eu-west-1`
+ Europe (London) – `eu-west-2`
+ South America (São Paulo) – `sa-east-1`
+ Oriente Médio (EAU): `me-central-1`

**Se a sua origem estiver em uma região da AWS na qual o CloudFront oferece o Origin Shield**

Se a origem estiver em uma região da AWS em que o CloudFront oferece o Origin Shield (consulte a lista anterior), habilite o Origin Shield na mesma região que a sua origem.

**Se a sua origem não estiver em uma região da AWS na qual o CloudFront oferece o Origin Shield**

 Se a sua origem não estiver em uma região da AWS em que o CloudFront oferece o Origin Shield, consulte a tabela a seguir para determinar em qual região habilitar o Origin Shield.


|  **Se a sua origem está em ...**  |  **Habilitar o Origin Shield em ...**  | 
| --- | --- | 
|  US West (N. California) – `us-west-1`  |  US West (Oregon) – `us-west-2`  | 
|  Africa (Cape Town) – `af-south-1`  |  Europe (Ireland) – `eu-west-1`  | 
|  Asia Pacific (Hong Kong) – `ap-east-1`  |  Asia Pacific (Singapore) – `ap-southeast-1`  | 
|  Canada (Central) – `ca-central-1`  |  US East (N. Virginia) – `us-east-1`  | 
|  Europe (Milan) – `eu-south-1`  |  Europe (Frankfurt) – `eu-central-1`  | 
|  Europe (Paris) – `eu-west-3`  |  Europe (London) – `eu-west-2`  | 
|  Europe (Stockholm) – `eu-north-1`  |  Europe (London) – `eu-west-2`  | 
|  Middle East (Bahrain) – `me-south-1`  |  Asia Pacific (Mumbai) – `ap-south-1`  | 

### Para origens fora da AWS
<a name="choose-origin-shield-region-outside-aws"></a>

É possível usar o Origin Shield com uma origem no local ou não em uma região da AWS. Nesse caso, habilite o Origin Shield na região da AWS que tem a menor latência de sua origem. Se você não tiver certeza de qual região da AWS tem a menor latência de sua origem, use as sugestões a seguir para ajudá-lo a fazer uma determinação.
+ É possível consultar a tabela anterior para obter uma aproximação de qual região da AWS pode ter a menor latência em relação à sua origem, com base na localização geográfica da sua origem.
+ É possível executar instâncias do Amazon EC2 em algumas regiões da AWS diferentes que estão geograficamente próximas da sua origem e executar alguns testes usando `ping` para medir as latências de rede típicas entre essas regiões e a sua origem.

## Habilitar o Origin Shield
<a name="enable-origin-shield"></a>

É possível habilitar o Origin Shield para melhorar sua taxa de acertos de cache, reduzir a carga em sua origem e ajudar a melhorar a performance. Para habilitar o Origin Shield, altere as configurações de origem em uma distribuição do CloudFront. O Origin Shield é uma propriedade da origem. Para cada origem em suas distribuições do CloudFront, é possível habilitar separadamente o Origin Shield em qualquer região da AWS que forneça a melhor performance para essa origem.

É possível habilitar o Origin Shield no console do CloudFront com o CloudFormation ou com a API do CloudFront.

------
#### [ Console ]

**Como habilitar o Origin Shield para uma origem existente (console)**

1. Faça login no Console de gerenciamento da AWS e abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Escolha a distribuição que tem a origem que você deseja atualizar.

1. Escolha a guia **Origens**.

1. Escolha a origem a ser atualizada e escolha **Edit (Editar)**.

1. Em **Enable Origin Shield** (Habilitar o Origin Shield), escolha **Yes (Sim)**.

1. Para a **Origin Shield Region** (Região do Origin Shield), escolha a região da AWS em que você deseja habilitar o Origin Shield. Para obter ajuda na escolha de uma região, consulte [Escolher a região da AWS para o Origin Shield](#choose-origin-shield-region).

1. Escolha **Salvar alterações**.

Quando seu status de distribuição for **Deployed (Implantado)**, o Origin Shield estará pronto. Isso leva alguns minutos.

**Como habilitar o Origin Shield para uma nova origem (console)**

1. Faça login no Console de gerenciamento da AWS e abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Para criar a nova origem em uma distribuição existente, faça o seguinte:

   1. Escolha a distribuição em que deseja criar a origem.

   1. Escolha **Create Origin (Criar origem)** e avance para a etapa 3.

   Para criar a nova origem em uma nova distribuição padrão, faça o seguinte:

   1. Siga as etapas para criar uma distribuição padrão no console. Para obter mais informações, consulte [Criar uma distribuição do CloudFront no console](distribution-web-creating-console.md#create-console-distribution).

   1. Na seção **Configurações**, selecione **Personalizar configurações de origem**. Vá para a etapa 3.

1. Em **Enable Origin Shield** (Habilitar o Origin Shield), escolha **Yes (Sim)**.

1. Para a **Origin Shield Region** (Região do Origin Shield), escolha a região da AWS em que você deseja habilitar o Origin Shield. Para obter ajuda na escolha de uma região, consulte [Escolher a região da AWS para o Origin Shield](#choose-origin-shield-region).

1. Siga as etapas no console para concluir a criação de sua origem ou distribuição.

Quando seu status de distribuição for **Deployed (Implantado)**, o Origin Shield estará pronto. Isso leva alguns minutos.

------
#### [ CloudFormation ]

Para habilitar o Origin Shield com o CloudFormation, use a propriedade `OriginShield` no tipo de propriedade `Origin` em um recurso `AWS::CloudFront::Distribution`. É possível adicionar a propriedade `OriginShield` a um `Origin` existente ou incluí-la ao criar um novo `Origin`.

O exemplo a seguir mostra a sintaxe, no formato YAML, para habilitar `OriginShield` na região Oeste dos EUA (Oregon) (`us-west-2`). Para obter ajuda na escolha de uma região, consulte [Escolher a região da AWS para o Origin Shield](#choose-origin-shield-region). Este exemplo mostra apenas o tipo de propriedade `Origin`, não o recurso `AWS::CloudFront::Distribution` inteiro.

```
Origins:
- DomainName: 3ae97e9482b0d011.mediapackage.us-west-2.amazonaws.com
  Id: Example-EMP-3ae97e9482b0d011
  OriginShield:
    Enabled: true
    OriginShieldRegion: us-west-2
  CustomOriginConfig:
    OriginProtocolPolicy: match-viewer
    OriginSSLProtocols: TLSv1
```

Para obter mais informações, consulte [AWS::CloudFront::Origem da distribuição](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-origin.html) na seção de referência de recursos e propriedade do *Guia do usuário do AWS CloudFormation*.

------
#### [ API ]

Para habilitar o Origin Shield com a API do CloudFront usando os AWS SDKs ou a AWS Command Line Interface (AWS CLI), use o tipo `OriginShield`. Especifique `OriginShield` em uma `Origin` em uma `DistributionConfig`. Para obter informações sobre o tipo `OriginShield`, consulte as seguintes informações na *Referência da API do Amazon CloudFront*.
+ [OriginShield](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_OriginShield.html) (tipo)
+ [Origin](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_Origin.html) (tipo)
+ [DistributionConfig](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_DistributionConfig.html) (tipo)
+ [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) (operação)
+ [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html) (operação)

A sintaxe específica para usar esses tipos e operações varia com base no cliente SDK, CLI ou API. Para obter mais informações, consulte a documentação de referência do SDK, da CLI ou do cliente.

------

## Estimar custos do Origin Shield
<a name="origin-shield-costs"></a>

Você acumula cobranças do Origin Shield com base no número de solicitações que vão para o Origin Shield como camada incremental.

 Para solicitações dinâmicas (não armazenáveis em cache) encaminhadas por proxy para a origem, o Origin Shield é sempre uma camada incremental. As solicitações dinâmicas usam os métodos HTTP: `PUT`, `POST`, `PATCH`, e `DELETE`.

As solicitações `GET` e `HEAD` com uma configuração de vida útil (TTL) de menos de 3600 segundos são consideradas solicitações dinâmicas. Além disso, as solicitações `GET` e `HEAD` que desabilitaram o armazenamento em cache também são consideradas solicitações dinâmicas.

Para estimar suas cobranças pelo Origin Shield para solicitações dinâmicas, use a seguinte fórmula:

Número total de solicitações dinâmicas **x** Origin Shield por 10.000 solicitações **/** 10.000

Para solicitações não dinâmicas com métodos HTTP `GET`, `HEAD` e `OPTIONS`, o Origin Shield às vezes é uma camada incremental. Ao habilitar o Origin Shield, escolha a Região da AWS para o Origin Shield. Para solicitações que naturalmente vão para o [cache de borda regional](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches) na mesma região que o Origin Shield, o Origin Shield não é uma camada incremental. Você não acumula cobranças do Origin Shield para essas solicitações. Para solicitações que vão para um cache de borda regional em uma região diferente do Origin Shield e que, depois, vão para o Origin Shield, o Origin Shield é uma camada incremental. Você acumula cobranças do Origin Shield para essas solicitações.

Para estimar suas cobranças pelo Origin Shield para solicitações que podem ser armazenadas em cache, use a seguinte fórmula:

Número total de solicitações que podem ser armazenadas em cache **x** (1 - taxa de acertos do cache) **x** taxa de acertos do cache que acessam o Origin Shield em um cache de borda regional **x** carga do Origin Shield por 10.000 solicitações **/** 10.000

Para obter mais informações sobre a cobrança por 10.000 solicitações do Origin Shield, consulte [Definição de preço do CloudFront](https://aws.amazon.com/cloudfront/pricing/).

## Alta disponibilidade do Origin Shield
<a name="origin-shield-high-availability"></a>

O Origin Shield utiliza o atributo de [caches de borda regional](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches) do CloudFront. Cada um desses caches de borda é criado em uma região da AWS usando pelo menos três [Zonas de disponibilidade](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) com frotas de instâncias do Amazon EC2 Auto Scaling. As conexões de locais do CloudFront com o Origin Shield também usam rastreamento de erro ativo para cada solicitação, para encaminhar automaticamente a solicitação para um local secundário do Origin Shield se o local primário do Origin Shield não estiver disponível.

## Como o Origin Shield interage com outros recursos do CloudFront
<a name="origin-shield-and-other-features"></a>

As seções a seguir explicam como o Origin Shield interage com outros recursos do CloudFront.

### Origin Shield e registro em log do CloudFront
<a name="origin-shield-logging"></a>

Para ver quando o Origin Shield processou uma solicitação, é necessário habilitar uma das seguintes opções:
+ [Registros em log padrão do CloudFront (logs de acesso)](AccessLogs.md). Os logs padrão são fornecidos gratuitamente.
+ [Logs em tempo real do CloudFront](real-time-logs.md). Há cobranças adicionais pelo uso de logs em tempo real. Consulte [Definição de preço do Amazon CloudFront](https://aws.amazon.com/cloudfront/pricing/)

Os acertos de cache do Origin Shield são exibidos como `OriginShieldHit` no campo `x-edge-detailed-result-type` nos logs do CloudFront. O Origin Shield utiliza os [caches de borda](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches) do Amazon CloudFront. Se uma solicitação for roteada de um ponto de presença do CloudFront para o cache de borda regional que está agindo como Origin Shield, ela será relatada como um `Hit` nos logs, não como um `OriginShieldHit`.

### Origin Shield e grupos de origem
<a name="origin-shield-and-origin-group"></a>

O Origin Shield é compatível com [Grupos de origem do CloudFront](high_availability_origin_failover.md). Como o Origin Shield é uma propriedade da origem, as solicitações sempre passam pelo Origin Shield para cada origem, mesmo quando a origem faz parte de um grupo de origem. Para uma determinada solicitação, o CloudFront roteia a solicitação para a origem primária no grupo de origem por meio do Origin Shield da origem primária. Se essa solicitação falhar (de acordo com os critérios de failover do grupo da origem), o CloudFront roteará a solicitação para a origem secundária por meio do Origin Shield da origem secundária.

### Origin Shield e Lambda@Edge
<a name="origin-shield-and-lambda-at-edge"></a>

O Origin Shield não afeta a funcionalidade das funções do [Lambda@Edge](lambda-at-the-edge.md) mas pode afetar a região da AWS em que essas funções são executadas.

Ao usar o Origin Shield com o Lambda@Edge, [triggers voltados para a origem](lambda-cloudfront-trigger-events.md) (solicitação e resposta de origem) são executados na região da AWS em que o Origin Shield está habilitado. Se o local primário do Origin Shield não estiver disponível e o CloudFront encaminhar as solicitações para um local secundário do Origin Shield, os acionadores de origem do Lambda@Edge também mudarão para usar o local secundário do Origin Shield.

Os triggers voltados para o visualizador não são afetados.

# Otimizar a alta disponibilidade com o failover de origem do CloudFront
<a name="high_availability_origin_failover"></a>

Também é possível configurar o CloudFront failover de origem para cenários que exigem alta disponibilidade. Para começar, crie um *grupo de origem* com duas origens: uma primária e outra secundária. Se a origem primária estiver indisponível ou retornar códigos de status de resposta HTTP específicos que indiquem falha, o CloudFront alternará automaticamente para a origem secundária.

Para configurar o failover de origem, você deve ter uma distribuição com pelo menos duas origens. Depois, crie um grupo de origens para a distribuição que inclua duas origens, definindo uma delas como a primária. Por último, crie ou atualize um comportamento de cache para usar o grupo de origem.

Para consultar as etapas da configuração de grupos de origens e configurar opções específicas de failover de origem, consulte [Criar um grupo de origem](#concept_origin_groups.creating).

Depois de você configurar o failover de origem para um comportamento de cache, o CloudFront faz o seguinte para solicitações do visualizador:
+ Quando houver um acerto de cache, o CloudFront retornará o objeto solicitado.
+ Quando houver um erro de cache, o CloudFront roteará a solicitação para a origem primária no grupo de origem.
+ Quando a origem primária retornar um código de status que não esteja configurado para failover, como um código de status HTTP 2xx ou 3xx, o CloudFront fornecerá o objeto solicitado ao visualizador.
+ Quando ocorrer uma das seguintes situações:
  + A origem primária retorna um código de status HTTP que você configurou para failover.
  + O CloudFront não consegue se conectar à origem primária (quando 503 é definido como um código de failover).
  + A resposta da origem primária demora muito (atinge o tempo limite) (quando 504 é definido como um código de failover).

  Assim, o CloudFront roteia a solicitação para a origem secundária do grupo de origem.
**nota**  
Em alguns casos de uso, como conteúdo de vídeo por streaming, convém que o CloudFront faça failover para a origem secundária rapidamente. Para ajustar a rapidez com que o CloudFront faz failover para a origem secundária, consulte [Controlar tempos limite e tentativas da origem](#controlling-attempts-and-timeouts).

O CloudFront roteia todas as solicitações recebidas para a origem primária, mesmo quando uma solicitação anterior tenha feito failover para a origem secundária. O CloudFront só envia solicitações para a origem secundária após uma falha de uma solicitação para a origem primária.

O CloudFront faz failover para a origem secundária somente quando o método HTTP da solicitação do visualizador for `GET`, `HEAD` ou `OPTIONS`. O CloudFront não faz failover quando o visualizador envia um método HTTP diferente (por exemplo `POST`, `PUT` etc.).

**nota**  
O CloudFront não fará failover se `OPTIONS` se estiver definida como [Métodos HTTP em cache](DownloadDistValuesCacheBehavior.md#DownloadDistValuesCachedHTTPMethods) no comportamento de cache.

O diagrama a seguir mostra como o failover de origem funciona.

![\[Como o failover de origem funciona\]](http://docs.aws.amazon.com/pt_br/AmazonCloudFront/latest/DeveloperGuide/images/origingroups-overview.png)


**Topics**
+ [

## Criar um grupo de origem
](#concept_origin_groups.creating)
+ [

## Controlar tempos limite e tentativas da origem
](#controlling-attempts-and-timeouts)
+ [

## Uso do failover de origem com funções do Lambda@Edge
](#concept_origin_groups.lambda)
+ [

## Usar páginas de erro personalizadas com failover de origem
](#concept_origin_groups.custom-error)

## Criar um grupo de origem
<a name="concept_origin_groups.creating"></a><a name="create-origin-groups-procedure"></a>

**Para criar um grupo de origens**

1. Faça login no Console de gerenciamento da AWS e abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Escolha a distribuição para a qual deseja criar o grupo de origem.

1. Escolha a guia **Origens**.

1. Certifique-se de que a distribuição tenha mais de uma origem. Se ela não tiver, adicione uma segunda origem.

1. Na guia **Origins** (Origem), no painel **Origin groups** (Grupos de origens), escolha **Create origin group** (Criar grupo de origens).

1. Escolha as origens para o grupo de origem. Depois de adicioná-las, use as setas para definir a prioridade, ou seja, qual será a origem primária e qual será a secundária.

1. Insira um nome para o grupo de origens.

1. Escolha os códigos de status de HTTP a serem usados como critérios de failover. Você pode escolher qualquer combinação dos seguintes códigos de status: 400, 403, 404, 416, 500, 502, 503 ou 504. Quando o CloudFront recebe uma resposta com um dos códigos de status especificados, ele executa o failover para a origem secundária.
**nota**  
O CloudFront faz failover para a origem secundária somente quando o método HTTP da solicitação do visualizador for `GET`, `HEAD` ou `OPTIONS`. O CloudFront não faz failover quando o visualizador envia um método HTTP diferente (por exemplo `POST`, `PUT` etc.).

1. Em **Critérios de seleção de origem**, especifique como suas origens são selecionadas quando sua distribuição roteia as solicitações do visualizador. Você pode escolher as seguintes opções:  
**Padrão**  
O CloudFront usará a prioridade de origem padrão que você especificar na página **Configurações**.  
**Pontuação de qualidade de mídia**  
O CloudFront rastreia e usa essa pontuação para determinar a primeira origem à qual encaminhar a solicitação. Isso também autoriza o CloudFront a fazer solicitações `HEAD` assíncronas à origem alternativa no grupo de origens para determinar a respectiva pontuação de qualidade de mídia. Você só pode escolher essa opção para origens do AWS Elemental MediaPackage v2. Para obter mais informações, consulte [Resiliência com Reconhecimento de Qualidade da Mídia](media-quality-score.md). 

1. Escolha **Create origin group** (Criar grupo de origens).

Certifique-se de atribuir seu grupo de origem como origem para o comportamento de cache distribuído. Para obter mais informações, consulte [Nome](DownloadDistValuesOrigin.md#DownloadDistValuesId).

## Controlar tempos limite e tentativas da origem
<a name="controlling-attempts-and-timeouts"></a>

Por padrão, o CloudFront tenta se conectar à origem primária em um grupo de origem por até 30 segundos (3 tentativas de conexão de 10 segundos cada) antes de fazer failover para a origem secundária. Para alguns casos de uso, como conteúdo de vídeo por streaming, talvez você queira que o CloudFront faça failover para a origem secundária mais rapidamente. É possível ajustar as configurações a seguir para afetar a rapidez com que o CloudFront faz failover para a origem secundária. Se a origem for uma origem secundária ou uma origem que não faça parte de um grupo de origem, essas configurações afetarão a rapidez com que o CloudFront retorna uma resposta HTTP 504 ao visualizador.

Para que o failover seja feito mais rapidamente, especifique um tempo limite de conexão mais curto, menos tentativas de conexão ou ambos. Para origens personalizadas (incluindo origens de bucket do Amazon S3 que *são* configuradas com hospedagem de site estático), também é possível ajustar o tempo limite de resposta da origem.

**Tempo limite de conexão da origem**  
A configuração de tempo limite de conexão da origem afeta o tempo de espera do CloudFront ao tentar estabelecer uma conexão com a origem. Por padrão, o CloudFront aguarda 10 segundos para estabelecer uma conexão, mas é possível especificar de 1 a 10 segundos (inclusive). Para obter mais informações, consulte [Tempo limite da conexão](DownloadDistValuesOrigin.md#origin-connection-timeout).

**Tentativas de conexão da origem**  
A configuração de tentativas de conexão da origem afeta o número de vezes que o CloudFront tenta se conectar à origem. Por padrão, o CloudFront tenta se conectar três vezes, mas é possível especificar de uma a três (inclusive). Para obter mais informações, consulte [Tentativas de conexão](DownloadDistValuesOrigin.md#origin-connection-attempts).  
Para uma origem personalizada (incluindo um bucket do Amazon S3 configurado com hospedagem de site estático), essa configuração também afeta o número de vezes que o CloudFront tenta obter uma resposta da origem caso o tempo limite de resposta da origem expire.

**Tempo limite da e resposta da origem**  
A configuração do tempo limite de resposta da origem, também chamada de tempo limite de leitura de origem, afeta o tempo que o CloudFront espera para receber uma resposta (ou para receber a resposta completa) da origem. Por padrão, o CloudFront aguarda 30 segundos, mas é possível especificar de 1 a 120 segundos (inclusive). Para obter mais informações, consulte [Tempo limite de resposta](DownloadDistValuesOrigin.md#DownloadDistValuesOriginResponseTimeout).

### Como alterar essas configurações
<a name="controlling-attempts-and-timeouts-how-to"></a>

**Como alterar essas configurações no [console do CloudFront](https://console.aws.amazon.com/cloudfront/v4/home)**
+ Para uma nova origem ou uma nova distribuição, especifique esses valores ao criar o recurso.
+ Para uma origem existente em uma distribuição existente, especifique esses valores ao editar a origem.

Para obter mais informações, consulte [Referência de configurações de todas as distribuições](distribution-web-values-specify.md).

## Uso do failover de origem com funções do Lambda@Edge
<a name="concept_origin_groups.lambda"></a>

Você pode usar as funções do Lambda@Edge com distribuições do CloudFront que tiver configurado com grupos de origem. Para usar uma função do Lambda, especifique-a em um [trigger de solicitação origem ou resposta de origem](lambda-cloudfront-trigger-events.md) de um grupo de origem ao criar o comportamento de cache. Ao usar uma função do Lambda@Edge com um grupo de origem, ela poderá ser acionada duas vezes para uma única solicitação de visualizador. Por exemplo, considere este cenário:

1. Você cria uma função do Lambda@Edge com um trigger de solicitação de origem.

1. A função do Lambda é acionada quando o CloudFront envia uma solicitação para a origem primária (em um falha de cache).

1. A origem primária responde com um código de status de HTTP configurado para failover.

1. A função do Lambda é acionada novamente quando o CloudFront envia a mesma solicitação à origem secundária.

O diagrama a seguir ilustra como o failover de origem funciona quando você inclui uma função do Lambda@Edge em uma solicitação de origem ou trigger de resposta.

![\[Como um failover de origem funciona com funções do Lambda@Edge\]](http://docs.aws.amazon.com/pt_br/AmazonCloudFront/latest/DeveloperGuide/images/origingroups-with-lambda-edge.png)


Para obter mais informações sobre como usar triggers do Lambda@Edge, consulte [Adicionar acionadores para uma função do Lambda@Edge](lambda-edge-add-triggers.md).

Para ter mais informações sobre como gerenciar failover de DNS, consulte [Configurar failover de DNS](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html) no *Guia do desenvolvedor do Amazon Route 53*.

## Usar páginas de erro personalizadas com failover de origem
<a name="concept_origin_groups.custom-error"></a>

Você pode usar as páginas de erro personalizadas com grupos de origens de forma semelhante à forma como você usá-los com origens que não são configuradas para o failover de origem. 

Ao usar o failover de origem, você pode configurar o CloudFront para retornar uma página de erro personalizada para a origem primária ou secundária (ou ambas):
+ **Retornar uma página de erro personalizada para a origem primária**: se a origem primária retornar um código de status HTTP que não estiver configurado para failover, o CloudFront retornará a página de erro personalizada aos visualizadores.
+ **Retornar uma página de erro personalizada à origem secundária**: se o CloudFront receber um código de status de falha da origem secundária, o CloudFront retornará a página de erro personalizada.

Para obter mais informações sobre como usar páginas de erro personalizadas com o CloudFront, consulte [Gerar respostas a erros personalizadas](GeneratingCustomErrorResponses.md).

# Gerenciar o tempo de permanência do conteúdo no cache (expiração)
<a name="Expiration"></a>

É possível controlar o tempo de permanência dos arquivos em um cache do CloudFront antes de o CloudFront encaminhar outra solicitação para a origem. A diminuição da duração permite fornecer conteúdo dinâmico. O aumento da duração significa que os usuários obtêm melhor performance, pois é mais provável que seus arquivos sejam fornecidos diretamente do cache de borda. Uma duração maior também reduz a carga na origem.

Normalmente, o CloudFront fornece um arquivo de um ponto de presença até passar a duração do cache especificada, ou seja, até o arquivo expirar. Depois de expirar, na próxima vez em que o local da borda receber uma solicitação para o arquivo, o CloudFront encaminhará a solicitação à origem a fim de verificar se o cache contém a versão mais recente do arquivo. A resposta da origem depende se o arquivo foi alterado ou não:
+ Se o cache do CloudFront já tiver a versão mais recente, a origem retornará um código de status `304 Not Modified`.
+ Se o cache do CloudFront não tiver a versão mais recente, a origem retornará um código de status `200 OK` e a versão mais recente do arquivo.

Se um arquivo em um ponto de presença não for solicitado com frequência, o CloudFront poderá exclui-lo (removê-lo antes da data de expiração) para criar espaço para os arquivos solicitados mais recentemente.

Recomendamos gerenciar a duração do cache atualizando a política de cache da sua distribuição. Se você optar por não usar uma política de cache, a vida útil (TTL) padrão será de 24 horas, mas você poderá atualizar as seguintes configurações para substituir o padrão:
+ Para alterar a duração do cache de todos os arquivos com o mesmo padrão de caminho, você pode alterar as configurações do CloudFront para **Minimum TTL (TTL mínimo)**, **Maximum TTL (TTL máximo)** e **Default TTL (TTL padrão)** para um comportamento de cache. Para obter mais informações sobre configurações individuais, consulte [Minimum TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMinTTL), [Maximum TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL) e [TTL padrão](DownloadDistValuesCacheBehavior.md#DownloadDistValuesDefaultTTL).
+ Para alterar a duração do cache de um arquivo individual, é possível configurar a origem para adicionar um cabeçalho `Cache-Control` com a diretiva `max-age` ou `s-maxage`, ou um cabeçalho `Expires` ao arquivo. Para obter mais informações, consulte [Usar cabeçalhos para controlar a duração do cache para objetos individuais](#expiration-individual-objects).

Para obter mais informações sobre como **Minimum TTL** (TTL mínimo), **Default TTL** (TTL padrão) e **Maximum TTL** (TTL máximo) interagem com as diretivas `max-age` e `s-maxage` e o campo de cabeçalho `Expires`, consulte [Especificar por quanto tempo o CloudFront armazena os objetos em cache](#ExpirationDownloadDist).

Você também pode controlar o tempo de permanência de erros (por exemplo, `404 Not Found`) em um cache do CloudFront antes de o CloudFront tentar obter novamente o objeto solicitado encaminhando outra solicitação para a origem. Para obter mais informações, consulte [Como o CloudFront processa códigos de status HTTP 4xx e 5xx da origem](HTTPStatusCodes.md).

**Topics**
+ [

## Usar cabeçalhos para controlar a duração do cache para objetos individuais
](#expiration-individual-objects)
+ [

## Fornecer conteúdo obsoleto (expirado)
](#stale-content)
+ [

## Especificar por quanto tempo o CloudFront armazena os objetos em cache
](#ExpirationDownloadDist)
+ [

## Adicionar cabeçalhos aos objetos usando o console do Amazon S3
](#ExpirationAddingHeadersInS3)

## Usar cabeçalhos para controlar a duração do cache para objetos individuais
<a name="expiration-individual-objects"></a>

Você pode usar os cabeçalhos `Cache-Control` e `Expires` para controlar o tempo de permanência dos objetos no cache. As configurações de **Minimum TTL**, **Default TTL** e **Maximum TTL ** também afetam a duração do cache, mas esta é uma visão geral de como os cabeçalhos podem afetar a duração do cache: 
+ A diretiva `Cache-Control max-age` permite especificar o tempo de permanência (em segundos) de um objeto no cache antes de o CloudFront obtê-lo novamente do servidor de origem. O tempo mínimo de expiração é compatível com o CloudFront é de 0 segundos. O valor máximo é de 100 anos. Especifique o valor no seguinte formato:

  `Cache-Control: max-age=`*segundos*

  Por exemplo, a seguinte diretiva solicita que o CloudFront mantenha o objeto associado no cache por 3600 segundos (uma hora):

  `Cache-Control: max-age=3600`

  Para que os objetos permaneçam nos caches de borda do CloudFront por uma duração diferente da permanência nos caches do navegador, use as diretivas `Cache-Control max-age` e `Cache-Control s-maxage` em conjunto. Para obter mais informações, consulte [Especificar por quanto tempo o CloudFront armazena os objetos em cache](#ExpirationDownloadDist).
+ O campo de cabeçalho `Expires` permite especificar uma data e hora de expiração usando o formato especificado em [RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1 Section 3.3.1, Full Date](https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3.1), por exemplo:

  `Sat, 27 Jun 2015 23:59:59 GMT`

Recomendamos o uso da diretiva `Cache-Control max-age`, em vez do campo de cabeçalho `Expires`, para controlar o armazenamento de objetos em cache. Se você especificar os valores de `Cache-Control max-age` e de `Expires`, o CloudFront usará somente o valor de `Cache-Control max-age`.

Para obter mais informações, consulte [Especificar por quanto tempo o CloudFront armazena os objetos em cache](#ExpirationDownloadDist).

Não é possível usar os campos de cabeçalho HTTP `Cache-Control` ou `Pragma` em uma solicitação `GET` de um visualizador para forçar o CloudFront a voltar ao servidor de origem para obter o objeto. O CloudFront ignora esses campos de cabeçalho em solicitações do visualizador.

Para obter mais informações sobre os campos de cabeçalho `Cache-Control` e `Expires`, consulte as seguintes seções em *RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1*: 
+ [Section 14.9 Cache Control](https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9)
+ [Section 14.21 Expires](https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.21)

## Fornecer conteúdo obsoleto (expirado)
<a name="stale-content"></a>

O CloudFront oferece suporte às diretivas de controle de cache `Stale-While-Revalidate` e `Stale-If-Error`. É possível usar essas diretivas para especificar por quanto tempo o conteúdo obsoleto fica disponível para os espectadores.

**Topics**
+ [

### `Stale-While-Revalidate`
](#stale-while-revalidate)
+ [

### `Stale-If-Error`
](#stale-if-error-only)
+ [

### Usar ambas as diretivas
](#use-both-stale-directives)

### `Stale-While-Revalidate`
<a name="stale-while-revalidate"></a>

Essa diretiva permite que o CloudFront forneça conteúdo obsoleto do cache enquanto busca de forma assíncrona uma nova versão da origem. Isso melhora a latência à medida que os visualizadores recebem respostas imediatamente de locais da borda sem precisar esperar a obtenção do segundo plano. O conteúdo novo é carregado em segundo plano para futuras solicitações.

**Example Exemplo: `Stale-While-Revalidate`**  
O CloudFront faz o seguinte quando você define o cabeçalho `Cache-Control` para usar essas diretivas.   

```
Cache-Control: max-age=3600, stale-while-revalidate=600
```

1. O CloudFront armazenará a resposta em cache por uma hora (`max-age=3600`).

1. Se uma solicitação for feita após essa duração, o CloudFront fornecerá o conteúdo obsoleto e, ao mesmo tempo, enviará uma solicitação à origem para revalidar e atualizar o conteúdo em cache. 

1. Enquanto o conteúdo é revalidado, o CloudFront fornece o conteúdo obsoleto por até 10 minutos (`stale-while-revalidate=600`).

**nota**  
O CloudFront fornecerá o conteúdo obsoleto até o valor da diretiva `stale-while-revalidate` ou o valor de [TTL máximo](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL) do CloudFront, o que for menor. Após a duração máxima de TTL, o objeto obsoleto não estará disponível no cache de borda, independentemente do valor de `stale-while-revalidate`. 

### `Stale-If-Error`
<a name="stale-if-error-only"></a>

Essa diretiva permite que o CloudFront forneça conteúdo obsoleto do cache se a origem estiver inacessível ou retornar o código de erro que esteja entre 500 e 600. Isso garante que os visualizadores possam acessar o conteúdo mesmo durante uma interrupção na origem.

**Example Exemplo: `Stale-If-Error`**  
O CloudFront faz o seguinte quando você define o cabeçalho `Cache-Control` para usar essas diretivas.   

```
Cache-Control: max-age=3600, stale-if-error=86400
```

1. O CloudFront armazena a resposta em cache por uma hora (`max-age=3600`).

1. Se a origem estiver inativa ou retornar um erro após essa duração, o CloudFront continuará fornecendo o conteúdo obsoleto por até 24 horas (`stale-if-error=86400`).

1. Se você tiver configurado respostas de erro personalizadas, o CloudFront tentará fornecer o conteúdo obsoleto caso seja encontrado um erro na duração de `stale-if-error` especificada. Se o conteúdo obsoleto estiver indisponível, o CloudFront fornecerá as respostas de erro personalizadas que você configurou para o código de status de erro correspondente. Para obter mais informações, consulte [Gerar respostas a erros personalizadas](GeneratingCustomErrorResponses.md).

**Observações**  
O CloudFront fornecerá o conteúdo obsoleto até o valor da diretiva `stale-if-error` ou o valor de [TTL máximo](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL) do CloudFront, o que for menor. Após a duração máxima de TTL, o objeto obsoleto não estará disponível no cache de borda, independentemente do valor de `stale-if-error`. 
Se você não configurar `stale-if-error` ou personalizar respostas de erro, o CloudFront retornará o objeto obsoleto ou encaminhará a resposta de erro de volta ao visualizador, dependendo se o objeto solicitado está no cache da borda ou não. Para obter mais informações, consulte [Como o CloudFront processará erros se você não tiver configurado páginas de erro personalizadas](HTTPStatusCodes.md#HTTPStatusCodes-no-custom-error-pages).

### Usar ambas as diretivas
<a name="use-both-stale-directives"></a>

`stale-while-revalidate` e `stale-if-error` são diretivas independentes de controle de cache que podem ser usadas em conjunto para reduzir a latência e adicionar um buffer para que a origem responda ou se recupere.

**Example Exemplo: uso de ambas as diretivas**  
O CloudFront faz o seguinte quando você define o cabeçalho `Cache-Control` para usar as diretivas a seguir.   

```
Cache-Control: max-age=3600, stale-while-revalidate=600, stale-if-error=86400
```

1. O CloudFront armazena a resposta em cache por uma hora (`max-age=3600`). 

1. Se uma solicitação for feita após essa duração, o CloudFront exibirá o conteúdo obsoleto por até 10 minutos (`stale-while-revalidate=600`) enquanto o conteúdo está sendo revalidado. 

1. Se o servidor de origem retornar um erro enquanto o CloudFront tenta revalidar o conteúdo, o CloudFront continuará fornecendo o conteúdo obsoleto por até 24 horas (`stale-if-error=86400`).

O armazenamento em cache é um equilíbrio entre desempenho e atualização. Usar diretivas como `stale-while-revalidate` e `stale-if-error` pode melhorar o desempenho e a experiência do usuário, mas certifique-se de que as configurações estejam alinhadas com a atualização do seu conteúdo. As diretivas de conteúdo obsoletas são mais adequadas para casos de uso em que o conteúdo precisa ser atualizado, mas ter a versão mais recente não é essencial. Além disso, se seu conteúdo não mudar ou raramente mudar, o `stale-while-revalidate` poderá adicionar solicitações de rede desnecessárias. Em vez disso, considere definir uma longa duração de cache.

## Especificar por quanto tempo o CloudFront armazena os objetos em cache
<a name="ExpirationDownloadDist"></a>

Para controlar a quantidade de tempo que o CloudFront mantém um objeto no cache antes de enviar outra solicitação para a origem, você pode:
+ Defina os valores de TTL mínimo, máximo e padrão no comportamento de cache de uma distribuição do CloudFront. Você pode definir esses valores em uma [política de cache](controlling-the-cache-key.md) anexada ao comportamento de cache (recomendado) ou nas configurações de cache herdadas.
+ Inclua os cabeçalhos `Cache-Control` ou `Expires` nas respostas da origem. Esses cabeçalhos também ajudam a determinar por quanto tempo um navegador mantém um objeto no cache do navegador antes de enviar outra solicitação para o CloudFront.

A tabela a seguir explica como os cabeçalhos `Cache-Control` e `Expires` enviados da origem funcionam em conjunto com as configurações de TTL em um comportamento de cache para afetar o cache.


****  

| Cabeçalhos de origem | TTL mínimo = 0 | TTL mínimo > 0 | 
| --- | --- | --- | 
|  **A origem adiciona uma `Cache-Control: max-age` diretiva ao objeto**  |  **Armazenamento em cache do CloudFront** O CloudFront armazena objetos em cache pelo valor da diretiva `Cache-Control: max-age` ou pelo valor do TTL máximo do CloudFront, o que for menor. **Armazenamento em cache no navegador** Os navegadores armazenam em cache o objeto para o valor da diretiva `Cache-Control: max-age`.  |  **Armazenamento em cache do CloudFront** O armazenamento em cache do CloudFront depende dos valores do TTL mínimo e do TTL máximo do CloudFront e da diretiva `Cache-Control max-age`: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) **Armazenamento em cache no navegador** Os navegadores armazenam em cache o objeto para o valor da diretiva `Cache-Control: max-age`.  | 
|  **A origem não adiciona uma `Cache-Control: max-age` diretiva ao objeto**  |  **Armazenamento em cache do CloudFront** O CloudFront armazena em cache o objeto para o valor do TTL padrão do CloudFront. **Armazenamento em cache no navegador** Depende do navegador.  |  **Armazenamento em cache do CloudFront** O CloudFront armazena objetos em cache pelo valor do TTL máximo do CloudFront ou TLL padrão, o que for maior. **Armazenamento em cache no navegador** Depende do navegador.  | 
|  **A origem adiciona diretivas `Cache-Control: max-age` e `Cache-Control: s-maxage` ao objeto**  |  **Armazenamento em cache do CloudFront** O CloudFront armazena objetos em cache pelo valor da diretiva `Cache-Control: s-maxage` ou pelo valor do TTL máximo do CloudFront, o que for menor. **Armazenamento em cache no navegador** Os navegadores armazenam em cache o objeto para o valor da diretiva `Cache-Control max-age`.  |  **Armazenamento em cache do CloudFront** O armazenamento em cache do CloudFront depende dos valores do TTL mínimo e do TTL máximo do CloudFront e da diretiva `Cache-Control: s-maxage`: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) **Armazenamento em cache no navegador** Os navegadores armazenam em cache o objeto para o valor da diretiva `Cache-Control: max-age`.  | 
|  **A origem adiciona um cabeçalho `Expires` no objeto**  |  **Armazenamento em cache do CloudFront** O CloudFront armazena o objeto até a data no cabeçalho `Expires` ou para o valor do TTL máximo do CloudFront, o que ocorrer antes. **Armazenamento em cache no navegador** Os navegadores armazenam o objeto em cache até a data no cabeçalho `Expires`.  |  **Armazenamento em cache do CloudFront** O armazenamento em cache do CloudFront depende dos valores do TTL mínimo e máximo do CloudFront e do cabeçalho `Expires`: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) **Armazenamento em cache no navegador** Os navegadores armazenam o objeto em cache até a data e hora no `Expires` cabeçalho.  | 
|  **A origem adiciona as diretivas `Cache-Control: no-cache`, `no-store` e/ou `private` ao objeto**  |  O CloudFront e os navegadores respeitam os cabeçalhos.  |  **Armazenamento em cache do CloudFront** O CloudFront armazena em cache o objeto para o valor do TTL mínimo do CloudFront. [Veja o aviso abaixo desta tabela](#stale-if-error). **Armazenamento em cache no navegador** Os navegadores respeitam os cabeçalhos.  | 

**Atenção**  
Se seu TTL mínimo for maior que 0, o CloudFront usa o TTL mínimo da política de cache, mesmo que as diretivas `Cache-Control: no-cache`, `no-store` e/ou `private` estejam presentes nos cabeçalhos de origem.  
Se a origem for alcançável, o CloudFront obterá o objeto da origem e o retornará ao visualizador.
Se a origem estiver inacessível e o valor do TTL mínimo *ou* máximo for maior que 0, o CloudFront atenderá ao objeto obtido da origem anteriormente.
Para evitar esse comportamento, inclua a `Cache-Control: stale-if-error=0` diretiva com o objeto retornado da origem. Isso faz com que o CloudFront retorne um erro em resposta a solicitações futuras se a origem não for alcançável, em vez de retornar o objeto obtido da origem anteriormente.
O CloudFront não armazena em cache o código de status HTTP 501 (não implementado) de uma origem do S3 quando os cabeçalhos de origem incluem as diretivas `Cache-Control: no-cache`, `no-store` e/ou `private`. Esse é o comportamento padrão para uma origem do S3, mesmo que sua configuração de [TTL mínimo](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMinTTL) seja maior que 0.

Para mais informações sobre como alterar as configurações de distribuições usando o console do CloudFront, consulte [Atualizar uma distribuição](HowToUpdateDistribution.md). Para mais informações sobre como alterar as configurações de distribuições usando a API do CloudFront, consulte [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html).

## Adicionar cabeçalhos aos objetos usando o console do Amazon S3
<a name="ExpirationAddingHeadersInS3"></a>

Você pode adicionar o campo de cabeçalho `Cache-Control` ou `Expires` aos objetos do Amazon S3. Para fazer isso, modifique os campos de metadados do objeto.

**Como adicionar um campo de cabeçalho `Cache-Control` ou `Expires` aos objetos do Amazon S3**

1. Siga o procedimento na seção **Substituir metadados definidos pelo sistema** no tópico [Editar metadados de objetos no console do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-object-metadata.html) no *Guia do usuário do Amazon S3*.

1. Em **Key** (Chave), escolha o nome do cabeçalho que você está adicionando (**Cache-Control** ou **Expires**).

1. Em **Value** (Valor), insira um valor de cabeçalho. Por exemplo, para um cabeçalho `Cache-Control`, você pode inserir `max-age=86400`. Em `Expires`, você pode inserir uma data de expiração e hora, como `Wed, 30 Jun 2021 09:28:00 GMT`.

1. Siga o restante do procedimento para salvar as alterações de metadados.

# Conteúdo em cache com base em parâmetros de string de consulta
<a name="QueryStringParameters"></a>

Alguns aplicativos web usam query strings para enviar informações para a origem. Uma string de consulta é a parte de uma solicitação da web que aparece após um caractere `?`. Ela pode conter um ou mais parâmetros separados por caracteres `&`. No seguinte exemplo, a string de consulta inclui dois parâmetros, *color = red* e *size = grandes*:

`https://d111111abcdef8.cloudfront.net/images/image.jpg?color=red&size=large`

Para distribuições, você pode escolher se deseja que o CloudFront encaminhe strings de consulta para a origem e se deve armazenar o conteúdo em cache com base em todos os parâmetros ou em parâmetros selecionados. Por que isso pode ser útil? Considere o seguinte exemplo.

Imagine que seu site esteja disponível em cinco idiomas. A estrutura do diretório e os nomes de arquivo de todas as cinco versões do site são idênticos. Quando um usuário visualiza seu site, as solicitações encaminhadas para o CloudFront incluem um parâmetro de string de consulta de idioma com base no idioma escolhido do usuário. É possível configurar o CloudFront para encaminhar strings de consulta para a origem e para armazenamento em cache com base no parâmetro de idioma. Se você configurar o servidor da Web para retornar a versão de uma página correspondente ao idioma selecionado, o CloudFront armazenará em cache a versão de cada idioma separadamente, com base no valor do parâmetro de string de consulta do idioma.

Neste exemplo, se a página principal do site for `main.html`, as cinco solicitações a seguir farão com que o CloudFront armazene `main.html` cinco vezes em cache, uma vez para cada valor do parâmetro da string de consulta do idioma:
+ `https://d111111abcdef8.cloudfront.net/main.html?language=de`
+ `https://d111111abcdef8.cloudfront.net/main.html?language=en`
+ `https://d111111abcdef8.cloudfront.net/main.html?language=es`
+ `https://d111111abcdef8.cloudfront.net/main.html?language=fr`
+ `https://d111111abcdef8.cloudfront.net/main.html?language=jp`

Observe o seguinte:
+ Alguns servidores HTTP não processam parâmetros de query string e, portanto, não retornam diferentes versões de um objeto com base nos valores de parâmetro. Para essas origens, se você configurar o CloudFront para encaminhar parâmetros de string de consulta para a origem, o CloudFront armazenará em cache com base nos valores dos parâmetros, mesmo que a origem retorne versões idênticas do objeto ao CloudFront para cada valor de parâmetro.
+ Para que os parâmetros de string de consulta funcionem conforme descrito no exemplo acima com os idiomas, é necessário usar o caractere `&` como delimitador entre os parâmetros da string de consulta. Se você usar um delimitador diferente, poderá obter resultados inesperados, dependendo dos parâmetros que especificar para o CloudFront usar como base para o armazenamento em cache, e a ordem em que os parâmetros serão exibidos na string de consulta.

  Os exemplos a seguir mostram o que acontece quando você usa um delimitador diferente e configura o CloudFront para armazenamento em cache com base no parâmetro `color`: 
  + Na solicitação a seguir, o CloudFront armazena o conteúdo em cache com base no valor do parâmetro `color`, mas interpreta o valor como *red;size=large*:

    `https://d111111abcdef8.cloudfront.net/images/image.jpg?color=red;size=large`
  + Na solicitação a seguir, o CloudFront armazena o conteúdo em cache, mas não baseia o armazenamento em cache nos parâmetros da string de consulta. Isso ocorre porque você configurou o CloudFront para armazenamento em cache com base no parâmetro `color`, mas ele interpreta a seguinte string como contendo apenas um parâmetro `size` com um valor de *large;color=red*:

    `https://d111111abcdef8.cloudfront.net/images/image.jpg?size=large;color=red`

É possível configurar o CloudFront para realizar uma destas ações:
+ Não encaminhar query strings para a origem. Se você não encaminhar strings de consulta, o CloudFront não armazenará em cache com base nos parâmetros da string de consulta.
+ Encaminhar query strings para a origem e armazenar em cache com base em todos os parâmetros na query string.
+ Encaminhar query strings para a origem e armazenar em cache com base em parâmetros específicos na query string.

Para obter mais informações, consulte [Otimizar o armazenamento em cache](#query-string-parameters-optimizing-caching).

**Topics**
+ [

## Configurações do console e da API para encaminhamento e armazenamento de strings de consulta em cache
](#query-string-parameters-console)
+ [

## Otimizar o armazenamento em cache
](#query-string-parameters-optimizing-caching)
+ [

## Parâmetros de string de consulta e logs padrão do CloudFront (logs de acesso)
](#query-string-parameters-access-logs)

## Configurações do console e da API para encaminhamento e armazenamento de strings de consulta em cache
<a name="query-string-parameters-console"></a>

Quando você cria uma distribuição no console do CloudFront, o CloudFront configura o encaminhamento e o armazenamento em cache da string de consulta para você com base no seu tipo de origem. Opcionalmente, você pode editar essas configurações manualmente. Para obter mais informações, consulte as configurações a seguir no [Referência de configurações de todas as distribuições](distribution-web-values-specify.md).
+ [Encaminhamento e armazenamento em cache de strings de consulta](DownloadDistValuesCacheBehavior.md#DownloadDistValuesQueryString)
+ [Lista de permissões de strings de consulta](DownloadDistValuesCacheBehavior.md#DownloadDistValuesQueryStringAllowlist)

Para configurar o encaminhamento e o armazenamento em cache de strings de consulta com a API do CloudFront, consulte [CachePolicy](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CachePolicy.html) e [OriginRequestPolicy](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_OriginRequestPolicy.html) na *Referência de API do Amazon CloudFront*.

## Otimizar o armazenamento em cache
<a name="query-string-parameters-optimizing-caching"></a>

Ao configurar o CloudFront para armazenamento em cache com base nos parâmetros da string de consulta, siga seguir as etapas a seguir para reduzir o número de solicitações que o CloudFront encaminha para a origem. Quando os pontos de presença do CloudFront fornecem objetos, a carga no servidor de origem e a latência são reduzidas, pois os objetos são fornecidos de locais mais próximos dos usuários.

**Armazenamento em cache baseado apenas em parâmetros para os quais a origem retorna diferentes versões de um objeto**  
Para cada parâmetro da string de consulta encaminhado pela aplicação Web para o CloudFront, o CloudFront encaminha solicitações para cada valor de parâmetro para a origem e armazena em cache uma versão separada do objeto para cada valor de parâmetro. Isso será verdadeiro mesmo se a sua origem sempre retornar o mesmo objeto, independentemente do valor do parâmetro. Para vários parâmetros, o número de solicitações e o número de objetos se multiplicam.  
Recomendamos configurar o CloudFront para armazenamento em cache com base apenas nos parâmetros da string de consulta para os quais a origem retorna diferentes versões, e considerar cuidadosamente os méritos do armazenamento em cache com base em cada parâmetro. Por exemplo, imagine que você tem um site de varejo. Você tem fotos de uma jaqueta em seis cores diferentes, e ela tem 10 opções de tamanhos diferentes. As imagens que você tem da jaqueta mostram a cores diferentes, mas não os tamanhos. Para otimizar o armazenamento em cache, configure o CloudFront para armazenamento em cache apenas com base no parâmetro de cor, não de tamanho. Isso aumenta a probabilidade de o CloudFront atender a uma solicitação do cache, melhorando a performance e reduzindo a carga na origem.

**Sempre liste os parâmetros na mesma ordem**  
A ordem dos parâmetros é importante em query strings. No exemplo a seguir, as query strings são idênticas, exceto pelo fato de os parâmetros estarem em ordem diferente. Isso fará com que o CloudFront encaminhe duas solicitações separadas de image.jpg para a origem e armazene duas versões separadas do objeto em cache:  
+ `https://d111111abcdef8.cloudfront.net/images/image.jpg?color=red&size=large`
+ `https://d111111abcdef8.cloudfront.net/images/image.jpg?size=large&color=red`
Recomendamos que você sempre indique os nomes de parâmetro na mesma ordem, como em ordem alfabética.

**Sempre use a mesma letra (maiúscula ou minúscula) para os nomes e valores de parâmetro**  
O CloudFront diferencia letras maiúsculas de minúsculas de nomes e valores de parâmetros ao armazenar em cache com base nos parâmetros da string de consulta. No exemplo a seguir, as query strings são idênticas, exceto pelo formato das letras nos nomes e valores do parâmetro. Isso faz com que o CloudFront encaminhe quatro solicitações separadas de image.jpg para a origem e armazene quatro versões separadas do objeto em cache:  
+ `https://d111111abcdef8.cloudfront.net/images/image.jpg?color=red`
+ `https://d111111abcdef8.cloudfront.net/images/image.jpg?color=Red`
+ `https://d111111abcdef8.cloudfront.net/images/image.jpg?Color=red`
+ `https://d111111abcdef8.cloudfront.net/images/image.jpg?Color=Red`
Recomendamos que você use letras maiúsculas/minúsculas de forma consistente nos nomes e valores de parâmetro, como todas as letras minúsculas.

**Não use nomes de parâmetro em conflito com signed URLs**  
Se você estiver usando signed URLs para restringir o acesso ao conteúdo (se tiver adicionado assinantes confiáveis à distribuição), o CloudFront removerá os seguintes parâmetros da string de consulta antes de encaminhar o restante do URL para a origem:  
+ `Expires`
+ `Key-Pair-Id`
+ `Policy`
+ `Signature`
Ao usar signed URLs e quiser configurar o CloudFront para encaminhar strings de consulta para a origem, seus próprios parâmetros da string de consulta não podem ser denominados `Expires`, `Key-Pair-Id`, `Policy` ou `Signature`.

## Parâmetros de string de consulta e logs padrão do CloudFront (logs de acesso)
<a name="query-string-parameters-access-logs"></a>

Se você habilitar o registro em log, o CloudFront registrará o URL completo em log, incluindo os parâmetros da string de consulta. Isso será verdadeiro independentemente de você ter configurado o CloudFront para encaminhar strings de consulta para a origem. Para obter mais informações sobre o log do CloudFront, consulte [Logs de acesso (logs padrão)](AccessLogs.md).

# Conteúdo em cache com base em cookies
<a name="Cookies"></a>

Por padrão, o CloudFront não considera cookies ao processar solicitações e respostas, nem ao armazenar os objetos em cache em pontos de presença. Se o CloudFront receber duas solicitações idênticas, exceto pelo que está no cabeçalho `Cookie`, por padrão, o CloudFront tratará as solicitações como idênticas e retornará o mesmo objeto para as duas solicitações.

É possível configurar o CloudFront para encaminhar à origem alguns ou todos os cookies em solicitações de visualizador e armazenar em cache versões separadas dos objetos com base nos valores de cookie encaminhados. Ao fazer isso, o CloudFront usa alguns ou todos os cookies das solicitações de visualizador (todos os que estiverem configurados para serem encaminhados) a fim de identificar exclusivamente um objeto no cache.

Por exemplo, imagine que as solicitações de `locations.html` contêm um cookie `country` com um valor de `uk` ou `fr`. Ao configurar o CloudFront para armazenar os objetos em cache com base no valor do cookie `country`, o CloudFront encaminhará as solicitações de `locations.html` para a origem e incluirá o cookie `country` e os respectivos valores. Sua origem retornará `locations.html`, e o CloudFront armazenará o objeto em cache uma vez para solicitações em que o valor do cookie `country` é `uk` e uma vez para solicitações em que o valor for `fr`.

**Importante**  
O Amazon S3 e alguns servidores HTTP não processam cookies. Não configure o CloudFront para encaminhar cookies a uma origem que não processe cookies ou que não varie a resposta com base em cookies. Isso pode fazer com que o CloudFront encaminhe mais solicitações para a origem para o mesmo objeto, o que reduz a performance e aumenta a carga na origem. Ao considerar o exemplo anterior, se sua origem não processar o cookie `country` ou sempre retornar a mesma versão de `locations.html` para o CloudFront, independentemente do valor do cookie `country`, não configure o CloudFront para encaminhar esse cookie.  
Por outro lado, se a origem personalizada depender de um cookie específico ou enviar respostas diferentes com base em um cookie, configure o CloudFront para encaminhar esse cookie para a origem. Caso contrário, o CloudFront remove o cookie antes de encaminhar a solicitação para a origem.

Para configurar o encaminhamento de cookies, atualize o comportamento de cache da sua distribuição. Para obter mais informações sobre comportamentos de cache, consulte [Configurações de comportamento de cache](DownloadDistValuesCacheBehavior.md), especificamente as seções [Cookies progressivos](DownloadDistValuesCacheBehavior.md#DownloadDistValuesForwardCookies) e [Lista de permissões de cookies](DownloadDistValuesCacheBehavior.md#DownloadDistValuesAllowlistCookies).

Você pode configurar cada comportamento de cache para realizar uma das seguintes ações:
+ **Encaminhar todos os cookies para a origem:** o CloudFront inclui todos os cookies enviados pelo visualizador ao encaminhar solicitações para a origem. Quando a origem retorna uma resposta, o CloudFront armazena a resposta em cache usando os nomes e os valores de cookie na solicitação do visualizador. Se a resposta da origem incluir cabeçalhos `Set-Cookie`, o CloudFront os retornará ao visualizador com o objeto solicitado. O CloudFront também armazena os cabeçalhos em cache `Set-Cookie` com o objeto retornado da origem e envia esses cabeçalhos `Set-Cookie` para visualizadores em todos os acertos do cache.
+ **Encaminhar um conjunto de cookies especificados:** o CloudFront remove todos os cookies enviados pelo visualizador que não estejam na lista de permissões antes de encaminhar uma solicitação para a origem. O CloudFront armazena a resposta em cache usando os nomes e valores de cookies na lista na solicitação do visualizador. Se a resposta da origem incluir cabeçalhos `Set-Cookie`, o CloudFront os retornará ao visualizador com o objeto solicitado. O CloudFront também armazena os cabeçalhos em cache `Set-Cookie` com o objeto retornado da origem e envia esses cabeçalhos `Set-Cookie` para visualizadores em todos os acertos do cache.

  Para obter informações sobre como especificar curingas em nomes de cookies, consulte [Lista de permissões de cookies](DownloadDistValuesCacheBehavior.md#DownloadDistValuesAllowlistCookies).

  Para saber a cota atual do número de nomes de cookies que você pode encaminhar para cada comportamento de cache ou para solicitar uma cota maior, consulte [Cotas em cadeias de consulta (configurações de cache herdadas)](cloudfront-limits.md#limits-allowlisted-query-strings).
+ **Não encaminhar cookies para a origem:** o CloudFront não armazena os objetos em cache com base no cookie enviado pelo visualizador. Além disso, o CloudFront remove os cookies antes de encaminhar as solicitações para a origem e remove os cabeçalhos `Set-Cookie` das respostas antes de retorná-las aos visualizadores. Como essa não é uma maneira ideal de usar seus recursos de origem, ao selecionar esse comportamento de cache, certifique-se de que sua origem não inclua cookies nas respostas de origem por padrão.

Observações sobre como especificar os cookies que você deseja encaminhar:

**Logs de acesso**  
Se você configurar o CloudFront para registrar solicitações e cookies em log, o CloudFront registrará todos os cookies e atributos de cookie em log, mesmo que você configure o CloudFront para não encaminhar cookies para a origem ou configure o CloudFront para encaminhar somente cookies específicos. Para obter mais informações sobre o log do CloudFront, consulte [Logs de acesso (logs padrão)](AccessLogs.md).

**Diferenciação de letras maiúsculas e minúsculas**  
Os nomes e valores de cookie diferenciam letras maiúsculas e minúsculas. Por exemplo, se o CloudFront estiver configurado para encaminhar todos os cookies, e duas solicitações de visualizador para o mesmo objeto tiverem cookies idênticos, apenas com diferenças de maiúsculas e minúsculas, o CloudFront armazenará o objeto em cache duas vezes.

**O CloudFront classifica cookies**  
Se o CloudFront estiver configurado para encaminhar cookies (todos ou um subconjunto), ele classificará os cookies na ordem natural pelo nome do cookie antes de encaminhar a solicitação para a origem.  
 Nomes de cookies que comecem com o caractere `$` não são aceitos. O CloudFront removerá o cookie antes de encaminhar a solicitação para a origem. É possível remover o caractere `$` ou especificar outro caractere no início do nome do cookie.

**`If-Modified-Since` e da `If-None-Match`**  
As solicitações condicionais `If-Modified-Since` e `If-None-Match` não são compatíveis com o CloudFront quando ele estiver configurado para encaminhar cookies (todos ou um subconjunto).

**O formato padrão do par nome-valor é obrigatório**  
O CloudFront encaminhará um cabeçalho de cookie somente se o valor estiver em conformidade com o [formato padrão do par nome-valor](https://tools.ietf.org/html/rfc6265#section-4.1.1), por exemplo: `"Cookie: cookie1=value1; cookie2=value2"`

**Desativar o armazenamento em cache de cabeçalhos `Set-Cookie`**  
Se o CloudFront estiver configurado para encaminhar cookies para a origem (sejam todos ou alguns específicos), ele também armazenará em cache os cabeçalhos `Set-Cookie` recebidos na resposta da origem. O CloudFront inclui esses cabeçalhos `Set-Cookie` em sua resposta ao visualizador original e também os inclui em respostas subsequentes que são fornecidas do cache do CloudFront.  
Se você quiser receber cookies na origem, mas não quiser que o CloudFront armazene os cabeçalhos `Set-Cookie` nas respostas da origem, configure a origem para adicionar um cabeçalho `Cache-Control` com uma diretiva `no-cache` que especifique `Set-Cookie` como um nome de campo. Por exemplo: `Cache-Control: no-cache="Set-Cookie"`. Para obter mais informações, consulte [Response Cache-Control Directives](https://tools.ietf.org/html/rfc7234#section-5.2.2) no padrão *Hypertext Transfer Protocol (HTTP/1.1): Caching*.

**Tamanho máximo dos nomes de cookies**  
Se você configurar o CloudFront para encaminhar cookies específicos para sua origem, o número total de bytes em todos os nomes de cookies que o CloudFront foi configurado para encaminhar não poderá exceder 512 menos o número de cookies que serão encaminhados. Por exemplo, se você configurar o CloudFront para encaminhar 10 cookies para a origem, o tamanho total dos nomes de todos eles não poderá ultrapassar 502 bytes (512 a 10).  
Se você configurar o CloudFront para encaminhar todos os cookies para a origem, o tamanho dos nomes dos cookies não importará.

Para obter informações sobre como usar o console do CloudFront para atualizar uma distribuição para que o CloudFront encaminhe cookies para a origem, consulte [Atualizar uma distribuição](HowToUpdateDistribution.md). Para obter informações sobre como usar a API do CloudFront para atualizar uma distribuição, consulte [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) na *Referência da API do Amazon CloudFront*.

# Conteúdo em cache com base nos cabeçalhos de solicitação
<a name="header-caching"></a>

O CloudFront permite que você escolha se quer que o CloudFront encaminhe cabeçalhos para a origem e armazene em cache versões distintas de um objeto especificado com base nos valores do cabeçalho nas solicitações do visualizador. Isso permite fornecer diferentes versões do seu conteúdo com base no dispositivo que o usuário estiver usando, a localização dele, o idioma usado por ele e uma variedade de outros critérios.

**Topics**
+ [

## Visão geral de cabeçalhos e distribuições
](#header-caching-web)
+ [

## Selecionar os cabeçalhos para basear o armazenamento em cache
](#header-caching-web-selecting)
+ [

## Configurar o CloudFront para respeitar as configurações do CORS
](#header-caching-web-cors)
+ [

## Configurar o armazenamento em cache com base no tipo de dispositivo
](#header-caching-web-device)
+ [

## Configurar o armazenamento em cache com base no idioma do visualizador
](#header-caching-web-language)
+ [

## Configurar o armazenamento em cache com base no local do visualizador
](#header-caching-web-location)
+ [

## Configurar o armazenamento em cache com base no protocolo da solicitação
](#header-caching-web-protocol)
+ [

## Configurar o armazenamento em cache para arquivos compactados
](#header-caching-web-compressed)
+ [

## Como o armazenamento em cache com base em cabeçalhos afeta a performance
](#header-caching-web-performance)
+ [

## Como a letra e os valores do cabeçalho afetam o armazenamento em cache
](#header-caching-web-case)
+ [

## Cabeçalhos que o CloudFront retorna ao visualizador
](#header-caching-web-response)

## Visão geral de cabeçalhos e distribuições
<a name="header-caching-web"></a>

Por padrão, o CloudFront não considera cabeçalhos ao armazenar seus objetos em cache em pontos de presença. Se a origem retornar dois objetos e seus valores nos cabeçalhos de solicitação forem diferentes, o CloudFront armazenará apenas uma versão do objeto em cache.

É possível configurar o CloudFront para encaminhar cabeçalhos para a origem, o que faz com que o CloudFront armazene várias versões de um objeto em cache com base nos valores de um ou mais cabeçalhos de solicitação. Para configurar o CloudFront para armazenamento em cache os objetos baseados nos valores de cabeçalhos específicos, você especifica as configurações de comportamento do cache para a sua distribuição. Para obter mais informações, consulte [ Cache baseado em cabeçalhos de solicitação selecionados](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesForwardHeaders).

Por exemplo, imagine que as solicitações do visualizador de `logo.jpg` contêm um cabeçalho `Product` personalizado com um valor de `Acme` ou `Apex`. Ao configurar o CloudFront para armazenar seus objetos em cache com base no valor do cabeçalho `Product`, o CloudFront encaminha solicitações de `logo.jpg` para a origem e inclui o cabeçalho `Product` e os valores de cabeçalho. O CloudFront armazena `logo.jpg` em cache uma vez para solicitações em que o valor do cabeçalho `Product` é `Acme`, e uma vez para solicitações em que o valor é `Apex`.

Você pode configurar cada comportamento de cache em uma distribuição para executar uma das seguintes ações: 
+ Encaminhar todos os cabeçalhos para sua origem
**nota**  
**Para configurações de cache herdadas**: se você configurar o CloudFront para encaminhar todos os cabeçalhos para a origem, ele não armazenará em cache os objetos associados a esse comportamento de cache. Em vez disso, ele enviará todas as solicitações para a origem.
+ Encaminhar uma lista específica de cabeçalhos. O CloudFront armazena seus objetos em cache com base nos valores de todos os cabeçalhos especificados. O CloudFront também encaminha os cabeçalhos encaminhados por ele por padrão, mas armazena seus objetos em cache com base apenas nos cabeçalhos especificados. 
+ Encaminhe somente os cabeçalhos padrão. Nessa configuração, o CloudFront não armazena seus objetos em cache com base nos valores dos cabeçalhos de solicitação.

Para saber a cota atual do número de cabeçalhos que você pode encaminhar para cada comportamento de cache ou para solicitar uma cota maior, consulte [Cotas para cabeçalhos](cloudfront-limits.md#limits-custom-headers).

Para obter informações sobre como usar o console do CloudFront para atualizar uma distribuição para que o CloudFront encaminhe cabeçalhos para a origem, consulte [Atualizar uma distribuição](HowToUpdateDistribution.md). Para obter informações sobre como usar a API do CloudFront para atualizar uma distribuição existente, consulte [Atualizar distribuição](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) na *Referência da API do Amazon CloudFront*.

## Selecionar os cabeçalhos para basear o armazenamento em cache
<a name="header-caching-web-selecting"></a>

Os cabeçalhos que podem ser encaminhados para a origem nos quais o CloudFront baseia o armazenamento em cache dependem de se a origem é um bucket do Amazon S3 ou uma origem personalizada.
+ **Amazon S3:** é possível configurar o CloudFront para encaminhar e armazenar os objetos em cache com base em vários cabeçalhos específicos (veja a lista de exceções a seguir). No entanto, recomendamos que você evite encaminhar cabeçalhos com uma origem do Amazon S3, a menos que você precise implementar o compartilhamento de recursos de origem cruzada (CORS) ou queira personalizar o conteúdo usando o Lambda@Edge em eventos voltados para a origem.
  + Para configurar o CORS, você deve encaminhar cabeçalhos que permitem que o CloudFront distribua conteúdo para sites habilitados para compartilhamento de recursos de origem cruzada (CORS). Para obter mais informações, consulte [Configurar o CloudFront para respeitar as configurações do CORS](#header-caching-web-cors). 
  + Para personalizar o conteúdo usando cabeçalhos que você encaminha para a origem do Amazon S3, escreva e adicione funções do Lambda@Edge e associe-as à sua distribuição do CloudFront a ser acionada por um evento voltado para origem. Para obter mais informações sobre como trabalhar com cabeçalhos para personalizar o conteúdo, consulte [Personalizar o conteúdo por cabeçalhos de país ou tipo de dispositivo: exemplos](lambda-examples.md#lambda-examples-redirecting-examples).

    Evite encaminhar os cabeçalhos que não estiver usando para personalizar o conteúdo, pois o encaminhamento de cabeçalhos extras pode reduzir a proporção de acertos do cache. Ou seja, o CloudFront não poderá atender a muitas solicitações de caches de borda como uma proporção de todas as solicitações.
+ **Origem personalizada: ** é possível configurar o CloudFront para armazenamento em cache com base no valor de qualquer cabeçalho de solicitação, com exceção de:
  + `Connection`
  + `Cookie`: se você quiser encaminhar e armazenar em cache com base em cookies, use uma configuração separada na distribuição. Para obter mais informações, consulte [Conteúdo em cache com base em cookies](Cookies.md).
  + `Host (for Amazon S3 origins)`
  + `Proxy-Authorization`
  + `TE`
  + `Upgrade`

  É possível configurar o CloudFront para armazenar os objetos em cache com base nos valores dos cabeçalhos `Date` e `User-Agent`, mas não é recomendável fazê-lo. Esses cabeçalhos têm vários valores possíveis, e o armazenamento em cache com base nesses valores pode fazer com que o CloudFront encaminhe significativamente mais solicitações para a origem.

Para obter uma lista completa dos cabeçalhos de solicitação HTTP e a maneira como o CloudFront os processa, consulte [Cabeçalhos de solicitação HTTP e comportamento do CloudFront (origens do Amazon S3 e personalizadas)](RequestAndResponseBehaviorCustomOrigin.md#request-custom-headers-behavior).

## Configurar o CloudFront para respeitar as configurações do CORS
<a name="header-caching-web-cors"></a>

Se você habilitou o compartilhamento de recursos entre origens (CORS) em um bucket do Amazon S3 ou uma origem personalizada, escolha os cabeçalhos específicos a serem encaminhados, para respeitar as configurações do CORS. Os cabeçalhos que você precisa encaminhar diferem dependendo da origem (Amazon S3 ou personalizada) e de se você quer armazenar respostas `OPTIONS`.

**Amazon S3**
+ Se quiser que as respostas `OPTIONS` sejam armazenadas em cache, faça o seguinte:
  + Escolha as opções para configurações de comportamento de cache padrão que permitem o armazenamento em cache de respostas `OPTIONS`. 
  + Configure o CloudFront para encaminhar os seguintes cabeçalhos: `Origin`, `Access-Control-Request-Headers` e `Access-Control-Request-Method`.
+ Se não quiser que as respostas `OPTIONS` sejam armazenadas em cache, configure o CloudFront para encaminhar o cabeçalho `Origin` junto com todos os outros cabeçalhos requeridos pela origem (por exemplo, `Access-Control-Request-Headers`, `Access-Control-Request-Method` ou outros).

**Origens personalizadas**: encaminhe o cabeçalho `Origin` com todos os outros cabeçalhos requeridos pela origem.

Para configurar o CloudFront para armazenamento em cache de respostas com base no CORS, configure-o para encaminhar cabeçalhos usando uma política de cache. Para obter mais informações, consulte [Controlar a chave de cache com uma política](controlling-the-cache-key.md).

Para obter mais informações sobre o CORS e o Amazon S3, consulte [Uso de compartilhamento de recursos entre origens (CORS)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/cors.html) no *Guia do usuário do Amazon Simple Storage Service*.

## Configurar o armazenamento em cache com base no tipo de dispositivo
<a name="header-caching-web-device"></a>

Para que o CloudFront armazene em cache diferentes versões de seus objetos com base no dispositivo que um usuário está usando para visualizar seu conteúdo, configure o CloudFront para encaminhar os cabeçalhos aplicáveis para a origem personalizada:
+ `CloudFront-Is-Desktop-Viewer`
+ `CloudFront-Is-Mobile-Viewer`
+ `CloudFront-Is-SmartTV-Viewer`
+ `CloudFront-Is-Tablet-Viewer`

Com base no valor do cabeçalho `User-Agent`, o CloudFront define o valor desses cabeçalhos como `true` ou `false` antes de encaminhar a solicitação para a origem. Se o dispositivo se encaixar em mais de uma categoria, mais de um valor poderá ser `true`. Por exemplo, para alguns tablets, o CloudFront pode definir tanto `CloudFront-Is-Mobile-Viewer` quanto `CloudFront-Is-Tablet-Viewer` como `true`.

## Configurar o armazenamento em cache com base no idioma do visualizador
<a name="header-caching-web-language"></a>

Se você quiser que o CloudFront armazene diferentes versões dos objetos em cache com base no idioma especificado na solicitação, configure o CloudFront para encaminhar o cabeçalho `Accept-Language` para a origem.

## Configurar o armazenamento em cache com base no local do visualizador
<a name="header-caching-web-location"></a>

Se você quiser que o CloudFront armazene em cache diferentes versões de seus objetos com base no país de origem da solicitação, configure-o para encaminhar o cabeçalho `CloudFront-Viewer-Country` para a origem. O CloudFront converte automaticamente o endereço IP da origem da solicitação em um código de país de duas letras. Para obter uma lista de códigos de país fácil de usar, classificável por código e nome do país, consulte a entrada da Wikipédia [ISO 3166-1 alfa-2](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2).

## Configurar o armazenamento em cache com base no protocolo da solicitação
<a name="header-caching-web-protocol"></a>

Se você quiser que o CloudFront armazene em cache diferentes versões de seus objetos com base no protocolo da solicitação, HTTP ou HTTPS, configure o CloudFront para encaminhar o cabeçalho `CloudFront-Forwarded-Proto` para a origem.

## Configurar o armazenamento em cache para arquivos compactados
<a name="header-caching-web-compressed"></a>

Se a origem for compatível com compactação Brotli, você poderá armazenar em cache com base no cabeçalho `Accept-Encoding`. Configure o armazenamento em cache com base em `Accept-Encoding` somente se a origem fornecer conteúdo diferente com base no cabeçalho.

## Como o armazenamento em cache com base em cabeçalhos afeta a performance
<a name="header-caching-web-performance"></a>

Ao configurar o CloudFront para armazenamento em cache com base em um ou mais cabeçalhos, e os cabeçalhos tiverem mais de um valor possível, o CloudFront encaminhará mais solicitações para o servidor de origem para o mesmo objeto. Isso reduz a performance e aumenta a carga no servidor de origem. Se o servidor de origem retornar o mesmo objeto, independentemente do valor de um determinado cabeçalho, recomendamos não configurar o CloudFront para armazenamento em cache com base nesse cabeçalho. 

Se você configurar o CloudFront para encaminhar mais de um cabeçalho, a ordem dos cabeçalhos nas solicitações do visualizador não afetará o armazenamento em cache, desde que os valores sejam os mesmos. Por exemplo, se uma solicitação contiver os cabeçalhos A:1,B:2 e outra solicitação contive B:2,A:1, o CloudFront armazenará em cache apenas uma cópia do objeto.

## Como a letra e os valores do cabeçalho afetam o armazenamento em cache
<a name="header-caching-web-case"></a>

Quando o CloudFront armazena em cache com base nos valores de cabeçalhos, ele não diferencia maiúsculas e minúsculas do nome do cabeçalho, mas diferencia maiúsculas e minúsculas do valor do cabeçalho:
+ Se as solicitações do visualizador incluírem `Product:Acme` e `product:Acme`, o CloudFront armazenará um objeto em cache apenas uma vez. A única diferença entre eles é a letra (maiúscula/minúscula) do nome de cabeçalho, que não afeta o armazenamento em cache.
+ Se as solicitações do visualizador incluírem `Product:Acme` e `Product:acme`, o CloudFront armazenará um objeto duas vezes em cache, pois o valor será `Acme` em algumas solicitações e `acme` em outras.

## Cabeçalhos que o CloudFront retorna ao visualizador
<a name="header-caching-web-response"></a>

Configurar o CloudFront para encaminhar e armazenar cabeçalhos em cache não afeta quais cabeçalhos o CloudFront retorna ao visualizador. O CloudFront retorna todos os cabeçalhos obtidos da origem, com algumas exceções. Para obter mais informações, consulte o tópico aplicável:
+ **Origens do Amazon S3:** consulte [Cabeçalhos de resposta HTTP removidos ou atualizados pelo CloudFront](RequestAndResponseBehaviorS3Origin.md#response-s3-removed-headers).
+ **Origens personalizadas:** consulte [Cabeçalhos de resposta HTTP que o CloudFront remove ou substitui](RequestAndResponseBehaviorCustomOrigin.md#ResponseCustomRemovedHeaders).