Domande frequenti su Amazon CloudFront

CloudFront offre due modi completamente gestiti per proteggere le origini:

1. Origin Access Control (OAC): CloudFront Origin Access Control (OAC) è una funzionalità di sicurezza che limita l'accesso alle origini Amazon Simple Storage Service (S3), alle origini AWS Elemental e agli URL delle funzioni Lambda, garantendo che solo CloudFront possa accedere ai contenuti.
2. Origini VPC: le origini del cloud privato virtuale (VPC) CloudFront consentono di utilizzare Amazon CloudFront per distribuire contenuti da applicazioni ospitate in una sottorete privata VPC. Nelle sottoreti è possibile utilizzare Application Load Balancer (ALB), Network Load Balancer (NLB) e istanze EC2 come origini VPC con CloudFront.

Se le soluzioni gestite da CloudFront non soddisfano i requisiti dei casi d'uso, di seguito sono riportati alcuni degli approcci alternativi disponibili:

1. Intestazioni di origine personalizzate: con CloudFront, è possibile aggiungere intestazioni personalizzate alle richieste in arrivo e quindi configurare l'origine affinché convalidi questi valori di intestazione specifici, limitando efficacemente l'accesso solo alle richieste instradate tramite CloudFront. Questo metodo crea un ulteriore livello di autenticazione, riducendo in modo significativo il rischio di accesso diretto non autorizzato all'origine.
2. Elenco di IP autorizzati: è possibile configurare il gruppo di sicurezza o il firewall dell'origine affinché consenta esclusivamente il traffico in entrata dagli intervalli IP di CloudFront. AWS mantiene e aggiorna regolarmente questi intervalli IP per praticità. Per informazioni dettagliate sull'implementazione dell'elenco di IP autorizzati, consulta la documentazione completa all'indirizzo: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/LocationsOfEdgeServers.html#managed-prefix-list. Questa risorsa offre indicazioni dettagliate su come utilizzare gli elenchi di prefissi gestiti di AWS per una configurazione di sicurezza ottimale.
3. Crittografia SSL/TLS: è possibile configurare CloudFront per utilizzare esclusivamente connessioni HTTPS con l'origine per ottenere una protezione dei dati end-to-end attraverso una comunicazione crittografata tra la distribuzione CloudFront e l'origine.

Origini del cloud privato virtuale (VPC) CloudFront è una nuova funzionalità che consente di utilizzare CloudFront per distribuire contenuti da applicazioni ospitate in una sottorete privata VPC. Con le origini VPC, è possibile collocare le applicazioni in una sottorete privata del VPC, accessibile solo tramite le distribuzioni CloudFront. Ciò elimina il requisito di un nome DNS (Domain Name Service) risolvibile esternamente per l'origine. È possibile configurare le origini VPC con applicazioni in esecuzione su Application Load Balancer (ALB), Network Load Balancer (NLB) e istanze EC2. Le origini VPC sono disponibili solo nelle regioni commerciali AWS; l'elenco completo delle regioni AWS supportate è disponibile qui.

È consigliabile utilizzare le origini VPC con CloudFront se si desidera migliorare la sicurezza delle applicazioni Web mantenendo al contempo prestazioni elevate e scalabilità globale. Con le origini VPC, è possibile limitare l'accesso alle origini in un VPC solo alle distribuzioni CloudFront senza dover disporre di configurazioni complesse come intestazioni segrete o liste di controllo degli accessi. Le origini VPC consentono inoltre di ottimizzare i costi IPv4 consentendo di instradare gratuitamente le connessioni alle origini in una sottorete privata con indirizzi IP IPv4 interni. Le origini VPC sono perfette se si desidera semplificare la gestione della sicurezza, consentendo di concentrarsi maggiormente sulla crescita del core business piuttosto che sulla gestione di complesse misure di sicurezza.

