La settimana dal 15 al 21 giugno 2026 è stata quella dell'AWS Summit New York, e per chi legge dal lato infrastruttura il titolo non è un agente: AWS Transform ha smesso di essere uno strumento di migrazione ed è diventato un servizio permanente che scansiona i tuoi repository in cerca di debito tecnico e lo corregge su una schedulazione. Nella stessa settimana CloudWatch ha cambiato il suo modello di metriche passando a OpenTelemetry nativo con PromQL e prezzo di ingestion per GB, la Management Console ha imparato a vivere interamente dentro una VPC, l'auto scaling di ECS ha ottenuto metriche a 20 secondi, e l'Extended Support di MySQL 5.7 è stato spostato a giugno 2029.

Gli annunci del Summit sugli agenti (AgentCore harness GA, AWS Continuum, Managed Knowledge Base) sono trattati in profondità su ercan.ai. Qui ricevono un solo punto elenco, perché il lato infra ne aveva abbastanza di suoi.

Quattro lanci di AWS Transform, una direzione

Il 15 giugno AWS ha lanciato la continuous modernization in AWS Transform, in preview in US East (N. Virginia) ed Europe (Frankfurt). Collega il codice da GitHub, GitLab, Bitbucket o altrove, e rileva, prioritizza e corregge in continuo il debito tecnico su "migliaia di repository": dipendenze a fine vita, framework obsoleti, più analisi di agentic-readiness e modernization-readiness e un aggancio ad AWS Security Agent per le vulnerabilità a livello di sorgente. La remediation può essere pianificata automaticamente "con supervisione umana", e il post di lancio la descrive mentre genera pull request rispetto a baseline configurabili.

Poi il 16 giugno, altri tre: la valutazione di migrazione model-to-model scansiona un codebase in cerca di utilizzi di OpenAI, Gemini, SDK Anthropic diretto, LiteLLM e Ollama (anche attraverso LangChain, LlamaIndex, CrewAI e LangGraph) e produce mappature verso Bedrock, confronti di costo e modifiche al codice, senza costi oltre il prezzo standard di Transform. AWS Transform for mainframe ha guadagnato un workflow di reimagine tracciabile per COBOL e PL/I su z/OS: le funzioni di business diventano requisiti pronti per lo sviluppo e codice cloud-native, ogni requisito risale al sorgente, e tutto arriva in Kiro e in altri IDE via MCP. E AWS Transform ora ha come target Amazon FSx for NetApp ONTAP in public preview, replicando lo storage a blocchi da sorgenti NetApp, Dell, Pure Storage o VMware nella stessa wave di compute e rete, dove prima EBS era l'unico target.

La continuous modernization è quella che cambia la relazione. Uno strumento di migrazione è un progetto: ha un inizio, una fine e un ambito che puoi rivedere. Un servizio che legge ogni repository in ogni momento e apre PR è un permesso permanente. Le domande da chiudere prima che la preview tocchi qualcosa sono banali e decisive: quali baseline, chi rivede le PR aperte dall'agente, cosa significa "remediation automatica" per un repo che nessuno ha deployato da due anni, e se il token di lettura copre repository che tengono secret nella history. Che la preview sia limitata a due Region è il vincolo meno interessante.

CloudWatch diventa uno store di metriche compatibile con Prometheus

CloudWatch ha introdotto metriche OpenTelemetry native con query PromQL e prezzo per GB il 16 giugno. CloudWatch accetta metriche via OTLP, espone un'API di query compatibile con Prometheus, e permette di interrogare metriche custom insieme alle metriche vended di oltre 70 servizi AWS in un'unica istruzione PromQL. L'ingestion ha un prezzo per GB con 15 mesi di storage inclusi. Disponibile in tutte le Region commerciali eccetto Middle East (UAE), Middle East (Bahrain) e Israel (Tel Aviv).

Non è arrivato da solo. La centralizzazione cross-account delle metriche (15 giugno, 17 Region) replica metriche da molti account e Region in un account di destinazione usando regole definite in AWS Organizations, così un team centrale possiede la copia per allarmi e governance. Log Analytics (15 giugno) fonde Logs Insights, Live Tail e Contributor Insights in un'unica esperienza console di default con query a schede, fatturata alle tariffe sottostanti. Query Studio è passato in GA.

