Nella settimana del 27 luglio AWS Transform ha abbandonato il presupposto che una migrazione inizi in vSphere. La voce del change log del 29 luglio rinomina il workflow in "Migrations (including VMware)" e apre discovery, pianificazione delle wave, landing zone, migrazione di rete e rehost dei server a Hyper-V, bare metal e altre piattaforme. Nella stessa settimana, AWS Interconnect verso Oracle Cloud Infrastructure è passato in GA, il policy-based routing di Transit Gateway ha permesso alle decisioni di forwarding di usare sorgente, porta e protocollo, IAM Identity Center ha esteso la replica multi-Region alla propria directory integrata, e CloudWatch ha iniziato a eseguire i collector Prometheus al posto tuo.

AWS Transform for migrations: l'hypervisor smette di contare

La documentazione su come migrare i server ora lo dice chiaramente: puoi migrare da data center on-premises, altri cloud provider o altre Region AWS, fisici o virtuali, su VMware, Hyper-V, KVM o qualsiasi altra cosa, e l'hypervisor è irrilevante purché il sistema operativo guest sia nella lista dei supportati di AWS Transform MGN. Il motore di replica è sempre stato MGN, a cui la sorgente non è mai importata; quello che è cambiato è che il workflow agentico attorno a esso, discovery, raccomandazioni 7R, pianificazione delle wave, conversione della rete, ora accetta anche quelle sorgenti. La stessa voce aggiunge al rehost le post-launch action: documenti SSM, predefiniti o custom, che l'agente raccomanda ed esegue su ogni server quando viene lanciato come istanza di test o di cutover, definiti a livello di account o per server nel file di inventario sotto mgn:launch:post-actions:<ACTION_NAME>:<FIELD_NAME>.

Per chiunque stia dimensionando un parco Hyper-V o bare metal per AWS, questa è la settimana in cui gli strumenti hanno raggiunto il discorso commerciale. Due avvertenze. Primo, la modifica è una voce nella documentazione, non un post What's New, quindi non c'è un elenco di Region o una nota sui prezzi da citare; verifica nella Region del tuo workspace prima di pianificarci attorno. Secondo, la replica agentless resta non supportata, quindi ogni server sorgente ha bisogno di un agent, e su bare metal non c'è un percorso vCenter che copra le macchine su cui non riesci a fare login. Conferma le credenziali per ogni server alla validazione dell'inventario, non quando il connector MGN va in timeout. Le post-launch action sono la vittoria silenziosa: la checklist "installa l'agent CloudWatch, unisci al dominio, lancia la scansione di compliance" che prima era un runbook diventa parte della wave, e mustSucceedForCutover ti permette di farne un gate.

Interconnect verso OCI, e un routing che legge più della destinazione

AWS Interconnect - multicloud ha raggiunto la GA il 29 luglio per Oracle Cloud Infrastructure, provisionato da console, CLI o API, con Google Cloud anch'esso supportato alla GA e Microsoft Azure atteso più avanti nel 2026. OCI ha costruito il proprio lato su una specifica aperta che AWS ha pubblicato su GitHub. La disponibilità è us-east-1 per OCI, e l'annuncio non indica livelli di banda né prezzi, quindi la documentazione è la prossima tappa.

Il confronto è con quello che i team fanno oggi: un Direct Connect in una struttura di colocation, un cross-connect verso l'altro provider, due sessioni BGP e una pagina wiki su chi chiamare quando si rompe. Interconnect sostituisce tutto questo con un oggetto gestito, e concentra il rischio in un solo prodotto, in una sola Region al lancio. Il pattern database in OCI, applicazione in AWS che il licensing Oracle continua a produrre è il cliente ovvio. Per tutto il resto, aspetta che l'elenco delle Region cresca.

Il policy-based routing su Transit Gateway, in GA dal 30 luglio senza costi aggiuntivi, è il pezzo che rende una rete hub-and-spoke capace di dire "questa sorgente, su questa porta, passa dal firewall; tutto il resto va diretto". Colleghi una policy table a un attachment, scrivi un insieme ordinato di regole che fanno match su IP sorgente e destinazione, porta e protocollo, e ogni regola manda i pacchetti corrispondenti a una route table nominata, vince il primo match. La modalità di guasto è quella che il PBR ha sempre avuto: una policy table è un secondo posto in cui si decide il routing, e "cerca la destinazione nella route table" smette di essere un modello mentale sufficiente. Documenta le regole accanto alle route table, e resisti alla tentazione di usare il PBR per qualunque cosa una route table possa esprimere.

