Dans la semaine du 21 septembre, AWS a redessiné deux primitives de base autour de l'organisation plutôt que du compte : CloudWatch Omni est une expérience d'observabilité à l'échelle d'une équipe, accessible en SSO sans accès à la console, et le bus EventBridge personnalisé relancé est un unique broker partagé via RAM avec ordonnancement, rétention et un modèle de prix construit pour le hub-and-spoke que tout le monde fait déjà tourner. Les global tables DynamoDB à cohérence forte multi-Région ont atteint 15 Régions et des configurations transcontinentales, Elastic Disaster Recovery a ajouté les serveurs source Graviton, et Security Hub a commencé à inventorier l'IA auto-hébergée sur des VM Azure.

CloudWatch Omni : la télémétrie organisée par équipe, pas par compte

Le 23 septembre, Amazon CloudWatch Omni est passé en disponibilité générale. Vous créez des espaces dans un compte central qui voient la télémétrie à travers les comptes et les Régions, et à travers d'autres clouds, y compris des charges Azure. Omni découvre automatiquement les services, cartographie les dépendances, fait remonter les golden metrics et embarque l'AWS DevOps Agent dans des sessions d'investigation pour corréler les signaux. Il est construit sur OpenTelemetry, donc l'instrumentation existante apparaît sans reconfiguration. La partie qui change la conception de l'organisation : c'est une expérience web autonome avec SSO pour toute l'équipe, sans accès à la console AWS, plus une extension IDE et un accès via l'Agent Toolkit.

C'est AWS qui construit ce que Datadog et Grafana vendent depuis dix ans : une URL, un login, tous les comptes, avec l'IA du fournisseur qui fait la première passe. La différence, c'est que la télémétrie ne quitte jamais CloudWatch, ce qui pour beaucoup de boutiques régulées constitue toute la décision.

Le compromis est une question d'identité. « Pas d'accès console » signifie que l'autorisation Omni est un mapping SSO vers des espaces, pas une politique IAM sur des log groups. C'est le bon modèle pour un développeur qui doit voir les traces de son service et rien d'autre, mais c'est un second système de contrôle d'accès à côté de celui que vous auditez déjà. Décidez quels espaces contiennent la télémétrie de production, qui y est mappé, et comment ce mapping est revu, avant que la première équipe ne se crée un espace en self-service. Et vérifiez la tarification des chemins d'ingestion inter-comptes et inter-clouds avant d'y pointer le parc Azure.

EventBridge relance le bus personnalisé pour l'entreprise

Le 24 septembre, EventBridge a relancé les bus d'événements personnalisés. Le bus amélioré peut être partagé avec chaque compte de l'organisation via AWS RAM, donc les producteurs écrivent directement sur le bus central. Une nouvelle API de publication accepte des formats ouverts comme CloudEvents sans réécrire le schéma. Les bus conservent 24 heures d'événements par défaut, extensibles à un an, donc vous pouvez rejouer après un bug ou hydrater un nouveau consommateur depuis l'historique. Une nouvelle ressource Subscriber regroupe filtrage, cibles et retries ; il y a de la déduplication par contenu, un ordonnancement strict là où vous le demandez, et l'invocation synchrone pour des cibles comme Lambda. Les bus existants continuent sans changement en tant que « classic ». Le billet du News Blog ajoute qu'un modèle de prix ingress/egress remplace les frais de routage inter-comptes qui se cumulaient dans le pattern multi-bus.

Le pattern que cela remplace est un bus par compte, des règles de transfert vers un bus central et retour, et une facturation à chaque saut. Un bus partagé avec des Subscribers est plus simple et, pour la plupart des topologies, moins cher. Les fonctions de rétention et d'ordonnancement sont celles qui forçaient auparavant les équipes à mettre Kinesis ou Kafka devant EventBridge ; une bonne partie de cette glu peut maintenant disparaître.

