Comportamenti della cache e impostazioni TTL

I comportamenti della cache sono le regole che indicano a CloudFront come gestire le richieste per diversi pattern di percorso URL. Ogni comportamento della cache associa un pattern di percorso (ad esempio /images/*, /api/*, *.css) a un'origine specifica e a una configurazione di caching.

Una distribuzione dispone di un Default Cache Behavior (che corrisponde a tutti i percorsi non gestiti da comportamenti più specifici) e di un massimo di 25 comportamenti aggiuntivi basati sul percorso. CloudFront valuta i comportamenti dal più specifico al meno specifico, quindi utilizza quello predefinito se nessuno dei precedenti corrisponde.

I pattern di percorso supportano i caratteri jolly: * corrisponde a qualsiasi combinazione di caratteri, incluse le barre, mentre ? corrisponde a un singolo carattere. Esempi:

• /images/* — tutti gli URL che iniziano con /images/
• *.jpg — tutte le richieste che terminano con .jpg, indipendentemente dalla posizione nel percorso
• /api/v2/* — tutte le route API v2
• /static/??.css — file CSS statici con esattamente due caratteri prima di .css

I comportamenti vengono valutati nell'ordine indicato nella configurazione della distribuzione. Inserisca prima i pattern più specifici. Il comportamento predefinito (*) corrisponde sempre per ultimo.

CloudFront separa la logica di caching in due tipi di policy:

• Cache Policy: definisce ciò che CloudFront utilizza come chiave della cache, ovvero la combinazione di header, stringhe di query e cookie che determina se un oggetto nella cache corrisponde a una richiesta. Imposta inoltre i limiti TTL.
• Origin Request Policy: definisce quali header, stringhe di query e cookie vengono inoltrati all'origine, anche se non fanno parte della chiave della cache (per inviare all'origine gli header di autenticazione senza variare la cache per ogni token)

AWS fornisce policy gestite (ad esempio CachingOptimized e CachingDisabled) che coprono la maggior parte dei casi d'uso, oppure è possibile creare policy personalizzate.

CloudFront rispetta tre valori TTL definiti dalla Cache Policy:

• Minimum TTL: il periodo di tempo minimo per cui CloudFront memorizza un oggetto nella cache, indipendentemente dagli header dell'origine (valore predefinito: 0)
• Default TTL: il periodo di tempo per cui CloudFront memorizza un oggetto nella cache quando l'origine non invia un header Cache-Control o Expires (valore predefinito: 86.400 secondi = 1 giorno)
• Maximum TTL: il periodo di tempo massimo per cui CloudFront memorizza un oggetto nella cache, limitando la direttiva Cache-Control max-age dell'origine (valore predefinito: 31.536.000 = 1 anno)

Questi tre valori delimitano la durata effettiva della cache indicata dalle origini tramite gli header Cache-Control.

Quando l'origine invia un header Cache-Control: max-age=3600, CloudFront memorizza l'oggetto nella cache per 3.600 secondi, purché questo valore rientri nei limiti Minimum e Maximum TTL della Cache Policy. Se l'origine invia Cache-Control: no-cache o Cache-Control: no-store, CloudFront verifica l'origine prima di fornire la copia nella cache ogni volta.

Per gli asset statici che cambiano raramente, imposti un max-age lungo (ad esempio 31536000 = 1 anno) e utilizzi il cache busting, includendo un hash del contenuto nei nomi dei file (ad esempio app.a3f4b5.js), in modo che l'URL cambi quando cambia il contenuto e la versione precedente nella cache venga invalidata automaticamente.

Un modello efficace per i comportamenti della cache separa i contenuti statici da quelli dinamici:

• /static/*, *.css, *.js, *.jpg → origine S3, policy CachingOptimized (TTL elevato, cookie e stringhe di query esclusi dalla chiave della cache)
• /api/* → origine ALB, policy CachingDisabled (recupero sempre dall'origine, tutti gli header e i cookie inoltrati)
• /* (predefinito) → origine ALB, caching moderato

In questo modo il livello statico, altamente memorizzabile nella cache, viene separato dal livello API dinamico: si massimizzano i rapporti di hit della cache per i contenuti statici e si garantisce che le risposte API siano sempre aggiornate.

Quando aggiorna i contenuti in S3 o nell'origine e desidera fornire immediatamente la nuova versione da CloudFront senza attendere la scadenza del TTL, crea una invalidazione della cache. Specifichi i percorsi da invalidare (ad esempio /images/logo.png o /images/*) e CloudFront rimuoverà tali oggetti da tutte le cache edge.

Le invalidazioni hanno un costo: i primi 1.000 percorsi al mese sono gratuiti; quelli aggiuntivi hanno un costo per percorso. Le invalidazioni con caratteri jolly (ad esempio /*) contano come un solo percorso. È consigliabile utilizzare nomi di file versionati per gli asset statici (cache busting) invece di ricorrere frequentemente alle invalidazioni, così da ridurre costi e ritardi.

La chiave della cache è l'identificatore univoco che CloudFront utilizza per cercare una risposta memorizzata nella cache. Per impostazione predefinita, la chiave della cache contiene solo il percorso URL. L'inclusione di componenti aggiuntivi aumenta il numero di voci distinte nella cache:

• Stringhe di query: /search?q=aws e /search?q=s3 sono voci separate nella cache se q fa parte della chiave della cache
• Header: includere Accept-Encoding consente a CloudFront di memorizzare separatamente le versioni gzip e non gzip
• Cookie: includere i cookie di sessione crea voci nella cache per singolo utente, disabilitando di fatto il caching

Riduca al minimo i componenti della chiave della cache per ottenere la massima efficienza. Includa solo quelli che producono effettivamente contenuti di risposta diversi.

CloudFront può comprimere automaticamente gli oggetti basati su testo (HTML, CSS, JavaScript, JSON) utilizzando gzip o Brotli prima di distribuirli ai visualizzatori. Questo riduce le dimensioni del payload del 60–80% e migliora i tempi di caricamento delle pagine senza modifiche all'origine.

Per abilitare la compressione: si assicuri che la Cache Policy includa Accept-Encoding nella chiave della cache (CloudFront deve memorizzare separatamente le versioni gzip e non gzip) e abiliti Compress Objects Automatically nel comportamento della cache. CloudFront comprime gli oggetti di dimensioni superiori a 1.000 byte e inferiori a 10 MB.

Il rapporto di hit della cache è la percentuale di richieste servite dalla cache CloudFront senza raggiungere l'origine. Un rapporto elevato (80% o più) significa costi inferiori per l'origine e prestazioni migliori. Lo monitori tramite il report Cache Statistics della console CloudFront o tramite la metrica CloudWatch CacheHitRate.

Per migliorare il rapporto di hit della cache: aumenti i valori TTL, riduca il numero di header e cookie nella chiave della cache, utilizzi la normalizzazione delle stringhe di query (inoltrando solo quelle effettivamente utilizzate dall'applicazione) e imposti header Cache-Control appropriati sull'origine.

Ogni comportamento della cache può puntare a un'origine diversa, consentendo a una singola distribuzione CloudFront di fornire contenuti da più backend. Ad esempio:

• /static/* → origine S3 (bucket privato tramite OAC)
• /api/* → origine ALB in us-east-1
• /media/* → origine CDN MediaPackage per lo streaming video

Ogni comportamento configura inoltre in modo indipendente Viewer Protocol Policy, Allowed HTTP Methods e le associazioni alle funzioni (CloudFront Functions o Lambda@Edge). In questo modo una singola distribuzione diventa un livello di distribuzione flessibile e multiuso.

Verifichi la Sua comprensione dei concetti di AWS Solutions Architect (SAA-C03) trattati in questa lezione.

In questa lezione ha imparato che: i comportamenti della cache associano i pattern dei percorsi URL alle origini e alle regole di caching, i limiti Min/Default/Max TTL determinano per quanto tempo i contenuti vengono memorizzati nella cache, mentre gli header Cache-Control dell'origine hanno la precedenza quando sono presenti, e le invalidazioni della cache rimuovono immediatamente i contenuti obsoleti da tutte le edge location. Riduca al minimo i componenti della chiave della cache per massimizzare il rapporto di hit. Nella prossima lezione esamineremo gli URL firmati, i cookie firmati e le restrizioni geografiche.