1. Sicurezza: con le origini VPC, è possibile migliorare il livello di sicurezza delle applicazioni posizionando i bilanciatori del carico e le istanze EC2 in sottoreti private, rendendo CloudFront l'unico punto di ingresso. Le richieste degli utenti passano da CloudFront alle origini VPC tramite una connessione privata e sicura, fornendo ulteriore sicurezza per le applicazioni.
2. Gestione: le origini VPC riducono il carico operativo richiesto per una connettività sicura di CloudFront Origin, consentendo di spostare le origini in sottoreti private senza accesso pubblico e senza dover implementare liste di controllo degli accessi, intestazioni condivise segrete o altri meccanismi per limitare l'accesso alle origini. In questo modo è facile proteggere le applicazioni web con CloudFront senza dover investire in un lavoro di sviluppo indifferenziato.
3. Scalabilità e prestazioni: con le origini VPC, i clienti possono utilizzare le posizioni edge globali di CloudFront e le reti backbone AWS, usufruendo di scalabilità e prestazioni simili a quelle di altri metodi di distribuzione dei contenuti esistenti e migliorando al contempo il livello di sicurezza. La soluzione ottimizza la gestione della sicurezza e la distribuzione globale delle applicazioni per i clienti, semplificando l'utilizzo di CloudFront come unica porta d'ingresso per le applicazioni.

Le origini del cloud privato virtuale (VPC) CloudFront consentono di utilizzare CloudFront per distribuire contenuti da applicazioni ospitate in una sottorete privata VPC con Application Load Balancer, Network Load Balancer e istanze EC2. Il Blocco dell'accesso pubblico per VPC Amazon (VPC BPA) è un controllo semplice e dichiarativo che blocca in modo autorevole il traffico VPC in entrata (ingress) e in uscita (egress) attraverso i percorsi Internet forniti da AWS. Quando VPC BPA è abilitato su una sottorete con origine VPC, le connessioni attive da CloudFront vengono terminate a favore di quella sottorete. Le nuove connessioni non vengono inviate alla sottorete, ma vengono instradate verso un'altra sottorete in cui l'origine del VPC si trova dove BPA non è abilitato oppure vengono interrotte se tutte le sottoreti in cui l'origine VPC si trova hanno il BPA abilitato.

Le origini VPC supportano gli Application Load Balancer, i Network Load Balancer e le istanze EC2.

No, IPv6 non è supportato per le origini private VPC. Per le origini VPC sono necessari indirizzi IPv4 privati, che sono gratuiti e non comportano costi IPv4.

Gli IP statici Anycast di Amazon CloudFront sono set di indirizzi IP statici che consentono di connettersi a tutte le posizioni edge CloudFront a livello globale. Forniscono un piccolo elenco statico di IP che può essere utilizzato per casi d'uso come la fatturazione a tasso zero, in cui i provider di rete rinunciano ai costi dei dati per indirizzi IP specifici con accordi specifici, e l'elenco di autorizzazione lato client per una maggiore sicurezza. Utilizzando gli IP statici Anycast, si elimina la sfida operativa dell'aggiornamento costante degli elenchi di autorizzazione o delle mappature IP, poiché lo stesso set di IP funziona per l'intera rete globale di CloudFront pur usufruendo di tutte le funzionalità di CloudFront.

Per abilitare gli IP statici Anycast, per prima cosa è necessario richiedere e creare un elenco di IP statici Anycast nell'account AWS. Una volta creato l'elenco, è possibile associare le distribuzioni CloudFront all'elenco degli IP statici Anycast. Questa operazione può essere eseguita tramite la sezione IP statici Anycast nella Console AWS o modificando ciascuna distribuzione e selezionando l'elenco di IP statici Anycast desiderato dal menu a tendina. Dopo aver salvato queste modifiche, il set specifico di indirizzi IP statici associati alle distribuzioni sarà disponibile per la copia o il download dall'elenco visualizzato nella Console AWS o tramite le API.

Quando si abilitano gli indirizzi IP di CloudFront Anycast si ricevono 21 indirizzi IP per IPv4. Tutti questi indirizzi IP dovranno essere aggiunti a tutti gli elenchi di autorizzazioni pertinenti.

No. CloudFront Anycast sarà disponibile solo con IP distribuiti in aree geografiche.

Man mano che CloudFront aggiunge nuove posizioni edge, l'elenco degli IP statici Anycast continuerà a rimanere valido. Annunceremo gli IP dalle nuove posizioni edge, a seconda dei casi.

