Test EventBridge Rules with the Event Sandbox (2026)

The EventBridge Event Sandbox lets you test EventBridge rules without actually triggering them, and the most surprising thing is how it uses a copy of your event bus to achieve this isolation.

Let’s see it in action. Imagine you’ve got a rule set up to trigger a Lambda function when a specific source and detail-type combination appears on your default event bus.

{
  "source": "my.application",
  "detail-type": "UserLoggedIn",
  "detail": {
    "userId": "user-123",
    "timestamp": "2023-10-27T10:00:00Z"
  }
}

This rule looks like this:

{
  "Name": "LogUserLoginRule",
  "EventBusName": "default",
  "Description": "Logs user login events",
  "State": "ENABLED",
  "EventPattern": "{\"source\": [\"my.application\"], \"detail-type\": [\"UserLoggedIn\"]}"
}

Normally, to test this, you’d have to actually send a UserLoggedIn event to your default bus. This might trigger downstream resources you don’t want to hit during testing, like sending emails or updating production databases.

The Event Sandbox changes this. When you create a sandbox, EventBridge creates a temporary, isolated copy of your chosen event bus. Any events you send to the sandbox are processed only by the rules within that sandbox’s copy of the bus. The original bus and its targets remain untouched.

Here’s how you set it up:

Create a Sandbox: You do this via the AWS CLI or the console. Let’s use the CLI. You specify the event bus you want to sandbox.
```
aws events create-event-sandbox \
    --name MyTestSandbox \
    --event-bus-name default \
    --description "Sandbox for testing user login rules"
```
This command returns a SandboxArn. Keep this handy.

Send Test Events to the Sandbox: Instead of sending events to your default bus ARN, you send them to the SandboxArn you just received.

aws events put-events \
    --entries '[
      {
        "Source": "my.application",
        "DetailType": "UserLoggedIn",
        "Detail": "{\"userId\": \"user-123\", \"timestamp\": \"2023-10-27T10:00:00Z\"}",
        "EventBusName": "arn:aws:events:us-east-1:123456789012:eventbus/sandbox/MyTestSandbox-abcdef1234567890"
      }
    ]'

Notice how EventBusName is now the ARN of your sandbox.

Verify Rule Matching (and Target Inaction): When you send this event to the sandbox, your LogUserLoginRule (which is automatically copied into the sandbox) will match the event. However, because it’s a sandbox, the Lambda function target associated with that rule will not be invoked. You can’t actually see the event in the sandbox itself, but you can infer it matched if you try to send an event that shouldn’t match and it doesn’t trigger any (non-existent) rule. The real power comes from not triggering things.

The Event Sandbox is essentially a "read-only" mirror of your event bus’s rule processing logic. It doesn’t give you visibility into the sandbox’s event stream or its internal processing; its sole purpose is to let you test rule matching without side effects. When you’re done, you simply delete the sandbox.

aws events delete-event-sandbox \
    --sandbox-name MyTestSandbox \
    --event-bus-name default

What most people don’t realize is that the sandbox doesn’t copy your event bus’s targets. It only copies the rules and their patterns. When an event matches a rule in the sandbox, the rule’s targets are ignored. This isolation is key; it prevents any accidental execution of your production infrastructure during testing.

The next step after mastering event rule testing is understanding how to manage event patterns for complex filtering scenarios.