Introduction
Hi, I'm miruky.
An Amazon EventBridge rule can be syntactically valid and still match the wrong events. The EventBridge Sandbox gives me a smaller feedback loop: I can test an event pattern against a sample event without creating or editing a rule.
This run uses one unchanged pattern against an intended sample, a one-field counterexample, and the restored sample. I do not publish the sample event or use the optional rule-creation path, so the exercise creates no rule, target, or event bus.
1. Open the EventBridge Sandbox
Use the English AWS Console in us-east-1 for all three Sandbox tests.
The header confirms United States (N. Virginia) while the EventBridge Console is in English. This fixes the Regional context for every Sandbox test.
Open Amazon EventBridge. In the navigation pane, expand Developer resources, choose Sandbox, and then choose the Event pattern tab. The page shows Sandbox with the Event pattern tab selected. No rule-creation wizard or target configuration is open.
The Sandbox evaluates the sample against the pattern and reports whether they match. This workflow does not publish the sample to an event bus or configure a target, which keeps the test separate from a deployed event flow.
2. Enter a matching sample event
Use this fixed sample event:
{
"version": "0",
"id": "example-event-id",
"detail-type": "OrderCreated",
"source": "demo.orders",
"account": "example-account",
"time": "2026-01-01T00:00:00Z",
"region": "us-east-1",
"resources": [],
"detail": {
"status": "ready",
"total": 125,
"orderRef": "order-blue"
}
}
The TestEventPattern request requires id, account, source, time, region, resources, and detail-type, so the sample keeps all seven fields. The account and ID strings are deliberate non-account placeholders: they are not copied from the signed-in account, and the pattern below does not inspect either field.
Under Sample event type, choose Enter my own, then replace the editor contents with the fixed event. In this run, the current Console changed Event source from AWS events or EventBridge partner events to Other when I selected the custom sample. The page shows Other and Enter my own selected, and the editor contains ready, total 125, example-account, and example-event-id. Every value is synthetic and independent of the signed-in account.
3. Add a precise custom pattern
For Creation method, choose Custom pattern (JSON editor). Enter this event pattern:
{
"source": ["demo.orders"],
"detail-type": ["OrderCreated"],
"detail": {
"status": ["ready"],
"total": [{ "numeric": [">=", 100] }]
}
}
The event-pattern contract requires the same field names and nesting as the event. EventBridge ignores fields that the pattern does not mention, so orderRef can remain in the event without appearing in the pattern.
The pattern editor shows demo.orders, OrderCreated, ready, comparison operator >=, and threshold 100. The unmentioned orderRef field remains outside the matching criteria.
Choose Test pattern. The result should state that the sample event matches the event pattern.
The result states that the sample event matches the event pattern. This is the positive baseline for the unchanged pattern.
This positive result proves the source, type, nested status, and numeric comparison agree for this sample. It does not prove that every future event is shaped the same way, so production samples still need contract tests at their publisher boundary.
The Sandbox pattern is deliberately limited to this payload decision. A deployed rule may also need explicit account and region conditions to fit its event-bus trust boundary.
4. Change one field and prove the rejection
In the sample event, change only the nested status from ready to pending. Leave the source, detail type, total, and all other fields unchanged.
{
"version": "0",
"id": "example-event-id",
"detail-type": "OrderCreated",
"source": "demo.orders",
"account": "example-account",
"time": "2026-01-01T00:00:00Z",
"region": "us-east-1",
"resources": [],
"detail": {
"status": "pending",
"total": 125,
"orderRef": "order-blue"
}
}
The edited sample shows pending while the source, detail type, total, and order reference remain unchanged. Only the status condition is placed outside the pattern.
Run the unchanged pattern against this counterexample.
The result states that the sample event does not match the event pattern. The unchanged numeric condition still passes, and pending is outside the pattern's status array, isolating the rejection to status.
Restore status to ready and run the test once more. The result should return to a match without changing the pattern.
The restored sample again matches the same event pattern. No rule or target is created after this final check.
The last check protects against accidentally editing both sides of the test. One unchanged pattern accepted the intended sample, rejected the single-field variant, and accepted the restored sample.
Wrap-up
The EventBridge Sandbox produced a useful three-point result without a deployed rule: match, reject, then match again. The negative sample mattered as much as the positive one because it showed that the nested status condition was actually controlling the outcome.
Before creating a rule, I now test at least one expected event and one nearby event that must not match. That small habit catches misspelled field names, incorrect nesting, and patterns that are broader than their design suggests.
Thanks for reading this far.
See you in the next one.
Disclosure: This article was written with AI assistance and independently verified against the linked primary sources and observed results.
Top comments (0)