Nella settimana dall'8 al 14 giugno 2026, AWS ha rinominato il suo motore di rehost in AWS Transform MGN, e questo ti dice dove sta andando la linea di prodotti per la migrazione: l'agente è il prodotto, e il servizio di replica è un pezzo che l'agente chiama. La stessa settimana ha portato un gruppo di strumenti di costo che leggono la fattura al posto tuo (il FinOps Agent in preview, le investigazioni delle anomalie basate su AI e le spiegazioni intelligenti dei costi), le prime istanze Graviton5 per carichi general-purpose, e un avviso di maintenance per AWS CLI v1 che chiunque abbia dieci anni di script shell dovrebbe leggere due volte.

Anche questa settimana: Claude Fable 5 di Anthropic è stato lanciato su Bedrock il 9 giugno e ha avuto l'accesso revocato il 12 giugno in base a una direttiva statunitense sull'export. Quella storia è raccontata su ercan.ai; la lezione infrastrutturale è la solita: non inchiodare la produzione a un singolo upstream che non controlli.

AWS Transform MGN: il cambio di nome che è una roadmap

AWS Application Migration Service ora è AWS Transform MGN, datato 8 giugno. L'annuncio è esplicito sul fatto che si tratta di un cambio di nome che riflette il ruolo di MGN come "il motore di replica collaudato che alimenta AWS Transform", non elenca modifiche ad API, prezzi o funzionalità, e mantiene le certificazioni di compliance (FedRAMP High, HIPAA, PCI DSS, ISO, SOC 1, 2, 3). È disponibile in tutte le Region commerciali e in entrambe le Region GovCloud.

Ora hai due esperienze di rehosting. La console AWS Transform MGN dà controllo diretto su replica e cutover, come MGN ha sempre fatto. Il workflow agentico di AWS Transform fa fare a un agente discovery, pianificazione delle wave, setup della landing zone, creazione della rete, e il rehost o la containerizzazione stessa, chiamando MGN sotto il cofano. Leggilo come una dichiarazione d'intenti: il percorso console è per chi sa cosa sta facendo e vuole le manopole; il percorso agente è dove AWS si aspetta che vada il volume.

Nella stessa data, AWS Transform ha aggiunto una valutazione dei costi di migrazione per RDS for SQL Server. Dagli in pasto export RVTools, dati del CMDB o l'output dello strumento di discovery di Transform, e raccomanda configurazioni di istanza, confronta Bring Your Own Media con License Included (BYOM è arrivato su RDS la settimana scorsa), prezza in Database Savings Plans (fino al 20% di sconto sull'On-Demand) e segnala l'idoneità MAP. Gli scenari what-if permettono di variare Region, utilizzo e durata. Il trade-off di qualsiasi strumento TCO: l'output è onesto quanto i dati di utilizzo che gli hai dato. I numeri di picco di RVTools producono una fattura conservativa; i numeri al 95° percentile producono quella su cui la finanza ti terrà inchiodato.

Nota pratica: l'annuncio non dice nulla su prefissi delle action IAM, namespace degli SDK o tipi di risorsa Terraform, quindi assumi che mgn resti dov'è finché un changelog non dice altrimenti.

Tre agenti per una fattura

La gestione dei costi ha ricevuto più attenzione agentica in una settimana che nell'anno precedente. AWS FinOps Agent è entrato in preview il 9 giugno in US East (N. Virginia), senza costi durante la preview. Risponde a domande sui costi, fa emergere raccomandazioni di rightsizing, risorse inattive e Savings Plans da Cost Optimization Hub e Compute Optimizer, investiga le anomalie, esegue workflow FinOps pianificati, apre ticket Jira e pubblica i risultati su Slack. I suoi dati coprono tutte le Region eccetto GovCloud e Cina.

