Write EventBridge Event Patterns: Exact, Prefix, and Anything-But (2026)

EventBridge event patterns are how you filter events from event sources to send to targets. You can match events based on exact values, prefixes, or exclude specific values.

Let’s see this in action. Imagine you’re running a fleet of EC2 instances and want to react to specific instance state changes.

Here’s a sample EC2 instance state change event you might receive:

{
  "version": "0",
  "id": "a1b2c3d4-e5f6-7890-1234-abcdef123456",
  "detail-type": "EC2 Instance State-change Notification",
  "source": "aws.ec2",
  "account": "123456789012",
  "time": "2023-10-27T10:00:00Z",
  "region": "us-east-1",
  "resources": [
    "arn:aws:ec2:us-east-1:123456789012:instance/i-0abcdef1234567890"
  ],
  "detail": {
    "instance-id": "i-0abcdef1234567890",
    "state": "running"
  }
}

Now, let’s build an event pattern to catch only instances that start running.

Exact Matching

The simplest way to match is with an exact value. If you want to trigger an action only when an instance state changes to "running", you’d use this pattern:

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

This pattern will match the example event above because the state field in the detail object is exactly "running". If the state was "stopped" or "terminated", this pattern would not match.

Prefix Matching

Sometimes, you want to match values that start with a specific string. For example, you might want to react to any instance state change that involves a new instance being launched. The state field doesn’t have common prefixes for this, but consider a scenario where you have instance IDs with a specific naming convention, say i-prod-..... If you wanted to match any instance ID that starts with i-prod-, you could use a prefix match.

Let’s imagine a different event structure, where instance-id is directly in the top-level detail:

{
  "version": "0",
  "id": "...",
  "detail-type": "EC2 Instance State-change Notification",
  "source": "aws.ec2",
  "detail": {
    "instance-id": "i-0abcdef1234567890",
    "state": "running"
  }
}

To match instance IDs starting with i-prod-:

{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Instance State-change Notification"],
  "detail": {
    "instance-id": [{"prefix": "i-prod-"}]
  }
}

This pattern would match an instance ID like i-prod-abcdef1234567890 but not i-dev-abcdef1234567890. The prefix operator is useful when dealing with ARN values or IDs that follow a predictable structure.

Anything-But Matching

What if you want to react to most instance state changes, but exclude a few specific ones? This is where anything-but comes in. For instance, you might want to know when an instance is starting, stopping, or has been terminated, but you don’t care about simple running or stopped states that might be part of a normal lifecycle.

Let’s say you want to trigger an alert for any instance state change except when it transitions to "running":

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

This pattern will match events where the state is "stopped", "pending", "terminated", or any other valid state except "running". You can also provide multiple values within anything-but to exclude more states, like {"anything-but": ["running", "stopped"]}.

Combining Operators

You can combine these operators. For example, to match all aws.ec2 instance state changes for instances with IDs starting with i-prod-, but only when the state is not "running":

{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Instance State-change Notification"],
  "detail": {
    "instance-id": [{"prefix": "i-prod-"}],
    "state": [{"anything-but": ["running"]}]
  }
}

This demonstrates the power of EventBridge event patterns to create highly specific filters, ensuring your targets only receive the events they absolutely need to process. The system then routes events that match all specified conditions in the pattern to your configured target, like an SQS queue or a Lambda function.

The next challenge is often managing multiple, complex event patterns for different services and ensuring they don’t overlap unintentionally, leading to duplicate processing or missed events.