Temps de lecture : 10 minutes

Les 3 piliers communément admis de l’observabilité sont : les métriques, les logs, les traces applicatives. Aujourd’hui nous vous proposons d’explorer un 4e pilier à travers le service Amazon Eventbridge : les événements !

A lire également sur ce sujet : 5 questions sur l’observabilité

Un peu de contexte

L’observabilité est une propriété d’architecture IT, au même titre que la fiabilité, ou encore la scalabilité.

On dit qu’un système est observable lorsqu’il a été conçu pour intégrer nativement des mécanismes de contrôle et d’analyse de performances et ce, dans n’importe quelle condition d’exploitation.

Quelle différence avec le monitoring ? Et bien le monitoring n’est que l’un des aspects de l’observabilité ! Creusons un peu …

Par définition, une alarme de monitoring se déclenche quand une métrique dépasse un certain seuil.

On peut définir un “événement” comme un point dans le temps où « quelque chose » se produit. Donc… une alarme, c’est un événement !

Malheureusement, la valeur d’une métrique évolue généralement en réaction à un incident ou à un événement. 

Par exemple : l’arrêt d’un service applicatif sur une instance risque de causer une hausse du taux d’erreur. Cette hausse va déclencher une alarme de monitoring, alors que le problème sera déjà perçu par les utilisateurs depuis plusieurs minutes.

Posons-nous maintenant la question : et si les équipes DevOps pouvaient être prévenues de l’événement, avant même que cela ait un impact applicatif ?

Dans cet article, nous allons voir comment EventBridge peut améliorer votre réactivité en cas d’incidents, dans un contexte d’observabilité d’infrastructure AWS.

Comment EventBridge se différencie des autres services de messaging ?

EventBridge peut être perçu comme un service de messaging “de plus” chez AWS, mais il offre plusieurs spécificités.

Au premier abord, il peut être compliqué de comprendre la distinction entre ce service et les autres services proposés par AWS.

Il y a d’abord Amazon MQ, qui propose des implémentations PaaS des services ActiveMQ et RabbitMQ. Ce service peut vous aider dans une dynamique de migration de type lift&shift ou re-host.

AWS propose également Simple Notification Service (SNS), qui – comme son nom l’indique – est un service de notification.

Son rôle est de recevoir en entrée des messages, et de les délivrer à une liste de destinataires.

L’une de ses principales caractéristiques est de permettre le fan-out : un unique message peut être transmis à de multiples destinataires. Ces destinataires peuvent être des boites mails, des SMS, des fonctions Lambda, des queues SQS ou encore des endpoints HTTP.

SNS dispose aussi de mécaniques de retry évoluées.

Comment ne pas citer le premier service lancé par Amazon Web Services … C’était il y a déjà près de 20 ans (en 2004 !) et il s’agit bien sûr de Simple Queue Service, mieux connu sous son acronyme SQS.

Avec SQS, la mécanique de fonctionnement est un peu différente : le service reçoit toujours des messages en entrée, mais les consommateurs doivent faire du polling sur les queues SQS pour récupérer les messages.

En fonctionnement normal, un message ne peut être consommé que par un seul consommateur. 

Ce service propose énormément de fonctionnalités, mais elles sortent largement du cadre de cet article.

Retenez simplement que l’un des usages les plus courants de SQS est de permettre de faire du découplage d’applications, ce qui est typiquement le cas dans les architectures micro-services.

Et AWS créa EventBridge … 

A l’origine, ce service est une émanation du service de monitoring Cloudwatch (il était initialement appelé Cloudwatch Events), avant qu’AWS ne prenne conscience du potentiel énorme de cet outil et qu’ils décident de le faire grandir.

Avec EventBridge, nous avons donc encore un service de type “bus de messages“.

Comme SQS et SNS, EventBridge reçoit en entrée des messages, que l’on appellera ici événements (ou events en anglais). La première particularité du service, c’est qu’AWS publie déjà un certain nombre de messages dans EventBridge, sans que vous n’ayez rien à faire.

Chacun de ces messages événements est évalué par des “règles” (rules) afin de permettre leur envoi à des “cibles” (targets) que l’on appellera parfois “consommateurs” (consumers).

