Domande frequenti su Amazon CloudFront

Amazon CloudFront è un servizio web che offre alle aziende e agli sviluppatori di applicazioni web un modo semplice ed economico per distribuire contenuti con bassa latenza e alte velocità di trasferimento dati. Come altri servizi AWS, Amazon CloudFront è un'offerta self-service, con pagamento in base al consumo, senza impegno a lungo termine o tariffe minime. Con CloudFront, i file vengono distribuiti agli utenti finali utilizzando una rete di posizioni edge.

Amazon CloudFront fornisce una semplice API che consente di:

• distribuire contenuti a bassa latenza e a velocità elevata di trasferimento di dati tramite l'elaborazione di richieste utilizzando una rete di edge location in tutto il mondo.
• Inizia a utilizzarlo senza negoziare contratti e impegni minimi.

Fai clic sul pulsante “Crea un account gratuito” sulla pagina dei dettagli di Amazon CloudFront. Se scegli di utilizzare un altro servizio AWS come origine dei file elaborati tramite Amazon CloudFront, devi registrarti per tale servizio prima di creare distribuzioni CloudFront.

Per utilizzare Amazon CloudFront, ecco cosa devi fare:

• Per i file statici, memorizza le versioni definitive dei tuoi file in uno o più server di origine. Possono essere dei bucket di Amazon S3. Per contenuti generati dinamicamente personalizzati o adattati, puoi utilizzare Amazon EC2, o qualunque altro server Web, come server di origine. Questi server di origine memorizzano o generano i contenuti che verranno distribuiti tramite Amazon CloudFront.
• Registra i tuoi server di origine con Amazon CloudFront con una semplice chiamata API. Questa chiamata restituirà un nome di dominio CloudFront.net che puoi utilizzare per distribuire contenuti dai tuoi server di origine tramite il servizio Amazon CloudFront. Per esempio, puoi registrare il bucket Amazon S3 “bucketname.s3.amazonaws.com” come origine per tutti i contenuti statici e l'istanza Amazon EC2 “dynamic.myoriginserver.com” per tutti i contenuti dinamici. Poi, utilizzando l'API o la Console di gestione AWS, puoi creare una distribuzione Amazon CloudFront che può restituire “abc123.cloudfront.net” come nome di dominio della distribuzione.
• Includi il nome di dominio cloudfront.net o un alias CNAME creato da te nella tua applicazione Web, lettore multimediale o sito Web. Ogni richiesta effettuata utilizzando il nome di dominio cloudfront.net (o il CNAME impostato da te) viene instradata verso la edge location più idonea per distribuire i contenuti con le prestazioni più elevate. La edge location proverà a elaborare la richiesta con una copia locale del file. Se non c'è una copia locale disponibile, Amazon CloudFront prenderà una copia dal server di origine. La copia sarà disponibile in quella posizione edge per future richieste.

Amazon CloudFront impiega una rete globale di posizioni edge e cache edge regionali in cui vengono memorizzate copie cache dei contenuti vicino agli utenti che ne usufruiranno. Con Amazon CloudFront, le richieste degli utenti finali vengono elaborate dalla edge location più vicina a loro. In questo modo le richieste devono percorrere meno strada e le prestazioni sono migliori. Per i file che non sono memorizzati in edge location o cache edge regionali, Amazon CloudFront mantiene connessioni permanenti con i server di origine, in modo che i file possano essere recuperati dai server di origine il più rapidamente possibile. Oltre a questo, Amazon CloudFront si avvale di ottimizzazioni supplementari (ad es., una finestra di congestione iniziale TCP più ampia) per fornire prestazioni più elevate durante la distribuzione dei contenuti agli utenti.

Come con gli altri servizi AWS, con Amazon CloudFront non sei obbligato a un impegno minimo e paghi solo quello che utilizzi. Diversamente dall'hosting autonomo, con Amazon CloudFront eviti le spese e la complessità di gestione di una rete di server di cache in più sedi su Internet ed elimini la necessità di riservare capacità supplementare per elaborare eventuali picchi del traffico. Amazon CloudFront utilizza inoltre tecniche come la compressione di richieste simultanee di utenti per lo stesso file in una edge location in una singola richiesta al tuo server di origine. Questo riduce il carico sui tuoi server di origine diminuendo la necessità di scalare l'infrastruttura di origine, contribuendo in tal modo alla riduzione dei costi.

Inoltre, se utilizzi un server di origine AWS (ad esempio Amazon S3, Amazon EC2, ecc.), dal 1 dicembre 2014 non paghi più le tariffe di trasferimento di dati AWS verso Amazon CloudFront. Questa novità si applica al trasferimento di dati da tutte le regioni AWS verso tutte le posizioni edge di CloudFront nel mondo.

Amazon CloudFront utilizza intestazioni di controllo di cache standard configurate sui file per identificare i contenuti statici e dinamici. Distribuire tutti i tuoi contenuti utilizzando una sola distribuzione Amazon CloudFront ti garantisce che l'ottimizzazione delle prestazioni viene applicata a tutto il tuo sito o applicazione Web. Quando utilizzi i server di origine AWS, la capacità di AWS di tracciare e correggere i percorsi di origine, monitorare l'integrità del sistema, rispondere rapidamente quando avvengono problemi, nonché l'integrazione di Amazon CloudFront con altri servizi AWS, risultano in prestazioni migliori, affidabilità e facilità d'uso. Puoi anche trarre vantaggio dall'utilizzo di diversi server di origine per diversi tipi di contenuti su un solo sito, ad es. Amazon S3 per gli oggetti statici, Amazon EC2 per i contenuti dinamici e i server di origine personalizzati per i contenuti di terza parte, pagando solo quello che utilizzi.

Amazon CloudFront è una buona scelta per la distribuzione di contenuti statici a cui si accede frequentemente e che traggono vantaggio dalla distribuzione edge, come immagini di siti web popolari, video, file multimediali o download di software.

Amazon CloudFront ti consente di ottenere rapidamente i vantaggi della distribuzione di contenuti a prestazioni elevate senza negoziare contratti o costi onerosi. Amazon CloudFront offre a tutti gli sviluppatori prezzi contenuti in base al consumo, con un modello self-service. Inoltre possono trarre vantaggio da una solida integrazione con altre offerte AWS. La soluzione è facile da usare con Amazon S3, Amazon EC2 ed Elastic Load Balancing come server di origine, offrendo agli sviluppatori una potente combinazione di storage durevole e distribuzione a prestazioni elevate. Inoltre, Amazon CloudFront si integra con Amazon Route 53 e AWS CloudFormation offrendo ulteriori vantaggi di prestazioni e facilità di configurazione.

Amazon CloudFront supporta contenuti che possono essere inviati tramite i protocolli HTTP o WebSocket. Fra questi ci sono le pagine Web dinamiche e le applicazioni, come le pagine HTML o PHP o le applicazioni basate su WebSocket, e qualunque tipo di file statici largamente utilizzati che fanno parte della tua applicazione Web, come immagini di siti Web, audio, video, file multimediali o download di software. Amazon CloudFront supporta, inoltre, la distribuzione di contenuti multimediali in streaming on demand e in tempo reale tramite HTTP.

Sì. Amazon CloudFront funziona con qualunque server di origine che contiene le versioni originali e definitive dei tuoi contenuti, sia statici sia dinamici. L'utilizzo di un server di origine personalizzato non comporta costi supplementari.

Per ogni origine che viene aggiunta a una distribuzione CloudFront, è possibile assegnare un'origine di backup che può essere utilizzata per gestire automaticamente il traffico nel caso in cui l'origine primaria non sia disponibile. È possibile scegliere una combinazione di codici di stato HTTP 4xx/5xx che, se restituiti dall'origine primaria, attivano il failover all'origine di backup. Le due origini possono essere una qualsiasi combinazione di origini AWS e non AWS.

Sì. L'Accordo sul livello di servizio di Amazon CloudFront prevede un credito sui servizi qualora la percentuale del tempo di attività del sistema durante un ciclo di fatturazione sia inferiore a quella promessa da Amazon. Ulteriori informazioni sono disponibili qui.

Sì. Puoi utilizzare la Console di gestione AWS per configurare e gestire Amazon CloudFront tramite una semplice interfaccia Web con un clic. La Console di gestione AWS supporta la maggior parte delle funzionalità di Amazon CloudFront, consentendoti di approfittare della distribuzione a bassa latenza di questo servizio senza scrivere codice supplementare o installare software. L'accesso alla Console di gestione AWS è disponibile gratuitamente all'indirizzo https://console.aws.amazon.com.

Nel nostro centro risorse è disponibile un'ampia gamma di strumenti che permettono di gestire le distribuzioni Amazon CloudFront e le librerie per i vari linguaggi di programmazione.

Sì. Puoi indirizzare l'apex di zona (example.com) alla tua distribuzione Amazon CloudFront in due modi.

Utilizzando Amazon Route 53, l'affidabile servizio DNS di AWS, puoi configurare un record ALIAS che ti consente di mappare il dominio apex o root (example.com) del tuo nome DNS alla tua distribuzione Amazon CloudFront. Amazon Route 53 risponderà quindi a ogni richiesta di record ALIAS con gli indirizzi IP corretti per la tua distribuzione CloudFront. Route 53 non prevede costi per le query rivolte a record ALIAS mappati a una distribuzione CloudFront.

In alternativa, con gli IP statici Anycast di CloudFront, puoi indirizzare il tuo dominio apex alla distribuzione CloudFront utilizzando qualsiasi provider DNS. È sufficiente creare record A standard utilizzando i 3 indirizzi IP statici forniti da CloudFront. Questa funzionalità estende il supporto del dominio apex oltre Route 53, mentre il traffico viene comunque indirizzato automaticamente verso le posizioni edge più vicine per una distribuzione di contenuti ad alte prestazioni in tutto il mondo.

CloudFront distribuisce i tuoi contenuti attraverso una rete mondiale di data center chiamati posizioni edge. Le cache edge regionali si trovano tra il tuo server Web di origine e le edge location globali che servono i contenuti direttamente agli utenti. È una funzione che permette di migliorare le prestazioni per gli utenti finali riducendo gli oneri operativi e i costi di ridimensionamento delle risorse di origine.

Amazon CloudFront dispone di più cache edge regionali distribuite a livello globale, che forniscono un ulteriore livello di caching vicino agli utenti finali. Si trovano tra il tuo server web di origine e le posizioni edge di AWS che distribuiscono i contenuti direttamente agli utenti. Man mano che gli oggetti diventano meno popolari, le singole edge location possono rimuoverli per lasciare spazio a contenuti più popolari. Le cache edge regionali hanno maggiore profondità di cache delle singole edge location, perciò gli oggetti vi vengono conservati per tempi più lunghi. In questo modo i contenuti rimarranno più vicini agli utenti finali, riducendo la necessità che CloudFront acceda costantemente al server Web di origine e migliorando le prestazioni complessive a beneficio degli utenti. Ad esempio, per recuperare oggetti, prima di accedere al server Web di origine, le edge location CloudFront in Europa ora passano dalla cache edge regionale a Francoforte. Le cache edge regionali possono essere utilizzate con qualsiasi origine, come S3, EC2 o origini personalizzate. Le cache edge regionali vengono saltate nelle regioni che ospitano attualmente le origini della tua applicazione.

Sì. Non è necessario apportare alcune modifica alle distribuzioni CloudFront; questa caratteristica viene abilitata di default per tutte le distribuzioni, nuove ed esistenti. Questa funzionalità non prevede costi aggiuntivi.

Amazon CloudFront utilizza una rete globale di posizioni edge e cache edge regionali per la distribuzione di contenuti. Consulta in questa pagina l'elenco completo delle posizioni di Amazon CloudFront.

