Fondamentaux d'EventBridge

Une alarme CloudWatch sait redémarrer l'unique instance que ses dimensions désignent. Elle ne sait pas faire ceci : quand n'importe quelle instance taguée Environment=prod passe à l'état stopped, ouvrir un OpsItem Systems Manager, lancer un runbook qui capture la sortie console, et prévenir l'équipe propriétaire. Il n'y a aucun nombre à comparer à un seuil ici. Rien ne monte ni ne descend. Quelque chose s'est simplement produit, une fois, sur une ressource, et plusieurs choses doivent se déclencher à cause de cela.

C'est le vide que comble EventBridge. C'est le routeur placé entre ce qui arrive dans votre compte et ce qui doit s'exécuter en réponse.

Les événements sont des faits, les métriques sont des nombres

Cette frontière mérite d'être posée avant tout le reste, parce que la moitié des questions de diagnostic de ce domaine en dépend.

Une métrique est une série temporelle de nombres. CPUUtilization sur une instance vaut 4 % à 09h00 et 71 % à 09h01. Les alarmes existent pour surveiller cette série et décider quand les nombres sont mauvais depuis assez longtemps pour compter.

Un événement est un document JSON qui décrit quelque chose qui s'est produit, livré une fois, près du moment où cela s'est produit. Une instance a changé d'état. Un snapshot EBS s'est terminé. Quelqu'un a appelé AuthorizeSecurityGroupIngress. Une notification AWS Health s'est ouverte pour une Région. Aucun de ces faits n'est un nombre, donc aucune alarme ne peut les surveiller.

Testez-vous avec une règle rapide : si un humain décrirait la situation avec un verbe au passé, c'est un événement. S'il la décrirait avec un nombre et une comparaison, c'est une métrique.

Les deux se rejoignent, et l'examen aime ce point de jonction. Le changement d'état d'une alarme CloudWatch est lui-même un événement sur le bus par défaut (aws.cloudwatch, detail-type CloudWatch Alarm State Change). La réponse à « mon alarme doit déclencher une réparation en cinq étapes » est donc presque toujours : gardez l'alarme, et laissez EventBridge cibler son événement de changement d'état pour démarrer le workflow.

L'enveloppe d'un événement

Tout événement a la même structure extérieure, la charge utile propre au service étant imbriquée dans detail. Voici un vrai événement de changement d'état EC2 :

{
  "version": "0",
  "id": "6a7e8feb-b491-4cf7-a9f1-bf3703467718",
  "detail-type": "EC2 Instance State-change Notification",
  "source": "aws.ec2",
  "account": "111122223333",
  "time": "2017-12-22T18:43:48Z",
  "region": "us-west-1",
  "resources": [
    "arn:aws:ec2:us-west-1:123456789012:instance/i-1234567890abcdef0"
  ],
  "detail": {
    "instance-id": "i-1234567890abcdef0",
    "state": "terminated"
  }
}

Les deux champs sur lesquels vous écrirez des patterns en permanence sont source (quel service ou quelle application a émis ceci, aws.* pour les services AWS) et detail-type (quel type d'événement c'est au sein de cette source). Tout ce qui est spécifique à l'événement vit sous detail, et sa forme est définie par le service émetteur.

Deux détails sur resources piègent régulièrement. Les événements d'appel d'API AWS issus de CloudTrail ont souvent un resources vide, donc un pattern qui filtre dessus ne correspondra jamais. Et les services globaux comme IAM et Route 53 n'existent qu'en US East (N. Virginia), donc leurs événements d'appel d'API ne sont disponibles que dans cette Région. Une règle en eu-west-1 qui attend un changement de policy IAM attendra pour toujours.

Les event buses : par défaut, personnalisés, partenaires

Un event bus est un routeur qui reçoit des événements et les propose aux règles qui lui sont attachées. Il en existe trois sortes, et la distinction n'est pas cosmétique.

L'event bus par défaut existe dans chaque compte et chaque Région, et c'est là que les services AWS livrent leurs événements. Ce n'est pas configurable. Quand une instance EC2 change d'état, cet événement va sur le bus par défaut de ce compte, point final.

Un event bus personnalisé est un bus que vous créez. Vos propres applications y publient avec PutEvents, et vous pouvez transférer des événements d'un bus vers un autre, y compris entre comptes et entre Régions, en faisant d'un bus le target d'une règle. Les bus personnalisés existent pour que les événements applicatifs n'aient pas à partager un espace de règles avec le trafic des services AWS, et pour que vous puissiez y attacher une resource-based policy autorisant d'autres comptes précis à publier.

Un partner event bus reçoit les événements d'un fournisseur SaaS via une partner event source que vous lui associez.

