In der Woche vom 21. September hat AWS zwei zentrale Primitive um die Organisation statt um den Account herum neu gezeichnet: CloudWatch Omni ist eine team-bezogene Observability-Erfahrung, erreichbar über SSO ohne Console-Zugang, und der neu aufgelegte EventBridge Custom Bus ist ein einziger, per RAM geteilter Broker mit Ordering, Retention und einem Preismodell für das Hub-and-Spoke-Muster, das ohnehin alle betreiben. DynamoDB Global Tables mit Multi-Region Strong Consistency haben 15 Regionen und kontinentübergreifende Konfigurationen erreicht, Elastic Disaster Recovery hat Graviton-Quellserver bekommen, und Security Hub hat angefangen, selbst gehostete KI auf Azure-VMs zu inventarisieren.

CloudWatch Omni: Telemetrie nach Team organisiert, nicht nach Account

Am 23. September ist Amazon CloudWatch Omni generally available geworden. Du erstellst Spaces in einem zentralen Account, die Telemetrie über Accounts und Regionen hinweg sehen, und über andere Clouds inklusive Azure-Workloads. Omni entdeckt Services automatisch, kartiert Abhängigkeiten, zeigt Golden Metrics und zieht den AWS DevOps Agent in Untersuchungs-Sessions, um Signale zu korrelieren. Es ist auf OpenTelemetry gebaut, bestehende Instrumentierung taucht also ohne Rekonfiguration auf. Der Teil, der das Org-Design ändert: Es ist eine eigenständige Web-Erfahrung mit SSO für das ganze Team, kein AWS-Console-Zugang nötig, plus eine IDE-Extension und Zugriff über das Agent Toolkit.

Das ist AWS, das baut, was Datadog und Grafana seit einem Jahrzehnt verkaufen: eine URL, ein Login, jeder Account, mit der KI des Vendors als erstem Durchgang. Der Unterschied ist, dass die Telemetrie CloudWatch nie verlässt, und für viele regulierte Häuser ist das die ganze Entscheidung.

Der Trade-off ist einer der Identität. "Kein Console-Zugang" heißt, Omni-Autorisierung ist ein SSO-Mapping auf Spaces, keine IAM-Policy auf Log Groups. Das ist das richtige Modell für einen Entwickler, der die Traces seines Services sehen soll und sonst nichts, aber es ist ein zweites Zugriffskontrollsystem neben dem, das du bereits auditierst. Entscheide, welche Spaces Produktions-Telemetrie halten, wer hineingemappt wird und wie dieses Mapping geprüft wird, bevor das erste Team sich selbst einen Space anlegt. Und prüfe die Preise für die Cross-Account- und Cross-Cloud-Ingestion-Pfade, bevor du die Azure-Landschaft darauf richtest.

EventBridge legt den Custom Bus für das Enterprise neu auf

Am 24. September hat EventBridge Custom Event Buses neu aufgelegt. Der erweiterte Bus kann über AWS RAM mit jedem Account der Organisation geteilt werden, sodass Publisher direkt auf den zentralen Bus schreiben. Eine neue Publishing-API nimmt offene Formate wie CloudEvents an, ohne das Schema umzuschreiben. Buses behalten Events standardmäßig 24 Stunden, verlängerbar auf ein Jahr, sodass du nach einem Bug replayen oder einen neuen Consumer aus der History befüllen kannst. Eine neue Subscriber-Ressource bündelt Filterung, Targets und Retries; es gibt inhaltsbasierte Deduplizierung, striktes Ordering, wo du es anforderst, und synchrone Invocation für Targets wie Lambda. Bestehende Buses laufen unverändert als "classic" weiter. Der Beitrag im News Blog ergänzt, dass ein Ingress/Egress-Preismodell die sich aufsummierenden Cross-Account-Routing-Gebühren des Multi-Bus-Musters ersetzt.

Das Muster, das das ersetzt, ist ein Bus pro Account, Weiterleitungsregeln in einen zentralen Bus und wieder zurück, und eine Gebühr an jedem Hop. Ein geteilter Bus mit Subscribern ist einfacher und für die meisten Topologien günstiger. Die Retention- und Ordering-Features sind die, die Teams bisher gezwungen haben, Kinesis oder Kafka vor EventBridge zu stellen; viel von diesem Klebstoff kann jetzt weg.