Sì, la funzionalità di restrizione geografica ti consente di specificare un elenco di Paesi nei quali gli utenti possono accedere ai tuoi contenuti. In alternativa, puoi specificare i paesi nei quali non possono accedervi. In entrambi i casi, CloudFront risponde alla richiesta di un utente in un Paese soggetto a restrizione con il codice di stato HTTP 403 (vietato).

La precisione del database di identificazione del Paese attraverso l'indirizzo IP varia a seconda della regione. Sulla base di test recenti, la precisione globale di mappatura dell'indirizzo IP con il Paese è del 99,8%.

Sì, puoi creare messaggi di errore personalizzati (per esempio, un file HTML o un grafico .jpg) con il tuo marchio e contenuti per diverse risposte di errore HTTP 4xx e 5xx. Puoi quindi configurare Amazon CloudFront in modo che restituisca messaggi di errore personalizzati all'utente quando il server di origine restituisce uno degli errori specificati a CloudFront.

Per impostazione predefinita, se non è impostata alcuna intestazione di controllo della cache, ogni posizione edge verifica se c'è una versione aggiornata del file ogni volta che riceve una richiesta più di 24 ore dopo l'ultima volta in cui ha verificato il server di origine per vedere se quel file era stato modificato. Questo si chiama "periodo di scadenza". Puoi impostare questo periodo di scadenza da 0 secondi fino alla durata desiderata, impostando le intestazioni di controllo di cache sui tuoi file nel tuo server di origine. Amazon CloudFront utilizza queste intestazioni di controllo di cache per determinare a quale frequenza è necessario verificare il server di origine per vedere se il file è stato aggiornato. Per un periodo di scadenza impostato a 0 secondi, Amazon CloudFront validerà di nuovo ogni richiesta con il server di origine. Se i file non vengono modificati spesso, è meglio impostare un periodo di scadenza lungo e implementare un sistema di controllo delle versioni per gestire gli aggiornamenti dei file.

Ci sono opzioni multiple per eliminare un file dalle posizioni edge. Si può semplicemente eliminare il file dal server di origine e, quando i contenuti nelle edge location arrivano alla data di scadenza definita nell'intestazione HTTP di ogni oggetto, verranno eliminati. Nel caso in cui occorra eliminare materiali offensivi o potenzialmente dannosi prima della fine del periodo di scadenza specificato, si può utilizzare l'API Invalidation per eliminare l'oggetto da tutte le edge location di Amazon CloudFront. Consulta in questa pagina le tariffe per le richieste di invalidazione.

Se si invalidano gli oggetti singolarmente, è possibile avere richieste di invalidazione in corso per un massimo di 3.000 oggetti per distribuzione contemporaneamente. Questo significa una richiesta di invalidamento per un massimo di 3.000 oggetti, fino a 3.000 richieste per un oggetto ciascuna o qualunque altra combinazione che non superi i 3.000 oggetti.

Utilizzando il carattere jolly * è possibile inoltrare richieste per un massimo di 15 percorsi di invalidamento in corso simultaneamente. Ci possono anche essere richieste di invalidamento per un massimo di 3.000 oggetti per distribuzione in corso simultaneamente; il limite per le richieste di invalidamento con carattere jolly è indipendente dai limiti degli oggetti da invalidare individualmente. Se si supera questo limite, le ulteriori richieste di invalidamento restituiranno un messaggio di errore finché non viene completata una delle richieste precedenti.

Si consiglia di utilizzare l'invalidazione solo in circostanze impreviste; se si sa in anticipo che i file dovranno essere rimossi frequentemente dalla cache, si consiglia di implementare un sistema di controllo delle versioni per i file e/o di impostare un periodo di scadenza breve.

I punti di presenza (PoP) incorporati di CloudFront sono un tipo di infrastruttura CloudFront distribuita più vicino agli utenti finali, all'interno delle reti dei provider di servizi Internet (ISP) e degli operatori di rete mobile (MNO). I POP incorporati sono progettati su misura per offrire eventi di live streaming su larga scala, video on demand (VOD) e download di giochi. Questi PoP incorporati sono di proprietà e gestiti da Amazon e sono distribuiti nell'ultimo miglio delle reti ISP/MNO per evitare i colli di bottiglia nelle reti congestionate che collegano gli utenti finali alle fonti di contenuti, migliorando le prestazioni.

I PoP incorporati di CloudFront si differenziano dai PoP CloudFront in base al luogo in cui vengono distribuiti e ai contenuti che forniscono. I POP incorporati di CloudFront vengono distribuiti direttamente nelle reti ISP e MNO, a differenza dei POP CloudFront distribuiti all'interno della rete AWS. I PoP incorporati sono progettati appositamente per distribuire traffico memorizzabile nella cache su larga scala, come flussi video e download di giochi, mentre i PoP CloudFront sono progettati per distribuire una varietà di carichi di lavoro, inclusi contenuti memorizzabili nella cache e dinamici.

I PoP integrati di CloudFront sono progettati per fornire contenuti memorizzabili nella cache a cui possono accedere contemporaneamente molti utenti finali, come streaming video in diretta su larga scala, video on demand e download di giochi.

No, non è previsto alcun costo aggiuntivo per l'utilizzo dei PoP incorporati di CloudFront.

I PoP incorporati sono una funzionalità opt-in destinata alla distribuzione di traffico memorizzabile nella cache su larga scala. Contatta il tuo rappresentante commerciale AWS per valutare se i PoP incorporati sono adatti ai tuoi carichi di lavoro.

No, non è necessario creare una nuova distribuzione specifica per i PoP incorporati. Se il carico di lavoro è idoneo, CloudFront abiliterà i PoP incorporati per la distribuzione esistente su richiesta.

Non devi scegliere tra i PoP incorporati di CloudFront o i PoP CloudFront per la distribuzione dei contenuti. Una volta abilitata la distribuzione CloudFront per i PoP integrati, il sistema di routing di CloudFront utilizza dinamicamente sia i PoP CloudFront che i PoP incorporati per fornire contenuti, garantendo prestazioni ottimali per gli utenti finali.

Contattaci per iniziare a implementare PoP incorporati nella tua rete.

È possibile utilizzare il portale PoP integrato per gestire i PoP incorporati distribuiti all'interno della rete. Il portale di POP incorporati è integrato con l'AWS Interconnect Portal e fornisce un'interfaccia unificata per eseguire facilmente il self-service di una serie di attività associate all'intero ciclo di vita di questi POP. Ciò include la richiesta di nuovi dispositivi, il monitoraggio dell'avanzamento delle richieste, il monitoraggio delle statistiche sulle prestazioni e la richiesta di supporto. Puoi accedere al portale autenticandoti con single sign-on (SSO) utilizzando il tuo account PeeringDB.

Amazon CloudFront [esclusa la distribuzione di contenuti tramite i PoP incorporati di CloudFront] è incluso nella gamma di servizi conformi allo Payment Card Industry Data Security Standard (PCI DSS) Merchant Level 1, il livello di conformità più elevato per i fornitori di servizi. Per ulteriori informazioni, consulta la guida per gli sviluppatori.

AWS ha esteso il proprio programma di conformità HIPAA in modo da includere Amazon CloudFront [esclusa la distribuzione di contenuti tramite i PoP incorporati di CloudFront] come servizio conforme all'HIPAA. Se hai stipulato un Business Associate Agreement (BAA) con AWS, puoi utilizzare Amazon CloudFront [esclusa la distribuzione di contenuti tramite i PoP incorporati di CloudFront] per accelerare la distribuzione di informazioni sanitarie protette. Per ulteriori informazioni, consulta la pagina sulla Conformità HIPAA e la guida per gli sviluppatori.

Amazon CloudFront [esclusa la distribuzione di contenuti tramite i PoP incorporati di CloudFront] è conforme alle misure SOC (System & Organization Control). I report SOC sono report analitici di terze parti che documentano come AWS abbia raggiunto obiettivi e controlli di conformità ottimali. Per ulteriori informazioni, consulta la pagina sulla conformità SOC di AWS e la guida per gli sviluppatori.

I report SOC 1 e SOC 2 di AWS sono disponibili ai clienti mediante AWS Artifact, un portale self-service per l'accesso on demand ai report di conformità di AWS. Accedi ad AWS Artifact dalla Console di gestione AWS oppure scopri di più nella pagina Nozioni di base su AWS Artifact. Il report SOC 3 di AWS più recente è disponibile pubblicamente sul sito web di AWS.

Amazon CloudFront supporta attualmente le richieste GET, HEAD, POST, PUT, PATCH, DELETE e OPTIONS.

Amazon CloudFront non memorizza nella cache le risposte POST, PUT, DELETE e PATCH; queste richieste vengono ritrasmesse tramite proxy al server di origine. Puoi attivare il caching per le risposte alle richieste OPTIONS.

Se disponi di una distribuzione Amazon CloudFront preesistente, puoi attivare HTTP/2 utilizzando l'API o la Console di gestione. Nella Console, naviga alla pagina "Distribution Configuration" e poi alla sezione "Supported HTTP Versions". Qui puoi selezionare "HTTP/2, HTTP/1.1, or HTTP/1.0". HTTP/2 viene attivato automaticamente per tutte le nuove distribuzioni CloudFront.

Attualmente, Amazon CloudFront supporta HTTP/2 per la fornitura di contenuti ai client e ai browser dei tuoi utenti. Per la comunicazione tra posizioni edge e i tuoi server di origine, Amazon CloudFront continuerà a utilizzare HTTP/1.1.

Al momento no. Tuttavia, la maggior parte dei browser moderni supporta HTTP/2 solo tramite una connessione crittografata. Per ulteriori informazioni sull'utilizzo di SSL con Amazon CloudFront fai clic qui.

HTTP/3 è la terza versione principale di Hypertext Transfer Protocol. HTTP/3 utilizza QUIC, un protocollo di trasporto sicuro basato su UDP (User Datagram Protocol) che combina e migliora le capacità del protocollo di controllo della trasmissione (TCP), TLS e HTTP/2 esistenti. HTTP/3 offre numerosi vantaggi rispetto alle versioni HTTP precedenti, tra cui tempi di risposta più rapidi e maggiore sicurezza.

HTTP/3 è basato su QUIC, un nuovo protocollo di trasporto Internet altamente performante, resiliente e sicuro. Il supporto HTTP/3 di CloudFront si basa su s2n-quic, una nuova implementazione del protocollo QUIC open source in Rust. Per maggiori informazioni su QUIC, fai riferimento al blog “Introducing s2n-quic”. 

I clienti cercano continuamente di fornire applicazioni più rapide e sicure per i propri utenti finali. Poiché la penetrazione di Internet aumenta a livello globale e sempre più utenti si connettono online tramite dispositivi mobili e da reti remote, la necessità di migliorare le prestazioni e l'affidabilità è più grande che mai. HTTP/3 soddisfa questa necessità in quanto offre diversi miglioramenti delle prestazioni rispetto alle versioni HTTP precedenti:

1. Connessioni più rapide e affidabili: CloudFront utilizza 1-RTT per l'handshake TLS per HTTP/3, consentendo di ridurre il tempo di creazione della connessione e di diminuire di conseguenza il numero di errori di handshake rispetto alle versioni HTTP precedenti.
2. Migliori prestazioni web: l'implementazione HTTP/3 di CloudFront supporta le migrazioni delle connessioni lato client, permettendo alle applicazioni client di ripristinarsi da connessioni scadenti con interruzioni minime. A differenza di TCP, QUIC gestisce la perdita di pacchetti e la congestione in modo efficiente, il che lo rende più adatto per reti congestionate con un'elevata perdita di pacchetti. Inoltre, il QUIC consente riconnnessioni più veloci durante i passaggi da Wi-Fi a reti mobili e viceversa.
3. Sicurezza: HTTP/3 offre una sicurezza più completa rispetto alle versioni precedenti di HTTP crittografando i pacchetti scambiati durante gli handshake TLS. Ciò rende più difficile l'ispezione da parte dei middlebox fornendo ulteriore privacy e riducendo gli attacchi man-in-the-middle. Il supporto HTTP/3 di CloudFront si basa su s2n-quic e Rust, entrambi con una forte enfasi sull'efficienza e sulle prestazioni.
    

