La settimana dal 22 al 28 giugno 2026 ha dato ai team di piattaforma tre primitive di governance che finora simulavano con tag e pagine wiki: watermark AMI che sopravvivono a copie, Region e condivisioni tra account; Lambda MicroVMs che mettono il codice non fidato in una macchina virtuale tutta sua; e un default corretto di Network Firewall che scartava in silenzio pacchetti legittimi dal server al client. Sul lato migrazione, AWS Transform ora porta i workload in qualsiasi Region commerciale, e sia OpenSearch sia MSK hanno rilasciato percorsi di migrazione guidati da agenti.

Nessun Summit questa settimana, quindi i lanci sono più piccoli e più utili: ogni voce principale è qualcosa su cui l'anno scorso avresti scritto un documento di policy sperando che la gente lo seguisse.

Migrazione: qualsiasi Region, e altri due percorsi guidati da agenti

AWS Transform for migrations ora supporta tutte le Region commerciali AWS come target di migrazione, pubblicato il 22 giugno. La Region target è dove vengono deployati landing zone, rete e server rehostati, e l'annuncio ne aggiunge 16: US West (N. California), Africa (Cape Town), Asia Pacific (Bangkok, Hong Kong, Hyderabad, Jakarta, Kuala Lumpur, Melbourne, New Zealand, Taipei), Canada (Calgary), Europe (Milan, Spain, Zurich), Mexico (Querétaro) e Middle East (Tel Aviv). Per i lettori europei, Zurich, Milan e Spain sono quelle che trasformano "l'agente non può portarlo dove il legale dice che deve stare" da blocco a menu a tendina.

Due lanci vicini al mondo database nella stessa settimana seguono lo schema del cambio di nome di MGN: la logica di migrazione si sposta in qualcosa che un agente guida. Amazon OpenSearch Service ora offre migrazioni assistite da AI (23 giugno): Migration Assistant guadagna un workflow guidato da agente, usabile da Kiro, Claude Code e altri, per pianificare il passaggio da Solr, Elasticsearch o OpenSearch self-managed a OpenSearch Serverless o Managed Clusters, deployare l'infrastruttura ed eseguire la migrazione storica più quella del traffico live, con capture-and-replay che ora copre Solr. Le Amazon MSK AI Agent Skills (22 giugno) danno a Kiro, Claude Code e Cursor una guida esperta per dimensionare, fare troubleshooting, monitorare e migrare cluster Kafka esterni verso MSK Express.

Il trade-off delle skill come meccanismo di distribuzione è il version control: un runbook nel tuo repo ha una history di commit, una skill del vendor scaricata a runtime è un prompt di cui non puoi fare il diff. Va bene per una migrazione una tantum. Per quaranta cluster identici, esporta quello che l'agente ha fatto la prima volta in qualcosa che possiedi.

Watermark AMI: una provenienza che non si perde nella copia

Amazon EC2 ha annunciato gli AMI Watermarks il 24 giugno. Incorpori un identificatore custom in un'AMI privata, e questo si propaga a ogni AMI derivata: copie in altre Region, immagini create da un'istanza in esecuzione e immagini condivise con altri account. Ogni watermark porta con sé l'ID dell'AMI originale, l'owner, la Region e i timestamp di creazione. La metà che riguarda l'enforcement è il punto: combina i watermark con Allowed AMIs per limitare i lanci alle immagini che portano un watermark approvato, e applicalo a tutta l'organizzazione con le Declarative Policies. EC2 Image Builder può applicare un watermark nella pipeline. Tutte le Region, GovCloud e Cina incluse, senza costi.

Il buco che chiude è specifico. I programmi di golden AMI impongono "lancia solo dall'account X" con Allowed AMIs. La prima volta che un team copia la golden image nel proprio account per aggiungere un pacchetto, la provenienza è persa, e la policy o lo blocca (così smettono di usare la golden image) o ammette il loro account (così la policy non significa nulla). Un watermark che sopravvive alla copia ti permette di dire invece "lancia qualsiasi cosa discenda dalla golden image".

Sii preciso su cosa dimostra. Un watermark è provenienza, non integrità: dice che l'immagine discende da una build che hai approvato, non che nulla sia cambiato nell'immagine derivata o sull'istanza in seguito. Sostituisce la provenienza basata sui tag; non sostituisce Inspector, la compliance SSM o la firma delle immagini.

Lambda MicroVMs: una VM per ogni sessione non fidata

