AWS porta i dati oltre il cloud: Spark accelera 3,7x e BigQuery legge S3 senza copie

☁️ Punti chiave

• Amazon EMR su EC2 G7 con NVIDIA RTX PRO 4500 accelera Apache Spark fino a 3,7 volte senza modificare il codice Spark esistente.
• Google BigQuery può interrogare direttamente tabelle Apache Iceberg conservate in Amazon S3 Tables senza creare una seconda copia dei dati.
• MWAA Serverless esegue ora PythonOperator e BashOperator nel runtime gestito, mentre Amazon Quick automatizza report governati su FSx for ONTAP.

AWS sta trasformando il proprio stack dati da insieme di servizi cloud a infrastruttura capace di attraversare confini tra motori, provider e acceleratori differenti. Amazon EMR sfrutta ora le GPU NVIDIA RTX PRO 4500 Blackwell delle istanze EC2 G7 per accelerare Apache Spark fino a 3,7 volte, Google BigQuery può interrogare direttamente tabelle Iceberg conservate in Amazon S3 senza duplicarle e MWAA Serverless esegue finalmente Python e Bash nativamente. Sul livello più vicino agli utenti, Amazon Quick Desktop utilizza invece file governati su FSx for NetApp ONTAP per automatizzare report aziendali mantenendo controlli IAM e revisione umana. Il tutto arriva esattamente nel giorno in cui Amazon EC2 compie vent’anni.

Apache Spark passa sulle RTX PRO 4500 senza riscrivere le pipeline

Nel benchmark congiunto AWS e NVIDIA, Amazon EMR on EKS utilizza il plugin NVIDIA cuDF per Apache Spark sulle nuove istanze Amazon EC2 G7, equipaggiate con GPU RTX PRO 4500 Blackwell Server Edition. AWS dichiara prestazioni fino a 3,7 volte superiori rispetto a istanze CPU comparabili senza richiedere modifiche al codice Spark esistente.

Nel benchmark TPC-DS da 3 TB, la configurazione da 64 GB completa il workload in 4,7 minuti, riducendo il tempo di esecuzione di oltre due terzi. Il vantaggio diventa particolarmente rilevante per feature engineering, ETL, fraud detection, clickstream e analytics quasi real-time, cioè carichi nei quali la preparazione dei dati può diventare più costosa dell’addestramento stesso.

La direzione completa il percorso già iniziato quando AWS aveva automatizzato migrazioni Apache Spark e workload dati attraverso strumenti sempre più agentici.

La GPU entra nel data engineering e non resta confinata all’AI generativa

L’aspetto più interessante è che le GPU Blackwell non vengono utilizzate soltanto per training e inferenza. Spark SQL, join, aggregazioni e trasformazioni ETL diventano workload accelerabili senza costringere il team a ricostruire l’applicazione intorno a CUDA. AWS e NVIDIA hanno qualificato insieme cuDF per Amazon EMR, co-ottimizzando i percorsi di esecuzione per RTX PRO 4500 e utilizzando RapidsShuffleManager nelle configurazioni G7. Le stesse istanze arrivano fino a 80 Gbps di banda di rete, elemento utile quando l’acceleratore permette di elaborare i dati più rapidamente della pipeline tradizionale. La GPU smette così di essere un componente riservato al data scientist e diventa una risorsa anche per il data engineer che deve accorciare finestre batch e preparare dataset destinati ai modelli.

BigQuery può leggere S3 Tables senza duplicare i dati su Google Cloud

Il secondo cambiamento riguarda il multicloud. AWS mostra come Google BigQuery possa interrogare direttamente Amazon S3 Tables utilizzando il formato aperto Apache Iceberg e il catalogo REST di AWS Glue. Nel primo modello basato su IAM, una singola policy governa accesso ai metadata e ai file, mentre BigQuery sincronizza il catalogo e legge direttamente i dati conservati su AWS. Non serve quindi replicare tabelle su Google Cloud Storage né mantenere pipeline permanenti tra i due provider.

È esattamente il problema affrontato dal Borderless Lakehouse di Google Cloud, progettato per separare il luogo nel quale risiede il dato dal motore che lo analizza. Il dato resta su S3, BigQuery diventa il motore di interrogazione e Apache Iceberg funge da lingua comune.

Lake Formation aggiunge credenziali temporanee e governance fine-grained

AWS propone anche un secondo modello per organizzazioni che non vogliono affidare tutto a policy IAM statiche. Nel percorso basato su AWS Lake Formation, BigQuery utilizza OpenID Connect per assumere un ruolo AWS, sincronizza i metadata attraverso AWS Glue Iceberg REST Catalog e riceve credenziali temporanee limitate esclusivamente alle tabelle autorizzate.

