Fan-out pattern cost: what one event costs when it becomes ten
Fan-out multiplies one event into many deliveries, and the bill multiplies with it. Different fan-out mechanisms have very different per-delivery economics. Here is what each one costs at scale.
Quick answer
Fan-out cost scales with deliveries, not publishes. SNS charges $0.50 per million publishes and delivers to SQS and Lambda targets at no per-delivery charge, so fanning one event to 10 SQS queues costs the publish plus the receiving queues' own $0.40 per million requests each. EventBridge charges $1.00 per million events published and includes delivery to all matching rules, so 10 targets cost the same as one on the bus side. Direct fan-out from a function costs nothing on the bus but multiplies invocations. At 100 million events a month to 10 targets, the spread is roughly $100 for EventBridge, $450 for SNS plus SQS, and far more for naive per-target function calls.
Fan-out is the defining shape of event-driven architecture: one thing happens, many things react. It is also the shape that turns a small number into a large bill, because every architectural decision about fan-out is multiplied by the number of consumers. A pattern that costs $10 a month with two subscribers can cost $500 with twenty.
The mechanisms and what they charge
| Mechanism | Publish cost | Delivery cost |
|---|---|---|
| SNS to SQS | $0.50 per million | No SNS delivery fee; SQS charges $0.40 per million |
| SNS to Lambda | $0.50 per million | No SNS delivery fee; Lambda charges apply |
| SNS to HTTP endpoint | $0.50 per million | $0.60 per million deliveries |
| EventBridge bus | $1.00 per million | Included for all matching rules |
| Kinesis Data Streams | Shard hours + PUT payload units | Free for standard consumers, per-GB for enhanced fan-out |
| Function calling N targets | $0 | N times the invocation and duration cost |
The structural difference is where the multiplication happens. On EventBridge it does not happen on the bus at all: one event matching 10 rules costs $1.00 per million, the same as matching one. On SNS the publish is single but each SQS subscriber runs its own meter. With a function that loops over targets, the multiplication lands entirely on compute, which is the most expensive place for it.
A 100 million event comparison
One hundred million events a month, each delivered to 10 consumers, each consumer a Lambda function running 100 ms at 512 MB.
| Layer | SNS to 10 SQS queues | EventBridge, 10 rules |
|---|---|---|
| Publish | $50 | $100 |
| Bus delivery | $0 | $0 |
| Queue requests (2 per message, 1B messages) | $800 | n/a |
| Lambda invocations (1B) | $200 | $200 |
| Lambda duration (50M GB-s) | $833 | $833 |
| Total | $1,883 | $1,133 |
Two things stand out. EventBridge's higher publish price is more than repaid by skipping the queue layer, and in both designs the consumers dominate: $1,033 of compute against $50 to $100 of bus. Fan-out cost is mostly a question of how many consumers you create and how efficient each one is, not which bus you pick.
Filtering before the multiplication
The cheapest delivery is the one that never happens. Both SNS and EventBridge support server-side filtering, and applying it changes the arithmetic more than any other lever. If 7 of your 10 consumers only care about 5 percent of events, filtering at the bus takes 700 million deliveries down to 35 million. In the table above that removes roughly $520 of queue requests, $140 of invocations, and $580 of duration: about $1,240 a month, or 66 percent.
The anti-pattern is filtering in the consumer. A function that starts, parses the event, decides it does not care, and returns still costs a full invocation plus its minimum billed duration. At 1 billion deliveries, even a 20 ms no-op at 512 MB is 10 million GB-seconds, $167, plus $200 in request charges, to do nothing.
Batching on the consumer side
SQS-to-Lambda event source mappings deliver up to 10 messages per invocation by default and up to 10,000 for standard queues with a batch window. Raising the batch size from 1 to 10 cuts invocation charges by 90 percent and usually cuts total duration too, since per-invocation overhead is amortized. On 1 billion messages that is $200 down to $20 in requests, and typically 30 to 50 percent off duration. Batch windows add latency, so this is a trade, but for most asynchronous consumers a few hundred milliseconds is free.
| Batch size | Invocations per 1B messages | Request cost |
|---|---|---|
| 1 | 1,000,000,000 | $200.00 |
| 10 | 100,000,000 | $20.00 |
| 100 | 10,000,000 | $2.00 |
When a stream beats a bus
Kinesis Data Streams prices differently again, and for very high volumes it often wins. On-demand mode charges $0.040 per stream-hour plus $0.08 per GB ingested and $0.04 per GB retrieved, while provisioned mode charges $0.015 per shard-hour plus $0.014 per million PUT payload units of 25 KB. A provisioned stream with 10 shards costs about $109 a month and can absorb 10,000 records per second, which at full utilization is over 25 billion records. Standard consumers read the same records at no additional per-consumer charge, so fan-out to five consumers costs nothing extra on the stream side. The trade is operational: shards need management, ordering is per shard, and enhanced fan-out costs $0.013 per consumer-shard-hour plus $0.013 per GB retrieved.
Designing fan-out for cost
Count deliveries, not events, when you estimate. Filter at the bus. Batch at the consumer. Question every new subscriber, since adding an eleventh consumer to a 100 million event stream adds roughly $100 of compute a month even if it does almost nothing. And prefer buses that include delivery over chains that meter every hop. The same delivery-count logic drives anyevent-driven cost breakdown. Price the full fan-out, all consumers included, against the resource catalog before the subscriber list grows.
FAQ
How is fan-out cost calculated on AWS?
By deliveries, not publishes. SNS charges $0.50 per million publishes with no per-delivery fee to SQS or Lambda targets, but each SQS queue then charges $0.40 per million requests. EventBridge charges $1.00 per million events published and includes delivery to all matching rules, so 10 targets cost the same on the bus as one target does.
Is SNS or EventBridge cheaper for fan-out?
EventBridge is usually cheaper once a queue layer is involved, despite its higher $1.00 per million publish price, because delivery to all matching rules is included. For 100 million events to 10 consumers, an SNS plus SQS design costs roughly $1,883 a month against about $1,133 for EventBridge, with the queue request charges accounting for most of the gap.
What dominates fan-out cost at scale?
The consumers. In a 100 million event, 10 consumer example, the bus costs $50 to $100 while Lambda invocations and duration total over $1,000. Choosing the bus matters far less than how many consumers exist and how efficiently each one runs, which is why filtering and batching deliver much larger savings than switching messaging services.
How much does event filtering save?
A great deal. If 7 of 10 consumers only need 5 percent of events, server-side filtering reduces 700 million deliveries to 35 million. In a 100 million event per month system that removes roughly $520 of queue requests, $140 of invocations, and $580 of duration, about $1,240 a month or 66 percent of the total pipeline cost.
Why is filtering inside the consumer expensive?
Because the invocation has already happened. A function that starts, parses the event, decides it is irrelevant, and returns still pays a full request charge plus its minimum billed duration. At 1 billion deliveries, even a 20 ms no-op at 512 MB costs about $167 in duration plus $200 in requests purely to discard events that server-side filtering would have dropped for free.
How does C3X help with fan-out cost?
C3X prices topics, buses, queues, and the functions subscribed to them from Terraform, so a fan-out design's total delivery cost appears in the pull request. Because adding a subscriber is a Terraform change, the incremental cost of the eleventh consumer on a high-volume stream is visible at review time rather than appearing as bill drift a month later.
What to do next
Count deliveries before you ship the design. 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.