La fausse idée à tuer tout de suite : créer un bus personnalisé ne déplace pas les événements des services AWS dessus. Si un scénario dit « isoler nos événements applicatifs du bruit des services AWS », le bus personnalisé est la bonne réponse. Si un scénario dit « recevoir les événements S3 sur notre bus personnalisé », la réponse honnête est qu'ils arrivent sur le bus par défaut et que vous les transférez.

Des quotas à retenir : 100 event buses par compte et par Région, 300 règles par event bus dans la plupart des Régions, et 5 targets par règle (ce dernier n'est pas ajustable).

Les règles : le pattern est le filtre

Une règle a un filtre et une liste de targets. Le filtre est soit un event pattern (cibler des événements par leur contenu), soit une schedule expression (se déclencher sur une expression cron ou rate). C'est l'un ou l'autre.

Le pattern a la même forme que l'événement qu'il cible, et c'est cette décision de conception qui rend les patterns lisibles. Celui-ci sélectionne les terminaisons d'instances EC2 :

{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Instance State-change Notification"],
  "detail": {
    "state": ["terminated"]
  }
}

Trois exigences distinctes, qui doivent toutes être vraies.

Comment fonctionne réellement le matching

Quatre règles gouvernent tous les patterns que vous écrirez ou déboguerez. Apprenez-les ici et la plupart des « ma règle ne se déclenche pas » deviennent un diagnostic de trente secondes.

Le matching est un test d'inclusion. Chaque champ que vous nommez doit correspondre. Chaque champ omis est ignoré. Donc {"source": ["aws.ecs"]} cible tous les événements ECS du bus. C'est le mécanisme derrière les règles qui se déclenchent des centaines de fois par jour : le pattern était sous-spécifié, pas faux.

Un tableau signifie OU. "state": ["stopped", "terminated"] cible l'une ou l'autre valeur. Pour exiger deux conditions, nommez deux champs, ce qui est un ET implicite. Un piège associé : si vous écrivez deux fois la même clé dans un pattern, EventBridge n'utilise que la dernière référence et ignore la première en silence.

Le matching est exact, caractère par caractère. La plupart des services AWS traitent : et / dans un ARN comme interchangeables. EventBridge non. Si l'événement porte instance/i-0abc et que votre pattern dit instance:i-0abc, rien ne correspond, et rien ne vous dit pourquoi.

Les opérateurs de comparaison ne fonctionnent que sur les feuilles. $or et anything-but sont les deux exceptions.

Ces opérateurs forment la seconde moitié de l'aisance sur les patterns :

Deux contraintes sur les deux derniers. wildcard est pris en charge dans les règles d'event bus mais pas dans les filtres de pipe, et chaque event bus n'accepte que 30 règles contenant des wildcards, un quota que vous ne pouvez pas relever. Et un $or qui se développe en plus de 1 000 combinaisons de règles est rejeté avec InvalidEventPatternException ; le nombre de combinaisons est le produit du nombre d'arguments de chaque tableau $or du pattern.

Un event pattern est plafonné à 2 048 caractères par défaut.

L'habitude de débogage la plus utile ici est le EventBridge Sandbox de la console (ou l'API TestEventPattern). Vous collez un vrai événement, vous collez votre pattern, vous obtenez un oui ou un non. Cela ne coûte rien et cela tranche des débats qui prendraient sinon un après-midi.

Les targets et les deux modèles de permission

Jusqu'à 5 targets par règle. La liste est longue, et ceux qui comptent pour la remédiation sont Lambda, SNS, SQS, Step Functions, Systems Manager Automation, Systems Manager Run Command, les OpsItems Systems Manager, les response plans Incident Manager, les tâches ECS, les API destinations et d'autres event buses. Certains targets ne reçoivent pas l'événement du tout : RebootInstances, StopInstances et TerminateInstances sur EC2 traitent l'événement uniquement comme le déclencheur de cet appel d'API.

Les permissions fonctionnent de deux façons, et savoir laquelle s'applique à quel target est matière à examen.

Un rôle IAM d'exécution. Vous posez RoleArn sur le target, la trust policy du rôle autorise events.amazonaws.com à l'assumer, et sa permission policy accorde l'action dont le target a besoin. C'est ainsi que fonctionne la plupart des targets, et c'est la seule option pour des targets comme Systems Manager Automation et ECS.

Une resource-based policy sur le target. Pour Lambda, SNS et SQS, si aucun rôle d'exécution n'est configuré, EventBridge se rabat sur une policy posée sur la ressource cible elle-même, qui accorde à events.amazonaws.com le droit d'invoquer ou de publier.