Direct Connect ha guadagnato la visibilità delle rotte BGP lo stesso giorno: rotte accettate e annunciate su VIF privati, transit e pubblici, con prefisso, AS path, community e address family, via console o ListVirtualInterfaceRoutes. Chiunque abbia debuggato un percorso asimmetrico chiedendo al team di rete di lanciare show ip bgp dalla loro parte sa perché conta.

Identity Center replica la propria directory

Il supporto multi-Region in IAM Identity Center richiedeva prima un identity provider esterno. Dal 29 luglio un'istanza di organizzazione che usa la directory integrata di Identity Center può replicare identità ed entitlement dalla sua Region primaria ad altre Region a tua scelta, tra le 17 Region commerciali abilitate di default. Se la Region primaria subisce un'interruzione, gli utenti mantengono l'accesso ai loro account tramite gli entitlement già provisionati altrove. L'amministrazione resta nella Region primaria, l'istanza deve usare una chiave KMS multi-Region gestita dal cliente, e l'unico costo è KMS.

Identity Center è il componente il cui guasto impedisce a ogni umano di sistemare qualsiasi altra cosa, e senza un IdP esterno è stato una dipendenza a singola Region dal lancio. Il prerequisito è il punto critico: una CMK multi-Region deve esistere prima di abilitare la replica, e un'istanza creata con la chiave di default di proprietà di AWS ha bisogno prima di un cambio di chiave. Pianificalo come una modifica a sé, con un rollback.

CloudWatch esegue il collector Prometheus

I managed collector di CloudWatch, in GA dal 31 luglio, fanno scraping delle metriche Prometheus da EKS (service discovery Kubernetes), ECS (DNS di Cloud Map), EC2 (diretto) e MSK e OpenSearch Service (endpoint di open monitoring) senza un OpenTelemetry Collector gestito da te. Consegni una configurazione di scrape e una connessione; CloudWatch provisiona e scala il collector, consegna le metriche in formato OpenTelemetry e ti permette di interrogarle con PromQL insieme alle metriche vended. I collector sono fatturati a ore in aggiunta all'ingestione standard delle metriche OpenTelemetry, e la funzionalità è disponibile ovunque ci sia l'endpoint OTLP di CloudWatch, tranne Asia Pacific (New Zealand).

Il collector self-managed era la parte dello stack di osservabilità con più probabilità di essere giù quando ti servivano le metriche, di solito perché il suo nodo era quello in difficoltà. Spostarlo fuori dal cluster è corretto. La questione è il costo alla cardinalità: la fee oraria è prevedibile, l'ingestione no, e una configurazione di scrape presa da un server Prometheus che teneva tutto ingerirà tutto. Mantieni le tue regole di drop in metric_relabel_configs, e leggi la riga dell'ingestione sulla prima fattura prima di aggiungere il secondo cluster.

Anche questa settimana

Il filo conduttore

Ogni titolo di questa settimana allarga un input che AWS prima vincolava. Transform accetta qualsiasi hypervisor. Interconnect accetta un altro cloud. Transit Gateway accetta match a cinque tuple invece di una destinazione. Identity Center porta la propria directory in più Region. I managed collector accettano la configurazione di scrape che già hai. Il costo si paga ogni volta nella stessa valuta: più input significa più posti in cui la configurazione può essere sbagliata, e meno di essi visibili in una route table. Il lancio della visibilità BGP è l'indizio: AWS ha aggiunto osservabilità a Direct Connect lo stesso giorno in cui ha aggiunto il policy routing a Transit Gateway, perché sa cosa il secondo fa al debugging.

Leggi questo dopo

Per la lettura AI e agenti delle stesse settimane, le field notes vivono su ercan.ai. Per consulenza su AWS, cloud, pipeline CI/CD, Linux, GitHub/GitLab e altro, parti da ercanermis.com.

Riferimenti