AWS EventBridge remplace les bus multi-comptes par un bus unique partagé
Le 24 septembre 2026, AWS a annoncé un bus d’événements « enhanced » dans Amazon EventBridge : un bus centralisé partagé entre tous les comptes d’une organisation, avec garanties d’ordre, une ressource Subscriber et un nouveau modèle tarifaire ingress/egress. Pour une plateforme multi-comptes qui enchaîne les règles cross-account, c’est la fin d’un bricolage coûteux.
24 septembre 2026. AWS annonce un bus d’événements « enhanced » dans Amazon EventBridge, disponible le jour même dans 14 régions. 24 septembre 2026. Le nouveau bus propose un quota par défaut de 10 000 Subscribers par bus, extensible sur demande. Depuis des années, la bonne pratique AWS impose une structure multi-comptes où chaque équipe vit dans son propre compte. Pourquoi c’est important : pour la première fois, une organisation peut déployer un bus d’événements unique partagé entre tous ses comptes, sans règles cross-account ni routing bus-à-bus.
Le bricolage multi-bus que tout le monde subit
Une organisation qui adopte EventBridge démarre presque toujours avec un bus d’événements personnalisé dans un seul compte. Tant qu’une seule équipe possède l’architecture, ça marche. Dès que l’adoption s’étend, la structure recommandée par AWS — un compte par équipe — transforme l’événementiel en casse-tête.
Pour router un événement entre deux comptes, il faut créer plusieurs bus reliés par des règles cross-account ou des configurations bus-à-bus. Ce contournement réintroduit exactement la complexité opérationnelle que le serverless était censé éliminer. Les équipes plateforme perdent la visibilité sur qui s’abonne à quoi, les frais de routing cross-account et bus-à-bus s’additionnent vite, et les équipes qui ont besoin d’ordre d’événements doivent bâtir des contournements complexes, voire changer de technologie.
Un bus unique partagé via AWS RAM
Le enhanced custom event bus change la donne. Il s’agit d’un bus centralisé, partagé entre tous les comptes d’une organisation AWS via AWS Resource Access Manager (RAM). L’équipe plateforme déploie un seul bus, l’établit comme colonne vertébrale d’événements, et supprime la nécessité de configurer des permissions cross-account ou du routing bus-à-bus.
Les équipes applicatives publient et s’abonnent sur le même bus sans attendre de provisionnement d’infrastructure. Les publishers envoient des événements sans savoir quelles équipes les consomment, et les subscribers créent leurs propres Subscriptions de façon indépendante. L’équipe plateforme conserve une visibilité sur tous les flux et un contrôle fin sur qui peut publier ou consommer.
Le quota par défaut de 10 000 Subscribers par bus — extensible sur demande — réduit la fragmentation qui survient quand les limites de subscribers forcent à découper en plusieurs bus.
L’ordre, sans file d’attente intermédiaire
Le bus enhanced résout aussi le problème de l’ordre des événements, qui poussait nombre d’équipes à intercaler Amazon SQS entre le bus et Lambda pour fiabiliser le traitement. Le mécanisme repose sur un EventGroupId : un publisher l’inclut dans ses événements, et EventBridge délivre en séquence, aux subscribers qui l’ont demandé, tous les événements qui partagent le même identifiant.
Le même bus supporte les deux modes à la fois. Les événements d’un même conducteur de flux restent dans le bon ordre pour les consommateurs qui en ont besoin, pendant que les autres subscribers reçoivent les mêmes événements sans contrainte d’ordre. Pour fiabiliser la livraison, le bus ajoute une invocation synchrone pour les cibles Lambda : le mode synchrone confirme le traitement réussi avant d’acquitter l’événement, ce qui élimine le pattern classique de la file SQS intermédiaire.
Le Subscriber : une ressource au lieu de trois
Le bus enhanced introduit une ressource Subscriber qui regroupe le filtrage d’événements, la configuration de cible, les politiques de retry et les dead-letter queues dans une seule unité gérable. Aujourd’hui, obtenir le même résultat avec EventBridge exige de configurer séparément des règles, des cibles et des paramètres de retry répartis sur plusieurs ressources.
Le Subscriber simplifie ce modèle : chaque consommateur définit, dans une ressource unique, les événements qu’il veut recevoir, où les livrer et comment gérer les échecs. Pour une équipe plateforme, cela se traduit par moins de ressources à auditer et une politique d’échec enfin lisible.
Un modèle tarifaire qui change la donne
Le bus enhanced adopte un modèle de tarification par débit ingress/egress. Les publishers paient les événements ingérés, les subscribers paient les événements livrés. Ce modèle remplace la tarification par événement dont les frais de routing cross-account et bus-à-bus se cumulaient dans les architectures multi-bus.
C’est aussi une question d’allocation de coûts : dans un bus partagé, savoir qui paie quoi devient structurel, plutôt que le résultat d’une comptabilité manuelle des règles de routage.
Ce qui ne change pas
Les bus d’événements personnalisés existants continuent de fonctionner exactement comme aujourd’hui, sans aucune migration requise. Ils apparaissent désormais dans la console sous le nom Custom event bus – classic. Le enhanced custom event bus est une ressource nouvelle, à adopter au rythme de chaque organisation : il apparaît simplement sous le nom Custom event bus.
La disponibilité couvre l’US East (N. Virginia, Ohio), l’US West (Oregon), l’Europe (Irlande, Francfort, Stockholm, Espagne) et l’Asie-Pacifique (Hong Kong, Malaisie, Mumbai, Singapour, Sydney, Thaïlande, Tokyo). Le bus se crée via la console AWS, l’AWS CLI ou les API EventBridge.
Classique ou enhanced : le tableau
| Critère | Custom event bus – classic | Enhanced custom event bus |
|---|---|---|
| Portée | Un compte, règles cross-account pour le reste | Toute l’organisation, via AWS RAM |
| Ordre | Non garanti nativement | EventGroupId + invocation synchrone |
| Consommateur | Règles, cibles et retry séparés | Un Subscriber unique |
| Tarification | Par événement, frais de routing cumulés | Ingress (publishers) / egress (subscribers) |
| Quota | Limité par compte | 10 000 Subscribers par bus |
Le tableau résume un arbitrage simple. Le bus classic reste l’outil d’un compte unique ; le bus enhanced devient l’épine dorsale d’une organisation. L’un n’annule pas l’autre : ils cohabitent dans la console, et rien n’oblige à migrer l’existant.
Migrer sans tout casser
La bascule vers le bus enhanced se fait par adoption progressive, pas par big bang. L’équipe plateforme crée d’abord le bus partagé, le partage via AWS RAM avec l’organisation, puis y branche les nouveaux flux. Les anciens bus classic continuent de tourner pendant que les équipes convertissent leurs règles en Subscriptions.
Le point d’attention est la tarification. Le passage d’un modèle par événement à un modèle ingress/egress change la façon de budgéter : l’équipe plateforme doit répartir les coûts entre publishers et subscribers, ce que le nouveau modèle rend justement plus lisible. C’est un chantier de gouvernance autant que d’architecture.
Verdict
Si vous exploitez une organisation AWS multi-comptes avec plusieurs bus reliés par des règles cross-account, migrez les nouveaux flux vers le bus enhanced : vous supprimez le routing bus-à-bus et ses frais cumulés, et vous récupérez une visibilité centrale sur qui consomme quoi. Si vous êtes mono-compte, mono-équipe, le bus classic reste parfaitement adapté — ne migrez pas pour migrer. Si votre point de douleur est l’ordre des événements, le couple EventGroupId et invocation synchrone remplace avantageusement la file SQS intermédiaire, à condition que vos consommateurs acceptent le mode synchrone. Le bus enhanced n’est pas une évolution cosmétique : c’est la réponse d’AWS à des années de contournements multi-bus, et le signal que l’événementiel d’entreprise a désormais un chemin officiel.