Modella il cambio di prezzo prima di spostare qualsiasi cosa. Le metriche custom di CloudWatch sono sempre state prezzate per metrica al mese, il che punisce la cardinalità. L'ingestion per GB prezza i byte, non le serie, che è come i workload in stile Prometheus sono sempre stati costificati. L'annuncio non dà tariffe, quindi fai i tuoi conti: prendi una settimana del tuo exporter OTel più carico, stima i byte e confronta con le stesse serie come metriche custom. Se usi Amazon Managed Service for Prometheus puramente come endpoint PromQL per Grafana, questo lancio chiede se ti serve ancora.

La console entra nel perimetro

Due lanci chiudono un buco che le architetture a data perimeter hanno aggirato per anni. AWS Management Console Private Access (15 giugno) ora instrada tutto il traffico console per le console di servizio supportate attraverso endpoint VPC PrivateLink, così la console funziona da una VPC senza percorso verso internet; paghi solo l'endpoint e i costi di elaborazione dei dati. In precedenza Private Access poteva limitare quali account e reti raggiungessero la console, ma richiedeva comunque connettività internet. AWS Sign-in ora supporta resource-based policy e resource control policy (16 giugno), valutate al sign-in e di nuovo ogni volta che la sessione richiede nuove credenziali, così una RCP a livello di organizzazione può limitare il sign-in alla console alle reti previste.

Se la tua posizione è che nessuno tocca la console in produzione, questo conta comunque: il percorso break-glass esiste, ed è meglio che sia raggiungibile solo dalla tua rete piuttosto che essere un endpoint pubblico dietro una condizione sull'IP sorgente che qualcuno allargherà durante un incidente.

Container: scaling più rapido, egress instradato

L'auto scaling dei servizi ECS ha ottenuto metriche a 20 secondi il 18 giugno: ECSServiceAverageCPUUtilizationHighResolution e ECSServiceAverageMemoryUtilizationHighResolution, abilitate per servizio e selezionabili come metriche di target tracking. Nei benchmark AWS, il tempo per innescare uno scale-out è sceso da 363 a 86 secondi e il tempo totale fino ai task in esecuzione da 386 a 109 secondi. La funzionalità è gratuita; le metriche CloudWatch ad alta risoluzione da cui dipende non lo sono, dove le metriche standard a 60 secondi lo erano.

L'egress del control plane EKS instradato dal cliente (18 giugno) manda il traffico in uscita del control plane, cioè callback degli admission webhook, lookup del provider OIDC e richieste API aggregate, attraverso la tua VPC, sotto le tue route table e i tuoi security group. Imposta controlPlaneEgressMode a CUSTOMER_ROUTED in creazione o aggiornamento, e imponilo su tutta la flotta con la condition key SCP eks:controlPlaneEgressMode. Il vantaggio è raggiungere un provider OIDC privato o un webhook server dentro la VPC; il rischio è che il tuo routing ora sta sul percorso di ogni chiamata webhook, così una route table sbagliata diventa un API server che non può ammettere Pod.

Anche questa settimana

Il filo conduttore

Leggi i lanci infra come una sola mossa: AWS sta riportando dentro il proprio confine cose che vivevano fuori. La remediation del debito tecnico diventa un servizio. Lo store di metriche Prometheus diventa CloudWatch. La console diventa un endpoint VPC. Le chiamate in uscita del control plane EKS diventano le tue route. Insieme significano che una parte maggiore della tua superficie operativa è un servizio gestito con una manopola di policy, e meno parti sono qualcosa di cui puoi leggere il codice. Decidi dove vuoi quella linea, perché questa settimana l'ha spostata.

Leggi questo dopo

Il lato agenti del Summit, dall'harness a Continuum, è su ercan.ai. Per consulenza su AWS, cloud, pipeline CI/CD, Linux, GitHub/GitLab e altro, parti da ercanermis.com.

Riferimenti