Distribuzioni e origini CloudFront

Amazon CloudFront è la Content Delivery Network (CDN) globale di AWS, che memorizza nella cache e distribuisce contenuti da edge location distribuite in oltre 400 città di più di 90 Paesi. Quando un utente richiede un contenuto, CloudFront lo fornisce dall'edge location più vicina, riducendo drasticamente la latenza rispetto al recupero dal server di origine.

CloudFront non serve solo per i file statici: accelera anche contenuti dinamici, API e streaming video. Si integra con altri servizi AWS come S3, ALB, Lambda@Edge, WAF e Shield, diventando il livello di distribuzione standard per le moderne architetture AWS.

Una distribuzione CloudFront è l'unità di configurazione principale. Definisce una o più origini (dove risiedono i contenuti), i comportamenti della cache (come vengono memorizzati nella cache i diversi percorsi URL), le impostazioni di sicurezza e i livelli di prezzo. Si accede ai contenuti tramite il nome di dominio della distribuzione (ad esempio d1234abcdef.cloudfront.net) o tramite un dominio personalizzato (ad esempio cdn.example.com), utilizzando un record CNAME o ALIAS.

Dopo la creazione, le distribuzioni impiegano 10–15 minuti per essere distribuite globalmente in tutte le edge location. Anche le modifiche a una distribuzione esistente richiedono diversi minuti per propagarsi. Storicamente esistevano due tipi di distribuzione, ma oggi tutte le distribuzioni utilizzano un'interfaccia di configurazione unificata.

Utilizzare un bucket S3 come origine CloudFront è uno dei pattern più comuni. CloudFront recupera gli oggetti da S3, li memorizza nella cache nelle edge location e fornisce le richieste successive dalla cache senza accedere nuovamente a S3. Questo riduce i costi delle richieste S3, migliora la latenza per gli utenti globali e riduce il carico sulla larghezza di banda di S3.

Per distribuire un sito basato su S3, non è necessario rendere pubblico il bucket. Utilizzi invece Origin Access Control (OAC), il sostituto moderno di Origin Access Identity (OAI). OAC concede solo alla distribuzione CloudFront l'autorizzazione a leggere dal bucket, mantenendo S3 privato mentre CloudFront distribuisce pubblicamente i contenuti.

CloudFront supporta anche le origini personalizzate: qualsiasi server HTTP o HTTPS accessibile da Internet, inclusi istanze EC2, Application Load Balancer, endpoint API Gateway e server on-premises. Le origini personalizzate consentono a CloudFront di memorizzare nella cache e accelerare applicazioni dinamiche e API, non solo file statici.

Quando utilizzate un ALB come origine personalizzata, configurate l'ALB in modo che nel relativo security group accetti connessioni solo dagli intervalli IP di CloudFront. In questo modo tutto il traffico esterno passa attraverso CloudFront, consentendo l'applicazione delle regole WAF e la terminazione TLS sull'edge, mentre l'ALB rimane interno ad AWS.

Origin Access Identity (OAI) era il metodo originale per limitare l'accesso al bucket S3 da parte di CloudFront. Si tratta di un'identità utente speciale di CloudFront a cui viene concessa l'autorizzazione nella policy del bucket S3. Sebbene OAI funzioni ancora, è considerato un metodo legacy.

Origin Access Control (OAC) è il sostituto moderno. OAC supporta tutti i tipi di bucket S3 (inclusi S3 nelle Regioni AWS Cina e i bucket crittografati con SSE-KMS), utilizza service principal IAM per un controllo più granulare e firma automaticamente le richieste a S3 tramite SigV4. Per le nuove distribuzioni, utilizzi sempre OAC invece di OAI.

La Viewer Protocol Policy controlla il modo in cui CloudFront gestisce le connessioni tra gli utenti (viewer) e l'edge location:

• HTTP e HTTPS: consente entrambi; non è consigliato per i contenuti sensibili
• Redirect HTTP to HTTPS: reindirizza in modo trasparente le richieste HTTP a HTTPS; è l'impostazione più comune
• HTTPS Only: rifiuta completamente le connessioni HTTP; da utilizzare per imporre rigorosamente TLS

