Amazon CloudFront Supporta HTTP/3

AWS ha recentemente annunciato che le distribuzioni CloudFront supportano richieste HTTP versione 3 (HTTP/3) su QUIC. L’utilizzo di HTTP/3 è opzionale ma fornisce tempi di risposta più rapidi e maggiore sicurezza rispetto alle versioni HTTP precedenti.

Il supporto HTTP/3 si basa su s2n-quic, una implementazione open source in Rust di QUIC migliorando le prestazioni e la user experience dell’utente. Channy Yun, principal principal developer advocate presso AWS, spiega come funziona HTTP/3:

HTTP/3 utilizza QUIC e supera molte delle limitazioni del protocollo TCP. Quando si utilizza HTTP/2 esistente su TCP e TLS, TCP necessita di un handshake per stabilire una sessione tra un client e un server e anche TLS necessita del proprio handshake per garantire che la sessione sia protetta. Ogni handshake deve compiere l’intero viaggio di andata e ritorno tra client e server, che può richiedere molto tempo quando client e server sono molto distanti. Tuttavia, QUIC ha bisogno solo di un singolo handshake per stabilire una sessione sicura.

Photo by Marc-Olivier Jodoin on Unsplash

Yan Cui, consulente cloud e AWS Serverless Hero, auspica

Le distribuzioni CloudFront gestite come quelle gestite da Amplify, AppSync e API Gateway saranno automaticamente abilitate a HTTP/3?

Essendo una impostazione opzionale non di default, HTTP/3 non è al momento disponibile per le API dei servizi gestiti AWS. Per abilitare HTTP/3 su una distribuzione CloudFront, bisogna modificare la configurazione utilizzando la console, l’API UpdateDistribution o CloudFormation. I client che non supportano HTTP/3 possono comunque utilizzare versioni HTTP precedenti.

Yun aggiunge:

HTTP/3 offre vantaggi a tutti gli utenti CloudFront sotto forma di tempi di connessione più rapidi, stream multiplexing e meno round trip nel processo di handshake. 

Amazon Cloudfront non è l’unico CDN che supporta il nuovo standard, con il supporto QUIC e HTTP/3 disponibile su Cloudflare dal 2019. Google Cloud CDN e HTTPS Load Balancing supportano HTTP/3 dallo scorso anno. Google afferma che sul proprio motore di ricerca la feature ha ridotto la latenza del 2% e i tempi di rebuffer video su YouTube del 9%.

Il supporto HTTP/3 è disponibile in tutte le edge location CloudFront senza costi aggiuntivi. Affinché i client e le distribuzioni utilizzino HTTP/3, i client devono supportare TLSv1.3 e Server Name Indication (SNI). CloudFront supporta la migrazione della connessione a HTTP/3 per cambiare rete senza perdere la connessione.

Vuoi leggere altre news su AWS?

Amazon Redshift Serverless è GA

Amazon annuncia le istanze EC2 Mac M1 per sviluppare e testare applicazioni su macOS

TLS 1.2 diventa il minimo protocollo TLS su AWS

AWS ha recentemente annunciato che il protocollo crittografico TLS 1.2 diventerà il livello minimo per gli endpoint API. Il provider cloud rimuoverà la compatibilità e il supporto per le versioni 1.0 e 1.1 su tutte le API e le region entro giugno 2023.

Janelle Hopper, senior technical program manager presso AWS, Daniel Salzedo, Senior specialist technical account manager presso AWS, e Ben Sherman, software development engineer presso AWS, spiegano:

Abbiamo mantenuto fino ad oggi il supporto AWS per TLS versioni 1.0 e 1.1 per mantenere la compatibilità con client meno recenti o difficili da aggiornare, come gli embedded device. Inoltre, abbiamo implementato misure di mitigazione che aiutano a proteggere i tuoi dati dai problemi identificati nelle versioni precedenti. Ora è però arrivato il momento di rimuovere TLS 1.0 e 1.1, perché un numero crescente di customers ha richiesto questa modifica per semplificare i processi di compliance e sono sempre meno i progetti che le utilizzano.

