Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Caching e disponibilità
È possibile utilizzare CloudFront per ridurre il numero di richieste a cui il server di origine deve rispondere direttamente. Con la CloudFront memorizzazione nella cache, più oggetti vengono serviti dalle CloudFront edge location, più vicine agli utenti. Questo riduce il carico e la latenza sul server di origine.
Maggiore è il numero di richieste che CloudFront possono essere inviate dalle cache edge, minore è il numero di richieste di visualizzazione che CloudFront devono essere inoltrate all'origine per ottenere la versione più recente o una versione unica di un oggetto. Per ottimizzare CloudFront in modo da inviare il minor numero possibile di richieste alla tua origine, prendi in considerazione l'utilizzo di CloudFront Origin Shield. Per ulteriori informazioni, consulta [Usa Amazon CloudFront Origin Shield](origin-shield.md).
La proporzione di richieste che vengono servite direttamente dalla CloudFront cache rispetto a tutte le richieste è chiamata *rapporto di successo della cache*. Nella CloudFront console puoi visualizzare la percentuale di richieste degli utenti che risultano positive, mancate ed errori. Per ulteriori informazioni, consulta [Visualizza i report sulle statistiche CloudFront della cache](cache-statistics.md).
La percentuale di riscontri nella cache è influenzata da diversi fattori. È possibile modificare la configurazione di CloudFront distribuzione per migliorare il rapporto di accesso alla cache seguendo le istruzioni riportate in[Aumentare la percentuale di richieste che vengono servite direttamente dalle CloudFront cache (rapporto di successo della cache)](cache-hit-ratio.md).
Per ulteriori informazioni su come aggiungere e rimuovere il contenuto che desideri CloudFront pubblicare, consulta[Aggiungere, rimuovere o sostituire i contenuti che vengono CloudFront distribuiti](AddRemoveReplaceObjects.md).
**Topics**
+ [
# Aumentare la percentuale di richieste che vengono servite direttamente dalle CloudFront cache (rapporto di successo della cache)
](cache-hit-ratio.md)
+ [
# Usa Amazon CloudFront Origin Shield
](origin-shield.md)
+ [
# Ottimizza l'alta disponibilità con il failover di CloudFront origine
](high_availability_origin_failover.md)
+ [
# Gestione della durata di permanenza dei contenuti nella cache (scadenza)
](Expiration.md)
+ [
# Memorizzazione nella cache di contenuti basati su parametri delle stringhe di query
](QueryStringParameters.md)
+ [
# Caching dei contenuti basati su cookie
](Cookies.md)
+ [
# Caching dei contenuti in base alle intestazioni di richiesta
](header-caching.md)
# Aumentare la percentuale di richieste che vengono servite direttamente dalle CloudFront cache (rapporto di successo della cache)
È possibile migliorare le prestazioni aumentando la percentuale di richieste dei visualizzatori che vengono servite direttamente dalla CloudFront cache anziché rivolgersi ai server di origine per la raccolta dei contenuti. Questo è noto come miglioramento del tasso di occorrenza nella cache.
Le seguenti sezioni illustrano come migliorare il tuo numero di riscontri nella cache.
**Topics**
+ [
## Specificate per quanto tempo CloudFront i vostri oggetti vengono memorizzati nella cache
](#cache-hit-ratio-duration)
+ [
## Utilizzo di Origin Shield
](#cache-hit-ratio-use-origin-shield)
+ [
## Caching Basato su parametri della stringa di query
](#cache-hit-ratio-query-string-parameters)
+ [
## Caching in base ai valori dei cookie
](#cache-hit-ratio-cookies)
+ [
## Caching in base alle intestazioni di richiesta
](#cache-hit-ratio-request-headers)
+ [
## Rimuovere l’intestazione `Accept-Encoding` quando la compressione non è necessaria
](#cache-hit-ratio-remove-accept-encoding)
+ [
## Distribuire contenuti multimediali tramite HTTP
](#cache-hit-ratio-http-streaming)
## Specificate per quanto tempo CloudFront i vostri oggetti vengono memorizzati nella cache
Per incrementare il numero di riscontri nella cache, puoi configurare il server di origine per aggiungere una direttiva [Cache-Control max-age](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control) ai tuoi oggetti e specificare il valore pratico più lungo per `max-age`. Più breve è la durata della cache, più frequentemente vengono CloudFront inviate richieste all'origine per determinare se un oggetto è cambiato e per ottenere la versione più recente. È possibile integrare `max-age` con le direttive `stale-while-revalidate` e `stale-if-error` per migliorare ulteriormente il rapporto di occorrenza nella cache in determinate condizioni. Per ulteriori informazioni, consulta [Gestione della durata di permanenza dei contenuti nella cache (scadenza)](Expiration.md).
## Utilizzo di Origin Shield
CloudFront Origin Shield può aiutarti a migliorare il rapporto di accesso alla cache della tua CloudFront distribuzione, poiché fornisce un ulteriore livello di caching davanti all'origine. Quando usi Origin Shield, tutte le richieste provenienti da tutti i livelli CloudFront di memorizzazione nella cache all'origine provengono da un'unica posizione. CloudFront può recuperare ogni oggetto utilizzando una singola richiesta di origine da Origin Shield e tutti gli altri livelli della CloudFront cache (edge location e [cache edge regionali](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches)) possono recuperare l'oggetto da Origin Shield.
Per ulteriori informazioni, consulta [Usa Amazon CloudFront Origin Shield](origin-shield.md).
## Caching Basato su parametri della stringa di query
Se configuri la cache CloudFront in base ai parametri della stringa di query, puoi migliorare la memorizzazione nella cache se esegui le seguenti operazioni:
+ CloudFront Configurate in modo da inoltrare solo i parametri della stringa di query per i quali l'origine restituirà oggetti univoci.
+ Utilizza la stessa combinazione di maiuscole e minuscole per tutte le istanze dello stesso parametro. Ad esempio, se una richiesta contiene `parameter1=A` e un'altra contiene`parameter1=a`, CloudFront inoltra richieste separate all'origine quando una richiesta contiene `parameter1=A` e quando una richiesta contiene`parameter1=a`. CloudFront quindi memorizza separatamente nella cache gli oggetti corrispondenti restituiti dall'origine, anche se gli oggetti sono identici. Se utilizzi solo `A` o `a`, CloudFront inoltra un numero minore di richieste al server di origine.
+ Elenca i parametri nello stesso ordine. Come per le differenze tra maiuscola e minuscola, se una richiesta per un oggetto contiene la stringa di query `parameter1=a¶meter2=b` e un'altra richiesta per lo stesso oggetto contiene `parameter2=b¶meter1=a`, CloudFront inoltra entrambe le richieste al server di origine e memorizza nella cache gli oggetti separatamente anche se sono identici. Se utilizzi sempre lo stesso ordine per i parametri, CloudFront inoltra meno richieste all'origine.
Per ulteriori informazioni, consulta [Memorizzazione nella cache di contenuti basati su parametri delle stringhe di query](QueryStringParameters.md). Se desideri esaminare le stringhe di query che CloudFront inoltrano all'origine, consulta i valori nella `cs-uri-query` colonna dei tuoi CloudFront file di registro. Per ulteriori informazioni, consulta [Registri di accesso (registri standard)](AccessLogs.md).
## Caching in base ai valori dei cookie
Se configuri la memorizzazione nella cache in base CloudFront ai valori dei cookie, puoi migliorare la memorizzazione nella cache effettuando le seguenti operazioni:
+ Configura CloudFront per inoltrare solo i cookie specifici invece di inoltrare tutti i cookie. Per i cookie che configuri per l'inoltro CloudFront all'origine, CloudFront inoltra ogni combinazione di nome e valore del cookie. Quindi memorizza nella cache separatamente gli oggetti restituiti dall’origine, anche se sono tutti identici.
Ad esempio, supponiamo che gli utenti includano due cookie in ogni richiesta, che ogni cookie abbia tre valori possibili e che tutte le combinazioni di valori dei cookie siano possibili. CloudFront inoltra fino a nove richieste diverse all'origine per ogni oggetto. Se l'origine restituisce versioni diverse di un oggetto basate su un solo cookie, allora CloudFront sta inoltrando all'origine più richieste del necessario e sta inutilmente memorizzando nella cache più versioni identiche dell'oggetto.
+ Crea comportamenti di cache separati per i contenuti statici e dinamici e configura l'inoltro dei cookie CloudFront all'origine solo per i contenuti dinamici.
Ad esempio, supponiamo di avere un solo comportamento di cache per la distribuzione e di utilizzare la distribuzione sia per contenuti dinamici, come `.js` i file, sia per `.css` file che vengono modificati raramente. CloudFront memorizza nella cache versioni separate dei `.css` file in base ai valori dei cookie, in modo che ogni CloudFront edge location inoltri una richiesta all'origine per ogni nuovo valore di cookie o combinazione di valori dei cookie.
Se create un comportamento di cache per il quale corrisponde lo schema di percorso `*.css` e per il quale CloudFront non lo memorizzate in base ai valori dei cookie, CloudFront inoltra le richieste di `.css` file all'origine solo per la prima richiesta ricevuta da una edge location per un determinato `.css` file e per la prima richiesta dopo la scadenza di un `.css` file.
+ Se possibile, crea comportamenti cache separati per i contenuti dinamici per cui i valori dei cookie sono univoci per ogni utente (ad esempio un ID utente) e per contenuti dinamici che variano in base a un numero minore di valori univoci.
Per ulteriori informazioni, consulta [Caching dei contenuti basati su cookie](Cookies.md). Se desideri esaminare i cookie che CloudFront inoltrano alla tua origine, consulta i valori nella `cs(Cookie)` colonna dei tuoi CloudFront file di registro. Per ulteriori informazioni, consulta [Registri di accesso (registri standard)](AccessLogs.md).
## Caching in base alle intestazioni di richiesta
Se CloudFront configuri la memorizzazione nella cache in base alle intestazioni delle richieste, puoi migliorare la memorizzazione nella cache effettuando le seguenti operazioni:
+ Configura CloudFront l'inoltro e la memorizzazione nella cache in base solo alle intestazioni specificate anziché all'inoltro e alla memorizzazione nella cache in base a tutte le intestazioni. Per le intestazioni specificate, CloudFront inoltra ogni combinazione di nome e valore dell'intestazione. Quindi memorizza nella cache separatamente gli oggetti restituiti dall’origine, anche se sono tutti identici.
**Nota**
CloudFront inoltra sempre all'origine le intestazioni specificate nei seguenti argomenti:
In che modo CloudFront elabora e inoltra le richieste al tuo server di origine Amazon S3 > [Intestazioni di richiesta HTTP che rimuovono o aggiornano CloudFront](RequestAndResponseBehaviorS3Origin.md#request-s3-removed-headers)
In che modo CloudFront elabora e inoltra le richieste al tuo server di origine personalizzato > [Intestazioni e CloudFront comportamento delle richieste HTTP (origini personalizzate e Amazon S3)](RequestAndResponseBehaviorCustomOrigin.md#request-custom-headers-behavior)
Quando configurate la memorizzazione nella cache in base CloudFront alle intestazioni delle richieste, non modificate le intestazioni da CloudFront inoltrare, ma solo se CloudFront memorizzate nella cache gli oggetti in base ai valori delle intestazioni.
+ Prova a evitare la memorizzazione nella cache in base alle intestazioni delle richieste che dispongono di un numero elevato di valori univoci.
Ad esempio, se desiderate pubblicare immagini di dimensioni diverse in base al dispositivo dell'utente, non configurate la cache in base CloudFront all'`User-Agent`intestazione, che ha un numero enorme di valori possibili. Configura CloudFront invece la memorizzazione nella cache in base alle intestazioni `CloudFront-Is-Desktop-Viewer` del CloudFront tipo di dispositivo,, e. `CloudFront-Is-Mobile-Viewer` `CloudFront-Is-SmartTV-Viewer` `CloudFront-Is-Tablet-Viewer` Inoltre, se restituisci la stessa versione dell’immagine per tablet e computer desktop, allora inoltra solo l’intestazione `CloudFront-Is-Tablet-Viewer` e non l’intestazione `CloudFront-Is-Desktop-Viewer`.
Per ulteriori informazioni, consulta [Caching dei contenuti in base alle intestazioni di richiesta](header-caching.md).
## Rimuovere l’intestazione `Accept-Encoding` quando la compressione non è necessaria
Se la compressione non è abilitata, perché l'origine non la supporta, non la supporta o il contenuto CloudFront non è comprimibile, puoi aumentare il rapporto di accesso alla cache associando un comportamento della cache nella tua distribuzione a un'origine che imposta quanto segue: Custom Origin Header
+ **Nome intestazione**: `Accept-Encoding`
+ **Header value (Valore intestazione)**: (Lasciare vuoto)
Quando usi questa configurazione, CloudFront rimuove l'intestazione dalla chiave della cache e non include l'`Accept-Encoding`intestazione nelle richieste di origine. Questa configurazione si applica a tutto il contenuto che viene CloudFront fornito con la distribuzione da quell'origine.
## Distribuire contenuti multimediali tramite HTTP
Per ulteriori informazioni su come ottimizzare i contenuti video on demand (VOD) e in streaming, consulta [Video on demand e video in streaming live con CloudFront](on-demand-streaming-video.md).
# Usa Amazon CloudFront Origin Shield
CloudFront Origin Shield è un livello aggiuntivo dell'infrastruttura di CloudFront caching che aiuta a ridurre al minimo il carico dell'origine, a migliorarne la disponibilità e a ridurne i costi operativi. Con lo scudo di origine CloudFront ottieni i seguenti vantaggi:
**Miglior rapporto di occorrenza nella cache**
Origin Shield può aiutarti a migliorare il rapporto di accesso alla cache della tua CloudFront distribuzione perché fornisce un ulteriore livello di caching davanti all'origine. Quando usi Origin Shield, tutte le richieste provenienti da tutti i livelli CloudFront di caching alla tua origine passano attraverso Origin Shield, aumentando la probabilità che si verifichi un errore nella cache. CloudFrontpuoi recuperare ogni oggetto con una singola richiesta di origine da Origin Shield all'origine e tutti gli altri livelli della CloudFront cache (edge location e [cache edge regionali](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches)) possono recuperare l'oggetto da Origin Shield.
**Carico di origine ridotto**
Origin Shield può ridurre ulteriormente il numero di [richieste simultanee](RequestAndResponseBehaviorCustomOrigin.md#request-custom-traffic-spikes) inviate all'origine per lo stesso oggetto. Le richieste di contenuto che non si trova nella cache dello scudo di origine vengono consolidate con altre richieste per lo stesso oggetto, con il risultato che solo una richiesta va alla tua origine. La gestione di un minor numero di richieste all'origine può preservare la disponibilità dell'origine durante i picchi di carico o i picchi di traffico imprevisti e può ridurre i costi per attività come la creazione di just-in-time pacchetti, le trasformazioni delle immagini e il trasferimento dei dati (DTO).
**Migliori prestazioni di rete**
Quando attivi Origin Shield nella AWS regione con [la latenza più bassa rispetto all'origine](#choose-origin-shield-region), puoi ottenere prestazioni di rete migliori. Per le origini in una AWS regione, il traffico di CloudFront rete rimane sulla CloudFront rete ad alto throughput fino all'origine. Per le origini esterne AWS, il traffico di CloudFront rete rimane sulla CloudFront rete fino a Origin Shield, che ha una connessione a bassa latenza con la tua origine.
Incorrono costi aggiuntivi per l’utilizzo di Origin Shield. Per ulteriori informazioni, consultare [Prezzi di CloudFront ](https://aws.amazon.com/cloudfront/pricing/).
**Nota**
Origin Shield non è supportato con le richieste gRPC. Se Origin Shield è abilitato in una distribuzione che supporta gRPC, le richieste gRPC continueranno a funzionare. Tuttavia, le richieste saranno inoltrate direttamente all’origine gRPC senza passare attraverso Origin Shield. Per ulteriori informazioni, consulta [Usare gRPC con le distribuzioni CloudFront](distribution-using-grpc.md).
**Topics**
+ [
## Casi d'uso per Origin Shield
](#origin-shield-use-cases)
+ [
## Scegli la AWS regione per Origin Shield
](#choose-origin-shield-region)
+ [
## Abilitazione di Origin Shield
](#enable-origin-shield)
+ [
## Stima dei costi di Origin Shield
](#origin-shield-costs)
+ [
## Alta disponibilità di Origin Shield.
](#origin-shield-high-availability)
+ [
## In che modo Origin Shield interagisce con altre funzionalità CloudFront
](#origin-shield-and-other-features)
## Casi d'uso per Origin Shield
CloudFront Origin Shield può essere utile per molti casi d'uso, inclusi i seguenti:
+ Visualizzatori che sono distribuiti in diverse regioni geografiche
+ Origins che forniscono just-in-time imballaggi per lo streaming live o on-the-fly l'elaborazione di immagini
+ Origini locali con vincoli di capacità o larghezza di banda
+ Carichi di lavoro che utilizzano più reti per la distribuzione di contenuti () CDNs
Origin Shield potrebbe non essere adatto in altri casi, ad esempio un contenuto dinamico che viene inoltrato tramite proxy all'origine, un contenuto con scarsa memorizzazione nella cache o un contenuto richiesto raramente.
Le sezioni seguenti illustrano i vantaggi di Origin Shield per i seguenti casi d'uso.
**Topics**
+ [
### Visualizzatori in diverse regioni geografiche
](#os-use-cases-global-viewers)
+ [
### Molteplici CDNs
](#os-use-cases-multi-cdn)
### Visualizzatori in diverse regioni geografiche
Con Amazon CloudFront, ottieni intrinsecamente un carico ridotto sulla tua origine perché le richieste che CloudFront possono essere inviate dalla cache non arrivano alla tua origine. Oltre alla [rete globale CloudFront di edge location, le cache edge](https://aws.amazon.com/cloudfront/features/#Amazon_CloudFront_Infrastructure) [regionali fungono da livello di caching](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches) di livello intermedio per fornire accessi alla cache e consolidare le richieste di origine per gli spettatori nelle aree geografiche vicine. Le richieste del visualizzatore vengono instradate prima a una edge location CloudFront vicina e, se l'oggetto non è memorizzato nella cache in tale posizione, la richiesta viene inviata a una cache edge regionale.
Quando i visualizzatori si trovano in regioni geografiche diverse, le richieste possono essere instradate attraverso cache edge diverse, ognuna delle quali può inviare una richiesta all'origine per lo stesso contenuto. Ma con Origin Shield, ottieni un ulteriore livello di memorizzazione nella cache tra le cache edge regionali e la tua origine. Tutte le richieste provenienti da tutte le cache edge regionali passano attraverso Origin Shield, riducendo ulteriormente il carico sulla tua origine. I seguenti diagrammi illustrano tutto questo. Nei seguenti diagrammi, l'origine è AWS Elemental MediaPackage.
**Senza scudo di origine**
Senza Origin Shield, l'origine potrebbe ricevere richieste duplicate per lo stesso contenuto, come illustrato nel diagramma seguente.
![\[Senza CloudFront Origin Shield, l'origine potrebbe ricevere richieste duplicate.\]](http://docs.aws.amazon.com/it_it/AmazonCloudFront/latest/DeveloperGuide/images/origin-shield-without.png)
**Con lo scudo di origine**
L'utilizzo di Origin Shield consente di ridurre il carico sull'origine, come illustrato nel diagramma seguente.
![\[Con CloudFront Origin Shield, l'origine può ricevere meno richieste duplicate.\]](http://docs.aws.amazon.com/it_it/AmazonCloudFront/latest/DeveloperGuide/images/origin-shield-with.png)
### Molteplici CDNs
Per offrire eventi video in diretta o contenuti on-demand popolari, puoi utilizzare più reti di distribuzione dei contenuti (CDNs). L'utilizzo di più contenuti CDNs può offrire alcuni vantaggi, ma significa anche che l'origine potrebbe ricevere molte richieste duplicate per lo stesso contenuto, ognuna proveniente da posizioni diverse CDNs o diverse all'interno dello stesso CDN. Queste richieste ridondanti potrebbero influire negativamente sulla disponibilità dell'origine o causare costi operativi aggiuntivi per processi come l' just-in-timeimballaggio o il trasferimento dei dati (DTO) su Internet.
Combinando Origin Shield con l'utilizzo della tua CloudFront distribuzione come origine per altri CDNs, puoi ottenere i seguenti vantaggi:
+ Meno richieste ridondanti ricevute all'origine, il che aiuta a ridurre gli effetti negativi dell'utilizzo di più richieste. CDNs
+ Una [chiave di cache](controlling-the-cache-key.md) comune e una gestione centralizzata delle funzionalità rivolte all'origine. CDNs
+ Prestazioni di rete migliorate. Il traffico di rete proveniente da altri utenti CDNs viene interrotto presso una CloudFront edge location vicina, il che potrebbe causare un impatto dalla cache locale. Se l'oggetto richiesto non si trova nella cache dell'edge location, la richiesta all'origine rimane sulla CloudFront rete fino a Origin Shield, che fornisce un throughput elevato e una bassa latenza all'origine. Se l'oggetto richiesto si trova nella cache dello scudo di origine, la richiesta all'origine viene evitata completamente.
**Importante**
Se sei interessato a utilizzare Origin Shield in un'architettura multi-CDN e hai prezzi scontati, [contatta noi](https://aws.amazon.com/contact-us/) o il tuo rappresentante di AWS vendita per ulteriori informazioni. Potrebbero essere applicati costi aggiuntivi.
I seguenti diagrammi mostrano in che modo questa configurazione può aiutare a ridurre al minimo il carico sull'origine quando si organizzano eventi video live popolari con più eventi. CDNs Nei diagrammi seguenti, l'origine è. AWS Elemental MediaPackage
**Senza Origin Shield (multiplo CDNs)**
Senza Origin Shield, l'origine potrebbe ricevere molte richieste duplicate per lo stesso contenuto, ognuna proveniente da un CDN diverso, come mostrato nel diagramma seguente.
![\[Grafico che mostra come un’origine può ricevere richieste duplicate, ciascuna proveniente da un CDN diverso.\]](http://docs.aws.amazon.com/it_it/AmazonCloudFront/latest/DeveloperGuide/images/origin-shield-without-multi-cdn.png)
**Con Origin Shield (multiplo CDNs)**
Usare Origin Shield, con CloudFront come origine per gli altri CDNs, può aiutarti a ridurre il carico sull'origine, come mostrato nel diagramma seguente.
![\[Grafica che mostra CloudFront Origin Shield che riceve meno richieste duplicate.\]](http://docs.aws.amazon.com/it_it/AmazonCloudFront/latest/DeveloperGuide/images/origin-shield-with-multi-cdn.png)
## Scegli la AWS regione per Origin Shield
Amazon CloudFront offre Origin Shield nelle AWS regioni in cui CloudFront è presente una [cache edge regionale](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches). Quando attivi Origin Shield, scegli la AWS regione per Origin Shield. Si consiglia vivamente di scegliere la regione AWS che ha la latenza più bassa rispetto alla propria origine. Puoi usare Origin Shield con origini che si trovano in una AWS regione e con origini che non si trovano in AWS.
### Per le origini in una AWS regione
Se sei originario di una AWS regione, stabilisci innanzitutto se proviene da una regione in cui è disponibile CloudFront Origin Shield. CloudFront offre Origin Shield nelle seguenti AWS regioni.
+ Stati Uniti orientali (Ohio) – `us-east-2`
+ Stati Uniti orientali (Virginia settentrionale) – `us-east-1`
+ Stati Uniti occidentali (Oregon) – `us-west-2`
+ Asia Pacifico (Mumbai) – `ap-south-1`
+ Asia Pacifico (Seul) - `ap-northeast-2`
+ Asia Pacifico (Singapore) – `ap-southeast-1`
+ Asia Pacifico (Sydney) - `ap-southeast-2`
+ Asia Pacifico (Tokyo) - `ap-northeast-1`
+ Europe (Francoforte) – `eu-central-1`
+ Europa (Irlanda) – `eu-west-1`
+ Europe (Londra) – `eu-west-2`
+ Sud America (San Paolo) – `sa-east-1`
+ Medio Oriente (Emirati Arabi Uniti) — `me-central-1`
**Se sei originario di una AWS regione in cui è disponibile CloudFront Origin Shield**
Se sei originario di una AWS regione che CloudFront offre Origin Shield (vedi l'elenco precedente), abilita Origin Shield nella stessa regione in cui sei originario.
**Se non sei originario di una AWS regione in cui è disponibile CloudFront Origin Shield**
Se il tuo paese di origine non è in una AWS regione in cui è CloudFront disponibile Origin Shield, consulta la tabella seguente per determinare in quale regione abilitare Origin Shield.
| **Se l'origine è in...** | **Attivare lo scudo di origine in...** |
| --- | --- |
| Stati Uniti occidentali (California settentrionale) – `us-west-1` | Stati Uniti occidentali (Oregon) – `us-west-2` |
| Africa (Città del Capo) – `af-south-1` | Europa (Irlanda) – `eu-west-1` |
| Asia Pacific (Hong Kong) – `ap-east-1` | Asia Pacifico (Singapore) – `ap-southeast-1` |
| Canada (Central) – `ca-central-1` | Stati Uniti orientali (Virginia settentrionale) – `us-east-1` |
| Europe (Milan) – `eu-south-1` | Europe (Francoforte) – `eu-central-1` |
| Europe (Paris) – `eu-west-3` | Europe (Londra) – `eu-west-2` |
| Europe (Stockholm) – `eu-north-1` | Europe (Londra) – `eu-west-2` |
| Middle East (Bahrain) – `me-south-1` | Asia Pacifico (Mumbai) – `ap-south-1` |
### Per origini diverse da AWS
È possibile utilizzare Origin Shield con un'origine locale o non presente in una regione AWS . In questo caso, abilita Origin Shield nella AWS regione con la latenza più bassa rispetto all'origine. Se non sei sicuro di quale AWS regione abbia la latenza più bassa rispetto alla tua origine, puoi usare i seguenti suggerimenti per aiutarti a fare una scelta.
+ È possibile consultare la tabella precedente per un'approssimazione circa quale regione AWS potrebbe avere la latenza più bassa rispetto alla propria origine, in base alla posizione geografica dell'origine.
+ Puoi avviare istanze Amazon EC2 in alcune AWS regioni diverse geograficamente vicine alla tua origine ed eseguire alcuni test per misurare le latenze di rete tipiche tra tali regioni e la tua origine. `ping`
## Abilitazione di Origin Shield
Origin Shield può essere abilitato per migliorare il tasso di occorrenza nella cache, ridurre il carico sull'origine e migliorare le prestazioni. Per abilitare Origin Shield, modifica le impostazioni di origine in una CloudFront distribuzione. Origin Shield è una proprietà dell'origine. Per ogni origine nelle tue CloudFront distribuzioni, puoi abilitare Origin Shield separatamente nella AWS regione che offre le migliori prestazioni per quell'origine.
Puoi abilitare Origin Shield nella CloudFront console CloudFormation, con o con l' CloudFrontAPI.
------
#### [ Console ]
**Per abilitare Origin Shield per un'origine esistente (console)**
1. Accedi Console di gestione AWS e apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Scegliere la distribuzione con l'origine che si desidera aggiornare.
1. Seleziona la scheda **Origins (Origini)**.
1. Scegliere l'origine da aggiornare, quindi scegliere **Edit (Modifica)**.
1. Per **Enable Origin Shield (Abilita scudo di origine)**, scegliere **Yes (Sì)**.
1. Per **Origin Shield Region (Regione scudo di origine)**, scegliere la regione AWS in cui si desidera abilitare lo scudo di origine. Per informazioni sulla scelta di una regione, vedere [Scegli la AWS regione per Origin Shield](#choose-origin-shield-region).
1. Scegli **Save changes** (Salva modifiche).
Quando lo stato di distribuzione è **Deployed (Distribuito)**, Origin Shield è pronto. Ci vogliono pochi minuti.
**Per abilitare Origin Shield per una nuova origine (console)**
1. Accedi a Console di gestione AWS e apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Per creare la nuova origine in una distribuzione esistente, effettuare le seguenti operazioni:
1. Scegliere la distribuzione in cui si desidera creare l'origine.
1. Scegliere **Create Origin (Crea origine)**, quindi procedere al passaggio 3.
Per creare la nuova origine in una nuova distribuzione, effettua le seguenti operazioni:
1. Segui le fasi per creare una distribuzione standard nella console. Per ulteriori informazioni, consulta [Crea una CloudFront distribuzione nella console](distribution-web-creating-console.md#create-console-distribution).
1. Nella sezione **Impostazioni**, seleziona **Personalizza impostazioni origine**. Procedi al passaggio 3.
1. Per **Enable Origin Shield (Abilita scudo di origine)**, scegliere **Yes (Sì)**.
1. Per **Origin Shield Region (Regione scudo di origine)**, scegliere la regione AWS in cui si desidera abilitare lo scudo di origine. Per informazioni sulla scelta di una regione, vedere [Scegli la AWS regione per Origin Shield](#choose-origin-shield-region).
1. Segui le fasi indicate nella console per completare la creazione dell’origine o della distribuzione.
Quando lo stato di distribuzione è **Deployed (Distribuito)**, Origin Shield è pronto. Ci vogliono pochi minuti.
------
#### [ CloudFormation ]
Per abilitare Origin Shield con CloudFormation, usa la `OriginShield` proprietà nel tipo di `Origin` proprietà in una `AWS::CloudFront::Distribution` risorsa. È possibile aggiungere la proprietà `OriginShield` a una `Origin` esistente, o includerla quando si crea una nuova `Origin`.
Nell'esempio seguente viene illustrata la sintassi, in formato YAML, per l'abilitazione di `OriginShield` nella regione US West (Oregon) (`us-west-2`). Per informazioni sulla scelta di una regione, vedere [Scegli la AWS regione per Origin Shield](#choose-origin-shield-region). In questo esempio viene visualizzato solo il tipo di proprietà `Origin` e non l'intera risorsa `AWS::CloudFront::Distribution`.
```
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
```
Per ulteriori informazioni, consulta [AWS::CloudFront::Distribution Origin](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-origin.html) nella sezione di riferimento alle risorse e alle proprietà della *Guida AWS CloudFormation per l'utente*.
------
#### [ API ]
Per abilitare Origin Shield con l' CloudFront API utilizzando AWS SDKs or AWS Command Line Interface (AWS CLI), usa il `OriginShield` tipo. È possibile specificare `OriginShield` in un `Origin`, in un oggetto `DistributionConfig`. Per informazioni sul `OriginShield` tipo, consulta le seguenti informazioni nell'*Amazon CloudFront API Reference*.
+ [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)(operazione)
+ [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html)(operazione)
La sintassi specifica per l'utilizzo di questi tipi e operazioni varia in base al client SDK, CLI o API. Per ulteriori informazioni, vedere la documentazione di riferimento per SDK, CLI o client.
------
## Stima dei costi di Origin Shield
I costi di Origin Shield vengono addebitati in base al numero di richieste che vanno allo scudo di origine come livello incrementale.
Per le richieste dinamiche (non memorizzabili nella cache) che vengono inoltrate tramite proxy all'origine, Origin Shield è sempre un livello incrementale. Le richieste dinamiche utilizzano i metodi HTTP `PUT`, `POST`, `PATCH` e `DELETE`.
Le richieste `GET` e `HEAD` con un’impostazione TTL (time to live) inferiore a 3600 secondi sono considerate richieste dinamiche. Inoltre, anche le richieste `GET` e `HEAD` che hanno disabilitato la cache sono considerate richieste dinamiche.
Per stimare gli addebiti relativi a Origin Shield per le richieste dinamiche, usa la seguente formula:
Numero totale di richieste dinamiche **x** addebito Origin Shield per 10.000 richieste **/** 10.000
Per le richieste non dinamiche con i metodi HTTP `GET`, `HEAD` e `OPTIONS`, Origin Shield è talvolta un livello incrementale. Quando attivi Origin Shield, scegli Origin Shield. Regione AWS Per le richieste che vengono indirizzate naturalmente alla [cache edge regionale](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches) nella stessa Regione di Origin Shield, Origin Shield non costituisce un livello incrementale. Per queste richieste non si accumulano addebiti per Origin Shield. Per le richieste che vengono indirizzate a una cache edge regionale in una Regione diversa da Origin Shield e quindi a Origin Shield, Origin Shield costituisce un livello incrementale. Per queste richieste si accumulano addebiti per Origin Shield.
Per stimare gli addebiti relativi a Origin Shield per le richieste dinamiche, usare la seguente formula:
Numero totale di richieste memorizzabili nella cache ** x** (1 - tasso di occorrenza nella cache) **x** percentuale di richieste che vanno a Origin Shield da una cache edge regionale in una regione diversa **x** addebito dello scudo di origine per 10.000 richieste **/** 10.000
Per ulteriori informazioni sull'addebito per 10.000 richieste per lo scudo di origine, vedere [Prezzi di CloudFront ](https://aws.amazon.com/cloudfront/pricing/).
## Alta disponibilità di Origin Shield.
Origin Shield sfrutta la funzionalità di [cache edge CloudFront regionali](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches). Ciascuna di queste cache edge è integrata in una AWS regione che utilizza almeno tre [zone di disponibilità](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) con flotte di istanze Amazon EC2 con scalabilità automatica. Le connessioni da posizioni CloudFront allo scudo di origine utilizzano inoltre il rilevamento degli errori attivo per ogni richiesta per instradare automaticamente la richiesta a una posizione secondaria dello scudo di origine se la posizione principale non è disponibile.
## In che modo Origin Shield interagisce con altre funzionalità CloudFront
Le sezioni seguenti spiegano il modo in cui lo scudo di origine interagisce con altre funzioni CloudFront.
### Origin Shield e CloudFront registrazione
Per vedere quando Origin Shield ha gestito una richiesta, è necessario abilitare una delle seguenti opzioni:
+ [CloudFront registri standard (registri di accesso)](AccessLogs.md). I registri standard sono forniti gratuitamente.
+ CloudFront registri di [accesso in tempo reale](real-time-logs.md). Sono previsti costi aggiuntivi per l'utilizzo dei log di accesso in tempo reale. Consulta [ CloudFronti prezzi di Amazon](https://aws.amazon.com/cloudfront/pricing/).
Gli accessi alla cache di Origin Shield vengono visualizzati come `OriginShieldHit` nel `x-edge-detailed-result-type` campo CloudFront dei log. Origin Shield sfrutta le [cache edge regionali CloudFront](HowCloudFrontWorks.md#CloudFrontRegionaledgecaches) di Amazon. Se una richiesta viene instradata da un' CloudFront edge location alla cache edge regionale che funge da Origin Shield, viene riportata come a `Hit` nei log, non come. `OriginShieldHit`
### Origin Shield e gruppi di origine
Lo scudo di origine è compatibile con [i gruppi di origine CloudFront ](high_availability_origin_failover.md). Poiché Origin Shield è una proprietà dell'origine, le richieste viaggiano sempre attraverso Origin Shield per ogni origine anche quando l'origine fa parte di un gruppo di origine. Per una determinata richiesta, CloudFront indirizza la richiesta all'origine primaria nel gruppo di origine tramite Origin Shield dell'origine primaria. Se la richiesta ha esito negativo (in base ai criteri di failover del gruppo di origine), CloudFront indirizza la richiesta all'origine secondaria tramite Origin Shield dell'origine secondaria.
### Origin Shield e Lambda@Edge
Origin Shield non influisce sulla funzionalità delle funzioni [Lambda@Edge](lambda-at-the-edge.md)ma può influire sulla AWS regione in cui vengono eseguite tali funzioni.
Quando usi Origin Shield con Lambda @Edge, i [trigger rivolti all'origine](lambda-cloudfront-trigger-events.md) (richiesta di origine e risposta all'origine) vengono eseguiti nella regione in AWS cui Origin Shield è abilitato. Se la sede principale di Origin Shield non è disponibile e CloudFront indirizza le richieste verso una sede Origin Shield secondaria, anche i trigger di origine di Lambda @Edge passeranno a utilizzare la posizione Origin Shield secondaria.
I trigger rivolti al visualizzatore non sono interessati.
# Ottimizza l'alta disponibilità con il failover di CloudFront origine
È possibile eseguire la configurazione CloudFront con il failover di origine per scenari che richiedono un'elevata disponibilità. Per iniziare, è necessario creare un *gruppo di origine* con due origini: una primaria e una secondaria. Se l'origine primaria non è disponibile o restituisce codici di stato di risposta HTTP specifici che indicano un errore, passa CloudFront automaticamente all'origine secondaria.
Per configurare il failover di origine, è necessario disporre di una distribuzione con almeno due origini. In seguito, viene creato un gruppo di origine per la distribuzione che include le due origini, impostandone una come primaria. Infine, è possibile creare o aggiornare un comportamento della cache per utilizzare il gruppo di origine.
Per vedere i passaggi per la configurazione dei gruppi di origine con le opzioni specifiche di failover di origine, consulta [Creazione di un gruppo di origine](#concept_origin_groups.creating).
Dopo aver configurato il failover di origine per il comportamento della cache, CloudFront esegue le seguenti operazioni per le richieste dei visualizzatori:
+ Quando si verifica un accesso alla cache, CloudFront restituisce l'oggetto richiesto.
+ In caso di perdita della cache, CloudFront indirizza la richiesta all'origine primaria del gruppo di origine.
+ Quando l'origine primaria restituisce un codice di stato non configurato per il failover, ad esempio un codice di stato HTTP 2xx o 3xx, invia l' CloudFront oggetto richiesto al visualizzatore.
+ Quando si verifica una delle seguenti condizioni:
+ L’origine primaria restituisce un codice di stato HTTP configurato per il failover
+ CloudFront non riesce a connettersi all'origine primaria (quando 503 è impostato come codice di failover)
+ La risposta dall’origine primaria richiede troppo tempo (timeout) (quando 504 è impostato come codice di failover)
Quindi CloudFront indirizza la richiesta all'origine secondaria nel gruppo di origine.
**Nota**
In alcuni casi d'uso, come lo streaming di contenuti video, potresti CloudFront voler eseguire rapidamente il failover sull'origine secondaria. Per regolare la velocità di CloudFront failover sull'origine secondaria, consulta[Controllo dei timeout e dei tentativi di origine](#controlling-attempts-and-timeouts).
CloudFront indirizza tutte le richieste in entrata all'origine primaria, anche quando una richiesta precedente non è passata all'origine secondaria. CloudFront invia richieste all'origine secondaria solo dopo che una richiesta all'origine primaria ha esito negativo.
CloudFront esegue il failover sull'origine secondaria solo quando il metodo HTTP della richiesta del visualizzatore è `GET``HEAD`, o`OPTIONS`. CloudFront non esegue il failover quando il visualizzatore invia un metodo HTTP diverso (ad esempio `POST``PUT`, e così via).
**Nota**
CloudFront non effettueranno il failover se non `OPTIONS` sono impostati come comportamento [Cached HTTP Methods (Metodi HTTP in cache)](DownloadDistValuesCacheBehavior.md#DownloadDistValuesCachedHTTPMethods) nella cache.
Il diagramma seguente illustrato il funzionamento del failover di origine.
![\[Come funziona il failover di origine\]](http://docs.aws.amazon.com/it_it/AmazonCloudFront/latest/DeveloperGuide/images/origingroups-overview.png)
**Topics**
+ [
## Creazione di un gruppo di origine
](#concept_origin_groups.creating)
+ [
## Controllo dei timeout e dei tentativi di origine
](#controlling-attempts-and-timeouts)
+ [
## Utilizzo del failover di origine con le funzioni Lambda@Edge
](#concept_origin_groups.lambda)
+ [
## Utilizzo di pagine di errore personalizzate con failover di origine
](#concept_origin_groups.custom-error)
## Creazione di un gruppo di origine
**Per creare un gruppo di origine**
1. Accedi a Console di gestione AWS e apri la CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Scegli la distribuzione per la quale desideri creare il gruppo di origine.
1. Seleziona la scheda **Origins (Origini)**.
1. Assicurati che la distribuzione abbia più di un’origine. In caso contrario, aggiungi una seconda origine.
1. Nella scheda **Origini**, nel pannello **Gruppi di origine**, scegli **Crea gruppo di origine**.
1. Scegli le origini per il gruppo di origine. Dopo aver aggiunto le origini, utilizza le frecce per impostare la priorità, ovvero quale origine è primaria e quale secondaria.
1. Digitare un nome per il gruppo di origine.
1. Scegli i codici di stato HTTP da utilizzare come criteri di failover. Puoi scegliere qualsiasi combinazione dei seguenti codici di stato: 400, 403, 404, 416, 429, 500, 502, 503 o 504. Quando CloudFront riceve una risposta con uno dei codici di stato specificati, esegue il failover sull'origine secondaria.
**Nota**
CloudFront esegue il failover sull'origine secondaria solo quando il metodo HTTP della richiesta del visualizzatore è `GET``HEAD`, o`OPTIONS`. CloudFront non esegue il failover quando il visualizzatore invia un metodo HTTP diverso (ad esempio `POST``PUT`, e così via).
1. In **Criteri di selezione origine**, specifica come vengono selezionate le origini quando la distribuzione instrada le richieste. Puoi scegliere le seguenti opzioni.
**Predefinita**
CloudFront utilizzerà la priorità di origine predefinita specificata nella pagina **Impostazioni**.
**Punteggio di qualità multimediale**
CloudFront traccia e utilizza questo punteggio per determinare la prima origine a cui inoltrare la richiesta. Ciò CloudFront autorizza anche a effettuare `HEAD` richieste asincrone all'origine alternativa nel gruppo di origine per determinarne il punteggio di qualità multimediale. Puoi scegliere questa opzione solo per le origini v2. AWS Elemental MediaPackage Per ulteriori informazioni, consulta [MQAR (Media Quality-Aware Resiliency)](media-quality-score.md).
1. Scegliere **Crea un gruppo di origine**.
Assicurati di assegnare il gruppo di origine come origine per il comportamento della cache della distribuzione. Per ulteriori informazioni, consulta [Nome](DownloadDistValuesOrigin.md#DownloadDistValuesId).
## Controllo dei timeout e dei tentativi di origine
Per impostazione predefinita, CloudFront tenta di connettersi all'origine primaria in un gruppo di origine per un massimo di 30 secondi (3 tentativi di connessione da 10 secondi ciascuno) prima di passare all'origine secondaria. In alcuni casi d'uso, come lo streaming di contenuti video, potresti CloudFront voler eseguire il failover sull'origine secondaria più rapidamente. È possibile modificare le seguenti impostazioni per influire sulla velocità di CloudFront failover sull'origine secondaria. Se l'origine è un'origine secondaria o un'origine che non fa parte di un gruppo di origine, queste impostazioni influiscono sulla velocità di CloudFront restituzione di una risposta HTTP 504 al visualizzatore.
Per eseguire il failover più rapidamente, specificare un timeout di connessione più breve, un minor numero di tentativi di connessione o entrambi. Per le origini personalizzate (incluse le origini del bucket Amazon S3 che *sono* configurate con l’hosting di siti web statici), è inoltre possibile regolare il timeout di risposta all’origine.
**Timeout connessione origine**
L'impostazione del timeout della connessione di origine influisce sulla durata delle CloudFront attese quando si tenta di stabilire una connessione all'origine. Per impostazione predefinita, CloudFront attende 10 secondi per stabilire una connessione, ma è possibile specificare da 1 a 10 secondi (inclusi). Per ulteriori informazioni, consulta [Timeout di connessione](DownloadDistValuesOrigin.md#origin-connection-timeout).
**Tentativi di connessione all’origine**
L'impostazione dei tentativi di connessione all'origine influisce sul numero di CloudFront tentativi di connessione all'origine. Per impostazione predefinita, CloudFront tenta di connettersi 3 volte, ma è possibile specificare 1—3 (incluso). Per ulteriori informazioni, consulta [Tentativi di connessione](DownloadDistValuesOrigin.md#origin-connection-attempts).
Per un'origine personalizzata (incluso un bucket Amazon S3 configurato con hosting di siti Web statici), questa impostazione influisce anche sul numero di volte in cui si CloudFront tenta di ottenere una risposta dall'origine in caso di timeout della risposta di origine.
**Timeout di risposta dell'origine**
Il timeout della risposta di origine, noto anche come timeout di lettura dell'origine, influisce sulla durata di CloudFront attesa per ricevere una risposta (o per ricevere la risposta completa) dall'origine. Per impostazione predefinita, CloudFront attende 30 secondi, ma è possibile specificare da 1 a 120 secondi (inclusi). Per ulteriori informazioni, consulta [Timeout di risposta](DownloadDistValuesOrigin.md#DownloadDistValuesOriginResponseTimeout).
### Come modificare queste impostazioni
**Per modificare queste impostazioni nella [console CloudFront](https://console.aws.amazon.com/cloudfront/v4/home)**
+ Per una nuova origine o una nuova distribuzione, è necessario specificare questi valori quando si crea la risorsa.
+ Per un’origine esistente in una distribuzione esistente, è necessario specificare questi valori quando si modifica l’origine.
Per ulteriori informazioni, consulta [Riferimento a tutte le impostazioni di distribuzione](distribution-web-values-specify.md).
## Utilizzo del failover di origine con le funzioni Lambda@Edge
Puoi usare le funzioni Lambda @Edge con le CloudFront distribuzioni che hai configurato con i gruppi di origine. Per utilizzare una funzione Lambda, specificarla in una [richiesta di origine o in un trigger di risposta di origine](lambda-cloudfront-trigger-events.md) per un gruppo di origine quando si crea il comportamento della cache. Quando utilizzi una funzione Lambda@Edge con un gruppo di origine, la funzione può essere attivata due volte per una singola richiesta del visualizzatore. Considera ad esempio questo scenario:
1. Crei una funzione Lambda@Edge con un trigger di richiesta di origine.
1. La funzione Lambda viene attivata una volta quando CloudFront invia una richiesta all'origine primaria (in caso di perdita della cache).
1. L’origine primaria risponde con un codice di stato HTTP configurato per il failover.
1. La funzione Lambda viene riattivata quando CloudFront invia la stessa richiesta all'origine secondaria.
Il seguente diagramma mostra il modo in cui il failover di origine funziona quando si include una funzione Lambda@Edge in un trigger di richiesta o di risposta origine.
![\[Come funziona il failover di origine con le funzioni Lambda@Edge\]](http://docs.aws.amazon.com/it_it/AmazonCloudFront/latest/DeveloperGuide/images/origingroups-with-lambda-edge.png)
Per ulteriori informazioni sull’utilizzo dei trigger Lambda@Edge, consulta [Aggiunta di trigger per una funzione Lambda@Edge](lambda-edge-add-triggers.md).
Per ulteriori informazioni sulla gestione del failover DNS, consulta [Configurazione di un failover DNS](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html) nella *Guida per gli sviluppatori di Amazon Route 53*.
## Utilizzo di pagine di errore personalizzate con failover di origine
È possibile utilizzare le pagine di errore personalizzate con i gruppi di origine in modo analogo a come si utilizzano con le origini che non sono impostate per il failover di origine.
Quando si utilizza il failover di origine, è possibile CloudFront configurare la restituzione di una pagina di errore personalizzata per l'origine primaria o secondaria (o entrambe):
+ **Restituisce una pagina di errore personalizzata per l'origine principale**: se l'origine primaria restituisce un codice di stato HTTP non configurato per il failover, CloudFront restituisce la pagina di errore personalizzata ai visualizzatori.
+ **Restituisce una pagina di errore personalizzata per l'origine secondaria**: se CloudFront riceve un codice di stato di errore dall'origine secondaria, CloudFront restituisce la pagina di errore personalizzata.
Per ulteriori informazioni sull'utilizzo di pagine di errore personalizzate con CloudFront, consulta[Generazione di risposte di errore personalizzate](GeneratingCustomErrorResponses.md).
# Gestione della durata di permanenza dei contenuti nella cache (scadenza)
Puoi controllare per quanto tempo i tuoi file rimangono in una CloudFront cache prima di CloudFront inoltrare un'altra richiesta all'origine. Riducendo la durata, puoi distribuire contenuti dinamici. Aumentando la durata, gli utenti otterranno prestazioni migliori, poiché è più probabile che i file vengano distribuiti direttamente dalla cache edge. Una durata maggiore riduce anche il carico sul server di origine.
In genere, CloudFront serve un file da una edge location fino alla scadenza della durata della cache specificata, ovvero fino alla scadenza del file. Dopo la scadenza, la volta successiva che l'edge location riceve una richiesta per il file, CloudFront inoltra la richiesta all'origine per verificare che la cache contenga la versione più recente del file. La risposta dall’origine dipende dall’eventuale modifica del file:
+ Se la CloudFront cache ha già la versione più recente, l'origine restituisce un codice di stato. `304 Not Modified`
+ Se la CloudFront cache non ha la versione più recente, l'origine restituisce un codice di stato `200 OK` e la versione più recente del file.
Se un file in una edge location non viene richiesto frequentemente, CloudFront potrebbe eliminarlo, ovvero rimuoverlo prima della data di scadenza, per fare spazio ai file che sono stati richiesti più di recente.
Ti consigliamo di gestire la durata della cache aggiornando la policy della cache della distribuzione. Se scegli di non utilizzare una policy della cache, il TTL (Time to Live) predefinito è di 24 ore, ma puoi aggiornare le seguenti impostazioni per sovrascrivere il valore predefinito:
+ **Per modificare la durata della cache per tutti i file che corrispondono allo stesso modello di percorso, puoi modificare le CloudFront impostazioni di TTL **minimo, TTL **massimo** e TTL** predefinito per il comportamento della cache.** Per ulteriori informazioni sulle singole impostazioni, consulta [Minimum TTL (TTL minimo)](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMinTTL), [Maximum TTL (TTL massimo)](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL) e [Default TTL (TTL di default)](DownloadDistValuesCacheBehavior.md#DownloadDistValuesDefaultTTL).
+ Per modificare la durata della cache per un singolo file, puoi configurare l’origine e aggiungere un’intestazione `Cache-Control` con la direttiva `max-age` o `s-maxage` oppure un’intestazione `Expires` al file. Per ulteriori informazioni, consulta [Utilizzo delle intestazioni per controllare la durata della cache per i singoli oggetti](#expiration-individual-objects).
Per ulteriori informazioni su come **Minimum TTL** (TTL minimo), **Default TTL** (TTL predefinito) e **Maximum TTL** (TTL massimo) interagiscono con le direttive `max-age` e `s-maxage` e il campo intestazione `Expires`, consulta [Specificate la quantità di tempo di memorizzazione degli oggetti nella cache CloudFront](#ExpirationDownloadDist).
Puoi anche controllare per quanto tempo gli errori (ad esempio`404 Not Found`) rimangono in una CloudFront cache prima di CloudFront riprovare a recuperare l'oggetto richiesto inoltrando un'altra richiesta all'origine. Per ulteriori informazioni, consulta [In che modo CloudFront elabora i codici di stato HTTP 4xx e 5xx dalla tua origine](HTTPStatusCodes.md).
**Topics**
+ [
## Utilizzo delle intestazioni per controllare la durata della cache per i singoli oggetti
](#expiration-individual-objects)
+ [
## Fornire contenuti obsoleti (scaduti)
](#stale-content)
+ [
## Specificate la quantità di tempo di memorizzazione degli oggetti nella cache CloudFront
](#ExpirationDownloadDist)
+ [
## Aggiunta di intestazioni agli oggetti tramite l’utilizzo della console Amazon S3
](#ExpirationAddingHeadersInS3)
## Utilizzo delle intestazioni per controllare la durata della cache per i singoli oggetti
Puoi utilizzare le intestazioni `Cache-Control` e `Expires` per controllare la durata della permanenza degli oggetti nella cache. Anche le impostazioni per **Minimum TTL (TTL minimo)**, **Default TTL (TTL predefinito)** e **Maximum TTL (TTL massimo)** influiscono sulla durata della cache, ma qui di seguito trovi una panoramica su come le intestazioni abbiano un impatto sulla durata della cache:
+ La `Cache-Control max-age` direttiva consente di specificare per quanto tempo (in secondi) un oggetto deve rimanere nella cache prima di CloudFront recuperarlo nuovamente dal server di origine. Il tempo di scadenza minimo CloudFront supportato è 0 secondi. Il valore massimo è 100 anni. Specifica il valore nel seguente formato:
`Cache-Control: max-age=`*seconds*
Ad esempio, la seguente direttiva indica CloudFront di mantenere l'oggetto associato nella cache per 3600 secondi (un'ora):
`Cache-Control: max-age=3600`
Se desideri che gli oggetti rimangano nelle cache CloudFront edge per una durata diversa da quella che rimangono nelle cache del browser, puoi usare le direttive `Cache-Control max-age` and `Cache-Control s-maxage` insieme. Per ulteriori informazioni, consulta [Specificate la quantità di tempo di memorizzazione degli oggetti nella cache CloudFront](#ExpirationDownloadDist).
+ Il campo intestazione `Expires` consente di specificare una data di scadenza e un orario utilizzando il formato specificato in [RFC 2616, Hypertext Transfer Protocol - HTTP/1.1 Sezione 3.3.1, Data completa](https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3.1), ad esempio:
`Sat, 27 Jun 2015 23:59:59 GMT`
Ti consigliamo di utilizzare la direttiva `Cache-Control max-age` invece del campo dell’intestazione `Expires` per controllare la memorizzazione nella cache dell’oggetto. Se specifichi i valori sia per `Cache-Control max-age` sia per `Expires`, CloudFront utilizza solo il valore di `Cache-Control max-age`.
Per ulteriori informazioni, consulta [Specificate la quantità di tempo di memorizzazione degli oggetti nella cache CloudFront](#ExpirationDownloadDist).
Non è possibile utilizzare i campi HTTP `Cache-Control` o di `Pragma` intestazione in una `GET` richiesta di un visualizzatore per CloudFront forzare il ritorno al server di origine dell'oggetto. CloudFront ignora quei campi di intestazione nelle richieste dei visualizzatori.
Per ulteriori informazioni sui campi delle intestazioni `Cache-Control` e `Expires`, consulta le seguenti sezioni in *RFC 2616, Hypertext Transfer Protocol - HTTP/1.1*:
+ [Section 14.9 Controllo della cache](https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9)
+ [Section 14.21 Scadenze](https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.21)
## Fornire contenuti obsoleti (scaduti)
CloudFront supporta le direttive di controllo `Stale-While-Revalidate` e `Stale-If-Error` cache. Puoi utilizzare queste direttive per specificare per quanto tempo i contenuti obsoleti rimangono disponibili per i visualizzatori.
**Topics**
+ [
### `Stale-While-Revalidate`
](#stale-while-revalidate)
+ [
### `Stale-If-Error`
](#stale-if-error-only)
+ [
### Utilizzo di entrambe le direttive
](#use-both-stale-directives)
### `Stale-While-Revalidate`
Questa direttiva consente di CloudFront fornire contenuti obsoleti dalla cache mentre recupera in modo CloudFront asincrono una nuova versione dall'origine. Ciò migliora la latenza poiché i visualizzatori ricevono risposte immediate dalle posizioni edge senza dover attendere il recupero in background. I nuovi contenuti vengono caricati in background per le richieste future.
**Example Ad esempio: `Stale-While-Revalidate`**
CloudFront esegue quanto segue quando si imposta l'`Cache-Control`intestazione per utilizzare queste direttive.
```
Cache-Control: max-age=3600, stale-while-revalidate=600
```
1. CloudFront memorizzerà nella cache una risposta per un'ora ()`max-age=3600`.
1. Se viene effettuata una richiesta dopo tale periodo, CloudFront serve il contenuto non aggiornato e contemporaneamente invia una richiesta all'origine per riconvalidare e aggiornare il contenuto memorizzato nella cache.
1. Mentre il contenuto viene riconvalidato, CloudFront serve il contenuto obsoleto per un massimo di 10 minuti (). `stale-while-revalidate=600`
**Nota**
CloudFront offrirà il contenuto non aggiornato fino al valore della `stale-while-revalidate` direttiva o al valore del [TTL CloudFront massimo, a seconda di quale](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL) sia inferiore. Dopo la durata massima del TTL, l’oggetto obsoleto non sarà più disponibile dalla cache edge, indipendentemente dal valore `stale-while-revalidate`.
### `Stale-If-Error`
Questa direttiva consente di CloudFront pubblicare contenuti obsoleti dalla cache se l'origine non è raggiungibile o restituisce un codice di errore compreso tra 500 e 600. Ciò garantisce che i visualizzatori possano accedere ai contenuti anche durante un’interruzione dell’origine.
**Example Ad esempio: `Stale-If-Error`**
CloudFront esegue quanto segue quando si imposta l'`Cache-Control`intestazione per utilizzare queste direttive.
```
Cache-Control: max-age=3600, stale-if-error=86400
```
1. CloudFront memorizza nella cache la risposta per un'ora (). `max-age=3600`
1. Se l'origine non è attiva o restituisce un errore dopo tale periodo, CloudFront continua a fornire il contenuto non aggiornato per un massimo di 24 ore () `stale-if-error=86400`
1. Se hai configurato risposte di errore personalizzate, CloudFront tenterà di fornire il contenuto non aggiornato se si verifica un errore entro la durata specificata`stale-if-error`. Se il contenuto obsoleto non è disponibile, CloudFront fornirà le risposte di errore personalizzate configurate per il codice di stato dell'errore corrispondente. Per ulteriori informazioni, consulta [Generazione di risposte di errore personalizzate](GeneratingCustomErrorResponses.md).
**Note**
CloudFront offrirà il contenuto non aggiornato fino al valore della `stale-if-error` direttiva o al valore del [TTL CloudFront massimo](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL), a seconda di quale sia inferiore. Dopo la durata massima del TTL, l’oggetto obsoleto non sarà più disponibile dalla cache edge, indipendentemente dal valore `stale-if-error`.
Se non configuri `stale-if-error` o personalizzi le risposte di errore, CloudFront restituirà l'oggetto non aggiornato o inoltrerà la risposta di errore al visualizzatore, a seconda che l'oggetto richiesto si trovi o meno nella cache edge. Per ulteriori informazioni, consulta [Come CloudFront elabora gli errori se non hai configurato pagine di errore personalizzate](HTTPStatusCodes.md#HTTPStatusCodes-no-custom-error-pages).
### Utilizzo di entrambe le direttive
`stale-while-revalidate` e `stale-if-error` sono entrambe direttive di controllo della cache indipendenti che possono essere utilizzate insieme per ridurre la latenza e aggiungere un buffer affinché l’origine risponda o venga ripristinata.
**Example Esempio: utilizzo di entrambe le direttive**
CloudFront esegue quanto segue quando si imposta l'`Cache-Control`intestazione per utilizzare le seguenti direttive.
```
Cache-Control: max-age=3600, stale-while-revalidate=600, stale-if-error=86400
```
1. CloudFront memorizza la risposta nella cache per un'ora (). `max-age=3600`
1. Se viene effettuata una richiesta dopo tale periodo, CloudFront serve il contenuto non aggiornato per un massimo di 10 minuti (`stale-while-revalidate=600`) mentre il contenuto viene riconvalidato.
1. Se il server di origine restituisce un errore durante il CloudFront tentativo di riconvalidare il contenuto, CloudFront continuerà a fornire il contenuto non aggiornato per un massimo di 24 ore (). `stale-if-error=86400`
Il caching è un equilibrio tra prestazioni e dati aggiornati. L’uso di direttive come `stale-while-revalidate` e `stale-if-error` può migliorare le prestazioni e l’esperienza utente, ma è necessario assicurarsi che le configurazioni siano in linea con l’aggiornamento desiderato dei contenuti. Le direttive sui contenuti non aggiornati sono più adatte per i casi d’uso in cui i contenuti devono essere aggiornati ma la disponibilità della versione più recente non è essenziale. Inoltre, se i contenuti non cambiano o cambiano raramente, `stale-while-revalidate` potrebbe aggiungere richieste di rete non necessarie. Prendere invece in considerazione l’impostazione di una lunga durata della cache.
## Specificate la quantità di tempo di memorizzazione degli oggetti nella cache CloudFront
Per controllare il periodo di tempo in cui un oggetto CloudFront rimane nella cache prima di inviare un'altra richiesta all'origine, puoi:
+ Imposta i valori TTL minimo, massimo e predefinito nel comportamento della cache di una CloudFront distribuzione. È possibile impostare questi valori in una [policy di cache](controlling-the-cache-key.md) collegata al comportamento della cache (scelta consigliata) o nelle impostazioni della cache legacy.
+ Includere l’intestazione `Cache-Control` o `Expires` nelle risposte dall’origine. Queste intestazioni aiutano anche a determinare per quanto tempo un browser conserva un oggetto nella cache del browser prima di inviare un'altra richiesta a. CloudFront
Nella tabella seguente viene illustrato come le intestazioni `Cache-Control` e `Expires` inviate dall’origine funzionano insieme alle impostazioni TTL in un comportamento di cache per influire sulla memorizzazione nella cache.
****
| Intestazioni di origine | TTL minimo = 0 | TTL minimo = 0 |
| --- | --- | --- |
| **L’origine aggiunge una direttiva `Cache-Control: max-age` all’oggetto** | **CloudFront memorizzazione nella cache** CloudFront memorizza nella cache l'oggetto con il valore minore tra il valore della `Cache-Control: max-age` direttiva o il valore del CloudFront TTL massimo. **Caching del browser** I browser memorizzano nella cache l’oggetto per il valore della direttiva `Cache-Control: max-age`. | **CloudFront memorizzazione nella cache** CloudFront la memorizzazione nella cache dipende dai valori del TTL CloudFront minimo e del TTL massimo e dalla direttiva: `Cache-Control max-age` [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) **Caching del browser** I browser memorizzano nella cache l’oggetto per il valore della direttiva `Cache-Control: max-age`. |
| **L’origine non aggiunge una direttiva `Cache-Control: max-age` all’oggetto** | **CloudFront memorizzazione nella cache** CloudFront memorizza nella cache l'oggetto per il valore del TTL CloudFront predefinito. **Caching del browser** Dipende dal browser. | **CloudFront memorizzazione nella cache** CloudFront memorizza l'oggetto nella cache per il valore maggiore tra il TTL CloudFront minimo o il TTL predefinito. **Caching del browser** Dipende dal browser. |
| **L’origine aggiunge le direttive `Cache-Control: max-age` e `Cache-Control: s-maxage` all’oggetto** | **CloudFront memorizzazione nella cache** CloudFront memorizza nella cache l'oggetto con il valore minore tra il valore della `Cache-Control: s-maxage` direttiva o il valore del CloudFront TTL massimo. **Caching del browser** I browser memorizzano nella cache l’oggetto per il valore della direttiva `Cache-Control max-age`. | **CloudFront memorizzazione nella cache** CloudFront la memorizzazione nella cache dipende dai valori del TTL CloudFront minimo e del TTL massimo e dalla direttiva: `Cache-Control: s-maxage` [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) **Caching del browser** I browser memorizzano nella cache l’oggetto per il valore della direttiva `Cache-Control: max-age`. |
| **L’origine aggiunge un’intestazione `Expires` all’oggetto** | **CloudFront memorizzazione nella cache** CloudFront memorizza l'oggetto nella cache fino alla data indicata nell'`Expires`intestazione o per il valore del TTL CloudFront massimo, a seconda di quale dei due eventi si verifichi per primo. **Caching del browser** I browser memorizzano nella cache l’oggetto fino alla data presente nell’intestazione `Expires`. | **CloudFront memorizzazione nella cache** CloudFront la memorizzazione nella cache dipende dai valori del TTL CloudFront minimo e del TTL massimo e dall'intestazione: `Expires` [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) **Caching del browser** I browser memorizzano nella cache l’oggetto fino alla data e all’ora presenti nell’intestazione `Expires`. |
| **L’origine aggiunge le direttive `Cache-Control: no-cache`, `no-store` e/o `private` all’oggetto** | CloudFront e i browser rispettano le intestazioni. | **CloudFront memorizzazione nella cache** CloudFront memorizza nella cache l'oggetto per il valore del TTL CloudFront minimo. [Consulta l’avviso sotto questa tabella](#stale-if-error). **Caching del browser** I browser rispettano le intestazioni. |
**avvertimento**
Se il TTL minimo è maggiore di 0, CloudFront utilizza il TTL minimo della policy di cache, anche se le and/or `private` direttive, `Cache-Control: no-cache``no-store`, sono presenti nelle intestazioni di origine.
Se l'origine è raggiungibile, CloudFront ottiene l'oggetto dall'origine e lo restituisce al visualizzatore.
Se l'origine non è raggiungibile e il valore TTL minimo *o* massimo è maggiore di 0, CloudFront servirà l'oggetto che ha ottenuto dall'origine in precedenza.
Per evitare questo comportamento, includere la direttiva `Cache-Control: stale-if-error=0` con l’oggetto restituito dall’origine. Ciò fa sì che CloudFront venga restituito un errore in risposta alle richieste future se l'origine non è raggiungibile, anziché restituire l'oggetto ottenuto dall'origine in precedenza.
CloudFront non memorizza nella cache il codice di stato HTTP 501 (non implementato) da un'origine S3 quando le intestazioni di origine includono le `Cache-Control: no-cache` direttive,,. `no-store` and/or `private` Questo è il comportamento predefinito per un’origine S3, anche se l’impostazione [TTL minima](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMinTTL) è maggiore di 0.
Per informazioni su come modificare le impostazioni per le distribuzioni utilizzando la console, consulta CloudFront. [Aggiornamento di una distribuzione](HowToUpdateDistribution.md) Per informazioni su come modificare le impostazioni per le distribuzioni utilizzando l' CloudFront API, consulta. [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)
## Aggiunta di intestazioni agli oggetti tramite l’utilizzo della console Amazon S3
Puoi aggiungere il campo di intestazione `Expires` o `Cache-Control` agli oggetti Amazon S3. Per farlo, è necessario modificare i campi dei metadati dell’oggetto.
**Come aggiungere il campo di intestazione `Expires` o `Cache-Control` agli oggetti Amazon S3**
1. Segui la procedura nella sezione **Sostituzione dei metadati definiti dal sistema** nell’argomento [Modifica dei metadati degli oggetti nella console Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-object-metadata.html) nella *Guida per l’utente di Amazon S3*.
1. Per **Chiave**, scegli il nome dell’intestazione che stai aggiungendo (**Cache-Control** o **Scadenze**).
1. In **Value (Valore)**immetti un valore di intestazione. Ad esempio, per un’intestazione `Cache-Control`, è possibile immettere `max-age=86400`. Per `Expires`, è possibile inserire una data di scadenza e un’ora ad esempio `Wed, 30 Jun 2021 09:28:00 GMT`.
1. Segui il resto della procedura per salvare le modifiche apportate ai metadati.
# Memorizzazione nella cache di contenuti basati su parametri delle stringhe di query
Alcune applicazioni Web utilizzano stringhe di query per inviare informazioni al server di origine. Una stringa di query è la parte di una richiesta Web che viene visualizzata dopo un carattere `?`; la stringa può contenere uno o più parametri, separati da caratteri `&`. Nell'esempio seguente, la stringa di query include due parametri *color=red* e*size=large*:
`https://d111111abcdef8.cloudfront.net/images/image.jpg?color=red&size=large`
Per le distribuzioni, è possibile scegliere se CloudFront inoltrare le stringhe di query all'origine e se inserire nella cache il contenuto in base a tutti i parametri o ai parametri selezionati. Perché questo potrebbe essere utile? Analizza l’esempio seguente.
Supponiamo che il tuo sito Web sia disponibile in cinque lingue. La struttura delle directory e i nomi dei file per le cinque versioni del sito Web sono identiche. Quando un utente visualizza il sito Web, le richieste inoltrate CloudFront includono un parametro della stringa di query linguistica basato sulla lingua scelta dall'utente. È possibile CloudFront configurare l'inoltro delle stringhe di query all'origine e la memorizzazione nella cache in base al parametro della lingua. Se configurate il server Web per restituire la versione di una determinata pagina che corrisponde alla lingua selezionata, CloudFront memorizza nella cache ogni versione linguistica separatamente, in base al valore del parametro della stringa di query della lingua.
In questo esempio, se la pagina principale del sito Web è`main.html`, le seguenti cinque richieste vengono memorizzate nella cache `main.html` cinque volte, una volta per ogni valore del parametro della stringa di query della lingua: CloudFront
+ `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`
Tenere presente quanto segue:
+ Alcuni server HTTP non elaborano parametri delle stringhe di query e, di conseguenza, non restituiscono diverse versioni di un oggetto in base ai valori dei parametri. Per queste origini, se configurate per CloudFront inoltrare i parametri della stringa di query all'origine, vengono CloudFront comunque memorizzate nella cache in base ai valori dei parametri, anche se l'origine restituisce versioni identiche dell'oggetto CloudFront per ogni valore del parametro.
+ Affinché i parametri delle stringhe di query funzionino come descritto nell’esempio precedente con le lingue, devi utilizzare il carattere `&` come delimitatore tra i parametri delle stringhe di query. Se si utilizza un delimitatore diverso, è possibile ottenere risultati imprevisti, a seconda dei parametri specificati CloudFront da utilizzare come base per la memorizzazione nella cache e dell'ordine in cui i parametri vengono visualizzati nella stringa di query.
Gli esempi seguenti mostrano cosa succede se si utilizza un delimitatore diverso e si configura la memorizzazione nella cache solo in base CloudFront al parametro: `color`
+ Nella richiesta seguente, CloudFront memorizza nella cache i contenuti in base al valore del `color` parametro, ma CloudFront interpreta il valore come: *red;size=large*
`https://d111111abcdef8.cloudfront.net/images/image.jpg?color=red;size=large`
+ Nella richiesta seguente, CloudFront memorizza nella cache il contenuto ma non basa la memorizzazione nella cache sui parametri della stringa di query. Questo perché hai configurato la cache in base CloudFront al `color` parametro, ma CloudFront interpreta la stringa seguente come contenente solo un `size` parametro il cui valore è: *large;color=red*
`https://d111111abcdef8.cloudfront.net/images/image.jpg?size=large;color=red`
È possibile configurare CloudFront in modo da eseguire una delle seguenti operazioni:
+ Non inoltrare le stringhe di query al server di origine. Se non inoltrate stringhe di query, CloudFront non viene memorizzata nella cache in base ai parametri delle stringhe di query.
+ Inoltra le stringhe di query al server di origine e memorizza nella cache in base a tutti i parametri della stringa di query.
+ Inoltra le stringhe di query al server di origine e memorizza nella cache in base a parametri specifici della stringa di query.
Per ulteriori informazioni, consulta [Ottimizzazione del caching](#query-string-parameters-optimizing-caching).
**Topics**
+ [
## Impostazioni della console e delle API per l’inoltro delle stringhe di query e per la memorizzazione nella cache
](#query-string-parameters-console)
+ [
## Ottimizzazione del caching
](#query-string-parameters-optimizing-caching)
+ [
## Parametri delle stringhe di query e log CloudFront standard (log di accesso)
](#query-string-parameters-access-logs)
## Impostazioni della console e delle API per l’inoltro delle stringhe di query e per la memorizzazione nella cache
Quando crei una distribuzione nella CloudFront console, CloudFront configura automaticamente l'inoltro e la memorizzazione nella cache delle stringhe di query in base al tipo di origine. Facoltativamente, puoi modificare manualmente queste impostazioni. Per ulteriori informazioni, consulta le impostazioni seguenti nella [Riferimento a tutte le impostazioni di distribuzione](distribution-web-values-specify.md):
+ [Query String Forwarding and Caching (Inoltro e caching di stringhe di query)](DownloadDistValuesCacheBehavior.md#DownloadDistValuesQueryString)
+ [Elenco consentiti stringhe di query](DownloadDistValuesCacheBehavior.md#DownloadDistValuesQueryStringAllowlist)
Per configurare l'inoltro e la memorizzazione nella cache delle stringhe di query con l' CloudFront API, consulta [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)nell'*Amazon CloudFront * API Reference.
## Ottimizzazione del caching
Quando configuri la cache in base CloudFront ai parametri della stringa di query, puoi eseguire le seguenti operazioni per ridurre il numero di richieste che vengono inoltrate CloudFront all'origine. Quando le CloudFront edge location servono oggetti, riduci il carico sul server di origine e riduci la latenza perché gli oggetti vengono serviti da posizioni più vicine agli utenti.
**Cache basata solo su parametri per i quali la tua origine restituisce versioni diverse di un oggetto**
Per ogni parametro della stringa di query a cui l'applicazione Web inoltraCloudFront, CloudFront inoltra le richieste all'origine per ogni valore di parametro e memorizza nella cache una versione separata dell'oggetto per ogni valore del parametro. Ciò è valido anche se il server di origine restituisce sempre lo stesso oggetto indipendentemente dal valore di parametro. Per più parametri, il numero di richieste e di oggetti si moltiplicano.
Ti consigliamo di configurare la cache solo in base CloudFront ai parametri della stringa di query per i quali l'origine restituisce versioni diverse e di considerare attentamente i vantaggi della memorizzazione nella cache in base a ciascun parametro. Supponiamo ad esempio che tu abbia un sito Web di vendita al dettaglio. Disponi delle immagini di una giacca in sei colori diversi e la giacca è disponibile in dieci taglie diverse. Le immagini che hai della giacca mostrano i diversi colori, ma non le differenti taglie. Per ottimizzare la memorizzazione nella cache, è CloudFront necessario configurarla solo in base al parametro color e non al parametro size. Ciò aumenta la probabilità che sia CloudFront possibile evadere una richiesta dalla cache, migliorando le prestazioni e riducendo il carico sull'origine.
**Elenca sempre i parametri nello stesso ordine**
L’ordine dei parametri è importante in materia di stringhe di query. In questo esempio, le stringhe di query sono identiche, anche che i parametri sono in ordine diverso. Ciò comporta CloudFront l'inoltro di due richieste separate per image.jpg all'origine e la memorizzazione nella cache di due versioni separate dell'oggetto:
+ `https://d111111abcdef8.cloudfront.net/images/image.jpg?color=red&size=large`
+ `https://d111111abcdef8.cloudfront.net/images/image.jpg?size=large&color=red`
Ti consigliamo sempre di elencare i nomi dei parametri nello stesso ordine, seguendo, ad esempio, l’ordine alfabetico.
**Usa sempre lo stesso formato per nomi e valori di parametri**
CloudFront considera il caso dei nomi e dei valori dei parametri durante la memorizzazione nella cache in base ai parametri della stringa di query. In questo esempio, le stringhe di query sono identiche, eccetto per il formato dei nomi e dei valori dei parametri. Ciò comporta CloudFront l'inoltro di quattro richieste separate per image.jpg all'origine e la memorizzazione nella cache di quattro versioni separate dell'oggetto:
+ `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`
Ti consigliamo di usare lo stesso formato, maiuscolo o minuscolo, per i nomi e i valori dei parametri, ad esempio tutte in minuscolo.
**Non utilizzare nomi di parametri che siano in conflitto con signed URLs**
Se utilizzi signed URLs per limitare l'accesso ai tuoi contenuti (se hai aggiunto firmatari fidati alla tua distribuzione), CloudFront rimuove i seguenti parametri della stringa di query prima di inoltrare il resto dell'URL all'origine:
+ `Expires`
+ `Key-Pair-Id`
+ `Policy`
+ `Signature`
Se utilizzi signed URLs e desideri configurare l'inoltro delle stringhe di query CloudFront all'origine, i parametri della tua stringa di query non possono essere denominati`Expires`,, `Key-Pair-Id` o. `Policy` `Signature`
## Parametri delle stringhe di query e log CloudFront standard (log di accesso)
Se abiliti la registrazione, CloudFront registra l'URL completo, inclusi i parametri della stringa di query. Ciò è vero indipendentemente dal fatto che tu sia stato configurato CloudFront per inoltrare le stringhe di query all'origine. Per ulteriori informazioni sulla CloudFront registrazione, vedere. [Registri di accesso (registri standard)](AccessLogs.md)
# Caching dei contenuti basati su cookie
Per impostazione predefinita, CloudFront non considera i cookie durante l'elaborazione di richieste e risposte o durante la memorizzazione nella cache degli oggetti in posizioni periferiche. Se CloudFront riceve due richieste identiche ad eccezione di ciò che si trova nell'`Cookie`intestazione, per impostazione predefinita CloudFront considera le richieste identiche e restituisce lo stesso oggetto per entrambe le richieste.
Puoi configurare l'inoltro CloudFront all'origine di alcuni o tutti i cookie nelle richieste dei visualizzatori e di memorizzare nella cache versioni separate degli oggetti in base ai valori dei cookie inoltrati. In tal caso, CloudFront utilizza alcuni o tutti i cookie nelle richieste dei visualizzatori, a prescindere da quelle configurate per l'inoltro, per identificare in modo univoco un oggetto nella cache.
Ad esempio, supponiamo che le richieste per `locations.html` contengano un cookie `country` con un valore di `uk` o `fr`. Quando configurate CloudFront per memorizzare nella cache gli oggetti in base al valore del `country` cookie, CloudFront inoltra le richieste all'origine e include il cookie e `locations.html` il relativo valore. `country` La tua origine restituisce `locations.html` e CloudFront memorizza l'oggetto nella cache una volta per le richieste in cui si trova il valore del `country` cookie `uk` e una volta per le richieste in cui è presente il valore. `fr`
**Importante**
Amazon S3 e alcuni server HTTP non elaborano i cookie. Non configurate CloudFront per inoltrare i cookie a un'origine che non elabora i cookie o che non varia la risposta in base ai cookie. Ciò può causare CloudFront l'inoltro di più richieste all'origine per lo stesso oggetto, con conseguente rallentamento delle prestazioni e aumento del carico sull'origine. Se, considerando l'esempio precedente, la tua origine non elabora il `country` cookie o restituisce sempre la stessa versione di `locations.html` to CloudFront indipendentemente dal valore del `country` cookie, non configurate l'inoltro CloudFront di quel cookie.
Al contrario, se la tua origine personalizzata dipende da un particolare cookie o invia risposte diverse in base a un cookie, assicurati di configurare CloudFront l'inoltro di quel cookie all'origine. Altrimenti, CloudFront rimuove il cookie prima di inoltrare la richiesta all'origine.
Per configurare l’inoltro dei cookie, aggiorna il comportamento della cache della distribuzione. Per ulteriori informazioni sui comportamenti della cache, consulta [Cache Behavior Settings (Impostazioni del comportamento della cache)](DownloadDistValuesCacheBehavior.md), in particolare le sezioni [Forward Cookies (Inoltra cookie)](DownloadDistValuesCacheBehavior.md#DownloadDistValuesForwardCookies) e [Cookie elenco consentiti](DownloadDistValuesCacheBehavior.md#DownloadDistValuesAllowlistCookies).
È possibile configurare ogni comportamento della cache per eseguire una delle operazioni seguenti:
+ **Inoltra tutti i cookie all'origine:** CloudFront include tutti i cookie inviati dal visualizzatore quando inoltra le richieste all'origine. Quando la tua origine restituisce una risposta, CloudFront memorizza la risposta nella cache utilizzando i nomi e i valori dei cookie nella richiesta del visualizzatore. Se la risposta di origine include `Set-Cookie` intestazioni, le CloudFront restituisce al visualizzatore con l'oggetto richiesto. CloudFront memorizza inoltre nella cache le `Set-Cookie` intestazioni con l'oggetto restituito dall'origine e invia tali `Set-Cookie` intestazioni ai visualizzatori su tutti gli accessi alla cache.
+ **Inoltra un set di cookie specificato:** CloudFront rimuove tutti i cookie inviati dal visualizzatore che non sono nell'elenco consentito prima di inoltrare una richiesta all'origine. CloudFront memorizza nella cache la risposta utilizzando i nomi e i valori dei cookie elencati nella richiesta del visualizzatore. Se la risposta di origine include `Set-Cookie` intestazioni, le CloudFront restituisce al visualizzatore con l'oggetto richiesto. CloudFront memorizza inoltre nella cache le `Set-Cookie` intestazioni con l'oggetto restituito dall'origine e invia tali `Set-Cookie` intestazioni ai visualizzatori su tutti gli accessi alla cache.
Per informazioni su come specificare i caratteri jolly nei nomi dei cookie, consulta [Cookie elenco consentiti](DownloadDistValuesCacheBehavior.md#DownloadDistValuesAllowlistCookies).
Per conoscere la quota corrente relativa al numero di nomi di cookie che puoi inoltrare per ogni comportamento cache o per richiedere una quota superiore, consulta [Quote sulle stringhe di query (impostazioni della cache legacy)](cloudfront-limits.md#limits-allowlisted-query-strings).
+ **Non inoltrate i cookie all'origine:** CloudFront non memorizza nella cache gli oggetti in base al cookie inviato dal visualizzatore. Inoltre, CloudFront rimuove i cookie prima di inoltrare le richieste all'origine e rimuove le `Set-Cookie` intestazioni dalle risposte prima di restituire le risposte agli utenti. Poiché questo non è un modo ottimale per utilizzare le risorse di origine, quando si seleziona questo comportamento della cache, è necessario assicurarsi che l’origine non includa i cookie nelle risposte di origine per impostazione predefinita.
Note importanti su come specificare i cookie che desideri inoltrare:
**Log di accesso**
Se configuri CloudFront per registrare le richieste e i cookie, CloudFront registra tutti i cookie e tutti gli attributi dei cookie, anche se configuri di CloudFront non inoltrare i cookie all'origine o se CloudFront configuri di inoltrare solo cookie specifici. Per ulteriori informazioni sulla CloudFront registrazione, vedere. [Registri di accesso (registri standard)](AccessLogs.md)
**Distinzione tra lettere maiuscole e minuscole**
I nomi e i valori dei cookie fanno entrambi distinzione tra maiuscole e minuscole. Ad esempio, se CloudFront è configurato per inoltrare tutti i cookie e due richieste di visualizzazione per lo stesso oggetto contengono cookie identici tranne che per i casi specifici, CloudFront memorizza l'oggetto due volte nella cache.
**CloudFront ordina i cookie**
Se CloudFront è configurato per inoltrare i cookie (tutti o un sottoinsieme), CloudFront ordina i cookie in ordine naturale in base al nome del cookie prima di inoltrare la richiesta all'origine.
I nomi dei cookie che iniziano con il `$` carattere non sono supportati. CloudFront rimuoverà il cookie prima di inoltrare la richiesta all'origine. Puoi rimuovere il carattere `$` o specificare un carattere diverso all’inizio del nome del cookie.
**`If-Modified-Since` e `If-None-Match`**
`If-Modified-Since`e le richieste `If-None-Match` condizionali non sono supportate quando CloudFront è configurato per inoltrare i cookie (tutti o un sottoinsieme).
**Il formato standard della coppia nome-valore obbligatorio**
CloudFront inoltra un'intestazione di cookie solo se il valore è conforme al formato [standard della coppia nome-valore](https://tools.ietf.org/html/rfc6265#section-4.1.1), ad esempio: `"Cookie: cookie1=value1; cookie2=value2"`
**Disabilitazione della memorizzazione nella cache delle intestazioni `Set-Cookie`**
Se CloudFront è configurato per inoltrare i cookie all'origine (che si tratti di tutti i cookie o di cookie specifici), memorizza anche nella cache le intestazioni ricevute nella risposta all'`Set-Cookie`origine. CloudFront include queste `Set-Cookie` intestazioni nella risposta al visualizzatore originale e le include anche nelle risposte successive che vengono fornite dalla cache. CloudFront
Se desideri ricevere i cookie all'origine ma non vuoi CloudFront memorizzare nella cache le `Set-Cookie` intestazioni nelle risposte dell'origine, configura la tua origine per aggiungere un'`Cache-Control`intestazione con una `no-cache` direttiva che specifichi `Set-Cookie` come nome di campo. Ad esempio: `Cache-Control: no-cache="Set-Cookie"`. Per ulteriori informazioni, consulta l’argomento relativo alle [direttive di controllo delle risposte della cache](https://tools.ietf.org/html/rfc7234#section-5.2.2) nello standard *Hypertext Transfer Protocol (HTTP/1.1): Caching*.
**Lunghezza massima dei nomi dei cookie**
Se CloudFront configuri l'inoltro di cookie specifici all'origine, il numero totale di byte in tutti i nomi di cookie che configuri CloudFront per l'inoltro non può superare i 512 meno il numero di cookie che stai inoltrando. Ad esempio, se configuri di CloudFront inoltrare 10 cookie all'origine, la lunghezza combinata dei nomi dei 10 cookie non può superare i 502 byte (512-10).
Se configuri CloudFront per inoltrare tutti i cookie all'origine, la lunghezza dei nomi dei cookie non ha importanza.
Per informazioni sull'utilizzo della CloudFront console per aggiornare una distribuzione in modo da CloudFront inoltrare i cookie all'origine, consulta[Aggiornamento di una distribuzione](HowToUpdateDistribution.md). Per informazioni sull'utilizzo dell' CloudFront API per aggiornare una distribuzione, [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)consulta *Amazon CloudFront API Reference*.
# Caching dei contenuti in base alle intestazioni di richiesta
CloudFront consente di scegliere se CloudFront inoltrare le intestazioni all'origine e memorizzare nella cache versioni separate di un oggetto specificato in base ai valori di intestazione nelle richieste dei visualizzatori. In questo modo è possibile distribuire diverse versioni dei tuoi contenuti in base al dispositivo che l’utente utilizza, alla posizione del visualizzatore, al linguaggio utilizzato dal visualizzatore e a un’ampia gamma di altri criteri.
**Topics**
+ [
## Intestazioni e distribuzioni – Panoramica
](#header-caching-web)
+ [
## Selezione delle intestazioni su cui basare il caching
](#header-caching-web-selecting)
+ [
## Configurare CloudFront per rispettare le impostazioni CORS
](#header-caching-web-cors)
+ [
## Configurazione del caching in base al tipo di dispositivo
](#header-caching-web-device)
+ [
## Configurazione del caching in base alla lingua del visualizzatore
](#header-caching-web-language)
+ [
## Configurazione del caching in base alla posizione del visualizzatore
](#header-caching-web-location)
+ [
## Configurazione del caching in base al protocollo della richiesta
](#header-caching-web-protocol)
+ [
## Configurazione del caching per i file compressi
](#header-caching-web-compressed)
+ [
## In che modo il caching basato sulle intestazioni influenza le performance
](#header-caching-web-performance)
+ [
## In che modo il formato delle intestazioni e dei valori delle intestazioni si ripercuotono sul caching
](#header-caching-web-case)
+ [
## Intestazioni che vengono CloudFront restituite al visualizzatore
](#header-caching-web-response)
## Intestazioni e distribuzioni – Panoramica
Per impostazione predefinita, CloudFront non considera le intestazioni quando memorizza nella cache gli oggetti in posizioni periferiche. Se la tua origine restituisce due oggetti che differiscono solo per i valori nelle intestazioni della richiesta, CloudFront memorizza nella cache solo una versione dell'oggetto.
È possibile configurare CloudFront l'inoltro delle intestazioni all'origine, il che comporta CloudFront la memorizzazione nella cache di più versioni di un oggetto in base ai valori di una o più intestazioni di richiesta. CloudFront Per configurare la memorizzazione nella cache degli oggetti in base ai valori di intestazioni specifiche, specificate le impostazioni di comportamento della cache per la distribuzione. Per ulteriori informazioni, consulta [Cache basata su intestazioni di richiesta selezionate](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesForwardHeaders).
Ad esempio, supponiamo che le richieste del visualizzatore per `logo.jpg` contengano un’intestazione personalizzata `Product` con un valore di `Acme` o `Apex`. Quando CloudFront configurate la memorizzazione nella cache degli oggetti in base al valore dell'`Product`intestazione, CloudFront inoltra le richieste all'origine e include i `logo.jpg` valori dell'intestazione e dell'`Product`intestazione. CloudFront memorizza nella cache `logo.jpg` una volta per le richieste in cui si trova il valore dell'`Product`intestazione `Acme` e una volta per le richieste in cui si trova il valore. `Apex`
Puoi configurare ogni comportamento cache in una distribuzione per eseguire una delle seguenti operazioni:
+ Inoltro di tutte le intestazioni al server di origine
**Nota**
**Per le impostazioni della cache legacy**: se si configura CloudFront l'inoltro di tutte le intestazioni all'origine, CloudFront non memorizza nella cache gli oggetti associati a questo comportamento della cache. ma invia ogni richiesta all’origine.
+ Inoltra un elenco di intestazioni che hai specificato. CloudFront memorizza nella cache gli oggetti in base ai valori di tutte le intestazioni specificate. CloudFront inoltra anche le intestazioni che inoltra per impostazione predefinita, ma memorizza nella cache gli oggetti solo in base alle intestazioni specificate.
+ Inoltra solo le intestazioni predefinite. In questa configurazione, CloudFront non memorizza nella cache gli oggetti in base ai valori nelle intestazioni della richiesta.
Per conoscere la quota corrente relativa al numero di intestazioni che puoi inoltrare per ogni comportamento cache o per richiedere una quota superiore, consulta [Quote delle intestazioni](cloudfront-limits.md#limits-custom-headers).
Per informazioni sull'utilizzo della CloudFront console per aggiornare una distribuzione in modo da CloudFront inoltrare le intestazioni all'origine, consulta. [Aggiornamento di una distribuzione](HowToUpdateDistribution.md) Per informazioni sull'utilizzo dell' CloudFrontAPI per aggiornare una distribuzione esistente, consulta [Update Distribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) in *Amazon CloudFront API Reference*.
## Selezione delle intestazioni su cui basare il caching
Le intestazioni che puoi inoltrare all'origine e su cui si CloudFront basa la memorizzazione nella cache dipendono dal fatto che l'origine sia un bucket Amazon S3 o un'origine personalizzata.
+ **Amazon S3:** puoi configurare CloudFront l'inoltro e la memorizzazione nella cache degli oggetti in base a una serie di intestazioni specifiche (consulta il seguente elenco di eccezioni). Tuttavia, ti consigliamo di evitare intestazioni di inoltro con un server di origine Amazon S3, a meno che non sia necessario implementare la condivisione delle risorse multi-origine (CORS) o si desideri personalizzare il contenuto utilizzando Lambda@Edge negli eventi relativi ai server di origine.
+ Per configurare CORS, è necessario inoltrare le intestazioni che consentono CloudFront di distribuire contenuti per siti Web abilitati per la condivisione di risorse tra le origini (CORS). Per ulteriori informazioni, consulta [Configurare CloudFront per rispettare le impostazioni CORS](#header-caching-web-cors).
+ Per personalizzare i contenuti utilizzando le intestazioni da inoltrare all'origine Amazon S3, è necessario scrivere e aggiungere funzioni Lambda @Edge e associarle alla distribuzione in modo che vengano attivate da un CloudFront evento rivolto all'origine. Per ulteriori informazioni sull’utilizzo delle intestazioni per personalizzare contenuti, consulta [Esempi di personalizzazione del contenuto in base alle intestazioni del paese o del tipo di dispositivo](lambda-examples.md#lambda-examples-redirecting-examples).
Consigliamo di evitare di inoltrare le intestazioni non utilizzate per personalizzare i contenuti perché inoltrare intestazioni aggiuntive può ridurre il rapporto di occorrenza nella cache. In altre parole, non è CloudFront possibile gestire tante richieste provenienti dalle cache edge quanto una percentuale di tutte le richieste.
+ **Origine personalizzata**: puoi configurare la memorizzazione nella cache in base CloudFront al valore di qualsiasi intestazione di richiesta tranne quanto segue:
+ `Connection`
+ `Cookie` – Se desideri inoltrare e memorizzare nella cache in base ai cookie, devi utilizzare un’impostazione separate nella tua distribuzione. Per ulteriori informazioni, consulta [Caching dei contenuti basati su cookie](Cookies.md).
+ `Host (for Amazon S3 origins)`
+ `Proxy-Authorization`
+ `TE`
+ `Upgrade`
Puoi CloudFront configurare la memorizzazione nella cache degli oggetti in base ai valori nelle `User-Agent` intestazioni `Date` and, ma non è consigliabile. Queste intestazioni hanno numerosi valori possibili e la memorizzazione nella cache in base ai loro valori potrebbe causare CloudFront l'inoltro di un numero significativamente maggiore di richieste all'origine.
Per un elenco completo delle intestazioni delle richieste HTTP e di come le CloudFront elabora, consulta. [Intestazioni e CloudFront comportamento delle richieste HTTP (origini personalizzate e Amazon S3)](RequestAndResponseBehaviorCustomOrigin.md#request-custom-headers-behavior)
## Configurare CloudFront per rispettare le impostazioni CORS
Se hai abilitato la condivisione di risorse multi-origine (CORS) su un bucket Amazon S3 o un server di origine personalizzato, devi selezionare intestazioni specifiche da inoltrare, in modo che vengano rispettate le impostazioni CORS. Le intestazioni che devi inoltrare variano a seconda del server di origine (Amazon S3 o personalizzato) e della volontà di memorizzare nella cache le risposte `OPTIONS`.
**Amazon S3**
+ Se desideri che le risposte `OPTIONS` vengano memorizzate nella cache, esegui le operazioni descritte di seguito:
+ Scegli le opzioni per le impostazioni predefinite di comportamento della cache che abilitano la memorizzazione nella cache per le risposte `OPTIONS`.
+ Configura CloudFront per inoltrare le seguenti intestazioni: `Origin``Access-Control-Request-Headers`, e. `Access-Control-Request-Method`
+ Se non desideri che le risposte `OPTIONS` vengano memorizzate nella cache, configura CloudFront affinché inoltri l'intestazione `Origin`, insieme ad altre intestazioni richieste dal server di origine, ad esempio, `Access-Control-Request-Headers`, `Access-Control-Request-Method` o altre.
**Server di origine personalizzati** – Inoltra l’intestazione `Origin` insieme a qualsiasi altra intestazione richiesta dal server di origine.
CloudFront Per configurare la memorizzazione nella cache delle risposte basate su CORS, è necessario CloudFront configurare l'inoltro delle intestazioni utilizzando una politica di cache. Per ulteriori informazioni, consulta [Controllo della chiave della cache con una policy](controlling-the-cache-key.md).
Per ulteriori informazioni su CORS e Amazon S3, consulta [Utilizzo delle funzionalità Cross-Origin Resource Sharing (CORS)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/cors.html) nella *Guida per l’utente di Amazon Simple Storage Service*.
## Configurazione del caching in base al tipo di dispositivo
Se desideri CloudFront memorizzare nella cache diverse versioni dei tuoi oggetti in base al dispositivo utilizzato dall'utente per visualizzare i tuoi contenuti, configura in modo CloudFront da inoltrare le intestazioni applicabili all'origine personalizzata:
+ `CloudFront-Is-Desktop-Viewer`
+ `CloudFront-Is-Mobile-Viewer`
+ `CloudFront-Is-SmartTV-Viewer`
+ `CloudFront-Is-Tablet-Viewer`
In base al valore dell'`User-Agent`intestazione, CloudFront imposta il valore di queste intestazioni su `true` o `false` prima dell'inoltro della richiesta all'origine. Se il dispositivo ricade in più di una categoria, allora più di un valore potrebbe essere `true`. Ad esempio, per alcuni tablet, CloudFront potrebbe impostare entrambi e su. `CloudFront-Is-Mobile-Viewer` `CloudFront-Is-Tablet-Viewer` `true`
## Configurazione del caching in base alla lingua del visualizzatore
Se desideri CloudFront memorizzare nella cache diverse versioni dei tuoi oggetti in base alla lingua specificata nella richiesta, configura CloudFront l'inoltro dell'`Accept-Language`intestazione all'origine.
## Configurazione del caching in base alla posizione del visualizzatore
Se desideri CloudFront memorizzare nella cache diverse versioni dei tuoi oggetti in base al paese da cui proviene la richiesta, configura CloudFront l'inoltro dell'`CloudFront-Viewer-Country`intestazione all'origine. CloudFront converte automaticamente l'indirizzo IP da cui proviene la richiesta in un codice del paese di due lettere. Per un easy-to-use elenco dei codici dei paesi, ordinabili per codice e per nome del paese, consulta la voce di Wikipedia [ISO](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2) 3166-1 alpha-2.
## Configurazione del caching in base al protocollo della richiesta
Se desideri CloudFront memorizzare nella cache diverse versioni dei tuoi oggetti in base al protocollo della richiesta, HTTP o HTTPS, configura l'inoltro dell'`CloudFront-Forwarded-Proto`intestazione CloudFront all'origine.
## Configurazione del caching per i file compressi
Se la tua origine supporta la compressione Brotli, puoi memorizzare nella cache in base all’intestazione `Accept-Encoding`. Configurare il caching solo in base a `Accept-Encoding` se l’origine distribuisce diversi contenuti in base all’intestazione.
## In che modo il caching basato sulle intestazioni influenza le performance
Quando configuri la cache in base CloudFront a una o più intestazioni e le intestazioni hanno più di un valore possibile, CloudFront inoltra più richieste al server di origine per lo stesso oggetto. Questo rallenta le prestazioni e aumenta il carico di lavoro del server di origine. Se il tuo server di origine restituisce lo stesso oggetto indipendentemente dal valore di una determinata intestazione, ti consigliamo di non configurare la cache in base CloudFront a quell'intestazione.
Se configuri CloudFront per inoltrare più di un'intestazione, l'ordine delle intestazioni nelle richieste dei visualizzatori non influisce sulla memorizzazione nella cache, purché i valori siano gli stessi. Ad esempio, se una richiesta contiene le intestazioni A:1, B:2 e un'altra richiesta contiene B:2, A:1, memorizza nella cache solo una copia dell'oggetto. CloudFront
## In che modo il formato delle intestazioni e dei valori delle intestazioni si ripercuotono sul caching
Quando viene CloudFront memorizzata nella cache in base ai valori dell'intestazione, non considera le maiuscole e le minuscole del nome dell'intestazione, ma le maiuscole e minuscole del valore dell'intestazione:
+ Se le richieste del visualizzatore includono entrambi `Product:Acme` e`product:Acme`, CloudFront memorizza un oggetto nella cache solo una volta. L’unica differenza tra loro è il caso del nome dell’intestazione, che non interessa la memorizzazione nella cache.
+ Se le richieste del visualizzatore includono entrambi `Product:Acme` e`Product:acme`, CloudFront memorizza un oggetto nella cache due volte, perché il valore è presente `Acme` in alcune richieste e `acme` in altre.
## Intestazioni che vengono CloudFront restituite al visualizzatore
La configurazione CloudFront per l'inoltro e la memorizzazione delle intestazioni nella cache non influisce sulle intestazioni CloudFront restituite al visualizzatore. CloudFront restituisce tutte le intestazioni che ottiene dall'origine con alcune eccezioni. Per ulteriori informazioni, consulta l’argomento applicabile:
+ **Origini di Amazon S3** Consulta [Intestazioni di risposta HTTP che rimuovono o aggiornano CloudFront](RequestAndResponseBehaviorS3Origin.md#response-s3-removed-headers).
+ **Origini personalizzate ** Consulta [Intestazioni di risposta HTTP che CloudFront rimuovono o sostituiscono](RequestAndResponseBehaviorCustomOrigin.md#ResponseCustomRemovedHeaders).