What do EventBridge archives and replay give you, and what would you be careful about before replaying events into a production bus?

## What an archive is By default an event bus is amnesiac. An event arrives, rules evaluate it, targets are invoked, and nothing remains. That is fine until a consumer has a bug, and then the events it mishandled are simply gone. An **archive** fixes that. You create it on a specific bus with: - an optional **event pattern**, using exactly the same syntax as a rule, so you can archive only what matters rather than every event on the bus; - a **retention period** in days, or zero for indefinite retention. From that moment, matching events are stored as they arrive. Archiving is passive: it does not intercept, delay or divert anything, and rules fire exactly as they would without it. The single most important property is that an archive is **not retroactive**. It captures nothing that arrived before it existed. This is why archives belong in the initial setup of any bus that carries business-meaningful events — by the time you want history, it is too late to start. ## What replay does `StartReplay` takes a named replay, the archive to read from, an `EventStartTime` and `EventEndTime` bounding the window, and a destination consisting of the event bus plus an optional list of rule ARNs to restrict delivery to. EventBridge then re-publishes the archived events in that window, and the destination's rules evaluate them like any other event. The uses are exactly what you would expect: - **Recovery.** A consumer was down or buggy between 02:00 and 04:00; fix it, replay that window to just that consumer's rule. - **Backfill.** A new service joins the system and needs the last month of events to build its state. - **Debugging with real traffic.** Point a replay at a rule whose target is a test consumer and watch it handle production-shaped events. Several constraints shape how you use it. Events are replayed to the **same bus** the archive was made from, so the rule filter is how you control who sees them. **Ordering is not guaranteed**, so a consumer that assumes chronological arrival will misbehave on a replay even if it looked fine live. Replayed events carry a **`replay-name`** field identifying the replay, which is the hook consumers use to branch — for example, to skip sending customer-facing notifications. And a replay's progress is visible as a state you poll; it is not instantaneous for a large window. ## The care that matters before replaying into production This is the part interviewers push on, because a careless replay is a self-inflicted incident. 1. **Everything not excluded will fire.** Unless you pass the rule filter, every rule on the destination bus reprocesses those events. If one of them sends email, charges a card, or posts to a partner API, you have just done it all again. The default posture should be to name the rules explicitly. 2. **Idempotency is your only real protection.** Target delivery is already at-least-once, so consumers should be idempotent anyway — but replay converts "rare duplicate" into "thousands of duplicates in minutes", which is where weak deduplication breaks (an in-memory cache, a TTL shorter than the replay window). 3. **Downstream load.** A two-hour window replays as fast as EventBridge can push it. Third-party APIs get rate-limited, a database gets a write spike, a Lambda hits its concurrency ceiling. Consider replaying a narrow window first and watching. 4. **Stale side effects.** Some events are only meaningful when fresh. Replaying a week-old "price changed" event into a rule that pushes a notification is worse than doing nothing. 5. **Nothing scheduled comes back.** Replay reproduces archived bus events, not schedule-driven invocations that never existed as archived events. A safe default pattern is: consumers check for `replay-name` and suppress externally visible side effects when it is present, while still updating internal state. That single convention makes replay a routine operation rather than a change-managed event. ## Cost and retention judgment Archives are charged on storage and replay is charged per event processed, so infinite retention of a chatty bus is a real bill. The useful discipline is to scope the archive's pattern to the events you would actually replay — the domain events with business meaning — and set retention to the window in which replaying is still plausible, which for most systems is weeks, not years. Long-term analytical history is a data-lake problem, not an archive one.