Cockroach Labs ha recentemente pubblicato il rapporto annuale sul cloud che valuta le prestazioni di AWS, Microsoft Azure e Google Cloud per carichi di lavoro OLTP. Diversamente dal 2021, il report quest’anno non indica un cloud provider migliore, ma osserva come le istanze AMD più recenti offrono prestazioni migliori di quelle Intel. Le istanze ARM non sono invece state testate. 

Secondo il rapporto, tutti e tre i principali fornitori di servizi cloud offrono opzioni simili a prezzi competitivi. Eseguendo oltre 3000 test su 56 diversi tipi di istanze e con 107 configurazioni differenti, la migliore qualità-prezzo è risultata dalle istanze AMD con processori Milan. L’esclusione dai test delle istanze ARM e di altre istanze recenti lascia dubbi per i casi d’uso in cui, ad esempio, le istanze AWS Graviton potrebbero risultare migliori.  Keith McClellan, director of partner solutions engineering at Cockroach Labs e autore del report, riconosce il problema:

ARM tornerà nel Cloud Report 2023 – sfortunatamente non avevamo ancora i binari ARM di CockroachDB per il report di quest’anno. 

Non tutte le analisi concordano sui vantaggi delle istanze AMD. Il benchmark “Economical Comparison of AWS CPUs for MySQL (ARM vs Intel vs AMD)” di Percona, conclude che Graviton è più economico nella maggior parte dei casi e di solito Intel ha prestazioni migliori di AMD, almeno su AWS.

Secondo Cockroach Labs, le istanze più piccole offrono in proporzione risultati migliori di quelle più grandi: per i test OLTP e CPU, il report mostra un vantaggio in termini di prestazioni per vCPU su istanze più piccole, indipendentemente dalla piattaforma CPU, dal cloud o dal tipo di istanza.

Processori e benchmark CPU non erano l’unico obiettivo degli autori. Il rapporto sottolinea l’importanza dei costi di storage e trasferimento dati che hanno un impatto significativo sul costo totale del deployment:

Anche per quantità relativamente piccole di storage, il costo totale di un carico di lavoro è molto più influenzato dal costo dello storage rispetto al costo dell’istanza.

Tranne rare eccezioni, il benchmark evidenzia che non valga la pena scegliere e pagare storage ad alte prestazioni, come ad esempio Provisioned IOPS. Per lo stesso processore, i fornitori di servizi cloud offrono classi di istanza diverse, con un rapporto vCPU/RAM diverso. Nel report, gli autori scrivono: 

I nostri test suggeriscono che, sebbene sia possibile risparmiare scegliendo istanze con un rapporto vCPU/RAM più basso, è probabile che si osservino prestazioni migliori con istanze con più memoria disponibile. (…) Nei nostri test, abbiamo riscontrato che il rapporto ideale di vCPU:RAM è pari a 1:4.

Rispetto all’edizione precedente, il report 2022 ha aggiunto test per tipi di istanze di dimensioni diverse, test di latenza tra regioni e test di salvataggio dati con fsync.

L’accesso al report completo è gratuito ma richiede la registrazione.

Vuoi leggere altre news su AWS?

AWS DataSync supporta il trasferimento dati tra AWS, Google Cloud e Azure

Amazon ha recentemente annunciato che AWS DataSync supporta Google Cloud Storage e Azure Files storage. Le due nuove opzioni del servizio aiutano a trasferire i dati sia in entrata che in uscita da AWS, ma i costi di data transfer rimangono significativi

DataSync può copiare e sincronizzare i dati da diverse sources, supportando progetti multi-cloud o particolari requisiti di protezione dei dati. Basandosi su un protocollo proprietario, DataSync esegue e verifica trasferimenti di dati una tantum e periodici e scala elasticamente in funzione del carico. Il servizio supporta filtri di inclusione/esclusione, controlli di limitazione di banda e il recovery automatico in caso di problemi temporanei di rete. Danilo Poccia, chief evangelist EMEA presso AWS, spiega:

In questo modo, puoi semplificare le tue attività di elaborazione dei dati o consolidamento dello storage. Questo aiuta anche se devi importare, condividere e scambiare dati con clienti, fornitori o partner che utilizzano Google Cloud Storage o Microsoft Azure Files. DataSync fornisce sicurezza end-to-end, inclusa la crittografia e la validazione dell’integrità dei dati.

Google Cloud Storage e Azure Files storage sono le prime sources di altri cloud providers, ma non sono le uniche opzioni supportate da AWS DataSync: in servizio può sincronizzare i dati con NFS, SMB, Hadoop Distributed File Systems (HDFS) e diversi servizi AWS come Amazon S3 o Amazon FSx. 