A l’aide d’un seul événement, on peut déclencher plusieurs actions sur des cibles différentes.

Et tout comme ses camarades SQS et SNS, le service EventBridge est serverless !

Le service est là et vous n’avez qu’à l’utiliser, sans vous préoccuper des infrastructures sous-jacentes.

EventBridge, comment ça marche ?

Les événements AWS

AWS publie automatiquement des événements pour bon nombre de services : 

• Une action d’autoscaling ? 
• Un changement d’état sur une instance EC2 ? 
• Un changement d’état sur une rule AWS Config ? 
• Un failover sur un cluster RDS ? 
• Un snapshot sur un volume EBS ? 
• AWS publie un incident ou un scheduled change sur le Personal Health Dashboard ? 

… tout cela génère des événements, qui sont automatiquement poussés dans le bus EventBridge. 

Le client n’a plus qu’à “se servir” !

Alors un événement, à quoi ça ressemble ?

Et bien c’est tout simplement un message JSON, prenant par exemple la forme suivante :

Il comportera systématiquement les données suivantes:

• Un service source (ici le service EC2)
• Un champ detail-type spécifiant le type d’événement
• Un champ detail

S’agissant des services AWS, l’événement comportera généralement les données suivantes :

• Un identifiant
• Un AWS Account
• Une région
• Un timestamp
• Une liste de ressources concernées

Vous pouvez retrouver la liste complète des services émettant des événements vers EventBridge dans la documentation AWS.

Mieux encore : si par malheur AWS ne propose pas d’événement pour votre besoin mais qu’il y a bien des appels aux API AWS, alors vous pouvez utiliser Cloudtrail en conjonction avec EventBridge.

En effet, chaque entrée dans Cloudtrail génère un événement.

Il vous suffit donc d’écrire une règle filtrant le bon message Cloudtrail pour déclencher le traitement de votre choix.

Autre cas de figure : certains services ne publient pas d’événements EventBridge, mais écrivent des logs Cloudwatch.

Vous avez la possibilité de mettre en place une log subscription qui va déclencher une fonction Lambda, qui va générer elle-même un événement dans EventBridge.

Le filtering

Par défaut, EventBridge vous proposera de déclencher un traitement sur tout événement lié à un service, ou à une famille d’événements liés à un service. Par exemple :

Mais vous pouvez aussi écrire vos propres filtres. Dans l’exemple suivant, on ne va récupérer que les événements RDS-EVENT-0069 et RDS-EVENT-0071, qui correspondent à des failovers (ratés ou réussis) de cluster RDS :

Dans cet autre exemple, le traitement ne sera déclenché que si une règle AWS Config change d’état pour une ressource de type EC2 :

Notons que depuis octobre 2023, EventBridge permet l’utilisation de wildcards dans les rules! https://aws.amazon.com/fr/about-aws/whats-new/2023/10/amazon-EventBridge-wildcard-filters-rules/

Les actions possibles

Détecter un événement, c’est bien … En faire quelque chose, c’est mieux !

On peut regrouper les actions en 2 grandes familles : les notifications, et le compute.

Les notifications consisteront à utiliser l’événement pour envoyer un message vers un autre système. Ce message peut par exemple être un mail (via le service SNS), une entrée de logs (via Cloudwatch Logs), un message qui sera poussé dans une queue SQS, ou encore un événement qui sera poussé dans un bus EventBridge.

En termes de compute, on peut tout imaginer : 

• L’éxécution d’une fonction Lambda
• Le déclenchement d’une Stepfunction
• Le lancement d’un CodePipeline
• Le déclenchement d’un SSM RunCommand ou encore d’une tâche ECS
• etc

… avec EventBridge, les possibilités sont presque infinies !

Et AWS User Notifications ?

En mai 2023, AWS a discrètement lancé User Notifications

Basé sur EventBridge, ce nouveau service simplifie l’envoi de notifications suite à des événements AWS.

Le service se veut simple, et il vous permettra d’envoyer des notifications … que ce soit par e-mail (via SNS), vers des canaux Chime/Slack/Teams (via AWS Chatbot), ou directement en push vers l’application AWS Console Mobile App.

