Nella settimana del 21 settembre AWS ha ridisegnato due primitive fondamentali attorno all'organizzazione invece che all'account: CloudWatch Omni è un'esperienza di osservabilità con ambito per team, raggiungibile via SSO senza accesso alla console, e il bus personalizzato EventBridge rilanciato è un singolo broker condiviso via RAM con ordinamento, retention e un modello di prezzo costruito per il pattern hub-and-spoke che tutti già usano. Le global table DynamoDB con strong consistency multi-Region hanno raggiunto 15 Region e configurazioni tra continenti, Elastic Disaster Recovery ha aggiunto i server sorgente Graviton, e Security Hub ha iniziato a inventariare l'AI self-hosted sulle VM Azure.

CloudWatch Omni: telemetria organizzata per team, non per account

Il 23 settembre Amazon CloudWatch Omni è diventato generally available. Crei degli space in un account centrale che vedono la telemetria tra account e Region, e tra altri cloud inclusi i workload Azure. Omni scopre automaticamente i servizi, mappa le dipendenze, fa emergere le golden metric e porta l'AWS DevOps Agent nelle sessioni di indagine per correlare i segnali. È costruito su OpenTelemetry, quindi la strumentazione esistente compare senza riconfigurazione. La parte che cambia il design dell'organizzazione: è un'esperienza web autonoma con SSO per tutto il team, nessun accesso alla console AWS richiesto, più un'estensione per IDE e l'accesso tramite Agent Toolkit.

Questo è AWS che costruisce quello che Datadog e Grafana vendono da un decennio: un URL, un login, ogni account, con l'AI del vendor che fa il primo passaggio. La differenza è che la telemetria non esce mai da CloudWatch, che per molte realtà regolamentate è l'intera decisione.

Il trade-off riguarda l'identità. "Nessun accesso alla console" significa che l'autorizzazione in Omni è una mappatura SSO sugli space, non una policy IAM sui log group. È il modello giusto per uno sviluppatore che dovrebbe vedere le trace del suo servizio e nient'altro, ma è un secondo sistema di controllo accessi accanto a quello che già verifichi. Decidi quali space contengono telemetria di produzione, chi viene mappato dentro e come quella mappatura viene rivista, prima che il primo team si crei uno space in self-service. E controlla il prezzo dei percorsi di ingestione cross-account e cross-cloud prima di puntarci sopra il parco Azure.

EventBridge rilancia il bus personalizzato per l'enterprise

Il 24 settembre EventBridge ha rilanciato i custom event bus. Il bus potenziato può essere condiviso con ogni account dell'organizzazione tramite AWS RAM, così i publisher scrivono direttamente sul bus centrale. Una nuova API di pubblicazione accetta formati aperti come CloudEvents senza riscrivere lo schema. I bus conservano 24 ore di eventi di default, estendibili a un anno, così puoi fare replay dopo un bug o alimentare un nuovo consumer dalla storia. Una nuova risorsa Subscriber raggruppa filtri, target e retry; c'è deduplicazione basata sul contenuto, ordinamento stretto dove lo chiedi, e invocazione sincrona per target come Lambda. I bus esistenti continuano senza modifiche come "classic". Il post sul News Blog aggiunge che un modello di prezzo ingress/egress sostituisce i costi di routing cross-account che si accumulavano nel pattern multi-bus.

Il pattern che questo sostituisce è un bus per account, regole di forwarding verso un bus centrale e di nuovo indietro, e un costo a ogni salto. Un bus condiviso con Subscriber è più semplice e, per la maggior parte delle topologie, più economico. Retention e ordinamento sono le funzionalità che prima costringevano i team a mettere Kinesis o Kafka davanti a EventBridge; molta di quella colla ora può sparire.