Lake Formation può applicare permessi a livello di catalogo, database e tabella e rilasciare short-lived credential diverse a motori differenti. La differenza è sostanziale: nel primo modello la governance è centrata su IAM; nel secondo diventa più granulare e più adatta a ecosistemi nei quali Athena, Spark, BigQuery e altri engine devono condividere gli stessi dati senza condividere necessariamente gli stessi privilegi.

MWAA Serverless esegue finalmente Python e Bash senza Lambda o ECS

Anche Amazon Managed Workflows for Apache Airflow Serverless elimina un limite importante. Finora il servizio poteva orchestrare operatori AWS ma, quando una pipeline aveva bisogno di codice Python personalizzato o shell script, gli sviluppatori dovevano trasferire il lavoro su Lambda, ECS o altri servizi compute. Con il supporto nativo a PythonOperator e BashOperator, il codice viene ora eseguito direttamente nel runtime serverless. I bundle possono essere singoli file .py o .sh, oppure archivi ZIP fino a 250 MB, salvati su S3 e fotografati al momento della creazione della versione del workflow. Il runtime viene isolato, i bundle sono cifrati tramite KMS e IAM controlla quali risorse AWS possono essere raggiunte. Di default i task Python e Bash non hanno accesso a Internet e possono comunicare soltanto con S3, ECR e CloudWatch, salvo configurazione esplicita attraverso VPC.

Serverless significa meno infrastruttura ma più attenzione all’esecuzione del codice

La semplificazione è evidente: un controllo di qualità, una trasformazione CSV-JSON o una verifica shell non richiedono più un servizio esterno separato. Ma la possibilità di eseguire Python e Bash direttamente nel runtime Airflow aumenta anche l’importanza del modello IAM, dei bundle immutabili e del controllo delle dipendenze. AWS risolve parte del problema fotografando il codice al momento della creazione del workflow: le successive esecuzioni usano quella copia e non l’oggetto S3 eventualmente modificato dopo. È una scelta che migliora riproducibilità e tracciabilità e mostra quanto l’orchestrazione dati stia diventando sempre più vicina all’esecuzione applicativa vera e propria.

Amazon Quick porta l’AI sui report senza spostare i file dalla governance aziendale

Sul livello business, AWS utilizza invece Amazon Quick Desktop per automatizzare attività che oggi richiedono ore di lettura e consolidamento manuale. Nel workflow costruito con FSx for NetApp ONTAP, i documenti rimangono nel filesystem aziendale e un S3 Access Point concede all’assistente accesso soltanto alla cartella approvata per il reporting.

Quick può quindi confrontare weekly review, piani operativi, forecast e registri dei rischi, generare un report e preparare una sintesi per Slack, mantenendo però una revisione umana prima della pubblicazione. Il modello approfondisce la strategia con cui Amazon Quick aveva già iniziato a usare cataloghi e metadata governati per fornire contesto affidabile agli agenti AI.

EC2 compie vent’anni passando da una sola VM a oltre 1.200 tipi di istanza

Tutto questo arriva esattamente vent’anni dopo il lancio della beta di Amazon EC2. Nel bilancio pubblicato da AWS per il ventesimo anniversario, il servizio nato il 25 agosto 2006 offriva un solo tipo di istanza, m1.small, in una sola Regione, con server Linux ridimensionabili e tariffazione oraria. Oggi AWS dichiara oltre 1.200 tipi di istanza distribuiti in 39 Regioni, con Nitro, Graviton, Trainium, Inferentia, Mac, HPC e acceleratori NVIDIA.

La storia di EC2 aiuta a leggere anche le novità attuali: il cloud non vende più semplicemente macchine virtuali, ma combinazioni sempre più specifiche di silicio, dati, runtime e governance. La stessa evoluzione aveva già portato AWS a integrare Lambda Managed Instances per eliminare cold start e avvicinare serverless e capacità EC2 dedicata.

AWS prova a rendere il dato indipendente dal luogo in cui viene elaborato

Le novità del 26 agosto mostrano quindi una direzione più interessante della semplice aggiunta di nuovi servizi. Il dato può restare su S3 ed essere interrogato da BigQuery, il codice Airflow può passare direttamente nel runtime serverless, Spark può utilizzare GPU Blackwell senza essere riscritto e i documenti aziendali possono alimentare assistenti AI senza abbandonare i controlli dello storage originario. È un modello nel quale compute, storage e analytics vengono progressivamente disaccoppiati, ma identità e governance devono seguire il dato lungo tutto il percorso. Dopo vent’anni, EC2 rimane la base fisica di gran parte di questa architettura, ma il cloud AWS non viene più definito dalla macchina virtuale. Viene definito dalla capacità di scegliere dove conservare il dato, dove elaborarlo e quale acceleratore utilizzare senza essere costretti a ricostruire ogni volta l’intera pipeline.