Puoi attivare HTTP/3 per le distribuzioni Amazon CloudFront nuove ed esistenti utilizzando la console CloudFront, l'operazione API UpdateDistribution o utilizzando un modello Cloudformation. Nella console, passa alla pagina "Distribution Configuration" (Configurazione distribuzione) e poi alla sezione "Supported HTTP Versions" (Versioni HTTP supportate). Qui puoi selezionare “HTTP/3, HTTP/2, HTTP/1.1 o HTTP/1.0”.

Quando si abilita HTTP/3 sulla distribuzione CloudFront, CloudFront aggiunge automaticamente l'intestazione Alt-Svc, che utilizza per segnalare che il supporto HTTP/3 è disponibile e non è necessario aggiungere manualmente l'intestazione Alt-Svc. Ci aspettiamo che tu abiliti il supporto per più protocolli nelle tue applicazioni, in modo tale che se l'applicazione non riesce a stabilire una connessione HTTP/3 ricadrà su HTTP/1.1 o HTTP/2 ovvero, i client che non supportano HTTP/3 saranno comunque in grado di comunicare con le distribuzioni CloudFront abilitate per HTTP/3 utilizzando HTTP/1.1 o HTTP/2. Il supporto di fallback è una parte obbligatoria della specifica HTTP/3 ed è implementato da tutti i principali browser che supportano HTTP/3.

CloudFront attualmente supporta HTTP/3 per la comunicazione tra i client/browser dei tuoi visualizzatori e le posizioni edge di CloudFront. Per la comunicazione tra la posizione edge e i tuoi server di origine, CloudFront continuerà a utilizzare HTTP/1.1.

HTTP/3 utilizza QUIC, che richiede TLSv1.3. Pertanto, indipendentemente dalla policy di sicurezza scelta, puoi utilizzare solo TLSv1.3 e le suite di crittografia TLSv1.3 supportate per stabilire connessioni HTTP/3. Per maggiori dettagli, fai riferimento alla sezione relativa ai protocolli e alle cifrature supportati tra i visualizzatori e CloudFront nella Guida per gli sviluppatori di CloudFront.

No, non sono previsti addebiti separati per l'abilitazione di HTTP/3 su distribuzioni Amazon CloudFront. Le richieste HTTP/3 saranno addebitate in base alle tariffe previste dal tuo piano tariffario.

Gestore SaaS CloudFront è una nuova funzionalità di Amazon CloudFront che aiuta i fornitori di piattaforme di sviluppo web e Software-as-a-Service (SaaS) a gestire in modo efficiente la distribuzione dei contenuti su più siti web. Gestore SaaS CloudFront semplifica il modo in cui le organizzazioni forniscono e proteggono le applicazioni multi-tenant su larga scala. Introducendo configurazioni e parametri riutilizzabili, Gestore SaaS CloudFront riduce il sovraccarico operativo. Elimina il lavoro di configurazione ridondante e consente ai clienti di mantenere impostazioni coerenti su tutti i loro siti web. Inoltre, Gestore SaaS CloudFront offre la flessibilità opzionale di personalizzare le impostazioni di sicurezza e automatizzare i rinnovi dei certificati per ciascun sito web quando necessario.

Gestore SaaS CloudFront è progettato per le organizzazioni che affrontano la sfida di gestire più siti web in modo efficiente. I fornitori di piattaforme di sviluppo web e Software-as-a-Service (SaaS) lo troveranno particolarmente utile, poiché consente loro di mantenere impostazioni coerenti in tutti i siti web dei loro tenant. Allo stesso modo, le aziende che gestiscono più siti web aziendali possono utilizzarlo per standardizzare la propria presenza sul web preservando la flessibilità di personalizzare i singoli siti. Se disponi solo di pochi siti web o se ogni sito web contiene configurazioni CloudFront diverse, allora la distribuzione single tenant (tradizionale) è probabilmente la soluzione più adatta.

CloudFront è disponibile come opzione tramite la Console AWS e le API per i clienti che desiderano gestire impostazioni condivise tra gruppi di domini. Ecco come iniziare: 1/Definisci le impostazioni condivise: crea una distribuzione multi-tenant che contenga impostazioni condivise che fungeranno da modello per gruppi di domini. 2/Crea tenant di distribuzione: crea tenant di distribuzione che ti consentano di associare i domini e il relativo certificato TLS a una distribuzione multi-tenant. 3/Ottimizza il controllo: facoltativamente, personalizza le impostazioni per i tenant di distribuzione applicando le sostituzioni.

Una distribuzione multi-tenant definisce la configurazione di base che verrà condivisa tra i domini. Contiene impostazioni di configurazione condivise come configurazioni di origine, comportamenti della cache e impostazioni di sicurezza. A differenza di una distribuzione standard, una distribuzione multi-tenant non può servire direttamente il traffico. Offre campi personalizzabili e parametrizzati per soddisfare le esigenze specifiche di ogni dominio. Ad esempio: percorsi di origine specifici del dominio o nomi di dominio di origine.

Un tenant di distribuzione rappresenta un dominio specifico che utilizza una distribuzione multi-tenant. Eredita la configurazione di base dalla distribuzione multi-tenant e deve avere almeno un dominio o sottodominio con un certificato TLS valido.
Ogni tenant di distribuzione può includere le seguenti personalizzazioni:

• Percorsi di origine e/o nomi di dominio di origine univoci (definiti tramite valori dei parametri nella distribuzione multi-tenant)
• Certificati TLS personalizzati
• Sostituzioni ACL Web
• Sostituzioni restrizioni geografiche
  

Sì. Tuttavia, CloudFront funziona con Gestione certificati AWS (ACM) per fornire un'esperienza di convalida del controllo del dominio senza interruzioni. L'integrazione con ACM elimina l'onere dell'emissione e della gestione dei certificati e fornisce una gestione automatizzata del ciclo di vita dei certificati SSL/TLS emessi da Amazon. Se si utilizza una CA diversa per emettere i certificati, ACM supporta i certificati emessi da CA di terze parti. In tali casi, sarai responsabile del ciclo di vita del certificato (caricamento iniziale, rinnovo, caricamento successivo) e ACM invierà notifiche al proprietario dell'account AWS tramite CloudWatch ed e-mail quando i certificati si avvicinano alla scadenza. Per maggiori dettagli puoi visitare https://aws.amazon.com/certificate-manager/faqs/.

Sì, CloudFront supporta i domini apex o root (ad esempio, example.com vs. www.example.com). I clienti possono utilizzare Route 53 per gestire il sistema dei nomi di dominio (DNS) e aggiungere un record ALIAS per il loro dominio apex in modo che punti a un dominio fornito da CloudFront. Per i clienti che non possono utilizzare Route53 per gestire domini personalizzati, gli IP statici Anycast forniscono un set dedicato di indirizzi IP che possono essere utilizzati al posto dei record CNAME/ALIAS. Ulteriori informazioni sono disponibili qui.

Sì. CloudFront addebita i costi in base al numero di risorse di tenant di distribuzione create. I tenant di distribuzione sono nuove risorse che ereditano le impostazioni di configurazione da una distribuzione multi-tenant di CloudFront. Per ulteriori informazioni, consulta la pagina dei prezzi di CloudFront.

WebSocket è un protocollo di comunicazione in tempo reale che consente la comunicazione bidirezionale tra un client e un server tramite una connessione TCP di lunga durata. Utilizzando una connessione permanente aperta, il client e il server possono inviarsi l'un l'altro dati in tempo reale senza che il client debba iniziare di frequente la verifica delle connessioni per lo scambio dei nuovi dati. Le connessioni WebSocket sono spesso utilizzate nelle applicazioni chat, nelle piattaforme di collaborazione, nei giochi multigiocatore e nelle piattaforme di transazioni finanziarie. Fai riferimento alla nostra documentazione per maggiori informazioni sull'uso del protocollo WebSocket con Amazon CloudFront. 

È possibile utilizzare WebSocket a livello globale. Non è necessaria alcuna configurazione aggiuntiva per abilitare il protocollo WebSocket all'interno della risorsa CloudFront, poiché ora è supportato per impostazione predefinita.

Amazon CloudFront stabilisce connessioni WebSocket solo se il client include l'intestazione “Upgrade: websocket” e il server risponde con il codice di stato HTTP 101, confermando che può passare al protocollo WebSocket.

Sì. Amazon CloudFront supporta connessioni WebSocket crittografate (WSS) tramite il protocollo SSL/TLS.

gRPC è un framework RPC (Remote Procedure Call) moderno e open source che consente la comunicazione bidirezionale tra un client e un server tramite una connessione HTTP/2 di lunga durata. Utilizzando una connessione aperta persistente, il client e il server possono scambiarsi dati in tempo reale senza che il client debba riavviare frequentemente le connessioni per verificare la presenza di nuovi dati da scambiare. gRPC è ideale per casi d'uso in cui bassa latenza e alte velocità di trasferimento sono essenziali, come le applicazioni di comunicazione in tempo reale e i giochi online.

gRPC è abilitato su ogni comportamento della cache nelle distribuzioni CloudFront. L'abilitazione di gRPC garantisce che sia HTTP/2 che il supporto per le richieste POST siano abilitati anche sulla distribuzione. gRPC supporta solo il metodo POST su HTTP/2.

Amazon CloudFront comunica tramite gRPC quando sono soddisfatte le seguenti condizioni:

1. HTTP/2 è abilitato sulla distribuzione
2. Le richieste POST e gRPC sono abilitate su un comportamento della cache
3. Un client invia un'intestazione “content-type” con il valore “application/grpc” su una connessione HTTP/2

1. Sicurezza: gRPC utilizza HTTP/2, che garantisce la crittografia end-to-end del traffico dal client ai server di origine. Inoltre, quando si utilizza gRPC, si ottiene AWS Shield Standard senza costi aggiuntivi ed è possibile configurare AWS WAF per proteggere il traffico gRPC dagli attacchi.
2. Prestazioni migliori: gRPC sfrutta un formato di messaggio binario, denominato Protocol Buffer, che è più piccolo dei payload tradizionali, come JSON utilizzato con le API RESTful. L'analisi dei Protocol Buffer richiede meno CPU perché i dati sono in formato binario, il che significa che i messaggi vengono scambiati più velocemente. Ciò si traduce in prestazioni complessive migliori.
3. Supporto per lo streaming integrato: lo streaming è parte integrante del framework gRPC e supporta la semantica di streaming sia lato client che lato server. Ciò semplifica notevolmente la creazione di servizi o client di streaming. gRPC su CloudFront supporta le seguenti combinazioni di streaming:
   • Unario (senza streaming)
   • Streaming da client a server
   • Streaming da server a client
   • Streaming bidirezionale

Al momento no. CloudFront supporta solamente gRPC su HTTP/2.

Per impostazione predefinita, puoi distribuire contenuti agli utenti su HTTPS utilizzando il nome di dominio della distribuzione CloudFront nell'URL, ad esempio https://dxxxxx.cloudfront.net/image.jpg. Se vuoi distribuire contenuti su HTTPS utilizzando il tuo nome di dominio e il tuo certificato SSL, puoi usare una delle nostre caratteristiche di supporto di certificato SSL personalizzato. Ulteriori informazioni.