Voici la conséquence pratique, et c'est un scénario de prédilection. Créez la règle dans la console et elle fonctionne, parce que la console attache la resource-based policy à votre place. Créez la même règle avec PutTargets et le target n'est jamais invoqué, parce que rien n'a attaché cette policy. La métrique TriggeredRules montre que la règle s'est déclenchée ; Invocations montre que rien n'arrive. Deux variantes de la même forme : une file SQS ou un topic SNS chiffrés exigent que kms:Decrypt et kms:GenerateDataKey soient accordés à events.amazonaws.com dans la key policy, et EventBridge ne peut pas du tout utiliser une file SQS chiffrée avec une clé détenue par AWS.

L'input transformation : remodeler l'événement

Certains targets veulent l'événement tel quel. D'autres veulent une structure précise, ou une ligne lisible par un humain. L'input transformer règle cela en deux parties.

L'input path définit des variables à partir de l'événement avec des chemins JSON :

{
  "timestamp": "$.time",
  "instance": "$.detail.instance-id",
  "state": "$.detail.state"
}

L'input template est ce que le target reçoit réellement :

{
  "instance": <instance>,
  "state": <state>,
  "note": "l'instance \"<instance>\" est en <state>"
}

Vous disposez de 100 variables au maximum, plus des variables réservées que vous n'avez pas à définir : aws.events.rule-arn, aws.events.rule-name, aws.events.event.ingestion-time, et aws.events.event.json pour la charge utile originale entière.

Le mode de défaillance à anticiper : EventBridge ne valide pas les input paths quand vous enregistrez la règle. Un chemin qui ne correspond à rien ne produit aucune variable, et ce champ disparaît de la sortie. Pas d'erreur, pas d'avertissement, juste un target qui reçoit moins que prévu.

Les règles planifiées et EventBridge Scheduler

Une règle peut se déclencher sur une planification au lieu d'un pattern, avec rate(...) ou cron(...). Deux faits sur les règles planifiées font l'objet de questions : l'expression est évaluée en UTC, et la résolution la plus fine est la minute, l'invocation tombant quelque part dans cette minute plutôt qu'à la seconde exacte.

EventBridge Scheduler est le service séparé et dédié à la planification, et c'est la bonne réponse dès qu'un scénario insiste sur l'échelle ou sur la souplesse par planification. Il gère des millions de schedules, accepte les invocations uniques comme les récurrentes, comprend les fuseaux horaires, offre des flexible time windows pour étaler la charge, et atteint plus de 270 services via son universal target parameter. Les règles planifiées sont contraintes par le quota de règles par bus et la limite de 5 targets par règle ; Scheduler non.

Indice lexical : « des milliers de planifications par client », « une seule fois » ou « dans le fuseau horaire local du client » désigne Scheduler. « Réagir quand tel service AWS fait quelque chose » désigne une règle.

Conseils pour l'examen

• Cherchez un verbe au passé dans l'énoncé. « Quand une instance est terminée », « quand un snapshot se termine », « quand quelqu'un modifie une policy » sont tous des cas EventBridge. « Quand le CPU dépasse 80 % pendant 10 minutes » est une alarme.
• Une règle qui se déclenche beaucoup plus souvent que prévu vient d'un pattern sous-spécifié. Une règle qui ne se déclenche jamais vient en général de trois choses : une ponctuation d'ARN incorrecte dans le pattern, un événement de service global attendu ailleurs qu'en us-east-1, ou un filtre sur un champ resources que les événements issus de CloudTrail laissent vide.
• TriggeredRules supérieur à zéro avec Invocations à zéro veut dire que le routage a marché et que les permissions non. C'est la question de la resource-based policy sous forme de métrique.
• Les alarmes composites ne peuvent effectuer ni action EC2 ni action Auto Scaling. Quand un scénario demande à une condition composite de piloter une réparation en plusieurs étapes, l'alarme composite notifie et une règle EventBridge cible son événement de changement d'état.
• Les event buses personnalisés ne reçoivent jamais directement les événements des services AWS. Si une option prétend le contraire, éliminez-la.
• Retenez les trois nombres durs : 5 targets par règle (non ajustable), 300 règles par event bus, 100 event buses par compte et par Région.

Le modèle mental à conserver : le bus ne choisit pas de destination. Chaque règle attachée à un bus voit chaque événement qui arrive, décide seule si elle correspond, et livre à ses propres targets. Ajouter une règle ajoute un consommateur sans toucher à ce qui tourne déjà, et c'est ce que « faiblement couplé » veut dire concrètement ici. Vous allez maintenant voir Pipes, qui traite le cas où un bus est le mauvais outil : un flux précis dont les enregistrements doivent être filtrés, enrichis par une recherche, et remis à exactement une destination.