Il 16 ottobre 2026 AWS Transform ha reso generally available la conversione di codice da Azure ad AWS: l'agente di modernizzazione .NET ora trova le chiamate all'Azure SDK nel tuo sorgente e le riscrive come chiamate all'AWS SDK, il che sposta la conversazione sulla migrazione da Azure da "sposta le VM" a "cambia il codice". La stessa settimana Lambda ha guadagnato un secondo form factor, Lambda Web Functions, fatturato sulla CPU attiva anziché sul tempo di orologio; ECS ha rilasciato una metrica di conteggio dei task che conta anche quelli in draining; e ARC Region switch ha imparato a controllare le quote della Region di standby prima che ti servano.

Transform converte il codice Azure SDK, non solo le VM Azure

L'annuncio del 16 ottobre è preciso sull'ambito. Transform individua l'Azure SDK nel sorgente .NET inviato, presenta le opzioni di conversione nel report di assessment, ti lascia accettarle o modificarle, poi converte le chiamate e valida il risultato. Generally available: Azure Functions verso AWS Lambda, Azure Blob Storage verso Amazon S3, Azure Queue Storage verso Amazon SQS. Azure Cosmos DB verso Amazon DynamoDB è in preview. AWS Transform gira in otto Region: N. Virginia, Mumbai, Tokyo, Seoul, Sydney, Canada Central, Francoforte e Londra.

Perché questo conta più di un'altra storia VMware: finora il percorso agentico per Azure era infrastruttura. Potevi replicare le VM Azure, ma una Functions app che parlava con Blob Storage era ancora una riscrittura che qualcuno doveva mettere a calendario. Le coppie in GA sono i tre servizi che compongono la maggior parte di un back end .NET cloud-native: un trigger, un object store, una coda. La coppia in preview è quella onesta. Cosmos DB verso DynamoDB è una conversione del modello dati, non uno scambio di SDK; partition key, livelli di consistenza e forma delle query non si traducono con una regex, quindi aspettati che il codice DynamoDB generato compili prima di essere corretto. Esegui l'assessment anche se non ti sposti questo trimestre: quanta parte del parco sta nelle coppie GA rispetto a Cosmos, Service Bus o Key Vault è il numero che ogni business case di migrazione ha sempre tirato a indovinare.

Altri tre elementi su Transform: Transform for migrations ha raggiunto Asia Pacific (Singapore) (15 ottobre). La modernizzazione full-stack Windows ora distribuisce i cluster Aurora PostgreSQL convertiti in una Region diversa ed è disponibile in altre sette (15 ottobre): carichi il DDL SQL Server, imposti una Region di destinazione, e il codice .NET dipendente viene reso compatibile con PostgreSQL nella stessa esecuzione. Sul lato mainframe, un post congiunto con Cognition (12 ottobre) mostra Transform che recupera le regole di business da COBOL, PL/I e JCL con tracciabilità a livello di riga sorgente, e Devin che trasforma i requisiti approvati in specifiche, backlog, codice e test, ciascuno come pull request che un umano mergia. Nessuna percentuale di automazione, nessuna dichiarazione di tempo risparmiato. Quella sobrietà è la cosa più credibile del post.

Lambda Web Functions: una porta, non un handler

Il 12 ottobre AWS ha annunciato Lambda Web Functions. Il tuo codice ascolta sull'host e sulla porta in AWS_LAMBDA_HTTP_ENDPOINT e gestisce HTTP come qualsiasi server; Express, Hono, Fastify e Next.js girano senza adapter, e le funzioni esistenti vengono rinominate Lambda Event Functions. Un ambiente caldo serve fino a 128 richieste concorrenti (default 64, tramite maxConcurrencyPerEnvironment); le richieste oltre il limite ricevono un 429, non una coda. Ogni ambiente ha 2 vCPU e 2 GB, il runtime è Node.js 24 su Arm64, ed è attivo in N. Virginia, Ohio, Oregon, Tokyo e Irlanda. aws lambda-web deploy --name app --code ./dist --regions us-east-1,eu-west-1 restituisce l'URL. Lo stesso giorno CloudFront ha aggiunto le Web Functions come origin con Origin Access Control, che è il modo per mettere un dominio personalizzato e il WAF davanti a una di esse.