Ne migrez pas le hub du jour au lendemain. Modélisez d'abord le coût ingress/egress face à vos frais par règle actuels, parce que « moins cher pour la plupart » n'est pas « moins cher pour tous ». Puis déplacez un producteur et un Subscriber, en gardant le transfert du bus classic en parallèle, et comparez les compteurs de livraison pendant une semaine. L'ordonnancement est opt-in et aura des conséquences sur le débit ; activez-le par abonnement là où un consommateur en a réellement besoin, pas globalement.

La cohérence forte DynamoDB à travers les continents

Le 23 septembre, les global tables DynamoDB à cohérence forte multi-Région ont ajouté cinq Régions (Canada Central, Stockholm, Espagne, Mumbai, Singapour) pour un total de 15, et toute configuration à trois Régions parmi elles est désormais autorisée, y compris celles qui s'étendent sur l'Amérique du Nord, l'Europe et l'Asie-Pacifique. Vous choisissez trois réplicas, ou deux réplicas plus une Région témoin, et vous obtenez un recovery point objective de zéro.

Un RPO de zéro à travers les continents est une vraie capacité, et c'est aussi de la physique. Une écriture à cohérence forte entre Francfort, la Virginie et Singapour paie un aller-retour intercontinental avant d'acquitter, à chaque fois. L'option transcontinentale est pour les données où cela en vaut la peine (droits d'accès, état des commandes, inventaire, les choses où une lecture obsolète est un bug de correction) et pas pour la table de sessions juste à côté. Gardez les tables MRSC petites et délibérées ; tout le reste reste sur des global tables à cohérence éventuelle avec une latence d'écriture locale.

Le coin migration et sécurité

Le 25 septembre, AWS Elastic Disaster Recovery a ajouté les serveurs source Graviton (arm64). DRS détecte arm64 et restaure sur des instances Graviton, rien de plus à configurer, aucun coût supplémentaire. Cela ferme une brèche qui bloquait l'adoption de Graviton là où « a un plan de DR » est une exigence d'audit. C'est la seule nouvelle d'outillage de migration de la semaine ; rien n'est sorti côté AWS Transform ni DMS.

Le 22 septembre, Security Hub AI Inventory a commencé à découvrir les actifs IA sur des VM Azure auto-hébergées, en utilisant l'analyse SBOM d'Inspector pour trouver endpoints d'inférence, modèles et agents (Ollama, vLLM, Hugging Face TGI et d'autres) et les corréler avec les findings. Inclus dans Security Hub Essentials. Si vous consolidez votre posture de sécurité dans AWS pendant qu'un parc Azure s'éteint, c'est l'étape d'inventaire que vous feriez sinon à la main.

Et le 25 septembre, la fédération d'identité sortante IAM a gagné des interface VPC endpoints pour ses endpoints de découverte OIDC et JWKS. Une charge vérificatrice dans un VPC sans chemin vers internet peut maintenant récupérer en privé les clés pour valider les JWT émis par STS. Si vous avez adopté la fédération sortante pour vous débarrasser des clés de longue durée, cela supprime la dernière raison pour laquelle certains sous-réseaux privés ne pouvaient pas suivre.

Aussi cette semaine

Le fil conducteur

Omni, la relance d'EventBridge, Network Security Manager et l'API de contexte de facturation supposent tous que l'unité d'exploitation est une AWS Organization avec un compte central, pas un compte seul avec une console. Le prix de ce rattrapage, c'est que chacun introduit un control plane au niveau de l'organisation (espaces, bus partagés, politiques de sécurité) avec son propre modèle d'accès, et le travail de l'équipe plateforme devient de garder ces modèles d'accès cohérents. Les changements DRS et endpoint OIDC sont la version plus discrète de la même histoire : des capacités qui atteignent enfin les configurations dans lesquelles sont les vrais parcs, flottes arm64 et VPC sans internet, donc la liste des exceptions raccourcit.

À lire ensuite

Pour la lecture IA et agents de la même semaine, voyez ercan.ai. Si votre équipe a besoin d'aide concrète sur AWS, l'architecture cloud, les pipelines CI/CD, Linux, GitHub ou GitLab, et le travail de plateforme autour, le volet conseil vit sur ercanermis.com.

Références