Tutte le funzionalità di CloudFront funzionano con Anycast, ma sono presenti tre importanti eccezioni: 1) gli IP statici Anycast non supportano i client legacy che non supportano SNI, 2) è necessario utilizzare la categoria di prezzo Tutti quando si utilizzano IP statici Anycast e 3) è necessario disabilitare IPv6 quando si utilizzano IP statici Anycast. Gli IP statici Anycast funzionano nella fase di risoluzione DNS e, una volta che la richiesta raggiunge un host, tutte le funzionalità e le integrazioni esistenti con altri servizi AWS continueranno a essere disponibili per le distribuzioni.

È possibile utilizzare gli IP statici Anycast con più distribuzioni, che devono però trovarsi nello stesso account. Gli IP statici di CloudFront Anycast possono essere associati a più distribuzioni dell'account. L'indirizzo IP statico di CloudFront Anycast supporterà l'indicazione del nome del server (SNI) in modo che venga restituito il certificato corretto da qualsiasi numero di distribuzioni associate alla policy dell'IP statico Anycast. Se si desidera disporre di IP statici distinti per più distribuzioni all'interno dell'account, è possibile creare un elenco di IP statici Anycast aggiuntivo e associarlo a distribuzioni specifiche.

Quando si crea una nuova distribuzione in un account con IP statici Anycast abilitati, è necessario associare esplicitamente la nuova distribuzione all'elenco di IP statici anycast esistente. Per impostazione predefinita, la nuova distribuzione utilizzerà indirizzi IP dinamici finché non lo colleghi all'elenco di IP statici.

1. Log standard (log di accesso): i log standard di CloudFront offrono record dettagliati su ogni richiesta effettuata a una distribuzione. Questi log sono utili per diversi scenari, tra cui gli audi di sicurezza e di accesso.
2. Log in tempo reale: i log in tempo reale di CloudFront offrono informazioni relative alle richieste effettuate a una distribuzione in tempo reale (i record dei log vengono distribuiti dopo pochi secondi dalla ricezione delle richieste). Puoi scegliere la frequenza di campionamento per i log in tempo reale, ossia la percentuale di richieste per cui desideri ricevere log in tempo reale.
3. Log delle funzioni edge: è possibile utilizzare Amazon CloudWatch Logs per ricevere log relativi alle funzioni edge, sia per Lambda@Edge che per Funzioni CloudFront. È possibile accedere ai log utilizzando la console CloudWatch o l'API CloudWatch Logs. Per ulteriori informazioni, consulta la pagina Edge function logs.
4. Log di attività di servizio: è possibile utilizzare AWS CloudTrail per registrare l'attività di servizio di CloudFront (attività API) nell'account AWS. CloudTrail offre un registro delle operazioni API intraprese da un utente, un ruolo o un servizio AWS in CloudFront. Con le informazioni raccolte da CloudTrail, è possibile risalire alla singola richiesta API effettuata a CloudFront, all'indirizzo IP da cui proviene, all'utente che l'ha effettuata, all'orario dell'evento e altri dettagli aggiuntivi. Per ulteriori informazioni, consulta la pagina Logging Amazon CloudFront API calls using AWS CloudTrail.

• I log standard di CloudFront vengono distribuiti nel bucket Amazon S3 a tua scelta, ad Amazon CloudWatch Logs e ad Amazon Data Firehose. Per ulteriori informazioni, consulta la pagina Use standard logs (access logs).
• I log in tempo reale di CloudFront vengono distribuiti nel flusso di dati prescelto in Flusso di dati Amazon Kinesis. CloudFront effettua addebiti per log in tempo reale, in aggiunta agli addebiti relativi all'utilizzo di Kinesis Data Streams. Per ulteriori informazioni, consulta la pagina Use real-time logs.
• I log delle funzioni edge di CloudFront (Lambda@Edge e Funzioni CloudFront) vengono distribuiti in Amazon CloudWatch Logs

I log di accesso standard di CloudFront possono essere distribuiti in Amazon S3, Amazon CloudWatch e Amazon Data Firehose. È possibile scegliere il formato di output dei log (testo normale, w3c, JSON, csv e parquet). È possibile selezionare i campi da registrare e l'ordine con cui includere tali campi nei log. Per i log distribuiti in S3, è anche possibile abilitare il partizionamento per i log S3, ovvero configurare il partizionamento automatico dei log su base oraria o giornaliera. È anche possibile distribuire i log di accesso standard nei bucket S3 nelle regioni AWS con consenso esplicito. Consulta la sezione Standard Access logs della guida per gli sviluppatori di CloudFront per ulteriori informazioni.