Non migrare l'hub da un giorno all'altro. Modella prima il costo ingress/egress rispetto ai tuoi attuali costi per regola, perché "più economico per la maggior parte" non è "più economico per tutti". Poi sposta un producer e un Subscriber, tenendo in parallelo il forwarding del bus classic, e confronta i conteggi di consegna per una settimana. L'ordinamento è opt-in e avrà implicazioni sul throughput; attivalo per sottoscrizione dove un consumer ne ha davvero bisogno, non globalmente.

DynamoDB strong consistency tra continenti

Il 23 settembre le global table DynamoDB con strong consistency multi-Region hanno aggiunto cinque Region (Canada Central, Stoccolma, Spagna, Mumbai, Singapore) per 15 in totale, e ora è permessa qualsiasi configurazione a tre Region tra queste, incluse quelle che attraversano Nord America, Europa e Asia Pacifico. Scegli tre repliche, o due repliche più una Region witness, e ottieni un recovery point objective pari a zero.

RPO zero tra continenti è una capacità reale ed è anche fisica. Una scrittura strongly consistent tra Francoforte, Virginia e Singapore paga un round trip intercontinentale prima di confermare, ogni volta. L'opzione tra continenti è per i dati in cui ne vale la pena (entitlement, stato degli ordini, inventario, le cose in cui una lettura stantia è un bug di correttezza) e non per la tabella delle sessioni accanto. Tieni le tabelle MRSC piccole e deliberate; tutto il resto resta su global table eventually consistent con latenza di scrittura locale.

Angolo migrazione e sicurezza

Il 25 settembre AWS Elastic Disaster Recovery ha aggiunto i server sorgente basati su Graviton (arm64). DRS rileva arm64 e ripristina su istanze Graviton, niente di extra da configurare, nessun costo aggiuntivo. Questo chiude un vuoto che bloccava l'adozione di Graviton dove "ha un piano di DR" è un requisito di audit. È l'unica notizia della settimana sul tooling di migrazione; niente è uscito da AWS Transform o DMS.

Il 22 settembre Security Hub AI Inventory ha iniziato a scoprire asset AI sulle VM Azure self-hosted, usando l'analisi SBOM di Inspector per trovare endpoint di inferenza, modelli e agenti (Ollama, vLLM, Hugging Face TGI e altri) e correlarli con i finding. Incluso in Security Hub Essentials. Se stai consolidando la postura di sicurezza in AWS mentre un parco Azure si avvia alla chiusura, questo è il passo di inventario che altrimenti fai a mano.

E il 25 settembre la federazione di identità in uscita di IAM ha guadagnato interface VPC endpoint per i suoi endpoint di OIDC discovery e JWKS. Un workload verificatore in una VPC senza percorso verso internet ora può recuperare privatamente le chiavi per validare i JWT emessi da STS. Se hai adottato la federazione in uscita per sbarazzarti delle chiavi a lunga vita, questo rimuove l'ultima ragione per cui alcune subnet private non potevano farlo.

Anche questa settimana

Il filo conduttore

Omni, il rilancio di EventBridge, Network Security Manager e l'API di billing context presuppongono tutti che l'unità operativa sia un'AWS Organization con un account centrale, non un singolo account con una console. Il costo di questo recupero è che ciascuno introduce un control plane a livello di organizzazione (space, bus condivisi, policy di sicurezza) con il proprio modello di accesso, e il lavoro del team di piattaforma diventa tenere coerenti quei modelli di accesso. Le modifiche a DRS e all'endpoint OIDC sono la versione più silenziosa della stessa storia: capacità che finalmente raggiungono le configurazioni in cui i parchi reali si trovano, flotte arm64 e VPC senza internet, così la lista delle eccezioni si accorcia.

Leggi questo dopo

Per la lettura AI e agenti della stessa settimana, vedi ercan.ai. Per consulenza su AWS, architettura cloud, pipeline CI/CD, Linux, GitHub o GitLab e il lavoro di piattaforma intorno a essi, parti da ercanermis.com.

Riferimenti