Before understanding rules, you need to understand what an event actually looks like. Every EventBridge event is a JSON object with a standardized envelope and a custom payload.
The Event Envelope
{
"version": "0",
"id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"source": "com.mycompany.orders",
"account": "123456789012",
"time": "2024-01-15T10:30:00Z",
"region": "us-east-1",
"resources": [],
"detail-type": "OrderPlaced",
"detail": {
"orderId": "ORD-999",
"customerId": "CUST-42",
"total": 149.99,
"currency": "USD",
"items": [
{ "sku": "WIDGET-A", "quantity": 2, "price": 49.99 },
{ "sku": "GADGET-B", "quantity": 1, "price": 50.01 }
],
"shippingAddress": {
"country": "US",
"state": "CA"
}
}
}
The top-level fields (version, id, source, account, time, region) are the envelope — metadata added by EventBridge. The detail object is your payload — the custom data your application provides.
Key fields to understand:
source: A string identifying the application or service that produced the event. By convention, use reverse-DNS notation:com.mycompany.orders. This is what you filter on in rules.detail-type: A human-readable string describing what happened:OrderPlaced,PaymentFailed,UserDeactivated. Think of it as the event's subject line.detail: The actual event data. This is a free-form JSON object — you define its structure.
Key Point: The source and detail-type fields together form the event's identity. A well-designed event naming convention (source = which system, detail-type = what happened) makes rules readable and maintainable at scale. Avoid generic names like source: "myapp" and detail-type: "event" — they force consumers to inspect the detail payload just to understand what happened, which defeats the purpose of the envelope.