定义 Amazon EventBridge 事件模式时的最佳实践 - Amazon EventBridge
避免编写无限循环使事件模式尽可能精确确定事件模式的范围，将事件源更新纳入考虑范围验证事件模式
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

定义 Amazon EventBridge 事件模式时的最佳实践

以下是在事件总线规则中定义事件模式时需要考虑的一些最佳实践。

避免编写无限循环

在中 EventBridge，可以创建导致无限循环的规则，即重复触发规则。例如，某规则可能检测到 S3 存储桶上的 ACL 已更改，然后触发软件以将 ACL 更改为所需状态。如果编写该规则时不小心，则 ACL 的后续更改将再次触发该规则，从而产生无限循环。

为了防止出现这些问题，请为规则编写尽可能精确的事件模式，这样它们就只会匹配您实际希望发送到目标的事件。在上面的示例中，您将创建一个事件模式来匹配事件，使触发的操作就不会重新触发相同的规则。例如，在规则中创建一个事件模式，仅在发现 ACL 处于不良状态时才匹配事件，而不是在任何更改之后都匹配事件。有关更多信息，请参阅 使事件模式尽可能精确 和 确定事件模式的范围，将事件源更新纳入考虑范围。

无限循环可能快速导致费用超出预期。它还可能导致节流和事件传送延迟。您可以监控调用速率的上限，在数量出现意外激增时收到警告。

使用预算，在费用超出指定限额时提醒您。有关更多信息，请参阅通过预算管理成本。

使事件模式尽可能精确

您的事件模式越精确，就越有可能只匹配您真正想要匹配的事件，并且在向事件源添加新事件，或更新现有事件以包含新属性时，避免意外匹配。

事件模式可以包括筛选器，匹配以下内容：

  • 有关该事件的事件元数据，例如 source、detail-type、account 或region。

  • 事件数据，即 detail 对象内的字段。

  • 事件内容，或 detail 对象内字段的实际值。

大多数模式都很简单，例如仅指定 source 和 detail-type 筛选器。但是， EventBridge 模式包括可以灵活地根据事件的任何键或值进行筛选。此外，您可以应用内容筛选器（例如 prefix 和 suffix 筛选器）来提高模式的精度。有关更多信息，请参阅 在 Amazon EventBridge 事件模式中筛选内容。

将事件源和详细信息类型指定为筛选器

使用 source 和 detail-type 元数据字段使事件模式更加精确，可以减少生成无限循环和匹配不想要的事件的概率。

如果需要匹配两个或更多字段中的特定值，请使用 $or 比较运算符，而不是在单个值数组中列出所有可能的值。

对于通过传送的事件 Amazon CloudTrail，我们建议您使用该eventName字段作为筛选条件。

以下事件模式示例匹配CreateQueue或SetQueueAttributes来自亚马逊简单队列服务CreateKey或来自该 Amazon Key Management Service 服务DisableKeyRotation的事件。

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

指定账户和区域作为筛选条件

在事件模式中包含 account 和 region 字段，有助于限制跨账户或跨区域的事件匹配。

指定内容筛选器

基于内容的筛选有助于提高事件模式的精度，同时仍将事件模式的长度保持最短。例如，与列出所有可能的数值相比，基于数值范围进行匹配可能更加合适。

有关更多信息，请参阅 在 Amazon EventBridge 事件模式中筛选内容。

确定事件模式的范围，将事件源更新纳入考虑范围

创建事件模式时，应考虑到事件架构和事件域可能会随着时间的推移而演变和扩展。再次重申，尽可能精确地设置事件模式，可以帮助您在事件源发生变化或扩展时限制意外匹配。

例如，假设您要与来自新的微服务的事件进行匹配，该服务发布与支付相关的事件。最初，该服务使用域 acme.payments，并发布单个事件 Payment accepted：

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

此时，您可以创建与已接受付款的事件相匹配的简单事件模式：

{ “source” : “acme.payments” }

但是，假设该服务稍后引入了一个针对拒绝付款的新事件：

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

在这种情况下，您创建的简单事件模式现在与 Payment accepted 和 Payment rejected 事件均可匹配。 EventBridge 将两种类型的事件路由到指定的目标进行处理，这可能会导致处理失败和额外的处理成本。

要将事件模式的范围仅限定于 Payment accepted 事件，您需要至少同时指定 source 和 detail-type：

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

您还可以在事件模式中指定账户和区域，进一步限制跨账户或跨区域事件何时匹配此规则。

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

验证事件模式

为确保规则与所需事件相匹配，我们强烈建议您验证您的事件模式。您可以使用 EventBridge 控制台或 API 验证您的事件模式：