Event replay cost: what it costs to run history again
Archiving events is cheap. Replaying them runs your entire downstream pipeline a second time at full price. Here is what archives, retention, and a replay actually cost.
Quick answer
Storing events is inexpensive: EventBridge archives cost $0.10 per GB-month, Kinesis extended retention costs $0.023 per shard-hour beyond 24 hours, and S3 event logs cost $0.023 per GB-month. Replaying is where the money goes, because the replay re-triggers every downstream consumer at full price. Replaying 50 million archived events into a pipeline of 3 consumers running 200 ms at 512 MB costs about $30 in invocations and $250 in duration, plus every downstream write those consumers perform. A replay is a full re-run of your architecture, so budget it as one rather than as a storage operation.
Event replay is one of the best properties of an event-driven system: if a consumer had a bug, fix it and run the history again. Teams adopt it enthusiastically because the storage is cheap. The surprise arrives when someone replays a month of events and discovers the replay cost more than the original month of processing, because the original month was spread out and the replay happened in an hour with full concurrency.
What retention costs
| Store | Rate | 50 GB for 30 days |
|---|---|---|
| EventBridge archive | $0.10 per GB-month | $5.00 |
| S3 Standard event log | $0.023 per GB-month | $1.15 |
| S3 Glacier Instant Retrieval | $0.004 per GB-month | $0.20 |
| Kinesis extended retention | $0.023 per shard-hour | $16.56 per shard |
| Kinesis long-term retention (past 7 days) | $0.023 per GB-month | $1.15 |
| SQS (max 14 days) | No storage charge | $0 |
For most workloads, keeping a replayable history is a few dollars a month. An S3-based event log written by a Firehose or a simple archiving consumer is the cheapest option and gives you arbitrary retention plus the ability to query with Athena. EventBridge archives are more convenient because replay is a built-in operation, and they cost about four times S3 Standard for the same volume.
What a replay costs
Replaying 50 million events into a pipeline where 3 consumers each run 200 ms at 512 MB.
| Line | Volume | Cost |
|---|---|---|
| Replayed event deliveries | 150 million | $150.00 at $1.00 per million |
| Lambda invocations | 150 million | $30.00 |
| Lambda duration | 15 million GB-s | $250.00 |
| DynamoDB writes, 2 per event | 300 million | $375.00 |
| CloudWatch Logs, 1 KB per invocation | 150 GB | $75.00 |
| Total | $880.00 |
Against $5 of archive storage. The ratio is roughly 175 to 1, and that is for a simple three-consumer pipeline. A replay is not a storage operation; it is a full re-run of your architecture at maximum concurrency.
The secondary effects
Replays run fast, which means they run concurrently. A replay that pushes 150 million invocations through in two hours needs roughly 4,200 concurrent executions to sustain it, which will hit account concurrency limits, throttle, and generate retries. It will also hammer every downstream dependency. A DynamoDB table on provisioned capacity sized for normal traffic will throttle hard, and the retries from that throttling add their own cost. A third-party API with rate limits will reject most of the calls, meaning you pay for the attempts and get nothing.
Replays also duplicate side effects unless consumers are idempotent. Replaying order events through a consumer that sends confirmation emails sends every customer their confirmation again. The financial cost of that is small; the trust cost is not.
Budgeting the capability, not just the event
Replay capability has a standing cost beyond storage. Keeping a full event log means paying the archiving path: a Firehose delivery stream to S3 charges $0.029 per GB for the first 500 TB a month, so archiving 50 GB costs about $1.45 in ingestion on top of storage. An archiving consumer built from a function instead charges invocation and duration for every event it stores, which on 50 million events at 128 MB and 50 ms is about $15 a month. Neither is expensive, but both scale with event volume, so a system publishing billions of events should archive by batching to S3 rather than per event, and should apply a lifecycle policy that moves older partitions to cheaper storage classes.
Replaying cheaply
Filter the replay. Both EventBridge archives and an S3-based log support replaying a time range, and EventBridge lets you target specific rules. Replaying only the consumer that had the bug removes two thirds of the cost in the example above. Narrow the time window to the period actually affected rather than replaying everything since the beginning.
Throttle the replay. Set reserved concurrency on the replay consumer so it processes at a rate your dependencies can absorb, which trades wall-clock time for avoiding throttle-and-retry waste. Switch DynamoDB to on-demand for the duration of a large replay if the table is provisioned, since the capacity mode can be changed once per 24 hours.
And consider whether you need a replay at all. For backfilling derived data, a single batch job reading the S3 event log and writing results in bulk is far cheaper than pushing every event through the live pipeline, because it amortizes per-invocation overhead across thousands of records. Replay through the real pipeline when you need the real side effects; use a batch job when you only need the end state. Estimate either path against the event bus pricing detail and price the pipeline against the resource catalog before you press the button.
FAQ
How much does it cost to archive events?
EventBridge archives cost $0.10 per GB-month, so 50 GB is $5.00. An S3 Standard event log is $0.023 per GB-month, about $1.15 for the same volume, and Glacier Instant Retrieval is $0.004 per GB-month. Kinesis extended retention adds $0.023 per shard-hour beyond 24 hours. Storage is a few dollars a month for most pipelines.
What does an event replay actually cost?
A replay re-runs your whole downstream pipeline. Replaying 50 million events into three consumers running 200 ms at 512 MB costs roughly $150 in deliveries, $30 in invocations, $250 in duration, $375 in DynamoDB writes, and $75 in logs, about $880 total, against $5 for the archive that made it possible.
Why do replays cause throttling?
Because they run at maximum concurrency. Pushing 150 million invocations through in two hours needs roughly 4,200 concurrent executions, which hits account concurrency limits and overwhelms downstream dependencies. A provisioned DynamoDB table sized for normal traffic will throttle hard, generating retries that add cost while producing no additional work.
How do I make an event replay cheaper?
Replay only the affected consumer rather than all of them, which removed two thirds of the cost in a three-consumer example. Narrow the time window to the period actually affected. Set reserved concurrency to throttle the replay to a rate dependencies can absorb, and temporarily switch provisioned DynamoDB tables to on-demand for the duration.
Is a batch backfill cheaper than a replay?
Usually, yes, when you only need the end state rather than the side effects. A single job reading an S3 event log and writing results in bulk amortizes per-invocation overhead across thousands of records, while a replay pays the full invocation and delivery cost for every event. Use replay when the real downstream side effects are required.
How does C3X help with replay cost?
C3X prices event buses, archives, functions, and the tables they write to from Terraform, so the standing cost of a replayable architecture is clear and the per-event cost of the pipeline is known. Knowing the per-event cost of the live path is what lets you multiply it by an archive's event count before committing to a replay.
What to do next
Know what a replay costs before you run one. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.
Share this post
Try C3X on your own Terraform
Free and open source. No API key required. One command to install, one command to estimate.