When a client says "I want things to happen when a file lands on S3", the easy answer is "drop a Lambda trigger". Works. But when files come from 4 sources and must be routed 6 ways, you end up with 24 triggers and zero observability. EventBridge is the better road.
The pattern
- S3 emits
ObjectCreatedevents to EventBridge (just enable it on the bucket). - EventBridge filters by pattern (e.g.
$.detail.object.key suffix .csv) and routes to the right target. - Targets can be Lambda, Step Functions, SQS, EventBridge Pipes (for enrichment), or third-party services via API Destinations.
What it gives over S3 → Lambda direct
- Declarative filtering: pattern matching, no code.
- Multi-target: the same event can trigger 5 things simultaneously.
- Replay: events can be replayed during debug.
- Per-rule DLQ: one dead letter queue covers the pipeline.
When S3 → Lambda direct still wins
- Single, simple handler.
- Minimum latency (S3 → Lambda is ~100-300ms; EventBridge adds ~150ms).
- Marginal cost on tiny volumes (EventBridge bills per event, S3 → Lambda is free).
Operational lesson
Build rules as code (Terraform, CDK, Pulumi). Rules created from the console get forgotten, and nobody knows what triggers what. On one client with 38 rules we spent two days reverse-engineering.