Separatamente, la Origin Protocol Policy controlla il modo in cui CloudFront comunica con l'origine: solo HTTP, solo HTTPS oppure corrispondenza con il viewer. Per le origini S3 con OAC, CloudFront utilizza sempre HTTPS.

Per distribuire contenuti da cdn.example.com invece che dal dominio CloudFront, configuri un Alternate Domain Name (CNAME) nella distribuzione e associ un certificato SSL/TLS proveniente da AWS Certificate Manager (ACM). Il certificato ACM deve trovarsi nella Regione us-east-1 (indipendentemente dalla posizione da cui la distribuzione serve il traffico), perché CloudFront è un servizio globale gestito da us-east-1.

Crei il record di Route 53 come record ALIAS che punti al nome di dominio della distribuzione CloudFront. CloudFront fornisce automaticamente il certificato alle richieste SNI corrispondenti.

La Price Class di CloudFront determina quali edge location vengono utilizzate per servire la distribuzione. Le classi di prezzo più elevate includono edge location più costose (in genere in regioni con costi di banda maggiori):

• Price Class 100: solo Nord America ed Europa (costo più basso)
• Price Class 200: Nord America, Europa, Asia, Medio Oriente e Africa
• Price Class All: tutte le edge location nel mondo (prestazioni migliori, costo più elevato)

Utilizzi Price Class 100 per strumenti interni o per utenti limitati al Nord America e all'Europa. Utilizzi Price Class All per applicazioni globali rivolte ai consumatori.

I gruppi di origini abilitano il failover dell'origine CloudFront. In un gruppo si definiscono un'origine primaria e un'origine secondaria. Se l'origine primaria restituisce uno specifico codice di errore HTTP (ad esempio 500, 502, 503 o 504), CloudFront riprova automaticamente la richiesta utilizzando l'origine secondaria.

Il failover dell'origine è utile per il disaster recovery: mantenga un bucket S3 primario in us-east-1 e una copia replicata in us-west-2 come origine secondaria. In caso di interruzione di S3, CloudFront esegue il failover in modo trasparente, senza richiedere modifiche al DNS. Questo modello integra la replica S3 Cross-Region Replication.

CloudFront può fornire log di accesso a un bucket S3, registrando i dettagli di ogni richiesta del visualizzatore: timestamp, edge location, codice di stato, byte trasferiti, hit/miss della cache, user agent e altro ancora. I log vengono forniti in batch ogni pochi minuti.

Utilizzi i log di accesso per analizzare i modelli di traffico, identificare i contenuti più richiesti, verificare i campi rilevanti per la sicurezza (IP, referrer, user agent) e misurare i rapporti di hit della cache. Il campo x-edge-result-type indica se, sull'edge, la richiesta ha prodotto un Hit, un Miss o un RefreshHit.

CloudFront dispone di due livelli di infrastruttura di caching:

• Edge location: centinaia di PoP distribuiti nel mondo e vicini agli utenti finali; forniscono contenuti nella cache con latenza minima
• Regional Edge Cache (REC): 13 cache più grandi e persistenti, situate tra le edge location e le origini; forniscono contenuti non abbastanza popolari da rimanere nelle cache più piccole delle edge location

Quando una richiesta non trova il contenuto nella cache dell'edge location, CloudFront controlla la REC prima di raggiungere l'origine. Le REC sono trasparenti: non vengono configurate direttamente, ma migliorano significativamente i rapporti di hit della cache per i contenuti a coda lunga e riducono il carico sull'origine.

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

In questa lezione ha imparato che: le distribuzioni CloudFront memorizzano i contenuti nella cache delle edge location a livello globale, OAC mantiene privati i bucket S3 consentendo al contempo l'accesso da parte di CloudFront e le origini personalizzate supportano ALB, API Gateway e qualsiasi server HTTP. I certificati ACM per CloudFront devono essere predisposti in us-east-1. Nella prossima lezione esamineremo i comportamenti della cache e le impostazioni TTL.