Mentre Danilo Poccia spiega come trasferire dati da Google Cloud Storage ad Amazon S3, Rodney Underkoffler e Aidan Keane, senior specialist solutions architect presso AWS, dimostrano invece come spostare i dati da SMB su Azure Files. 

AWS DataSync può aiutare a migrare i dati tra i principali fornitori di servizi cloud, ma i costi del trasferimento dei dati possono rappresentare un ostacolo significativo. Per mitigare l’impatto e ridurre i costi, AWS consiglia di installare l’agent DataSync nell’ambiente di origine dei dati per sfruttare la compressione dei dati in transito. 

Non ci sono costi specifici per le nuove opzioni DataSync, ma spostando dati verso AWS, si è soggetti a costi in uscita da Google Cloud e Microsoft Azure. Viceversa, spostando i dati da AWS, viene addebitato il costo del trasferimento dei dati da EC2 a Internet. La velocità di copia di AWS DataSync dipende dalla quantità di dati e dalle condizioni della rete.

Vuoi leggere altre news su AWS?

AWS introduce il routing IP-based su Route 53

AWS ha recentemente introdotto il supporto per il routing IP-based su Amazon Route 53. La nuova opzione del servizio DNS consente ai clienti di instradare le richieste in base alla subnet del client per ottimizzare i costi di transito e la latenza.

Se il routing basato sulla geolocalizzazione è pensato per instradare il traffico in base alla localizzazione, è basato comunque su dati centralizzati che Amazon Route 53 raccoglie e mantiene aggiornati. La gestione del routing IP-based permette invece di gestire le richieste basandosi su una conoscenza specifica dei clienti e delle reti. E’ possibile ad esempio gestire gli utenti che arrivano da uno specifico ISP mandando tutte le richieste ricevute a un endpoint dedicato. 

Scott Morrison, Senior Specialist Solutions Architect presso AWS, e Suresh Samuel, Senior Technical Account Manager presso AWS, spiegano:

Con il routing IP-based, puoi migliorare il tuo routing DNS sfruttando la tua conoscenza della rete, delle applicazioni e dei client per prendere le migliori decisioni di routing per i tuoi utenti finali. Il routing IP-based offre un controllo granulare per ottimizzare le prestazioni o ridurre i costi di rete.

Per implementare il routing IP-based per i record su Route 53, è necessario creare una o più CIDR collection, mappando location e blocchi CIDR, che possono essere poi utilizzate nella definizione dei record DNS. Morrison e Samuel chiariscono in che modo il routing IP-based determina l’indirizzo IP della richiesta:

Quando è disponibile, Route 53 utilizzerà il valore EDNS Client Subnet (ECS). In caso contrario, utilizzerà l’IP del resolver  (…) Se il valore ECS nella query DNS corrisponde a una delle sottoreti associate alla location, Route 53 risponde alla query DNS con il valore corrispondente.

IP-based e geolocalizzazione non sono le uniche opzioni di routing disponibili su Route 53: è possibile gestire il traffico attraverso diversi modelli di failover e routing, ad esempio routing basato su latenza, prossimità geografica o weighted routing. 

Se una query arriva da un indirizzo IPv4 o IPv6 non definito, Route 53 risponderà con il valore di default. Con costi a partire da 0,80 USD per milione di query, il routing IP-based è più costoso del routing  geo DNS e geo proximity che partono da 0,70 USD per milione di query. La nuova funzionalità di Route 53 non è supportata per private hosted zone.

Vuoi leggere altre news su AWS?

AWS introduce PowerShell Custom Runtime per Lambda

AWS ha recentemente annunciato una nuova custom runtime per AWS Lambda per eseguire le funzioni Lambda scritte in PowerShell. Grazie alla nuova runtime, gli sviluppatori possono scrivere codice PowerShell nativo in Lambda senza dover compilare il codice, semplificando il rilascio e il test.

Julian Wood,  serverless developer advocate presso AWS, spiega i vantaggi:

La nuova custom runtime per PowerShell utilizza PowerShell nativo, invece di compilare PowerShell e farlo girare su .NET. L’utilizzo nativo di PowerShell rende l’ambiente di runtime della funzione simile a una sessione standard PowerShell, semplificando il processo di sviluppo e test (…) Questa runtime personalizzata restituisce tutto ciò che è nella pipeline come output della funzione. Ciò offre un maggiore controllo sull’output e sui messaggi di errore.

Nonostante Lambda supporti PowerShell dal 2018, la soluzione precedente richiede la compilazione utilizzando la runtime .NET Core per PowerShell. 