La crittografia a livello di campo è una funzionalità di CloudFront che permette di caricare in modo sicuro sui server di origine dati inviati dall'utente quali numeri di carte di credito. Con questa funzionalità, puoi crittografare ulteriormente i dati sensibili in formato HTTPS mediante chiavi di crittografia specifiche del campo (fornite da te) prima che una richiesta PUT/POST venga inviata alla tua origine. Questo garantisce che i dati sensibili vengano decrittografati e visualizzati solo da determinati componenti o servizi del tuo stack applicativo. Per ulteriori informazioni sulla crittografia a livello di campo, consulta la sezione Field-Level Encryption nella nostra documentazione.

Molte applicazioni web raccolgono dagli utenti dati sensibili, che vengono quindi elaborati dai servizi applicativi in esecuzione sull'infrastruttura di origine. Tutte queste applicazioni Web usano la crittografia SSL/TLS tra l'utente finale e CloudFront e tra CloudFront e la tua origine. La tua origine potrebbe avere più microservizi che eseguono operazioni critiche in base all'input dell'utente. Tuttavia, di solito le informazioni sensibili vengono utilizzate solo da un piccolo sottogruppo di questi microservizi, il che significa che la maggior parte dei componenti hanno accesso diretto a questi dati senza alcuna ragione. Un semplice errore di programmazione, come ad esempio una registrazione di log con la variabile sbagliata, potrebbe risultare nella trascrizione in un file del numero di carta di credito di un cliente.

Con la crittografia a livello di campo, le edge location di CloudFront possono crittografare i dati delle carte di credito. Da quel punto in poi solo le applicazioni che hanno le chiavi private possono decrittografare i campi sensibili. Pertanto il servizio di adempimento degli ordini può solo visualizzare i numeri delle carte di credito, mentre i servizi di pagamento possono decrittografarli. Questo garantisce un livello di sicurezza più elevato poiché, anche se uno dei servizi dell'applicazione dovesse divulgare il testo crittografato, i dati rimangono protetti da crittografia.

L'SSL personalizzato con IP dedicato assegna indirizzi IP dedicati per distribuire contenuti SSL in ogni posizione edge di CloudFront. Poiché c'è una mappatura individuale fra gli indirizzi IP e i certificati SSL, l'SSL personalizzato con IP dedicato funziona con browser e altri client che non supportano SNI. Dati i costi attuali degli indirizzi IP, il costo dell'SSL personalizzato con IP dedicato è di 600 USD al mese ripartito proporzionalmente sul numero di ore.

L'SSL personalizzato su SNI si basa sull'estensione SNI del protocollo Transport Layer Security, che permette a più domini di servire traffico SSL sullo stesso indirizzo IP includendo il nome host al quale gli utenti stanno cercando di connettersi. Analogamente a quanto accade con l'SSL personalizzato con IP dedicato, CloudFront distribuisce contenuti da ogni posizione edge di Amazon CloudFront e con lo stesso livello di sicurezza garantito dall'SSL personalizzato con IP dedicato. L'SSL personalizzato su SNI funziona con i browser più moderni, fra cui Chrome versione 6 e successive (su Windows XP e successive o OS X 10.5.7 e successive), Safari versione 3 e successive (su Windows Vista e successive o Mac OS X 10.5.6. e successive), Firefox 2.0 e successive e Internet Explorer 7 e successive (su Windows Vista e successive). I browser meno recenti che non supportano SNI non possono stabilire una connessione con CloudFront per caricare la versione HTTPS dei tuoi contenuti. L'SSL personalizzato su SNI è disponibile senza costi supplementari, a parte le tariffe standard di trasferimento dati e di richieste di CloudFront.

L'Indicazione nome server (SNI) è un'estensione del protocollo Transport Layer Security (TLS). Questo meccanismo identifica il dominio (nome del server) della richiesta SSL associata in modo che possa essere utilizzato il certificato giusto nell'handshake SSL. Questo permette l'utilizzo di un solo indirizzo IP su più server. SNI necessita del supporto di un browser per aggiungere il nome del server e, se la maggior parte dei browser moderni lo supportano, non è il caso di alcuni browser meno recenti. Per ulteriori informazioni, consulta la sezione SNI del documento CloudFront Developer Guide o l'articolo relativo all'estensione SNI su Wikipedia.

Sì, ora puoi effettuare il provisioning di certificati SSL/TLS e associarli in pochi minuti alle distribuzioni CloudFront. È sufficiente effettuare il provisioning di un certificato utilizzando il nuovo AWS Certificate Manager (ACM), trasmetterlo alla distribuzione CloudFront con un paio di clic e quindi attendere che ACM gestisca i rinnovi dei certificati. ACM permette di effettuare il provisioning, distribuire e gestire il certificato senza costi aggiuntivi.

Tieni presente che CloudFront supporta ancora l'utilizzo di certificati ottenuti da un'autorità di certificazione di terze parti e caricati nell'archivio di certificati IAM.

Sì, Amazon CloudFront ha una funzionalità opzionale di contenuti privati. Quando questa funzionalità è attivata, Amazon CloudFront distribuisce file solo con la tua approvazione effettuando un accesso sicuro alle tue richieste. Per ulteriori informazioni su questa funzionalità, consulta il documento CloudFront Developer Guide.

In qualità di cliente AWS, potrai usufruire di AWS Shield Standard senza costi aggiuntivi. AWS Shield è un servizio gestito che protegge le applicazioni web in esecuzione su AWS da attacchi di tipo DDoS (Distributed Denial of Service). AWS Shield Standard offre protezione a tutti i clienti AWS contro gli attacchi all'infrastruttura più comuni e frequenti (livello 3 e 4), come i flood SYN/UDP, gli attacchi di riflessione e altri, al fine di garantire la massima disponibilità delle applicazioni su AWS.

AWS Shield Avanzato è un servizio opzionale a pagamento rivolto ai clienti che usufruiscono di Supporto AWS Business e Supporto AWS Enterprise. AWS Shield Avanzato offre ulteriori protezioni contro attacchi più consistenti e sofisticati alle applicazioni in esecuzione su Elastic Load Balancing (ELB), Amazon CloudFront e Route 53.

È possibile integrare la distribuzione CloudFront con AWS WAF, il firewall che protegge le applicazioni web dagli attacchi consentendo la configurazione di regole basate su indirizzi IP, intestazioni HTTP e stringhe URI personalizzate. Tramite queste regole, AWS WAF può bloccare, consentire o monitorare (conteggiare) le richieste web dirette all'applicazione web. Per ulteriori informazioni, consulta il documento AWS WAF Developer Guide.

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 del 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.

Le origini del cloud privato virtuale (VPC) CloudFront sono una nuova funzionalità che consente di utilizzare CloudFront per distribuire contenuti da applicazioni ospitate in una sottorete privata del 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 che l'origine disponga di un nome DNS (sistema dei nomi di dominio) risolvibile esternamente. È 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 la soluzione perfetta 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 tra CloudFront e origine, 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 dedicare tempo ad attività di sviluppo generiche.
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 unico punto di accesso 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 del 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 affidabile 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 verso quella sottorete. Le nuove connessioni non vengono inviate alla sottorete e vengono instradate verso un'altra sottorete in cui si trova l'origine VPC e in cui BPA non è abilitato, oppure vengono eliminate se tutte le sottoreti in cui si trova l'origine VPC hanno 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.

Sì, è possibile configurare Amazon CloudFront per aggiungere intestazioni personalizzate alle richieste inoltrate al server di origine o per sovrascrivere il valore delle intestazioni esistenti. Queste intestazioni possono essere impiegate per verificare che le richieste indirizzate al server di origine siano state inviate da CloudFront; è anche possibile configurare l'origine in modo che consenta esclusivamente le richieste che contengono determinati valori di intestazione personalizzati. Inoltre, se si usano diverse distribuzioni CloudFront con lo stesso server di origine, è possibile impiegare intestazioni personalizzate per riconoscere le richieste di ciascuna distribuzione. Infine, le intestazioni personalizzate possono risultare utili per determinare le intestazioni CORS corrette restituite per le richieste. Puoi configurare le intestazioni personalizzate tramite l'API CloudFront e la Console di gestione AWS. Questa caratteristica non comporta costi supplementari. Per ulteriori dettagli su come impostare le intestazioni personalizzate, consulta questa pagina.

Amazon CloudFront supporta la distribuzione di contenuti dinamici o personalizzati mediante i cookie HTTP. Per sfruttare questa caratteristica, è necessario specificare se si desidera che Amazon CloudFront inoltri alcuni o tutti i cookie al server di origine personalizzato. Durante l'identificazione di un oggetto univoco nella cache, Amazon CloudFront terrà quindi anche conto dei valori del cookie inoltrato. In questo modo, gli utenti finali potranno visualizzare contenuti personalizzati sfruttando le prestazioni di Amazon CloudFront. Un'altra opzione consiste nel registrare i valori dei cookie nei log di accesso di Amazon CloudFront.

Una stringa di query può essere configurata in modo opzionale per far parte della chiave di cache per identificare oggetti nella cache di Amazon CloudFront. Questo consente di creare pagine web dinamiche (ad es. risultati di ricerca) che possono essere memorizzate nella cache all'edge per un certo periodo di tempo.

Sì, la funzionalità di whitelisting delle stringhe di query permette di configurare Amazon CloudFront in modo che utilizzi solo determinati parametri nella chiave di cache, inoltrando comunque tutti i parametri all'origine.

Sì, è possibile configurare fino a 10 parametri in una whitelist di Amazon CloudFront.

Amazon CloudFront supporta parametri di query URI secondo quanto definito nella sezione 3.4 del documento RFC3986. Nello specifico, supporta i parametri di query integrati in una stringa GET HTTP dopo il carattere “?” e delimitati dal carattere “&”.

Sì, CloudFront comprime automaticamente il testo o i dati binari. Per usare questa funzionalità, è sufficiente accedere alle impostazioni della cache e richiedere la compressione automatica degli oggetti da parte di CloudFront, accertando che il client includa Accept-Encoding: gzip nell'intestazione della richiesta (la maggior parte dei browser web effettua questa operazione per impostazione predefinita). Per ulteriori informazioni su questa funzionalità, consulta la guida per sviluppatori.

In genere, per streaming si intende la distribuzione di contenuti audio e video a utenti finali tramite Internet senza dover scaricare il file multimediale prima della riproduzione. I protocolli utilizzati per lo streaming sono quelli che distribuiscono contenuti tramite HTTP, ad esempio HTTP Live Streaming (HLS) di Apple, MPEG Dynamic Adaptive Streaming over HTTP (MPEG-DASH), HTTP Dynamic Streaming (HDS) di Adobe e Smooth Streaming di Microsoft. L'uso di questi protocolli differisce dalla distribuzione di pagine Web e di altri contenuti online perché implica la distribuzione di contenuti in tempo reale: gli utenti guardano i contenuti nel momento stesso in cui vengono distribuiti. Lo streaming dei contenuti offre diversi vantaggi potenziali sia per te sia per gli utenti finali:

• lo streaming offre agli utenti un maggiore controllo sulla loro esperienza di visualizzazione. Ad esempio, per gli utenti è più semplice cercare avanti e indietro in un video tramite lo streaming che utilizzando il classico metodo del download.
• Lo streaming offre inoltre un maggiore controllo sui contenuti, perché al termine della visualizzazione sul computer dell'utente finale non rimane alcun file.
• Lo streaming consente di ridurre i costi, poiché distribuisce solo le parti del file multimediale che l'utente effettivamente guarda. Quando un utente scarica un file, invece, deve scaricare il file intero anche se poi ne guarderà solo una parte.

Sì, Amazon CloudFront offre diverse opzioni di distribuzione di video on demand. Se sono in uso file multimediali che sono stati convertiti in formato HLS, MPEG-DASH o Microsoft Smooth Streaming, ad esempio utilizzando AWS Elemental MediaConvert, prima di essere memorizzati in Amazon S3 o in un server di origine personalizzato possono essere trasmessi in streaming nello stesso formato senza dover eseguire alcun server multimediale utilizzando una distribuzione web di Amazon CloudFront.