CloudFront non prevede costi per l'abilitazione dei log standard, ma sono previsti addebiti per la distribuzione, l'archiviazione e l'accesso ai log in base alla destinazione di consegna. Consulta la sezione “Funzionalità aggiuntive” della pagina dei prezzi di CloudFront per ulteriori informazioni.

Puoi scegliere una destinazione in base al tuo caso d'uso. Se hai casi d'uso sensibili al tempo e richiedi l'accesso rapido ai dati dei log in pochi secondi, scegli i log in tempo reale. Se hai bisogno che la tua pipeline di log in tempo reale sia più economica, puoi scegliere di filtrare i dati di log abilitando i log solo per comportamenti cache specifici o scegliendo una frequenza di campionamento inferiore. La pipeline di log in tempo reale è progettata per la consegna rapida dei dati. Pertanto, i record di log possono essere eliminati in caso di ritardi nei dati. D'altra parte, se hai bisogno di una soluzione di elaborazione dei log a basso costo senza la necessità di dati in tempo reale, l'opzione dei log standard è più adatta a te. I log standard in S3 sono progettati per la completezza e sono in genere disponibili in pochi minuti. Questi log possono essere abilitati per l'intera distribuzione e non per comportamenti cache specifici. Pertanto, se hai bisogno di log per indagini, audit e analisi ad hoc, puoi scegliere di abilitare solo i log standard in S3. Puoi anche decidere di utilizzare una combinazione di entrambi i log. Utilizza un elenco filtrato di log in tempo reale per la visibilità operativa, quindi utilizza i log standard per l'audit.
 

I log standard di CloudFront vengono consegnati nel bucket S3. È inoltre possibile utilizzare l'integrazione creata da soluzioni di terze parti come DataDog e Sumologic per creare dashboard da questi log.

I log in tempo reale sono consegnati al Kinesis Data Stream. Da Kinesis Data Streams, i log possono essere pubblicati in Amazon Kinesis Data Firehose. Amazon Kinesis Data Firehose supporta la consegna facile dei dati ad Amazon S3, Amazon Redshift, Amazon Elasticsearch Service e a provider di servizi come Datadog, New Relic e Splunk. Kinesis Firehose supporta la consegna dei dati anche a un endpoint HTTP generico.

Utilizza la seguente procedura per stimare il numero di shard necessari:

1. Calcola (o stima) il numero di richieste al secondo ricevute dalla distribuzione CloudFront. Per calcolare le richieste al secondo puoi utilizzare i report di utilizzo di CloudFront o i parametri CloudFront.
2. Determina la dimensione tipica di un singolo record di log in tempo reale. Un record tipico che include tutti i campi disponibili è circa 1 KB. Se non sei sicuro di quale sia la dimensione del tuo record di log, puoi abilitare i log in tempo reale con una bassa frequenza di campionamento (ad esempio, 1%), quindi calcolare la dimensione media del record utilizzando i dati di monitoraggio in Kinesis Data Streams (numero totale di record diviso per byte totali in entrata).
3. Moltiplica quindi il numero di richieste al secondo (dal passaggio 1) per la dimensione di un record di log in tempo reale tipico (dal passaggio 2) per determinare la quantità di dati al secondo che è probabile che la configurazione del registro in tempo reale invii a Kinesis Data Stream.
4. Con i dati al secondo, potrai calcolare il numero di shard necessari. Un singolo shard può gestire non più di 1 MB al secondo e 1.000 richieste (record di log) al secondo. Quando calcoli il numero di shard necessari, è preferibile aggiungere fino al 25% come buffer.

Ad esempio, supponiamo che la tua distribuzione riceva 10.000 richieste al secondo e che la dimensione dei record di log in tempo reale sia in genere 1 KB. Ciò significa che la configurazione dei log in tempo reale potrebbe generare 10.000.000 di byte (10.000 moltiplicati per 1.000) o 9,53 MB al secondo. In questo caso, avrai bisogno solo di 10 shard Kinesis. Per avere un po' di buffer, dovresti pensare di creare almeno 12 shard.