Il modello di fatturazione è il vero annuncio. La pagina dei prezzi Lambda elenca le Web Functions in N. Virginia su Arm a $0.0000276944 per vCPU-secondo attivo, $0.0000036667 per GB-secondo di memoria trattenuta e $0.30 per milione di richieste, contro $0.20 per milione per le Event Functions e $0.0000166667 per GB-secondo alla tariffa x86 delle Event Functions. Prendi i due estremi. Un ambiente da 2 vCPU e 2 GB a CPU piena costa circa $0.000063 al secondo; una Event Function da 2 GB circa $0.000033. Un ambiente che aspetta per lo più un database costa circa $0.0000073 al secondo per la memoria e quasi nulla per la CPU. Il modello vince quando la CPU è inattiva, il normale livello web, e perde quando è occupata, elaborazione di immagini e SSR pesante. Misura la tua quota di CPU al p95 prima di spostare un workload; la pagina dei prezzi non mostra alcun free tier per le Web Functions.

Modalità di guasto che vale la pena dichiarare: 128 richieste concorrenti in un solo processo Node.js condividono un unico event loop, quindi un percorso sincrono lento degrada 127 vicini. E poiché le richieste in eccesso ricevono un 429, la policy di retry del tuo client fa parte dell'architettura.

ECS finalmente conta i task che stanno ancora girando

Il 13 ottobre Amazon ECS ha aggiunto LiveTaskCount e rimosso il costo di RunningTaskCount. LiveTaskCount riporta i task tra ACTIVATING, RUNNING e DEACTIVATING, inclusi quelli che servono ancora traffico mentre fanno draining durante lo scale-in. Quella clausola è il bug che corregge: il vecchio conteggio sottostimava durante lo scale-in, così un servizio con 20 task in draining sembrava più piccolo di quanto fosse e la policy poteva sovracorreggere. Se scali sul conteggio dei task, cambia la metrica e ritara il target. RunningTaskCount in Container Insights ora è gratuito.

Region switch controlla le quote prima del failover

Il 14 ottobre ARC Region switch ha aggiunto quattro capacità: blocchi di esecuzione Systems Manager Run Command e con payload Lambda, controlli di parità delle service quota, e un'attesa dello stato di salute dei target group nelle azioni di scaling del calcolo. Il controllo delle quote è quello da adottare questa settimana. I piani di failover falliscono nel modo più banale immaginabile: la Region di standby ha un limite di default di 32 vCPU dove la produzione ne ha 2.000, scoperto al momento dello scale-out durante l'incidente. La parità delle quote valutata in anticipo trasforma tutto questo in un ticket in un martedì tranquillo. L'attesa sui target group chiude l'altro vuoto classico, dove il runbook dichiara la Region attiva quando l'ASG raggiunge la capacità desiderata mentre l'ALB sta ancora fallendo gli health check.

Anche questa settimana

Il filo conduttore

Ogni titolo di questa settimana sostituisce qualcosa che prima stimavi con qualcosa che puoi misurare. L'assessment di Transform dice quanta parte di un codebase Azure è convertibile invece di lasciare indovinare a un comitato direttivo. Le Web Functions fatturano la CPU che bruci, e il listino ti dà il punto di pareggio prima di spostarti. LiveTaskCount conta i task che servono davvero. Region switch controlla le quote di standby prima del giorno in cui contano. Meno emozionante di un keynote, più utile di martedì.

Leggi questo dopo

Per la lettura su modelli e agenti della stessa settimana, le note AI sono su ercan.ai. Per consulenza su AWS, cloud, pipeline CI/CD, Linux, GitHub/GitLab e altro, parti da ercanermis.com.

Riferimenti