Settantanove annunci sono arrivati nella settimana del 28 settembre, cinque dei quali modelli di frontiera, e quello con la coda più lunga era un avviso di ciclo di vita: Amazon DevOps Guru, Amazon Managed Blockchain e il Backint Agent per SAP ASE sono entrati in sunset, la console standalone di Infrastructure Composer se ne va a dicembre, e Mechanical Turk ha raggiunto la fine del supporto. Due giorni dopo AWS Health ha rilasciato un catalogo delle versioni perché quel genere di notizia smetta di arrivare come una sorpresa. Sul fronte migrazione, AWS Transform ha aggiunto le valutazioni agentiche da Kafka a MSK. EKS Auto Mode ha aperto il tuning di kubelet, sysctl e hugepage, Kubernetes 1.37 è arrivato, e Aurora PostgreSQL ha iniziato a interrogare Iceberg e Parquet in S3 tramite un DuckDB integrato.

La lista dei sunset, e il catalogo che dovrebbe sostituirla

Gli AWS Service Availability Updates del 29 settembre spostano Amazon Chime SDK SIP Media Application e Amazon WorkSpaces Secure Browser in manutenzione (chiusi ai nuovi clienti dal 29 ottobre 2026, i clienti esistenti continuano). Entrano in sunset: Amazon Managed Blockchain (fine del supporto il 29 settembre 2027), Amazon DevOps Guru (30 settembre 2027), AWS Backint Agent per SAP ASE (29 settembre 2027) e la console standalone di AWS Infrastructure Composer (7 dicembre 2026). Amazon Mechanical Turk ha raggiunto la fine del supporto il 29 settembre 2026.

DevOps Guru è quello che la maggior parte dei team infra sentirà. Molti lo hanno attivato nel 2021 e se ne sono dimenticati, quindi è ancora nei template CloudFormation e ancora collegato a topic SNS che chiamano qualcuno. AWS non nomina un successore; dato che CloudWatch Omni e il DevOps Agent sono usciti una settimana prima, il percorso di indagine agentica è la lettura ovvia. Fai subito un audit delle risorse AWS::DevOpsGuru::ResourceCollection e NotificationChannel e decidi cosa sostituisce gli alert, perché dodici mesi passano in fretta quando la rimozione richiede un change ticket in quaranta account.

Poi il 2 ottobre AWS Health ha introdotto il catalogo delle versioni: una vista a livello di servizio delle versioni software supportate e delle loro timeline di ciclo di vita, nella Health Dashboard per tutti e tramite la Health API per i clienti Business Support Plus, Enterprise Support e Unified Operations. Al lancio copre RDS, EKS e Lambda, altri servizi a seguire. Collega l'API a qualunque cosa tracci il tuo backlog di upgrade; una versione EKS con quattro mesi di vita dovrebbe essere un ticket, non un'email.

AWS Transform valuta Kafka verso MSK

Il 29 settembre AWS Transform ha aggiunto le valutazioni agentiche di migrazione da Apache Kafka on-premises ad Amazon MSK. Carichi un file di inventario dei cluster o descrivi i cluster in chat, e l'agente controlla la compatibilità di ciascun cluster con MSK su topologia, versione, configurazione, autenticazione e quote, dimensiona i broker MSK Express e produce un business case TCO con opzioni di prezzo e passi successivi.

La parte lenta di una migrazione Kafka non è la copia dei dati, sono le settimane di lavoro su fogli di calcolo per scoprire se ci sta e quanto costa. Comprimere tutto questo in minuti cambia chi può permettersi di fare la domanda.

Leggi la parola "valutazione" alla lettera. Produce un caso, non una migrazione. Gli offset dei consumer group, lo schema registry, la topologia MirrorMaker, le modifiche all'auth lato client e le decisioni sul numero di partizioni che i broker Express impongono restano tutte tue. Tratta il TCO come un numero di apertura e verifica il dimensionamento dei broker Express rispetto ai tuoi picchi di retention e throughput.

EKS Auto Mode perde la sua ultima scusa

Il 1° ottobre EKS Auto Mode ha aggiunto la configurazione avanzata del calcolo: un nuovo campo advancedCompute nella risorsa NodeClass permette di impostare in modo dichiarativo opzioni kubelet, sysctl Linux e hugepage: user namespace per build di immagini rootless, soglie di eviction, limiti della cache ARP, hugepage da 2Mi o 1Gi per database e HPC. EKS valida le impostazioni, le applica al boot e le mantiene attraverso scaling e upgrade, senza launch template, AMI personalizzate o DaemonSet privilegiati.

"Ci serve un'AMI personalizzata per il tuning sysctl" era la ragione onesta più comune per restare sui node group self-managed. Quella ragione è sparita, nel modo giusto: il tuning vive in un oggetto Kubernetes versionato, non in una pipeline di immagini che nessuno vuole possedere. La modalità di guasto è la stessa di ogni manopola a livello di nodo: un sysctl sbagliato in una NodeClass si propaga a ogni nodo che quella classe provisiona. Dai alla NodeClass con il tuning il suo node pool e fai un canary con un singolo workload.

Il 2 ottobre EKS ed EKS Distro hanno aggiunto Kubernetes 1.37: la Metrics API è GA come metrics.k8s.io/v1, taint e toleration dei device DRA sono GA, e lo scale-to-zero di HPA è in beta e attivo di default. Lo stesso giorno ECS ha aggiunto deployment blue/green, linear e canary per i servizi dietro VPC Lattice.

Aurora PostgreSQL legge il data lake sul posto

Il 30 settembre Aurora PostgreSQL ha guadagnato l'interrogazione diretta di dati Apache Iceberg e Parquet. Crei foreign table PostgreSQL sopra dati in S3, S3 Tables o nel Glue Data Catalog (inclusi cataloghi Iceberg REST esterni federati tramite Glue), e Aurora esegue quelle query con DuckDB integrato nell'engine. Applicazioni e strumenti BI esistenti continuano a parlare PostgreSQL puro; per i percorsi sensibili alla latenza puoi materializzare i dati del lake in locale.

Questo elimina una classe di job notturni "copia le tabelle dimensionali in Postgres", e DuckDB è un engine sensato per scansionare file colonnari. Il trade-off è che la scansione ora gira sulla tua istanza OLTP. Una query di reporting su un anno di Parquet è molta CPU e memoria sulla macchina che serve anche i checkout; metti il workload rivolto al lake su un reader, e sorveglia la connessione che dai allo strumento BI con la stessa attenzione che daresti a un cron job.

Anche questa settimana

Il filo conduttore

Il vero tema della settimana è il ciclo di vita. Un servizio che hai adottato nel 2021 se ne va. Il catalogo delle versioni esiste perché il prossimo non ti colga di sorpresa. AWS Transform ora scrive il business case per lasciare Kafka on-prem. EKS Auto Mode ha rimosso il vuoto di configurazione che teneva in vita i node group oltre il loro tempo, e Aurora ha rimosso il job di copia che teneva in vita una dozzina di pipeline ETL oltre il loro. Il lavoro di piattaforma è soprattutto decidere cosa smettere di far girare, e questa settimana AWS ha rilasciato strumenti per entrambe le metà: scoprire cosa sta finendo, e rendere la sostituzione abbastanza economica da farla davvero.

Leggi questo dopo

Per la lettura AI e agenti della stessa settimana, vedi ercan.ai. Per consulenza su AWS, architettura cloud, pipeline CI/CD, Linux, GitHub o GitLab e il lavoro di piattaforma intorno a essi, parti da ercanermis.com.

Riferimenti