EventBridge repose sur le concept de producteur (source), bus d'événements et consommateur (cible). Les événements sont générés par des sources, tels que des services AWS, des applications personnalisées ou même des événements personnalisés déclenchés par l'utilisateur. Ces événements sont ensuite transmis à un bus d'événements qui agit comme un canal de communication centralisé.
Dans le modèle "hub and spoke", le compte centralisé (hub) agit comme un point du réseau permettant aux comptes individuels (spokes) de communiquer entre eux de manière sécurisée. Cette structure ressemble à une topologie en étoile, où le hub représente le centre du réseau auquel tous les spokes sont connectés. C’est un modèle assez commun dans de grosses organisations pour gérer du multi-comptes.
Ce modèle peut s’appliquer à la gestion d’événements avec des comptes périphériques agissant comme des spokes en envoyant et recevant des événements depuis et vers le hub.
Voilà à quoi pourrait ressembler notre architecture pour EventBridge :
Voici ce que l’on retrouve dans notre architecture :
Dans le modèle hub-and-spoke, nous commençons par configurer un bus d'événements global. Ce bus global servira de hub principal pour recevoir tous les événements. Pour créer un bus d'événements global, utilisez la console AWS ou l'interface de ligne de commande (AWS CLI).
aws events create-event-bus --name GlobalEventBusVous pouvez également le faire via la console AWS en naviguant vers le service EventBridge, en sélectionnant "Event buses" et en cliquant sur "Create event bus".
Chacun des comptes spoke doit avoir son propre bus d'événements local pour recevoir des événements du bus global et envoyer des événements locaux. Configurons un bus d'événements local dans un compte spoke.
aws events create-event-bus --name LocalEventBusAssurez-vous de répéter cette étape pour chaque compte spoke que vous avez dans votre architecture.
Une fois que vous avez configuré les bus d'événements global et locaux, vous devez permettre au bus global de recevoir des événements d’un compte local et d'envoyer des événements aux bus locaux.
Pour cela, vous devez créer la règle appropriée :
aws events put-rule --event-bus-name GlobalEventBus \
--name ForwardToSpokeRule \
--event-pattern "{\"account\":[\"\"]}"
aws events put-targets --rule ForwardToSpokeRule \
--event-bus-name GlobalEventBus \
--targets "Id"="1","Arn"="arn:aws:events:us-east-1::event-bus/LocalEventBus"Concernant les rôles IAM, voici un exemple simple de ce que l’on peut utiliser dans notre cas :
# Créer un rôle IAM dans le compte global pour permettre l'envoi
# d'événements vers les bus locaux
aws iam create-role --role-name EventBridgeGlobalRole \
--assume-role-policy-document file://trust-policy.json
# Attacher une stratégie permettant l'envoi d'événements vers les bus
# locaux au rôle IAM dans le compte global
aws iam attach-role-policy --role-name EventBridgeGlobalRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEventBridgeFullAccess
# Créer un rôle IAM dans chaque compte local pour permettre
# la réception des événements provenant du bus global
aws iam create-role --role-name EventBridgeLocalRole \
--assume-role-policy-document file://trust-policy.json
# Attacher une stratégie permettant la réception des événements
# provenant du bus global au rôle IAM dans chaque compte local
aws iam attach-role-policy --role-name EventBridgeLocalRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEventBridgeReadOnlyAccess
Et voici le fichier policy.json utilisé ci-dessus :
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "events.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}Chez Theodo Cloud, nous avons déployé avec succès ce système de gestion d’événements via AWS EventBridge pour une compagnie aérienne lors de la migration d’une application on-premise vers une architecture serverless. La migration, basée sur le modèle MVM (Minimum Viable Module), impliquait la création de comptes AWS distincts pour chaque fonctionnalité de l'application.
Dans ce contexte, nous avons utilisé EventBridge pour faciliter la communication entre l'équipe de gestion des réservations, l'équipe de gestion des paiements, et l'équipe d'engagement client. Une fois qu'une réservation était effectuée, un événement était déclenché par une fonction Lambda et envoyé sur le bus global d'événements. Ce bus global agissait comme un hub central, distribuant ensuite cet événement à tous les comptes distants (spokes) dédiés à chaque fonctionnalité.
Concrètement, cela signifie que dès qu'une réservation était faite, cet événement était automatiquement relayé aux équipes en charge des paiements et de l'engagement client, permettant ainsi une coordination efficace entre les différentes parties de l'application.
Ce modèle a prouvé son efficacité en assurant une communication transparente et rapide entre les comptes AWS, ce qui était essentiel pour le bon fonctionnement de l'application dans un environnement serverless distribué.
En conclusion, AWS EventBridge se révèle être un outil essentiel pour orchestrer efficacement les événements au sein d'une infrastructure multi-comptes, en particulier en adoptant le modèle hub-and-spoke.
En configurant des bus d'événements en hub-and-spoke et en établissant des règles précises, vous pouvez centraliser intelligemment le traitement des événements tout en préservant une architecture distribuée.
Bien que la mise en place initiale puisse présenter des défis, les avantages tels que la centralisation du traitement des événements, la flexibilité de configuration et l'intégration native avec d'autres services AWS en font un outil puissant.