Secondo AWS, il 95% dei deployment utilizza già protocolli crittografici più recenti e l’uso più comune oggi di TLS 1.0 o 1.1 sono le versioni di .NET Framework precedenti alla 4.6.2. Colm MacCárthaigh, VP e distinguished engineer presso AWS, scrive:

In AWS non deprechiamo quasi mai nulla, ma TLS1.0 e TLS1.1 sono l’eccezione! Pochissimi clienti utilizzano ancora queste versioni e puoi controllare i log di CloudTrail per vedere se hai richieste.

Utilizzando il nuovo attributo tlsDetails , i log di AWS CloudTrail possono essere monitorati per identificare se le versioni TLS obsolete sono attualmente utilizzate senza rendersene conto. AWS consiglia di analizzare i record con CloudTrail Lake, CloudWatch Log Insights o Athena. CloudWatch Log Insights dispone di due nuove query che possono essere utilizzate per logs in cui è stato utilizzato TLS 1.0 o 1.1 e trovare il numero di richieste per servizio che hanno utilizzato versioni TLS obsolete.

Fonte: https://aws.amazon.com/blogs/security/tls-1-2-required-for-aws-endpoints/

Per ridurre al minimo l’impatto sui servizi, AWS implementerà le modifiche endpoint per endpoint nei prossimi mesi, partendo da quelli dove non sono rilevate connessioni con versioni TLS 1.0 e 1.1. Dopo il 28 giugno 2023, AWS aggiornerà la configurazione di tutti gli endpoint rimasti, anche se i customer hanno ancora connessioni che utilizzano versioni non supportate.

Vuoi leggere altre news su AWS?

Il software per moduli hardware AWS IoT ExpressLink è GA

Amazon introduce il ripristino automatico di default delle EC2

Amazon ha recentemente annunciato che le istanze EC2 ora verranno ripristinate automaticamente nel caso in cui diventino irraggiungibili a causa di problemi hardware. Il ripristino automatico migra l’istanza su un hardware diverso mantenendo l’instance ID, gli indirizzi IP privati, l’Elastic IP e i metadati.

Esistono diversi scenari che possono attivare il ripristino automatico di una EC2: ad esempio, una perdita di connettività di rete o di alimentazione e problemi software o hardware sull’host. Durante il ripristino di un’istanza, è richiesto un reboot della EC2 e tutti i dati in memoria vengono persi. Se l’istanza aveva un indirizzo IPv4 pubblico, questo verrà mantenuto. Allo stesso modo, se la EC2 si trovava in un placement group, la nuova istanza verrà fatta ripartire nello stesso.  

Photo by JESHOOTS.COM on Unsplash

Mani Chandrasekaran, Principal Solutions Architect di AWS, scrive:

Questo può sembrare un annuncio minore, ma avrà un impatto significativo e positivo sui nostri clienti. Anche se era disponibile in precedenza,  “impostazione predefinita” è la parola chiave.

Una prima iterazione della funzionalità era stata rilasciata anni fa ed è in alternativa possibile ripristinare un’istanza automaticamente configurando un CloudWatch Alarm.

 Il nuovo comportamento di default  è pensato per accelerare il ripristino di un’istanza quando è impattata da un problema hardware, ma è sempre possibile disabilitarlo. Il ripristino automatico non viene avviato se un’istanza fa parte di un gruppo Auto Scaling.

Amazon evidenzia che il ripristino automatico di un’istanza non è inteso come una soluzione HA in quanto potrebbe non riuscire se la capacità nella zona di disponibilità è insufficiente o se si verificano problemi di infrastruttura che influiscono sul processo di recupero.

Non tutte le classi di istanze EC2 attualmente disponibili supportano il ripristino automatico. Anche le istanze con un’interfaccia EFA, le istanze che utilizzano instance store e le istanze metal non supportano il ripristino automatico. È possibile verificare le istanze che supportano il ripristino automatico utilizzando il comando CLI describe-instance-types :

aws ec2 describe-instance-types --filters Name=auto-recovery-supported,Values=true   --query "InstanceTypes[ *].[InstanceType]" --output text | sort

La nuova funzionalità non garantisce un massimo recovery time entro cui una EC2 sia disponibile.

Vuoi leggere altre news su AWS?

AWS Firewall Manager Supporta Palo Alto Networks