La creazione di funzioni Lambda con PowerShell attualmente supporta  .NET 6 e .NET Core 3.1. La runtime definisce due variabili principali messe a disposizione della funzione Lambda: $LambdaInput, un PSObject che contiene i dati dell’evento di input e $LambdaContext, un oggetto che fornisce metodi e proprietà con informazioni su ambiente e runtime. 

Kevin Marquette, Systems development engineer presso Amazon e creatore di PowerShell Explained, scrive:

È davvero fantastico. Non ero soddisfatto dell’esperienza precedente con PowerShell  e Lambda, quindi ho creato una custom runtime per mostrare come migliorare la user experience. (…) Sono contento che questo sia stato finalmente rilasciato.

La nuova custom runtime consente di modificare il codice PowerShell direttamente all’interno della console Lambda e supporta funzionalità aggiuntive, tra cui Add-Type e diversi handler options. 

È disponibile un repository GitHub con il codice per la custom runtime, informazioni per l’installazione e diversi esempi.

Vuoi leggere altre news su AWS?

AWS introduce le prime EC2 con processori Graviton3

AWS ha recentemente annunciato la GA delle istanze C7g, le prime EC2 che utilizzano processori Graviton3. Progettati per carichi di lavoro che richiedono molta capacità di calcolo, forniscono crittografia della memoria sempre attiva e cache dedicata per ogni vCPU.

Annunciate in anteprima all’ultimo re:Invent, le istanze C7g sono disponibili in otto versioni, da 1 a 64 vCPU, con fino a 128 GiB di memoria, 30 Gbps di network e 20 Gbps di network EBS. Sébastien Stormacq, principal developer advocate presso AWS, scrive:

I processori Graviton3 offrono prestazioni fino al 25% superiori e un accesso alla memoria più veloce del 50% basato sulla tecnologia DDR5, all’avanguardia rispetto ai processori Graviton2. 

Secondo il comunicato stampa, le istanze C7g sono progettate per carichi di lavoro come web servers, load balancer, calcolo ad alte prestazioni (HPC), giochi, video transcoding e  modellazione scientifica. Josh Triplett, Rust developer e language team lead, ha testato le istanze di Graviton3 compilando il kernel Linux e scrive:

Queste EC2 offrono un notevole aumento delle prestazioni. Compilazione di un kernel arm64 5.18 su istanze a 64 CPU:
c6g.16xlarge defconfig: 82.246s
c6g.16xlarge allmodconfig: 364.054s
c7g.16xlarge defconfig: 65.442s
c7g.16xlarge allmodconfig: 282.196s
E partono anche più velocemente.

Le nuove istanze sfruttano il sistema AWS Nitro, una combinazione di hardware dedicato e hypervisor Nitro. AWS afferma che “Graviton3 utilizza fino al 60% di energia in meno per le stesse prestazioni di istanze EC2 comparabili”, ma non chiarisce come sia stato eseguito il benchmark e quali fossero le EC2 comparabili. Testando FreeBSD, Colin Percival, fondatore di Tarsnap, scrive:

Per quanto riguarda FreeBSD, Graviton3 è solo una versione più veloce di Graviton2 (…) Graviton3 è un bel miglioramento rispetto a Graviton2: ad eccezione di sha256 — che, a 1,2 GB/s, è già più che sufficientemente veloce — vediamo costantemente miglioramenti di CPU tra il 30% e il 45%.

Ian Smith, engineering manager presso Honeycomb.io, aggiunge:

Abbiamo potuto provare in anteprima le istanze Graviton3, che hanno offerto enormi miglioramenti delle prestazioni per il nostro carico di lavoro anche rispetto a Graviton2 (e incredibilmente meglio delle istanze Intel di quinta e persino di sesta generazione)

Le istanze C7g sono attualmente disponibili solo in due regioni negli Stati Uniti, con altre regioni previste in futuro. I costi partono da $ 0,0363/ora per una c7g.medium, un aumento del 7% rispetto al prezzo della precedente c6g.medium ($ 0,034/ora).

Vuoi leggere altre news su AWS?

Amazon EC2 Supporta NitroTPM e UEFI Secure Boot

AWS ha recentemente annunciato la GA di UEFI Secure Boot e NitroTPM, un modulo TPM virtuale per istanze EC2 basato su AWS Nitro. Le nuove funzionalità sono progettate per la convalida del processo di avvio, la protezione delle chiavi e la gestione dei diritti digitali.

Presentato per la prima volta a re:Invent, NitroTPM può essere utilizzato per dimostrare l’integrità del software di avvio dell’istanza, consentendo il supporto dell’attestazione remota.   Sviluppati per fornire funzionalità di sicurezza basate su hardware, i Trusted Platform Module (TPM) possono generare, archiviare in modo sicuro e controllare l’uso di chiavi di crittografia, credenziali e altri dati. Sébastien Stormacq, principal developer advocate at AWS,  spiega:

Puoi utilizzare NitroTPM per archiviare chiavi di crittografia o chiavi SSH, al di fuori della memoria dell’istanza EC2, proteggendole dalle applicazioni in esecuzione sull’istanza. NitroTPM sfrutta le proprietà di isolamento e sicurezza del sistema Nitro per garantire che solo l’istanza possa accedere a questi dati. NitroTPM fornisce le stesse funzioni di un TPM fisico e segue la specifica ISO TPM 2.0.

Lo Unified Extensible Firmware Interface (UEFI) Secure Boot impedisce la modifica non autorizzata del flusso di esecuzione dell’istanza EC2 garantendo che l’istanza esegua solo software firmato con chiavi crittografiche archiviate nel database dall’UEFI.

Oltre a NitroTPM, AWS Nitro offre Nitro Cards, una famiglia di schede che  accelera l’IO in lettura e scrittura, Nitro Security Chip, Nitro Hypervisor e Nitro Enclaves per creare ambienti di calcolo isolati e proteggere ulteriormente dati altamente sensibili.

Riguardo a NitroTPM, attualmente sono supportati solo i tipi di istanza Intel e AMD che supportano la modalità di avvio UEFI. Le istanze Graviton1, Graviton2, basate su Xen, Mac e bare-metal non sono supportate, una limitazione che ha sollevato alcuni dubbi nella community. 

Stormacq spiega come BitLocker sia un buon caso d’uso per NitroTPM:

BitLocker rileva e usa automaticamente NitroTPM quando disponibile. Non c’è nessuno step aggiuntivo oltre a quelli che fai oggi per installare e configurare BitLocker. Al momento dell’installazione, BitLocker riconosce il modulo TPM e inizia a usarlo automaticamente.

NitroTPM e UEFI Secure Boot sono disponibili in tutte le regioni AWS tranne quelle cinesi. Non ci sono costi aggiuntivi per l’utilizzo delle nuove funzionalità.

Vuoi leggere altre news su AWS?

AWS Introduce le EC2 con Storage Ottimizzato I4i

AWS ha recentemente introdotto le istanza I4i, EC2 progettate per carichi di lavoro che richiedono prestazioni elevate di lettura e scrittura sequenziali per insiemi di dati di grandi dimensioni sullo storage locale.  Le nuove istanze sono pensate per casi d’uso come database relazionali, file system distribuiti, data warehouse.

Le istanze EC2 I4i hanno processori Intel Xeon Scalable (Ice Lake) di terza generazione e storage locale Nitro SSD, fornendo elevate prestazioni di I/O, bassa latenza e minima variabilità della latenza. Jeff Barr, vicepresidente e chief evangelist di AWS, suggerisce possibili casi d’uso:

Database transazionali come MySQL, Oracle DB e Microsoft SQL Server, nonché database NoSQL: MongoDB, Couchbase, Aerospike, Redis e simili. Sono inoltre istanze ideali per carichi di lavoro che possono trarre vantaggio da prestazioni di calcolo molto elevate per TB di storage, come l’analisi dei dati e i motori di ricerca.

Rispetto alle precedenti I3, le nuove istanze introducono una dimensionle nuove istanze e massima dell’istanza maggiore (i4i.32xlarge), con 1 TB di memoria e 30 TB di storage NVMe locale. Secondo AWS, forniscono una latenza di I/O di archiviazione inferiore fino al 60% e una variabilità di latenza di I/O di archiviazione inferiore fino al 75% rispetto alle istanze I3.

Facendo un confronto con la generazione precedente, Michał Chojnowski, software engineer di ScyllaDB, scrive:

Abbiamo osservato un throughput in lettura per vCPU fino a 2,7 volte superiore sulla nuova I4i rispetto alle istanze I3. Con un mix di letture e scritture, abbiamo osservato un throughput per vCPU 2,2 volte superiore, con una riduzione del 40% della latenza media rispetto alle istanze I3 (…) Bastano tre nodi I4i.16xlarge per supportare ben oltre un milione richieste al secondo – con un carico di lavoro realistico.

L’I4i non è l’unica opzione EC2 ottimizzata per lo storage in scrittura rilasciata da AWS: all’ultimo re:Invent, AWS ha rilasciato le Im4gn/Is4gen. Le istanze I4i supportano solo AMI con  i driver ENA più recenti e NVMe 1.4. Le nuove istanze sono attualmente disponibili solo in alcune regioni negli Stati Uniti e in Europa. E i costi? La nuova classe parte da $ 0,172/ora on-demand per le i4i.large, un aumento del 10% rispetto alle i3.large ($ 0,156/ora).

Vuoi leggere altre news su AWS?

Amazon MSK Serverless è GA