In alternativa, è possibile eseguire in Amazon EC2 un server di streaming di terze parti (ad esempio Wowza Media Server, disponibile in AWS Marketplace), con cui convertire un file multimediale nel formato di streaming HTTP desiderato. Tale server potrà essere designato come server di origine per una distribuzione web di Amazon CloudFront.

Consulta la pagina dedicata al protocollo Video on Demand (VOD) su AWS.

Sì. È possibile usare Amazon CloudFront per lo streaming in tempo reale con qualsiasi servizio video live che produca flussi basati su HTTP, ad esempio AWS Elemental MediaPackage o AWS Elemental MediaStore. MediaPackage è un servizio di creazione di origini e pacchetti video just-in-time che permette ai distributori di contenuti video di offrire contenuti in streaming in modo sicuro e affidabile su larga scala utilizzando diversi standard di distribuzione e di sicurezza. MediaStore un servizio di creazione e archiviazione di origini HTTP che offre prestazione elevate, consistenza immediata e bassa latenza prevedibile, condizioni ideali per distribuire contenuti multimediali in tempo reale sfruttando la sicurezza e la durabilità offerte dall'archiviazione di Amazon.

Consulta la pagina dedicata allo streaming video in diretta di AWS per ulteriori informazioni.

La resilienza sensibile alla qualità multimediale (MQAR) è una funzionalità integrata tra Amazon CloudFront e AWS Media Services che consente di automatizzare la selezione delle origini tra regioni e il failover in base a un punteggio di qualità video generato dinamicamente. Con MQAR, è possibile implementare un flusso di lavoro ridondante per i servizi multimediali AWS in due diverse Regioni AWS e garantire così una distribuzione resiliente degli eventi in diretta. Quando si abilita la funzionalità MQAR per la distribuzione, si autorizza CloudFront a selezionare automaticamente l'origine che si ritiene abbia il punteggio di qualità più elevato. Il punteggio di qualità rappresenta i problemi di qualità dello streaming multimediale percepiti dall'utente, come fotogrammi neri, fotogrammi bloccati o saltati o fotogrammi ripetuti. Ad esempio, se le origini di AWS Elemental MediaPackage v2 sono implementate in due diverse Regioni AWS e una riporta un punteggio di qualità multimediale più elevato rispetto all'altra, CloudFront passerà automaticamente all'origine che vanta il punteggio più alto. Questa funzionalità simula il controllo video continuo e sempre attivo per offrire eventi in diretta e canali di programmazione 24/7, ed è progettata per contribuire a offrire un'esperienza di alta qualità ai visualizzatori. Per ulteriori informazioni su MQAR, consulta il documento Amazon CloudFront Developer Guide.

Origin Shield è un livello di caching centralizzato che aiuta ad aumentare il cache hit ratio per ridurre il carico sull'origine. Origin Shield abbassa anche i costi operativi dell'origine, riducendo le richieste tra le varie regioni in modo che una sola richiesta vada all'origine per ogni oggetto. Se attivato, CloudFront instrada tutte le chiamate all'origine attraverso Origin Shield e invia una richiesta all'origine solo se il contenuto non è già memorizzato nella cache di Origin Shield.

Origin Shield è ideale per carichi di lavoro con visualizzatori distribuiti in diverse regioni geografiche o carichi di lavoro che prevedono il cosiddetto “just-in-time packaging” per lo streaming video, la gestione delle immagini immediata o processi simili. L'utilizzo di Origin Shield davanti all'origine ridurrà il numero di recuperi di origine ridondanti controllando prima la sua cache centrale e realizzando solo un recupero di origine consolidato per contenuti non già presenti nella cache di Origin Shield. Analogamente, Origin Shield può essere utilizzato in un'architettura multi-CDN per ridurre il numero di duplicati di origine che vengono recuperati tra le CDN posizionando Amazon CloudFront come origine su altre CDN. Consulta il documento Amazon CloudFront Developer Guide per maggiori dettagli su questi e altri casi d'uso di Origin Shield.

Amazon CloudFront offre Origin Shield nelle Regioni AWS dove CloudFront ha una cache edge regionale. Quando attivi Origin Shield, devi scegliere la Regione AWS per Origin Shield che ha la latenza più bassa rispetto alla tua origine. Puoi usare Origin Shield con origini che sono in una Regione AWS e con origini che non sono in AWS. Per ulteriori informazioni, consulta la sezione Choosing the AWS Region for Origin Shield nel documento Amazon CloudFront Developer Guide.

Sì. Tutte le Regioni Origin Shield sono costruite utilizzando un'architettura con un'elevata disponibilità che si estende su diverse Zone di disponibilità con flotte di istanze Amazon EC2 autoscalabili. Le connessioni dalle posizioni CloudFront a Origin Shield utilizzano anche il tracciamento attivo degli errori per ogni richiesta al fine di instradare automaticamente la richiesta a una posizione secondaria di Origin Shield se la posizione principale di Origin Shield non è disponibile.

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 di indirizzi IP statici che possono essere utilizzati per casi d'uso come la fatturazione a tasso zero, in cui i provider di rete rinunciano ai costi di traffico dati per indirizzi IP specifici con accordi appropriati in vigore, e l'inserimento in liste di autorizzazione lato client per una maggiore sicurezza. Utilizzando gli IP statici Anycast, si elimina la sfida operativa di aggiornare costantemente gli elenchi di autorizzazioni o le mappature IP, poiché lo stesso set di IP funziona per l'intera rete globale di CloudFront, continuando a beneficiare 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 Anycast di CloudFront si ricevono 21 indirizzi IP per IPv4. Sarà necessario aggiungere tutti questi indirizzi IP a tutti gli elenchi di indirizzi IP consentiti pertinenti.

No. CloudFront Anycast sarà disponibile solo con IP distribuiti su più regioni geografiche.

Mano a 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 Anycast di CloudFront possono essere associati a più distribuzioni nell'account. L'indirizzo IP statico Anycast di CloudFront 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 associarli 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.

Sì. Completa il modulo per richiedere l'aumento dei limiti qui ed entro due giorni lavorativi aggiungeremo più capacità all'account.

Per quanto riguarda il limite attuale del numero di distribuzioni che puoi creare per ogni account AWS, consulta la pagina Amazon CloudFront Limits nel documento Amazon Web Services General Reference. Per richiedere un limite superiore, vai a Modulo di aumento del limite di CloudFront.

