Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Bonnes pratiques relatives aux modèles EventBridge d'événements Amazon

Vous trouverez ci-dessous quelques bonnes pratiques à prendre en compte lors de la définition de modèles d’événements dans les règles de votre bus d’événements.

Évitez d’écrire des boucles infinies

Dans EventBridge, il est possible de créer des règles qui mènent à des boucles infinies, où une règle est déclenchée à plusieurs reprises. Par exemple, une règle peut détecter les modifications ACLs apportées à un compartiment S3 et déclencher le logiciel pour qu'il les modifie à l'état souhaité. Si la règle n'est pas écrite avec soin, la modification suivante la ACLs déclenche à nouveau, créant ainsi une boucle infinie.

Pour éviter ces problèmes, écrivez les modèles d’événements de vos règles aussi précisément que possible, afin qu’ils correspondent uniquement aux événements que vous souhaitez réellement envoyer à la cible. Dans l’exemple ci-dessus, vous créez un modèle d’événement pour mettre en correspondance des événements afin que les actions déclenchées ne déclenchent pas à nouveau la même règle. Par exemple, créez un modèle d'événement dans votre règle qui correspondrait aux événements uniquement s'ACLsils s'avèrent être en mauvais état, plutôt qu'après une modification. Pour plus d’informations, consultez Faites en sorte que les modèles d’événements soient aussi précis que possible et Définissez la portée de vos modèles d’événements pour prendre en compte les mises à jour de la source d’événement.

Une boucle infinie peut rapidement entraîner des coûts plus importants que prévu. Elle peut également entraîner des limitations et un retard dans la livraison des événements. Vous pouvez surveiller la limite supérieure de vos taux d’invocation pour être averti de pics de volume inattendus.

Utilisez les budgets pour vous avertir lorsque les frais dépassent votre limite spécifiée. Pour plus d'informations, consultez Gestion des coûts avec les budgets.

Faites en sorte que les modèles d’événements soient aussi précis que possible

Plus votre modèle d’événement est précis, plus il est probable qu’il corresponde uniquement aux événements auxquels vous souhaitez réellement qu’il corresponde. De plus, vous évitez les correspondances inattendues lorsque de nouveaux événements sont ajoutés à une source d’événement ou que des événements existants sont mis à jour pour inclure de nouvelles propriétés.

Les modèles d’événements peuvent inclure des filtres qui mettent en correspondance les éléments suivants :

La plupart des modèles sont simples, tels que la spécification des filtres source et detail-type uniquement. Cependant, EventBridge les modèles incluent la possibilité de filtrer sur n'importe quelle clé ou valeur de l'événement. En outre, vous pouvez appliquer des filtres de contenu tels que prefix et suffix pour améliorer la précision de vos modèles. Pour plus d’informations, consultez Utilisation d'opérateurs de comparaison dans les modèles EventBridge d'événements Amazon.

Spécifiez la source de l’événement et le type de détail sous forme de filtres

Vous pouvez réduire la génération de boucles infinies et la mise en correspondance d’événements indésirables en rendant vos modèles d’événements plus précis à l’aide des champs de métadonnées source et detail-type.

Lorsque vous devez mettre en correspondance des valeurs spécifiques dans deux champs ou plus, utilisez l’opérateur de comparaison $or, plutôt que de répertorier toutes les valeurs possibles dans un seul tableau de valeurs.

Pour les événements diffusés via AWS CloudTrail, nous vous recommandons d'utiliser le eventName champ comme filtre.

L'exemple de modèle d'événement suivant correspond CreateQueue ou SetQueueAttributes provient du service Amazon Simple Queue Service, CreateKey ou à DisableKeyRotation des événements du AWS Key Management Service service.

{
  "detail-type": ["AWS API Call via CloudTrail"],
  "$or": [{
      "source": [
        "aws.sqs"
        ],
      "detail": {
        "eventName": [
          "CreateQueue",
          "SetQueueAttributes"
        ]
      }
    },
    {
      "source": [
        "aws.kms"
        ],
      "detail": {
        "eventName": [
          "CreateKey",
          "DisableKeyRotation"
        ]
      }
    }
  ]
}

Spécifiez le compte et la région sous forme de filtres

L’inclusion des champs account et region dans votre modèle d’événement permet de limiter la mise en correspondance des événements entre comptes ou entre régions.

Spécifiez des filtres de contenu

Le filtrage basé sur le contenu peut contribuer à améliorer la précision des modèles d’événements, tout en maintenant leur longueur au minimum. Par exemple, la mise en correspondance basée sur une plage numérique peut être utile au lieu de répertorier toutes les valeurs numériques possibles.

Pour plus d’informations, consultez Utilisation d'opérateurs de comparaison dans les modèles EventBridge d'événements Amazon.

Définissez la portée de vos modèles d’événements pour prendre en compte les mises à jour de la source d’événement

Lorsque vous créez des modèles d’événements, vous devez tenir compte du fait que les schémas d’événements et les domaines d’événements peuvent évoluer et s’étendre au fil du temps. Là encore, le fait de rendre vos modèles d’événements aussi précis que possible contribue à limiter les correspondances inattendues en cas de modification ou d’extension de la source d’événement.

Supposons, par exemple, que vous compariez des événements provenant d’un nouveau microservice qui publie des événements liés au paiement. Dans un premier temps, le service utilise le domaine acme.payments et publie un seul événement, Payment accepted :

{
  "detail-type": "Payment accepted",
  "source": "acme.payments",
  "detail": {
    "type": "credit",
    "amount": "100",
    "date": "2023-06-10",
    "currency": "USD"
    }
  }
}

À ce stade, vous pouvez créer un modèle d’événement simple qui correspond aux événements Payment accepted :

{ “source” : “acme.payments” }

Supposons toutefois que le service introduise ultérieurement un nouvel événement pour les paiements rejetés :

{
  "detail-type": "Payment rejected",
  "source": "acme.payments",
  "detail": {
  }
}

Dans ce cas, le modèle d’événement simple que vous avez créé correspondra désormais à la fois aux événements Payment accepted et Payment rejected. EventBridge achemine les deux types d'événements vers la cible spécifiée pour traitement, ce qui peut entraîner des échecs de traitement et des coûts de traitement supplémentaires.

Pour définir la portée de votre modèle d’événements sur les événements Payment accepted uniquement, vous devez spécifier au moins source et detail-type :

{
  "detail-type": "Payment accepted",
  "source": "acme.payments"
  }
}

Vous pouvez également spécifier le compte et la région dans votre modèle d’événement, afin de limiter davantage les cas où les événements entre comptes ou entre régions correspondent à cette règle.

{
  "account": "012345678910",
  "source": "acme.payments",
  "region": "AWS-Region",
  "detail-type": "Payment accepted"
}

Validez les modèles d’événements

Pour garantir que les règles correspondent aux événements souhaités, nous vous recommandons vivement de valider vos modèles d’événements. Vous pouvez valider vos modèles d'événements à l'aide de la EventBridge console ou API :