Migriere den Hub nicht über Nacht. Modelliere zuerst die Ingress/Egress-Kosten gegen deine aktuellen Gebühren pro Regel, denn "günstiger für die meisten" ist nicht "günstiger für alle". Dann bewege einen Producer und einen Subscriber, lass die Weiterleitung des Classic Bus parallel laufen und vergleiche eine Woche lang die Zustellungszahlen. Ordering ist Opt-in und wird Auswirkungen auf den Durchsatz haben; schalte es pro Subscription ein, wo ein Consumer es wirklich braucht, nicht global.

DynamoDB Strong Consistency über Kontinente

Am 23. September haben DynamoDB Global Tables mit Multi-Region Strong Consistency fünf Regionen hinzugefügt (Canada Central, Stockholm, Spanien, Mumbai, Singapur), insgesamt 15, und jede Drei-Regionen-Konfiguration darüber ist jetzt erlaubt, auch solche, die Nordamerika, Europa und Asia Pacific umspannen. Du wählst drei Replikas, oder zwei Replikas plus eine Witness-Region, und bekommst ein Recovery Point Objective von null.

RPO null über Kontinente ist eine echte Fähigkeit, und es ist auch Physik. Ein stark konsistenter Write über Frankfurt, Virginia und Singapur zahlt einen interkontinentalen Round Trip, bevor er bestätigt, jedes Mal. Die kontinentübergreifende Option ist für die Daten, bei denen sich das lohnt (Entitlements, Bestellstatus, Inventar, die Dinge, bei denen ein veralteter Read ein Korrektheitsfehler ist), und nicht für die Session-Tabelle daneben. Halte MRSC-Tabellen klein und bewusst; alles andere bleibt auf eventually consistent Global Tables mit lokaler Write-Latenz.

Migrations- und Sicherheitsecke

Am 25. September hat AWS Elastic Disaster Recovery Graviton-basierte (arm64) Quellserver bekommen. DRS erkennt arm64 und stellt auf Graviton-Instances wieder her, nichts zusätzlich zu konfigurieren, keine Mehrkosten. Das schließt eine Lücke, die die Graviton-Adoption dort blockiert hat, wo "hat einen DR-Plan" eine Audit-Anforderung ist. Es ist die einzige Migrationstooling-Nachricht der Woche; von AWS Transform oder DMS kam nichts.

Am 22. September hat Security Hub AI Inventory angefangen, KI-Assets auf selbst gehosteten Azure-VMs zu entdecken, und nutzt die SBOM-Analyse von Inspector, um Inferenz-Endpunkte, Modelle und Agenten (Ollama, vLLM, Hugging Face TGI und andere) zu finden und mit Befunden zu korrelieren. In Security Hub Essentials enthalten. Wenn du die Security Posture nach AWS konsolidierst, während eine Azure-Landschaft ausläuft, ist das der Inventarschritt, den du sonst von Hand machst.

Und am 25. September hat IAM Outbound Identity Federation Interface VPC Endpoints für seine OIDC-Discovery- und JWKS-Endpunkte bekommen. Ein verifizierender Workload in einer VPC ohne Internetpfad kann jetzt die Keys privat abrufen, um STS-ausgestellte JWTs zu validieren. Wenn du Outbound Federation eingeführt hast, um langlebige Keys loszuwerden, beseitigt das den letzten Grund, warum manche privaten Subnetze es nicht konnten.

Auch diese Woche

Der rote Faden

Omni, der EventBridge-Relaunch, Network Security Manager und die Billing-Context-API gehen alle davon aus, dass die Betriebseinheit eine AWS Organization mit einem zentralen Account ist, nicht ein einzelner Account mit einer Console. Der Preis dieses Aufholens ist, dass jedes davon eine Control Plane auf Org-Ebene einführt (Spaces, geteilte Buses, Security Policies) mit eigenem Zugriffsmodell, und der Job des Plattform-Teams wird, diese Zugriffsmodelle kohärent zu halten. Die DRS- und OIDC-Endpunkt-Änderungen sind die leisere Version derselben Geschichte: Fähigkeiten, die endlich die Konfigurationen erreichen, in denen echte Landschaften stecken, arm64-Flotten und VPCs ohne Internet, sodass die Ausnahmeliste kürzer wird.

Lies das als Nächstes

Für die KI- und Agenten-Lesart derselben Woche siehe ercan.ai. Wenn dein Team Hands-on-Hilfe bei AWS, Cloud-Architektur, CI/CD-Pipelines, Linux, GitHub oder GitLab und der Plattformarbeit darum herum braucht, lebt die Consulting-Seite auf ercanermis.com.

Referenzen