La dimensione massima di un singolo file che può essere distribuito tramite Amazon CloudFront è di 30 GB. Questo limite è valido per tutte le distribuzioni Amazon CloudFront.

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 dell'attività del servizio: è possibile utilizzare AWS CloudTrail per registrare l'attività del servizio 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 ad 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 del Flusso di dati Amazon Kinesis. 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 dei log di output (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 degli stessi. Consulta la sezione “Funzionalità aggiuntive” della pagina dei prezzi di CloudFront per ulteriori informazioni.

Sì. Che si tratti di ricevere report di statistiche di cache dettagliate, monitorare l'utilizzo del tuo CloudFront, vedere da dove i clienti visualizzano i tuoi contenuti o impostare allarmi in tempo reale su parametri operativi, Amazon CloudFront offre una vasta gamma di soluzioni per i tuoi bisogni di reporting. Per accedere a tutte le opzioni di reportistica, visita il pannello di controllo Report e analisi di Amazon CloudFront nella Console di gestione AWS. Inoltre, puoi trovare ulteriori informazioni sulle varie opzioni di reportistica nella pagina Report e analisi di Amazon CloudFront.

Sì. Amazon CloudFront supporta l'applicazione di tag per l'allocazione dei costi. Grazie ai tag è più semplice suddividere i costi e ottimizzare le spese dividendo per categoria e raggruppando le risorse AWS. Ad esempio, puoi utilizzare tag per raggruppare le risorse in base ad amministratore, nome applicazione, centro di costo o progetto specifico. Per ulteriori informazioni sull'applicazione di tag per l'allocazione dei costi, consulta la pagina Using Cost Allocation Tags. Se sei pronto per aggiungere tag alle tue distribuzioni CloudFront, consulta la pagina Amazon CloudFront Add Tags.

Sì. Per ricevere uno storico di tutte le chiamate API di Amazon CloudFront effettuate sull'account, è sufficiente attivare AWS CloudTrail nella Console di gestione AWS di CloudTrail. Per avere ulteriori informazioni, visita la home page di AWS CloudTrail.

È possibile monitorare, inviare allarmi e ricevere notifiche sulle prestazioni operative delle distribuzioni Amazon CloudFront entro pochi minuti dalla richiesta del visualizzatore utilizzando Amazon CloudWatch. CloudFront pubblica automaticamente su Amazon CloudWatch sei parametri operazionali, con granularità di 1 minuto. È quindi possibile utilizzare CloudWatch per impostare allarmi su eventuali modelli anomali di traffico di CloudFront. Per ulteriori informazioni sul monitoraggio delle attività di CloudFront e su come impostare gli allarmi usando CloudWatch, consulta la spiegazione dettagliata nel documento Amazon CloudFront Developer Guide oppure accedi alla Console di gestione di Amazon CloudFront e seleziona Monitoraggio e allarmi nel riquadro di navigazione.

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 garantire 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. Dal Flusso di dati Amazon Kinesis, i log possono essere pubblicati in Amazon Kinesis Data Firehose. Amazon Kinesis Data Firehose supporta la facile consegna dei dati ad Amazon S3, Amazon Redshift, Servizio OpenSearch di Amazon 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.

Funzioni CloudFront è una funzionalità di calcolo edge serverless che permette di eseguire codice JavaScript nelle posizioni edge di CloudFront per trasformazioni e manipolazioni HTTP ridotte. Funzioni è progettato ad-hoc per fornire ai clienti la flessibilità di un ambiente di programmazione completo con le prestazioni e la sicurezza necessarie per le applicazioni web moderne. A un prezzo nettamente inferiore a quello di AWS Lambda@Edge, i clienti possono scalare le risorse istantaneamente e in modo conveniente per supportare milioni di richieste al secondo.

Funzioni CloudFront è integrato in modo nativo in CloudFront, permettendo ai clienti di creare, testare e distribuire funzioni facilmente all'interno dello stesso servizio. È inoltre possibile utilizzare CloudFront KeyValueStore con Funzioni CloudFront per archiviare e recuperare i dati di ricerca a complemento della logica delle funzioni. Il nostro repository GitHub consente agli sviluppatori di iniziare facilmente offrendo un'ampia raccolta di codice di esempio che può essere utilizzato come punto di partenza per la creazione di funzioni. Puoi creare funzioni nella console di CloudFront utilizzando l'IDE o le API/l'interfaccia a riga di comando di CloudFront. Dopo aver realizzato il codice, potrai testare la funzione su una distribuzione CloudFront di produzione, assicurandoti che verrà eseguita correttamente dopo la distribuzione. La funzionalità di test nella console fornisce un editor visivo per creare eventi di test e convalidare funzioni rapidamente. Dopo essere stato associato a una distribuzione di CloudFront, il codice viene distribuito nella rete globale di posizioni edge di AWS per l'esecuzione in risposta alle richieste di CloudFront.

Funzioni CloudFront è la soluzione ideale per funzioni leggere e di breve durata come quelle riportate di seguito:

• Normalizzazione della chiave di cache: è possibile trasformare gli attributi delle richieste HTTP (intestazioni, stringhe di query, cookie e persino il percorso relativo dell'URL della richiesta) per creare una chiave di cache ottimale, che può migliorare il tasso di occorrenze della cache.
• Manipolazione delle intestazioni: è possibile inserire, modificare o eliminare intestazioni HTTP nella richiesta o nella risposta. Ad esempio, puoi aggiungere intestazioni HTTP Strict Transport Security (HSTS) o di Condivisione di risorse tra le origini (CORS) a ogni risposta.
• Reindirizzamenti o riscritture di URL: è possibile reindirizzare i visualizzatori ad altre pagine in base alle informazioni nella richiesta o reindirizzare tutta la richiesta da un percorso a un altro.
• Richiesta dell'autorizzazione: è possibile convalidare token di autorizzazione, come token web JSON (JWT), ispezionando le intestazioni dell'autorizzazione o altri metadati della richiesta.

CloudFront KeyValueStore è un archivio dati chiave-valore globale, a bassa latenza e completamente gestito. KeyValueStore consente il recupero dei dati dei valori chiave dall'interno di Funzioni CloudFront, rendendo le funzioni più personalizzabili consentendo aggiornamenti indipendenti dei dati. I dati del valore chiave sono accessibili in tutte le posizioni edge di CloudFront, fornendo un archivio chiave-valore in memoria altamente efficiente con letture rapide dall'interno di Funzioni CloudFront.

CloudFront KeyValueStore è ideale per letture frequenti presso le posizioni edge e aggiornamenti poco frequenti come:

• Gestione di riscritture e reindirizzamenti degli URL: reindirizza gli utenti a un sito di un Paese specifico in base alla geolocalizzazione. L'archiviazione e l'aggiornamento di questi URL geolocalizzati in KeyValueStore semplifica la gestione degli URL.
• Test A/B e segnalazioni di funzionalità: esegui esperimenti assegnando una percentuale di traffico a una versione del sito web. Si possono aggiornare i pesi degli esperimenti senza aggiornare il codice della funzione o la distribuzione CloudFront.
• Autorizzazione all'accesso: implementa il controllo e l'autorizzazione degli accessi per i contenuti distribuiti tramite CloudFront creando e convalidando token generati dall'utente, come i token HMAC o i token web JSON (JWT), per consentire o rifiutare le richieste. 

No. Funzioni CloudFront ha lo scopo di integrare Lambda@Edge, non di sostituirlo. La combinazione di Lambda@Edge e CloudFront Functions permette di scegliere lo strumento adatto per il processo. Puoi scegliere di utilizzare sia CloudFront Functions che Lambda@Edge su diversi trigger di eventi all'interno dello stesso comportamento cache nelle tue distribuzioni di CloudFront. Ad esempio, puoi utilizzare Lambda@Edge per manipolare file manifest per lo streaming in tempo reale, allo scopo di inserire token personalizzati per proteggere streaming live. Puoi utilizzare Funzioni CloudFront per convalidare tali token quando un utente richiede un segmento del file manifesto.

La combinazione di Funzioni CloudFront e Lambda@Edge fornisce due opzioni potenti e flessibili per eseguire codice in risposta agli eventi di CloudFront. Entrambi offrono modi sicuri per eseguire codice in risposta a eventi di CloudFront senza infrastruttura di gestione. CloudFront Functions è progettato ad-hoc per trasformazioni e manipolazioni della richiesta/risposta leggere, altamente scalabili e sensibili alla latenza. Lambda@Edge usa runtime per utilizzo generico che supportano un'ampia gamma di esigenze di elaborazione e personalizzazioni. Lambda@Edge è l'ideale per operazioni a elevata intensità di calcolo, come le elaborazioni che richiedono più tempo per il completamento (da diversi millisecondi a secondi) o chiamate di rete per l'elaborazione dei dati, oppure elaborazioni che presentano dipendenze su librerie esterne di terze parti o che necessitano di integrazioni con altri servizi AWS (ad esempio S3 o Dynamo DB). Alcuni dei casi d'uso avanzati più comuni di Lambda@Edge includono la manipolazione di file manifesto per lo streaming HLS, le integrazioni con servizi di rilevamento di bot e autorizzazioni di terze parti, il rendering lato server (SSR, Server-Side Rendering) di applicazioni a pagina singola (SPA, Single-Page Apps) a livello di edge e molto altro. Per ulteriori dettagli, consulta la pagina dei casi d'uso di Lambda@Edge.

Funzioni CloudFront fornisce le prestazioni, la scalabilità e la convenienza che ti aspetti, ma con un modello di sicurezza unico che offre rigidi limiti di isolamento tra il codice delle funzioni. Quando esegui codice personalizzato in un ambiente di calcolo multi-tenant condiviso, è fondamentale mantenere un ambiente di esecuzione altamente sicuro. Un malintenzionato potrebbe tentare di sfruttare bug presenti nel runtime, nelle librerie o nella CPU per divulgare dati sensibili dal server o da altre funzioni del cliente. Senza una barriera di isolamento rigorosa tra il codice delle funzioni, questi exploit sono possibili. Sia AWS Lambda che Lambda@Edge ottengono questo isolamento di sicurezza attraverso l'isolamento delle VM basato su Firecracker. Con Funzioni CloudFront abbiamo distribuito un modello di isolamento basato sui processi che fornisce lo stesso livello di sicurezza contro attacchi side-channel come Spectre e Meltdown, attacchi basati sul timing o altre vulnerabilità del codice. CloudFront Functions non può accedere a dati che appartengono ad altri clienti o modificarli. Questa operazione può essere effettuata eseguendo funzioni in un processo dedicato con una CPU dedicata. CloudFront Functions viene eseguito sui processi di lavoro che servono un solo cliente alla volta e tutti i dati specifici del cliente vengono cancellati (scaricati) tra le esecuzioni.

CloudFront Functions non utilizza V8 come motore JavaScript. Il modello di sicurezza di Funzioni è diverso ed è considerato più sicuro del modello basato sull'isolamento di v8 offerto da altri fornitori.

Puoi testare qualsiasi funzione utilizzando la funzionalità di test integrata. Il test di una funzione eseguirà il codice su una distribuzione di CloudFront per verificare che la funzione restituisca il risultato previsto. Oltre a convalidare l'esecuzione del codice, viene fornita anche una metrica di utilizzo del calcolo. La metrica di utilizzo del calcolo fornisce una percentuale che indica quanto la funzione è vicina al limite di tempo dell'esecuzione. Ad esempio, un utilizzo del calcolo pari a 30 indica che la funzione sta utilizzando il 30% del tempo di calcolo totale consentito. È possibile creare oggetti di test con un editor visivo, permettendo di aggiungere facilmente stringhe di query, intestazioni, URL e metodi HTTP per ogni oggetto, oppure puoi creare oggetti di test utilizzando una rappresentazione JSON della richiesta o della risposta. Dopo aver eseguito il test, i risultati e il parametro di utilizzo del calcolo possono essere visualizzati nello stesso stile dell'editor visivo o esaminando la risposta JSON. Se la funzione viene eseguita correttamente e la metrica di utilizzo del calcolo non è vicina a 100, sai che la funzione verrà eseguita correttamente quando associata a una distribuzione di CloudFront.

Funzioni CloudFront genera sia metriche che log di esecuzione per monitorare l'utilizzo e le prestazioni di una funzione. I parametri sono generati per ogni chiamata di una funzione e puoi esaminare i parametri di ogni funzione individualmente nella console di CloudFront o CloudWatch. I parametri includono il numero di chiamate, l'utilizzo del calcolo, gli errori di convalida e gli errori di esecuzione. Se la funzione genera un errore di convalida o un errore di esecuzione, il messaggio di errore verrà visualizzato anche nei log di accesso di CloudFront, fornendo una migliore visibilità dell'impatto della funzione sul traffico di CloudFront. Oltre ai parametri, puoi generare log di esecuzione anche includendo un'istruzione console.log() nel del codice della funzione. Ogni istruzione di log genererà una voce di log di CloudWatch che verrà inviata a CloudWatch. I log e le metriche sono inclusi nel prezzo di Funzioni CloudFront. 

Lambda@Edge è un'estensione di AWS Lambda che permette di eseguire codice in posizioni edge globali senza il provisioning o la gestione dei server. Lambda@Edge fornisce elaborazione serverless potente e flessibile per funzioni complesse e una logica delle applicazioni completa più vicina ai visualizzatori. Le funzioni di Lambda@Edge vengono eseguite in un ambiente Node.js o Python. Puoi pubblicare le funzioni in una singola regione AWS e quando associ la funzione a una distribuzione di CloudFront, Lambda@Edge replica automaticamente il tuo codice in tutto il mondo. Lambda@Edge si adatta automaticamente al numero delle richieste, che siano poche al giorno o migliaia al secondo.

Lambda@Edge viene eseguito associando funzioni a comportamenti cache specifici in CloudFront. Puoi anche specificare a quale punto durante la richiesta o la risposta di CloudFront deve essere eseguita la funzione (ad esempio quando si riceve una richiesta di visualizzazione, quando viene inoltrata o ricevuta una richiesta dall'origine o subito prima della risposta all'utente finale). È possibile scrivere codice utilizzando Node.js o Python dalla console Lambda, dall'API o utilizzando framework come il Serverless Application Model (SAM). Dopo aver testato la funzione, la puoi associare al comportamento della cache e al trigger di eventi di CloudFront selezionati. Una volta salvata, la prossima volta che verrà effettuata una richiesta alla distribuzione di CloudFront, la funzione verrà propagata all'edge di CloudFront e verrà scalata ed eseguita in base alle necessità. Per avere ulteriori informazioni, consulta la documentazione.

Le funzioni Lambda@Edge disponibili si attiveranno automaticamente in risposta ai seguenti eventi di Amazon CloudFront:

• Richiesta visualizzatore: questo evento si verifica quando un utente finale o un dispositivo collegato a Internet invia una richiesta HTTP(S) a CloudFront e la richiesta arriva alla posizione edge più vicina all'utente.
• Risposta visualizzatore: questo evento si verifica quando il server di CloudFront nella posizione edge è pronto a rispondere all'utente finale o al dispositivo che ha effettuato la richiesta.
• Richiesta origine: questo evento si verifica quando il server CloudFront nella posizione edge non contiene già l'oggetto richiesto nella propria cache e la richiesta del visualizzatore è pronta per essere inviata al server web di origine del backend (ad es. Amazon EC2 o Application Load Balancer o Amazon S3).
• Risposta origine: questo evento si verifica quando il server di CloudFront nella posizione edge riceve una risposta dal server web di origine del backend.

L'implementazione continua su CloudFront offre la possibilità di testare e convalidare le modifiche alla configurazione con una porzione di traffico live prima di distribuire le modifiche a tutti i visualizzatori.

L'implementazione continua con CloudFront ti offre un alto livello di sicurezza nella distribuzione. Ora puoi distribuire due ambienti distinti ma identici, uno blu e l'altro verde, e consentire una semplice integrazione nelle tue pipeline CI/CD (continuous integration/continuous delivery ) con la possibilità di distribuire gradualmente i rilasci senza modificare il sistema dei nomi di dominio (DNS). Garantisce che il tuo spettatore abbia un'esperienza coerente grazie alla persistenza della sessione, legando la sessione dello spettatore allo stesso ambiente. Inoltre, puoi confrontare le prestazioni delle tue modifiche monitorando i log standard e in tempo reale e tornare rapidamente alla configurazione precedente quando una modifica ha un impatto negativo su un servizio. 

Puoi impostare l'implementazione continua associando una distribuzione di staging a una distribuzione primaria attraverso la console di CloudFront, l'SDK, l'interfaccia a riga di comando (CLI) o il modello CloudFormation. Puoi quindi definire delle regole per suddividere il traffico configurando l'intestazione del client o richiamando una percentuale di traffico da testare con la distribuzione di staging. Una volta impostata, puoi aggiornare la configurazione di staging con le modifiche desiderate. CloudFront gestirà la suddivisione del traffico verso gli utenti e fornirà le analisi associate per aiutarti a decidere se continuare l'implementazione o effettuare il rollback. Una volta convalidato il test con le distribuzioni di staging, puoi unire le modifiche alla distribuzione principale.

Per ulteriori informazioni su questa funzionalità, consulta la relativa documentazione.

L'implementazione continua consente il monitoraggio reale degli utenti attraverso il traffico web. Puoi utilizzare uno qualsiasi dei metodi di monitoraggio disponibili: console CloudFront, API CloudFront, CLI o CloudWatch per misurare individualmente le metriche operative della distribuzione primaria e di quella di staging. Puoi misurare i criteri di successo della tua specifica applicazione misurando e confrontando le metriche di throughput (velocità di trasmissione effettiva), latenza e disponibilità tra le due distribuzioni.

Sì, puoi usare qualsiasi distribuzione esistente come base per creare una distribuzione di staging e introdurre e testare le modifiche.

Con l'implementazione continua, puoi associare funzioni diverse alle distribuzioni primarie e di staging. Puoi anche utilizzare la stessa funzione con entrambe le distribuzioni. Se aggiorni una funzione utilizzata da entrambe le distribuzioni, entrambe riceveranno l'aggiornamento.

Ogni risorsa del tuo stack CloudFormation è mappata a una specifica risorsa AWS. Una distribuzione di staging avrà un proprio ID risorsa e funzionerà come qualsiasi altra risorsa AWS. Puoi usare CloudFormation per creare o aggiornare questa risorsa.

Quando si utilizza una configurazione basata sul peso per instradare il traffico verso una distribuzione di staging, è anche possibile abilitare la persistenza della sessione, che aiuta a garantire che CloudFront tratti le richieste provenienti dallo stesso visualizzatore come un'unica sessione. Quando si abilita la persistenza della sessione, CloudFront imposta un cookie in modo che tutte le richieste provenienti dallo stesso visualizzatore in una singola sessione vengano gestite da un'unica distribuzione, quella primaria o quella di staging.

La funzionalità di implementazione continua è disponibile in tutte le posizioni edge di CloudFront senza costi aggiuntivi.

Ogni server e dispositivo collegato a Internet deve avere un indirizzo numerico di protocollo Internet o IP (Internet Protocol). Come Internet e il numero di utenti cresce in modo esponenziale, così aumenta la necessità di indirizzi IP. IPv6 è una nuova versione dell'Internet Protocol, che usa uno spazio di indirizzi di dimensioni maggiori rispetto al suo predecessore, IPv4. Con IPv4, ogni indirizzo IP è a 32 bit, consentendo 4,3 miliardi di indirizzi univoci. Un esempio di indirizzo IPv4 è 192.0.2.1. Gli indirizzi IPv6, invece, sono a 128 bit, perciò sono possibili circa 340 trilioni di trilioni di indirizzi IP univoci. Un esempio di indirizzo IPv6 è 2001:0db8:85a3:0:0:8a2e:0370:7334

Grazie al supporto di IPv6 per Amazon CloudFront, le applicazioni possono connettersi alle posizioni edge di Amazon CloudFront senza bisogno di software o sistemi di conversione da IPv6 a IPv4. È possibile soddisfare i requisiti per l'adozione di IPv6 imposti dalle autorità, tra cui il governo federale degli Stati Uniti, e ottenerne tutti i vantaggi in fatto di estensibilità, semplicità di gestione di rete e supporto integrato aggiuntivo per la sicurezza.

No, le prestazioni di Amazon CloudFront sono identiche qualunque protocollo sia in uso, IPv4 o IPv6.

Tutte le funzionalità esistenti di Amazon CloudFront continueranno a funzionare correttamente con il protocollo IPv6, anche se prima di attivarlo per la distribuzione potresti dover apportare due modifiche all'elaborazione interna dell'indirizzo IPv6.

1. Se hai attivato la funzionalità dei log di accesso di Amazon CloudFront, puoi visualizzare l'indirizzo IPv6 degli utenti nel campo “c-ip” e potresti dover verificare che i sistemi di elaborazione dei log continuino a funzionare per IPv6.
2. Quando abiliti il protocollo IPv6 per una distribuzione Amazon CloudFront, gli indirizzi IPv6 saranno nell'intestazione “X-Forwarded-For” inviata alle origini. Se i sistemi delle origini sono in grado di elaborare esclusivamente indirizzi IPv4, dovrai prima verificare che siano compatibili con il protocollo IPv6.

Inoltre, se usi whitelist di indirizzi IP per Trusted Signer, devi utilizzare una distribuzione solo con IPv4 per URL di Trusted Signer con whitelisting di IP e una distribuzione IPv4/IPv6 per il resto dei contenuti. Questo modello permette di aggirare un problema che potrebbe verificarsi se la richiesta di firma arriva e viene firmata su indirizzo IPv4, ma la richiesta di contenuti arriva su un indirizzo IPv6 differente non incluso nella whitelist.

Per ulteriori informazioni sul supporto di IPv6 in Amazon CloudFront, consulta “Supporto IPv6 su Amazon CloudFront” nella Guida per sviluppatori di Amazon CloudFront.

Se desideri usare IPv6 e gli URL di firmatari attendibili con whitelist di IP devi usare due distribuzioni separate. Una distribuzione deve essere dedicata agli URL Trusted Signer con whitelisting di IP, con protocollo IPv6 disabilitato. Dovresti quindi utilizzare un'altra distribuzione per tutti gli altri contenuti, che sarà compatibile sia con IPv4 che con IPv6.

Sì, gli indirizzi IPv6 degli utenti saranno visualizzati nel campo “c-ip” dei log di accesso, sempre che la relativa funzionalità di Amazon CloudFront sia stata abilitata. Potrai verificare che i sistemi di elaborazione di log funzionino correttamente con gli indirizzi IPv6 prima attivare il protocollo IPv6 sulle distribuzioni. Contatta il supporto per sviluppatori se gli strumenti o i software in uso riscontrano problemi di gestione degli indirizzi IPv6 nei log di accesso a causa del traffico IPv6. Per avere ulteriori informazioni, consulta la documentazione sui log di accesso di Amazon CloudFront.

Sì, puoi usare l'API o la console di Amazon CloudFront per abilitare e disabilitare il protocollo IPv6 sulle singole distribuzioni, sia nuove sia esistenti.

Nella nostra esperienza, l'unico caso più frequente per cui i clienti disabilitano il protocollo è per l'elaborazione di indirizzi IP interni. Quando il protocollo IPv6 è abilitato nella distribuzione Amazon CloudFront, oltre a ricevere un indirizzo IPv6 nei log di accesso dettagliati, riceverai indirizzi IPv6 nell'intestazione “X-Forwarded-For” inviata alle origini. Se i sistemi delle origini sono in grado di elaborare solo indirizzi IPv4, potrebbe essere necessario verificare che continuino con l'elaborazione di indirizzi IPv6 prima di passare interamente a questo protocollo.

Amazon CloudFront dispone di connettività di diverso tipo a seconda dell'area geografica, ma alcune reti non dispongono di una connettività IPv6 diffusa. Anche se nel lungo termine l'IPv6 è di sicuro la soluzione vincente, nel breve termine è l'IPv4 ad essere supportato di sicuro da tutti gli endpoint Internet. Se in alcune aree la connettività IPv4 è migliore, la preferiremo alla connettività IPv6.

Sì, puoi creare record alias di Route 53 che puntino alla distribuzione Amazon CloudFront per supportare sia IPv4 sia IPv6 utilizzando rispettivamente i tipi di record “A” e “AAAA”. Se desideri abilitare solo il protocollo IPv4, devi configurare un solo record alias di tipo “A”. Per ulteriori informazioni sui set di record delle risorse alias, consulta il documento Amazon Route 53 Developer Guide.

A partire dall'1 dicembre 2021, tutti i clienti AWS riceveranno 1 TB di trasferimento dati in uscita, 10.000.000 di richieste HTTP/HTTPS, oltre a 2.000.000 di invocazioni di Funzioni CloudFront ogni mese gratuitamente. Tutti gli altri tipi di utilizzo (ad esempio invalidazioni, richieste proxy, Lambda@Edge, Origin Shield, trasferimento di dati all'origine, ecc.) sono esclusi dal piano gratuito.  

No, i clienti con fatturazione consolidata che saldano i costi di più account in un'unica fattura avranno accesso a un solo Piano gratuito per ciascuna organizzazione.

Il trasferimento dati di 1 TB e i 10.000.000 di richieste Get rappresentano i limiti del piano gratuito in tutte le posizioni edge. Se l'utilizzo supera i limiti del piano gratuito mensile, paghi semplicemente le tariffe standard del servizio AWS on-demand per ogni regione. Per conoscere tutti i dettagli sui prezzi, consulta la pagina dei prezzi di AWS CloudFront.

Tramite l'accesso al tuo account e al pannello di controllo per la Gestione di fatturazione e costi, è possibile visualizzare le attività di utilizzo passate e presenti per regione. A quel punto è possibile gestire i costi e l'utilizzo con AWS Budgets, visualizzare i fattori di costo e le tendenze di utilizzo attraverso Cost Explorer e approfondire le informazioni relative ai costi utilizzando i Report di costi e utilizzo. Per ulteriori informazioni sul controllo dei costi di AWS, guarda il tutorial da 10 minuti Controllo delle tue spese con AWS.

Anche i clienti abbonati al piano Bundle CloudFront Security Savings possono beneficiare del piano gratuito. Se hai necessità di ridurre il tuo impegno nei confronti del Bundle CloudFront Security Savings per via del piano gratuito, contatta il servizio clienti e valuteremo la tua richiesta di modifiche. Forniremo maggiori dettagli in merito nei prossimi giorni. Rimani in contatto. 

Per consultare ulteriori domande, visita https://aws.amazon.com/free/free-tier-faqs/.

Le tariffe di Amazon CloudFront si basano sull'utilizzo effettivo del servizio in cinque aree: trasferimento dati in uscita, richieste HTTP/HTTPS, richieste di invalidazione, richieste di log in tempo reale e certificati SSL personalizzati con IP dedicato associati a una distribuzione CloudFront.

Grazie al Piano di utilizzo gratuito di AWS, è possibile iniziare a utilizzare Amazon CloudFront gratuitamente e mantenere le tariffe basse mano a mano che l'utilizzo aumenta. Tutti i clienti CloudFront ricevono gratuitamente 1 TB di trasferimento dati in uscita e 10.000.000 di richieste HTTP e HTTPS per Amazon CloudFront, anche al superamento di questi limiti. Se 

• Trasferimento dati in uscita a Internet
  Viene fatturato il volume dei dati trasferiti in uscita dalle edge location di Amazon CloudFront, misurati in GB. Consulta le tariffe di trasferimento dei dati verso Internet di Amazon CloudFront in questa pagina. L'utilizzo del trasferimento di dati viene conteggiato separatamente per ciascuna regione geografica, poiché le tariffe in vigore sono variabili. Se vengono utilizzati i servizi AWS come origine dei file, i costi di ognuno dei servizi utilizzati saranno addebitati separatamente, inclusi i costi di archiviazione e le ore di utilizzo dei servizi di elaborazione. Se viene utilizzata un'origine in AWS (ad es. Amazon S3, Amazon EC2 e così via), a partire dal 1° dicembre 2014 non viene addebitato alcun costo per il trasferimento di dati in uscita verso Amazon CloudFront. Questa novità si applica al trasferimento di dati da tutte le Regioni AWS verso tutte le posizioni edge di CloudFront nel mondo.
• Trasferimento dati in uscita verso l'origine
  Viene fatturato il volume dei dati trasferiti in uscita, misurato in GB, dalle posizioni edge di Amazon CloudFront ai tuoi server di origine (sia di origine AWS sia di altra origine). Le tariffe per il trasferimento dati da Amazon CloudFront verso l'origine sono indicate qui.
• Richieste HTTP/HTTPS
  Viene fatturato il numero di richieste HTTP/HTTPS fatte ad Amazon CloudFront sui contenuti. Le tariffe delle richieste HTTP/HTTPS sono disponibili qui.
• Richieste di invalidazione
  Viene fatturato ogni percorso in una richiesta di invalidamento. Un percorso elencato in una richiesta di invalidamento rappresenta l'URL (o gli URL, se il percorso contiene caratteri jolly) degli oggetti che desideri invalidare dalla cache di CloudFront. Non è previsto alcun costo per i primi 1.000 percorsi richiesti ogni mese da Amazon CloudFront. Oltre tale soglia, ogni richiesta di percorso per l'invalidamento verrà addebitata. Le tariffe delle richieste di invalidazione sono disponibili qui.
• Richieste di log in tempo reale
  I log in tempo reale vengono addebitati in base al numero di righe di log generate; il prezzo è di 0,01 USD ogni 1.000.000 righe di log pubblicate da CloudFront sulle destinazioni di log dell'utente.
• SSL personalizzato con IP dedicato
  Vengono fatturati 600 USD al mese per ogni certificato SSL personalizzato con una o più distribuzioni CloudFront utilizzando la versione IP dedicata del supporto certificato SSL. Questa quota mensile si calcola all'ora. Ad esempio, se si ha un certificato SSL personalizzato associato ad almeno una distribuzione CloudFront solo per 24 ore (ossia 1 giorno) nel mese di giugno, il costo totale per l'utilizzo della funzione Certificato SSL personalizzato per giugno sarà (1 giorno/30 giorni) di * 600 USD = 20 USD. Per utilizzare il supporto per certificati SSL personalizzati con IP dedicato, si deve caricare un certificato SSL e utilizzare la Console di gestione AWS per associarlo alle distribuzioni CloudFront. Se devi associare più di due certificati SSL personalizzati a una distribuzione CloudFront, includi i dettagli del caso d'uso e il numero di certificati SSL personalizzati che vuoi utilizzare nel modulo di richiesta di incremento dei limiti di CloudFront.

I piani di utilizzo per il trasferimento dati sono misurati separatamente per ogni regione geografica. Salvo diversa indicazione, i prezzi sopra indicati non includono eventuali tasse, imposte o altri importi statali applicabili, qualora esistenti.

Salvo diversamente specificato, i prezzi sono al netto di eventuali tasse e imposte doganali, inclusa l'IVA ed eventuali imposte sulle vendite. Per i clienti con indirizzo di fatturazione in Giappone, l'utilizzo dei servizi AWS è soggetto all'imposta sul consumo giapponese. Ulteriori informazioni.

Se disponi di una distribuzione che serve 1.000 richieste al secondo con una dimensione dei log di 1 KB e crei un flusso di dati Kinesis negli Stati Uniti orientali (Ohio) con 2 shard:

costo mensile del flusso di dati Kinesis: 47,74 USD/mese, calcolato utilizzando il calcolatore Kinesis disponibile qui.

Costo mensile dei log in tempo reale di CloudFront: richieste al mese X costo dei log in tempo reale = 1.000 * (60 sec * 60 min * 24 ore * 30 giorni) X (0,01 USD/1.000.000) = 25,92 USD/mese

Una risposta 304 è una risposta a una richiesta GET condizionale e comporterà un addebito della richiesta HTTP/HTTPS e del trasferimento dati in uscita verso Internet. Una risposta 304 non contiene un corpo messaggio, tuttavia le intestazioni HTTP consumano della larghezza di banda per la quale vengono addebitate le tariffe standard di trasferimento dati di CloudFront. La quantità di dati trasferiti dipende dalle intestazioni associate all'oggetto.

Sì, le categorie di prezzo offrono la possibilità di ridurre i prezzi pagati per distribuire contenuti da Amazon CloudFront. Di default, Amazon CloudFront riduce al minimo la latenza dell'utente finale distribuendo i contenuti da tutta la sua rete globale di edge location. Tuttavia, poiché le nostre tariffe sono più elevate dove i costi sono maggiori, l'utente pagherà di più per distribuire i propri contenuti con bassa latenza agli utenti finali in alcune location. Le categorie di prezzo consentono di ridurre i costi di distribuzione escludendo le edge location di Amazon CloudFront più care dalla propria distribuzione Amazon CloudFront. In questi casi, Amazon CloudFront distribuirà i contenuti dalle edge location entro le location incluse nella categoria di prezzo selezionata e verrà fatto pagare il trasferimento dati e i costi delle richieste dalla location attuale in cui sono stati distribuiti i contenuti.

Se per te le prestazioni hanno la massima priorità, non dovrai preoccuparti di niente: i tuoi contenuti saranno distribuiti da tutta la nostra rete di location. Tuttavia, se desideri avvalerti di un'altra categoria di prezzo, puoi configurare la tua distribuzione dalla Console di gestione AWS o attraverso l'API di Amazon CloudFront. Se selezioni una categoria di prezzo che non include tutte le location, alcuni utenti, soprattutto quelli in aree geografiche non incluse nella tua categoria di prezzo, potrebbero avere una latenza più elevata rispetto alla distribuzione dei contenuti da tutte le location di Amazon CloudFront.

Si ricorda che Amazon CloudFront potrebbe comunque servire richieste per i tuoi contenuti da una edge location in una zona non inclusa nella categoria di prezzo selezionata. In questo caso, saranno addebitati solo i costi per la posizione meno cara nella tua categoria di prezzo.

L'elenco delle posizioni per ogni categoria di prezzo è riportato qui.

Bundle CloudFront Security Savings è un piano tariffario self-service flessibile che ti consente di risparmiare fino al 30% delle spese di CloudFront a fronte di un impegno per un importo consistente di utilizzo mensile (ad esempio, 100 USD al mese) per un periodo di un anno.  Come beneficio aggiunto, è incluso l’utilizzo di AWS WAF (Web Application Firewall) senza costi supplementari, fino al 10% dell’importo del piano stabilito, per proteggere le risorse CloudFront.  Ad esempio, un impegno di 100 USD di utilizzo di CloudFront al mese coprirebbe un valore di 142,86 USD di utilizzo di CloudFront, per un risparmio del 30% rispetto alle tariffe standard. Inoltre, fino a 10 USD di utilizzo di AWS WAF sono inclusi per proteggere le risorse CloudFront senza costi aggiuntivi ogni mese (fino al 10% del tuo impegno CloudFront).  I costi standard di CloudFront e AWS WAF si applicano a qualsiasi utilizzo superiore a quello coperto dal tuo impegno di spesa mensile.  Mano a mano che il tuo utilizzo aumenta, puoi acquistare altri pacchetti di risparmio per ottenere sconti sull'utilizzo incrementale. 

Acquistando un piano Bundle CloudFront Security Savings, riceverai un risparmio del 30% che apparirà sulla parte relativa al servizio CloudFront della tua fattura mensile e che compenserà qualsiasi tipo di utilizzo di CloudFront fatturato, tra cui trasferimento di dati in uscita, trasferimento di dati all'origine, tariffe delle richieste HTTP/S, richieste di crittografia a livello di campo, Origin Shield, invalidazioni, SSL personalizzato con IP dedicato, IP statici Anycast, Lambda@Edge, Funzioni CloudFront, log in tempo reale, utilizzo della cache edge regionale, gRPC, supporto WebSocket e altre funzionalità di CloudFront. Riceverai anche benefici aggiuntivi che contribuiscono a coprire l'utilizzo di AWS WAF associato alle distribuzioni di CloudFront.

È possibile iniziare a utilizzare il piano Bundle CloudFront Security Savings visitando la console di CloudFront per ottenere suggerimenti sull'importo dell'impegno in base all'utilizzo storico di CloudFront e AWS WAF o inserendo l'utilizzo mensile stimato. Otterrai un confronto tra i costi mensili del Bundle CloudFront Security Savings e i costi on-demand e vedrai il risparmio stimato, in modo tale da poter decidere il piano giusto per le tue esigenze.  Una volta eseguita la registrazione a un pacchetto di risparmio, ti verrà addebitata la tariffa mensile e vedrai apparire i crediti che compensano le tue spese di utilizzo di CloudFront e WAF.  I costi standard del servizio si applicano a qualsiasi utilizzo superiore a quello coperto dal tuo impegno di spesa mensile. 

Una volta scaduto il periodo del servizio Bundle CloudFront Security Savings, verranno applicati i costi del servizio standard per l'utilizzo di CloudFront e AWS WAF.   L'impegno mensile del pacchetto di risparmio non sarà più fatturato e i vantaggi del pacchetto di risparmio non saranno più applicati.  In qualsiasi momento prima della scadenza del termine del tuo pacchetto, puoi scegliere di rinnovare automaticamente il servizio Bundle CloudFront Security Savings per un altro periodo di 1 anno.

Bundle CloudFront Security Savings può essere acquistato in qualsiasi account all'interno di una famiglia AWS Organizations/Fatturazione consolidata.   I benefici di CloudFront Security Savings Bundle vengono applicati come crediti sulla tua fattura. I benefici forniti dal pacchetto di risparmio sono applicabili per impostazione predefinita all'uso su tutti gli account all'interno della famiglia AWS Organizations/Fatturazione consolidata (la condivisione dei crediti è attivata) e dipendono da quando l'account sottoscrittore si unisce o lascia un'organizzazione.  Per ulteriori informazioni su come i crediti AWS si applicano ad account singoli e multipli, vedi Crediti AWS.

Sì, puoi acquistare altri servizi Bundle CloudFront Security Savings mano a mano che il tuo utilizzo aumenta per ottenere sconti sull'utilizzo incrementale.   Tutti i servizi Bundle CloudFront Security Savings attivi verranno presi in considerazione quando si calcola la tua fattura AWS.

I costi dell'impegno mensile compaiono in una sezione separata del piano Bundle CloudFront Security sulla fattura.  L'utilizzo coperto dal piano Bundle CloudFront Security Savings compare in entrambe le parti CloudFront e WAF della fattura sotto forma di crediti in compensazione dei costi di utilizzo standard.  

Sì, AWS Budgets consente di impostare soglie di costo e di utilizzo e di ricevere notifiche per e-mail o attraverso un argomento Amazon SNS quando i costi effettivi o previsti superano la soglia.  Puoi creare un budget AWS filtrato personalizzato per il servizio CloudFront e impostare l'importo della soglia di budget sull'utilizzo on-demand di CloudFront coperto da Bundle CloudFront Security Savings per ricevere una notifica quando questa soglia viene superata.   Per ulteriori informazioni sui budget, vedi le sezioni Managing your costs with AWS Budgets e Creating a budget nel documento AWS Billing and Cost Management User Guide. 

Come ulteriore vantaggio del piano Bundle CloudFront Security Savings, è incluso l'utilizzo di AWS WAF senza costi supplementari, fino al 10% dell'importo del piano stabilito, per proteggere le risorse CloudFront. I costi standard di CloudFront e AWS WAF si applicano per qualsiasi utilizzo oltre quello coperto dal servizio Bundle CloudFront Security Savings.  Le regole WAF gestite sottoscritte attraverso AWS Marketplace non sono coperte dal piano Bundle CloudFront Security Savings. 

È consentito abbonarsi o all'uno o all'altro.  Per eventuali domande sul contratto con prezzi personalizzati, contatta il tuo AWS Account Manager.

È possibile abbonarsi a un piano Bundle CloudFront Security Savings solo attraverso la console di CloudFront.  Valuteremo di rendere disponibile il servizio mediante API come miglioramento futuro.