Pour en savoir plus, vous pouvez consulter la documentation du service.

Le scheduler

Jusqu’ici nous avons parlé d’événements publiés par d’autres services AWS dans EventBridge, mais il existe un autre type d’événement un peu particulier : le time-based event.

Concrètement, cela vous permet de faire du serverless cron ou, pour le dire autrement : d’avoir accès gratuitement à un ordonnanceur de tâches.

Pour déclencher une action, il suffit de définir une expression Cron, ou de choisir une “fréquence” d’éxécution (toutes les X minutes/heures/jours). L’activité sera lancée soit instantanément, soit dans une fenêtre de lancement pouvant aller jusqu’à 4 heures.

Le scheduler d’EventBridge propose également de mettre en place des retry policies et/ou de router les tâches en échec vers une dead-letter queue (SQS).

Un dernier détail aussi important qu’appréciable : vous pouvez spécifier la timezone s’appliquant au scheduling que vous définissez !

Quelques use-cases

La théorie c’est bien, mais quoi de mieux que des exemples concrets pour comprendre toute la richesse apportée par EventBridge ?

Par exemple, vous pouvez utiliser EventBridge en conjonction avec Cloudtrail, pour détecter une tentative de connection avec l’utilisateur root de votre compte AWS, et ainsi déclencher une notification et/ou une remédiation :

A ce sujet, il faut savoir qu’EventBridge est la manière la plus réactive de traiter ce genre d’événements.Il est possible d’utiliser l’ingestion des trails dans Cloudwatch logs, mais cette dernière peut avoir du retard.De la même manière, la recopie des trails vers S3 se fait toutes les 5 minutes, et vous pouvez donc avoir jusqu’à 5 minutes de retard sur l’événement.

Toujours dans le domaine de la sécurité et de la conformité, vous pouvez réagir à une anomalie AWS Config :

Par exemple, vous pouvez détecter l’ajout d’une règle autorisant le port SSH sur un security group associé à une instance EC2, et lancer une remédiation automatisée afin de préserver l’intégrité de vos infrastructures.

Vous pouvez également traiter les findings GuardDuty (relatifs aux VPC Flow Logs, à CloudTrail, aux DNS Logs ou aux EKS audit logs) de la même manière, car chaque finding génère un événement dans EventBridge.

D’un point de vue applicatif, il arrive que l’on doive exploiter des applications moins robustes qu’espérées.

Par exemple, il m’est arrivé d’avoir une application qui se comporte mal si le cluster de base de données RDS fait un fail-over.

Avec Cloudwatch, nous avons pu détecter ces événements de failover RDS, et si besoin déclencher des actions de remédiation directement sur le service applicatif hébergé sur des instances EC2, à l’aide de SSM RunCommand, tout en notifiant les équipes RUN à l’aide du service SNS :

EventBridge peut également être utile pour mettre en place des architectures plus complexes.

Par exemple, on peut combiner EventBridge avec des healthchecks, Cloudwatch et Route53 afin de réaliser un failover RDS multi-régions et ainsi disposer d’un Disaster Recovery Plan (en cas de perte d’une région) :

Pricing

C’est peut-être la meilleure partie de l’article : l’usage d’EventBridge ne vous coûtera (presque) rien !

En effet, AWS publie déjà ses événements dans le service : ils sont là, et il n’y a qu’à se servir.

L’évaluation des règles est également gratuite, de même que l’invocation des services AWS cibles.

Avec EventBridge, le client ne paye que le coût d’exécution du service appelé par EventBridge (par exemple : Lambda).

En conclusion

EventBridge est un service encore trop méconnu mais qui peut s’avérer fort pratique. 

Peu onéreux, c’est un bon complément aux systèmes de monitoring classiques et il peut vous apporter beaucoup de valeur ajoutée (notamment en termes d’excellence opérationnelle).

Au cours des derniers mois, EventBridge est un service qui a subi beaucoup d’évolutions et qui a été énormément enrichi par AWS. 

Dans un prochain article, nous traiterons de fonctionnalités plus avancées et des capacités permises par EventBridge.