本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# Amazon EventBridge 事件模式的最佳實務
<a name="eb-patterns-best-practices"></a>

以下是在事件匯流排規則中定義事件模式時應考慮的一些最佳實務。

## 避免編寫無限循環
<a name="eb-patterns-best-practices-loops"></a>

在 EventBridge 中，您可以建立規則，該規則會導致無限循環，並且規則會在循環中重複觸發。例如，規則可能會偵測到已在 S3 儲存貯體上變更 ACL，並觸發軟體來將它們變更為所需的狀態。如果未謹慎寫入規則，後續對 ACL 的變更會再次觸發規則，建立無限循環。

為了避免這些問題，請盡可能精確地編寫規則的事件模式，以便它們僅匹配您實際想要傳送至目標的事件。在上述範例中，您會建立事件模式來比對事件，以便觸發的動作不會重新觸發相同的規則。例如，在規則中建立一個事件模式，該模式僅會在 ACL 處於錯誤狀態時才符合事件，而不是在任何變更之後。如需詳細資訊，請參閱 [使事件模式盡可能精確](#eb-patterns-best-practices-precision) 及 [將事件模式的範圍設定為考量事件來源更新](#eb-patterns-best-practices-future-proof)。

無限循環可能會快速引發較預期還高的費用。這也可能導致限流和延遲事件交付。您可以監控調用率的上限，以便在數量意外峰值時發出警告。

使用預算編列在費用超過您指定的限制時提醒您。如需詳細資訊，請參閱[在符合預算的情形下管理成本](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html)。

## 使事件模式盡可能精確
<a name="eb-patterns-best-practices-precision"></a>

您的事件模式越精確，它就越有可能僅與您實際想要的事件相符，並且在將新事件新增至事件來源或更新現有事件以包含新屬性時避免意外相符。

事件模式可以包含符合下列項目的篩選條件：
+ 有關事件的事件中繼資料，例如 `source`、`detail-type`、`account` 或 `region`。
+ 事件資料，這是 `detail` 對象內的字段。
+ 事件内容，或者 `detail` 物件內欄位的實際值。

大多數模式都很簡單，例如僅指定 `source` 和 `detail-type` 篩選條件。不過，EventBridge 模式包含篩選任何索引鍵或事件值的彈性。此外，您可以套用內容篩選條件，例如 `prefix` 和 `suffix` 篩選條件，以改善模式的精確度。如需詳細資訊，請參閱 [在 Amazon EventBridge 事件模式中使用比較運算子](eb-create-pattern.md#eb-event-patterns-content-based-filtering)。

### 將事件來源和詳細資料類型指定為篩選條件
<a name="eb-patterns-best-practices-source"></a>

您可以使用 `source` 和 `detail-type` 中繼資料欄位讓事件模式更精確，以減少產生無限迴圈和比對不需要的事件。

當您需要符合兩個或多個字段中的特定值時，請使用 `$or` 比較運算子，而不是在單個值陣列中列出所有可能的值。

對於透過 交付的事件 AWS CloudTrail，我們建議您使用 `eventName` 欄位做為篩選條件。

下列事件模式範例符合 `SetQueueAttributes` `CreateQueue`Amazon Simple Queue Service 服務中的 或 ，或 AWS Key Management Service 服務中的 `CreateKey`或 `DisableKeyRotation`事件。

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

### 將帳戶和區域指定為篩選條件
<a name="eb-patterns-best-practices-accounts-regions"></a>

在您的事件模式中包含 `account` 和 `region` 欄位，有助於限制跨帳戶或跨區域事件比對。

### 指定內容篩選條件
<a name="eb-patterns-best-practices-content"></a>

基於內容的篩選可以幫助改善事件模式的精確度，同時仍將事件模式的長度保持在最小。例如，根據數值範圍進行比對可能會很有幫助，而不是列出所有可能的數值。

如需詳細資訊，請參閱 [在 Amazon EventBridge 事件模式中使用比較運算子](eb-create-pattern.md#eb-event-patterns-content-based-filtering)。

## 將事件模式的範圍設定為考量事件來源更新
<a name="eb-patterns-best-practices-future-proof"></a>

建立事件模式時，您應該考慮事件結構描述和事件網域可能會隨著時間的推移而發展和擴展。同樣地，讓您的事件模式盡可能精確地協助您在事件來源變更或擴充時限制非預期的相符項目。

例如，假設您要比對來自發佈付款相關事件的新微型服務的事件。起始時，服務會使用網域 `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": "{{AWS-Region}}",
  "detail-type": "Payment accepted"
}
```

## 驗證事件模式
<a name="eb-patterns-best-practices-validate"></a>

為了確保規則符合所需的事件，我們強烈建議您驗證您的事件模式。您可以使用 EventBridge 控制台或 API 驗證您的事件模式：
+ 在 EventBridge 主控台中，您可以透過[作爲建立規則的一部分](eb-create-rule-visual.md)來建立和測試事件模式，或者透過[使用沙盒](eb-event-pattern-sandbox.md)單獨建立和測試事件模式。
+ 您可以使用 [test-event-pattern](https://docs.aws.amazon.com/cli/latest/reference/events/test-event-pattern.html) 命令 AWS CLI 在 中測試事件模式。