Utiliser AWS Eventbridge pour gérer des événements intercomptes

Comprendre AWS EventBridge

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é.

Hub-and-spoke : Un modèle de multicomptes

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 :

• Un compte global en bas qui comprend un bus EventBridge qui reçoit les événements depuis les comptes “spoke” et un ou plusieurs règles EventBridge qui décrivent comment et à qui transférer les événements en fonction de leur type.
• Des comptes “spoke” comprenant :
  • une lambda contenant du code applicatif qui va publier des événements dans le bus EventBridge global
  • un bus Eventbridge local qui recevra les événements envoyés depuis le compte global
  • des règles Eventbridge qui décrivent comment les événements dans le bus local vont être gérés (déclencher de nouvelles lambdas, envoyer un mail avec AWS SES, activer des notifications via AWS SNS, …)

Configurer un bus d'événements global

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 GlobalEventBus

Vous 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".

Configurer des bus d'Événements locaux

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 LocalEventBus

Assurez-vous de répéter cette étape pour chaque compte spoke que vous avez dans votre architecture.

Autoriser les événements à passer du global aux locaux

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"

• La première règle consiste à dire au bus global qu’il doit traiter uniquement les événements provenant des comptes AWS locaux. L’option event-pattern permet de filtrer le modèle d’événements que l’on veut traiter avec cette règle.
• La deuxième indique au bus global qu’il doit envoyer ses événements vers les bus locaux.

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"
    }
  ]
}

Exemple de cas d’utilisation

Chez Padok, 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é.

Avantages et inconvénients de l'outil

Avantages

• Centralisation du traitement des événements : EventBridge offre une solution centralisée pour gérer les événements à l'échelle de l'entreprise, simplifiant ainsi le processus de traitement.
• Flexibilité de Configuration : Le modèle hub-and-spoke permet une configuration flexible pour s'adapter aux besoins spécifiques de votre architecture multi-comptes.
• Intégration avec d'Autres Services AWS : EventBridge s'intègre nativement à de nombreux services AWS, ce qui facilite l'orchestration des événements dans l'ensemble de votre infrastructure cloud.

Inconvénients

• Complexité Initiale : La mise en place d'une architecture hub-and-spoke avec EventBridge peut être complexe initialement, en particulier pour les utilisateurs débutants dans le domaine.
• Coût : Bien que la tarification d'EventBridge soit basée sur la consommation réelle, la multiplication des bus d'événements peut entraîner des coûts supplémentaires, à prendre en compte dans la planification budgétaire.
• Dépendance à AWS : Comme tout service cloud, l'utilisation d'EventBridge implique une dépendance à la plateforme AWS, ce qui peut poser des défis en cas de changement d'infrastructure.

Conclusion

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.