翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# Amazon EventBridge のイベントパターンのベストプラクティス
<a name="eb-patterns-best-practices"></a>

イベントバスルールでイベントパターンを定義する際に考慮すべきいくつかのベストプラクティスを以下に示します。

## 無限ループを記述することは避ける
<a name="eb-patterns-best-practices-loops"></a>

EventBridge では、ルールが繰り返し開始される無限ループにつながるルールが作成される可能性があります。たとえば、S3 バケットで ACL が変更されたことを検出し、ソフトウェアをトリガーして 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` メタデータフィールドを使用してイベントパターンをより正確にすることで、無限ループの生成や望ましくないイベントの一致を減らすことができます。

2 つ以上のフィールド内の特定の値を一致させる必要がある場合は、値の 1 つの配列に考えられるすべての値を一覧表示するのではなく、`$or` 比較演算子を使用してください。

経由で配信されるイベントの場合は AWS CloudTrail、 `eventName`フィールドをフィルターとして使用することをお勧めします。

次のイベントパターンの例では、Amazon Simple Queue Service サービス`SetQueueAttributes`からの `CreateQueue`または 、`CreateKey`または AWS 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"
        ]
      }
    }
  ]
}
```

### アカウントと地域をフィルターとして指定する
<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` を使用し、1 つのイベント `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[test-event-pattern](https://docs.aws.amazon.com/cli/latest/reference/events/test-event-pattern.html) コマンド AWS CLI を使用して、 でイベントパターンをテストできます。