AWS ha introdotto Lambda MicroVMs il 22 giugno: una primitiva serverless che dà a ogni utente o job una VM isolata con Firecracker e con il proprio kernel, suspend e resume con stato di memoria e disco intatti per un runtime totale fino a 8 ore, e un endpoint HTTPS dedicato che supporta HTTP/2, gRPC e WebSocket. I limiti per MicroVM sono 16 vCPU, 32 GB di memoria, 32 GB di disco, solo ARM64. Secondo il post di lancio, costruisci un'immagine da un Dockerfile con aws lambda-microvms create-microvm-image, la lanci con aws lambda-microvms run-microvm e una idle policy, e paghi il compute di base mentre gira. Disponibile in US East (N. Virginia, Ohio), US West (Oregon), Europe (Ireland) e Asia Pacific (Tokyo).

Ne ho scritto a lungo in AWS Lambda MicroVMs: il serverless ottiene una sandbox isolata e stateful. La versione breve: la domanda di design non è "funzioni o MicroVMs" ma "cosa nel mio sistema esegue codice che non ho scritto io". Notebook, plugin dei clienti e qualsiasi cosa generi un LLM stanno dietro un confine di VM con un ciclo di vita, e fino a questa settimana questo significava una tua flotta Firecracker o un container per tenant. L'angolo agenti è su ercan.ai.

Network Firewall corregge un default che rompeva le connessioni

AWS Network Firewall ha aggiornato la sua azione di drop di default il 22 giugno. Le nuove firewall policy ora hanno come azione stateful di default "Application drop established (server-directed only)". Il default precedente, "Application drop established (bidirectional)", poteva scartare in silenzio pacchetti TCP legittimi dal server al client come window update, keep-alive e reset, che si manifestavano come errori di connessione intermittenti che nessuno riusciva a riprodurre. Le policy esistenti non vengono modificate automaticamente; AWS rimanda alla documentazione per aggiornarle, e nota che gli ambienti che hanno bisogno dell'azione bidirezionale per handshake TLS post-quantum frammentati possono cambiare o aggiungere un flag to_server alle loro regole di drop TCP.

Questa è quella su cui agire oggi, perché è una modifica a un default e non una funzionalità. Ogni aws_networkfirewall_firewall_policy nel tuo Terraform copiata da un vecchio esempio porta con sé il vecchio default. Cerca con grep le azioni stateful di default, confrontale con la nuova raccomandazione, e fai passare la modifica prima dallo staging. Se hai un ticket aperto per un timeout intermittente inspiegato su qualcosa dietro Network Firewall, potresti averne appena trovato la causa.

Anche questa settimana

  • Le investigazioni basate su AI di GuardDuty entrano in preview in 10 Region (23 giugno): ogni finding riceve una disposizione con punteggio di confidenza, mappatura MITRE ATT&CK, 90 giorni di attività correlata e una raccomandazione di soppressione, contenimento o remediation, via console, CLI, API o l'AWS MCP Server.
  • L'ingestion syslog gestita di CloudWatch Logs (23 giugno) accetta RFC 5424, RFC 3164 e Cisco FTD/ASA via TCP, TCP+TLS o UDP verso un endpoint VPC, senza agent, con facility, severity e hostname estratti.
  • OTel Container Insights per EKS (23 giugno) raccoglie metriche infrastrutturali a 30 secondi tramite i receiver cAdvisor, Kube State Metrics e NVIDIA DCGM con label Kubernetes e un endpoint PromQL, attraverso l'add-on CloudWatch Observability v6.2.0 o successivo.
  • Governance aperta per MySQL: Oracle ha annunciato uno steering committee con quattro seggi non-Oracle, uno dei quali ad AWS. Vista l'estensione dell'Extended Support della settimana scorsa, AWS pianifica di far girare MySQL per molto tempo.

Il filo conduttore

Tre delle quattro voci principali di questa settimana rendono applicabile una proprietà che prima era un'aspirazione: da dove viene un'immagine, dove gira il codice non fidato, come un firewall tratta la metà di ritorno di una connessione. La quarta, Transform in ogni Region commerciale, fa lo stesso per la residenza dei dati. Niente di tutto questo è entusiasmante. Tutto è il tipo di controllo che, una volta che esiste, fa sembrare negligente il modo precedente in una post-incident review.

Leggi questo dopo

La lettura lato agenti delle MicroVMs e delle investigazioni GuardDuty è su ercan.ai. Per consulenza su AWS, cloud, pipeline CI/CD, Linux, GitHub/GitLab e altro, parti da ercanermis.com.

Riferimenti