Le investigazioni dei costi basate su AI (8 giugno) stanno dentro Cost Anomaly Detection: scegli "Investigate with Amazon Q" su un'anomalia rilevata e determina se la variazione è guidata dall'uso o dalla tariffa, nomina i servizi, gli account e le Region che contribuiscono, e per le variazioni d'uso correla con CloudTrail per attribuire il picco a chiamate API e principal IAM specifici. Con un organization trail copre gli account membri. Nessun costo aggiuntivo, salvo che il percorso cross-account legge un organization trail consegnato a CloudWatch Logs, quindi si applicano i costi di scansione di Logs Insights. Le spiegazioni intelligenti dei costi in Cost Explorer (9 giugno) e l'analisi della copertura target nel Savings Plans Purchase Analyzer (8 giugno) completano il quadro.

Se hai intenzione di lasciare un agente vicino alla produzione, il costo è il primo dominio giusto: i dati sono read-only, il blast radius di una risposta sbagliata è un ticket Jira sbagliato, e l'alternativa è un umano che fa la stessa correlazione su CloudTrail alle 23 dopo un alert di anomalia. La modalità di guasto è il rumore. Un agente che apre un ticket per ogni anomalia addestra il team a chiudere i ticket senza leggerli entro un mese. Delimita schedulazioni e soglie prima di attivare le integrazioni, allo stesso modo in cui delimiteresti un avviso di budget.

Graviton5 arriva nel general purpose

Le istanze M9g e M9gd sono diventate generally available il 10 giugno. AWS dichiara fino al 25% di prestazioni di calcolo in più rispetto a Graviton4 nel complesso, fino al 35% per applicazioni web e inferenza ML, fino al 30% per i database, e una cache L3 5 volte più grande. Le taglie più grandi arrivano a 192 vCPU e 768 GiB; M9gd porta fino a 11.4 TB di NVMe locale. Disponibili in US East (N. Virginia), US East (Ohio), US West (Oregon) ed Europe (Frankfurt).

Quattro Region sono il vincolo. Se i tuoi Savings Plans sono EC2 Instance plan bloccati su M8g in una Region fuori da quella lista, per ora non c'è nulla da fare. Se sono Compute Savings Plans, M9g è un esperimento drop-in: stessi binari ARM64, una modifica al launch template, e una settimana di CloudWatch per vedere se il 25% si presenta per il tuo workload o solo per il benchmark.

AWS CLI v1 entra in maintenance il 15 luglio

Il team di AWS CLI ha annunciato il 10 giugno che la CLI v1 entra in maintenance mode il 15 luglio 2026. Da allora, la v1 include le proprie copie di botocore e s3transfer invece di dipendere dai pacchetti standalone; aggiornare la CLI non li aggiorna più, e installarli non cambia più cosa usa la CLI. Le nuove release v1 sono limitate a correzioni critiche e problemi di sicurezza.

La rottura sottile riguarda gli ambienti in cui CLI v1 e boto3 condividono un'installazione Python. Dopo il cambiamento ci sono due copie di botocore in quell'ambiente, e qualsiasi script che presupponeva che "pip install awscli" tenesse aggiornate le dipendenze di boto3 è sbagliato. Fissa esplicitamente le dipendenze di boto3, poi pianifica il passaggio alla v2. Le differenze tra v1 e v2 sono per lo più default di output e paginazione, che è esattamente il tipo di cosa che rompe un cron job in silenzio.

Anche questa settimana

Il filo conduttore

Ogni titolo di questa settimana è AWS che sposta un compito umano in un servizio: la pianificazione delle wave in un agente, l'investigazione delle anomalie in Q, la modellazione del TCO in Transform. I motori non sono cambiati; è cambiato chi legge l'output. Decidi deliberatamente di quali di quei lettori ti fidi, e tieni caldo il percorso console per il giorno in cui l'agente si sbaglia sul tuo parco.

Leggi questo dopo

Per il lato modelli e agenti della stessa settimana, inclusa l'interruzione di Fable 5, leggi ercan.ai. Per consulenza su AWS, cloud, pipeline CI/CD, Linux, GitHub/GitLab e altro, parti da ercanermis.com.

Riferimenti