Quick Answer
AWS EventBridge is a serverless event bus that routes events from over 250 AWS services, SaaS partners, and your own applications to targets like Lambda, Step Functions, and SQS. You define rules that match event patterns; EventBridge delivers matching events to the right destinations. Custom events cost $1 per million ingested, AWS management events are free to ingest, and the real spend usually lives downstream in whatever the events trigger.
In July 2023, AWS shipped a feature whose entire job is to stop you from paying AWS too much.
It’s called recursive loop detection. If a Lambda function gets caught in a loop, S3 triggers Lambda, Lambda writes back to S3, S3 triggers Lambda again, forever, AWS now detects the pattern and drops the event after 16 invocations. On by default. For every account on Earth.
Cloud providers don’t build revenue-reducing features for fun. They build them because enough customers looped themselves into oblivion that it became a support problem. AWS Serverless Hero Yan Cui documented the classic incidents years earlier: “A sizable AWS bill soon followed.”
Here’s the part that matters for this article. That safety net covers SQS, SNS, S3, and direct Lambda calls. It does not cover EventBridge. Route events through the bus, wire a circular path by accident, and the seatbelt AWS built for everyone else quietly isn’t there.
So let’s understand this thing properly: what AWS EventBridge is, how it routes events, when to pick it over its siblings, and, since we’re CloudZero and following the money is the whole personality, where the bill really comes from.
What is AWS EventBridge?
Amazon EventBridge is AWS’s serverless event bus: a routing service that receives events (an order placed, a file uploaded, an instance terminated) and delivers each one to whatever should react to it, based on rules you define. No servers, no polling, no glue code.
The mental model is a very fast, very organized post office. Producers drop letters (events) into a mailbox (an event bus). Sorting rules read each envelope (the event pattern) and deliver copies to the right recipients (targets). Nobody waits on anybody. Producers don’t know consumers exist.
That decoupling is the entire point, and it’s also EventBridge’s answer to the pub/sub pattern: publishers announce, subscribers react, and adding a fifth subscriber next quarter requires zero changes to the publisher. Many organizations formalize this as a hub and spoke design, one central bus per domain with application buses feeding it, which keeps sprawling architectures navigable.
Fun trivia beat for your next architecture review: EventBridge is CloudWatch Events with a better haircut. AWS built the original bus for CloudWatch, realized it was generally useful, and relaunched it in 2019. Same underlying service, same API. That’s the complete answer to the 700-searches-a-month EventBridge vs CloudWatch Events question: there is no versus.
Report
Finance needs to prove AI’s return: CloudZero report
260 senior finance leaders (more than half CFOs) told us why the speed of seeing AI spend, not the size of it, separates who pulls ahead on AI from who gets burned.
How does AWS EventBridge work?
Five components do all the work. Events flow from sources onto a bus, rules match them, and targets receive them; Pipes and Scheduler handle the point-to-point and time-based cases.
- Event buses. The pipes. Every account gets a default bus that receives events from over 250 AWS services automatically. You add custom buses for your applications and partner buses for SaaS sources like Datadog, Shopify, or PagerDuty. Some services, S3 included, can also send opt-in data plane events (object-level activity, not just management operations).
- Rules. The routing logic. A rule is a JSON pattern (“source is orders-service AND detail-type is OrderPlaced”) plus up to five targets. Rules evaluate in parallel; one event can match many rules.
- Targets. Where events land. EventBridge targets include Lambda functions, Step Functions state machines, SQS queues, SNS topics, Kinesis streams, other event buses, and API destinations for any HTTP endpoint, public or private via PrivateLink.
- EventBridge Pipes. Point-to-point plumbing with built-in filtering, enrichment, and transformation. One source, one target, no bus in the middle.
- EventBridge Scheduler. Cron, evolved. One-time and recurring schedules that can invoke over 270 AWS services, with a permanent free tier of 14 million invocations a month, roughly five invocations per second, around the clock, free.
A free schema registry catalogs your event shapes so developers stop reverse-engineering payloads from production logs, an activity with a rich and shameful history. And the whole thing is infrastructure-as-code friendly: Terraform and CloudFormation both treat buses, rules, and schedules as first-class resources, which is how rule sprawl stays auditable.
What is AWS EventBridge used for?
Four patterns cover most of the real world:
- Reacting to infrastructure. An EC2 instance changes state, a security group gets modified, a certificate nears expiry. The default bus already carries these events free; a rule and a Lambda turn them into automation instead of a ticket queue. Pair it with AWS Budgets alerts and the ops loop starts closing itself.
- Decoupling microservices. The order-placed event fans out to fulfillment, notifications, analytics, and fraud checks simultaneously. This is the serverless architecture pattern that keeps Lambda functions small and single-purpose, and it’s why event-driven design dominates modern serverless systems.
- Wiring SaaS into AWS. Partner event sources push Shopify orders or PagerDuty incidents straight onto a bus. No webhook servers, no polling loops, no 3 a.m. “the poller died” pages.
- Orchestrating AI pipelines. The newest and fastest-growing pattern: a document lands in S3, EventBridge fires, Lambda calls a model on Amazon Bedrock to classify or summarize it, and the result event triggers the next stage. Scheduler drives nightly batch inference; agentic systems emit events as they work. If you’re running Claude on AWS Bedrock, EventBridge is very likely the nervous system connecting your triggers to your inference spend. Hold that thought; it’s about to matter financially.
How much does AWS EventBridge cost?
The short version of AWS EventBridge pricing: you pay per million events, with ingestion and delivery billed separately depending on event type and destination:
| Component | Ingestion | Free tier |
|---|---|---|
| AWS management events (default bus) | Free | Ingestion always free |
| Custom and partner events | $1.00/M | No |
| EventBridge Pipes | $0.40/M requests after filtering | No |
| Scheduler invocations | $1.00/M | 14M/month, permanent, all regions |
| API destinations | $0.20/M invocations + data transfer | None |
| Archive / replay | $0.10/GB processing; $0.023/GB-month storage; replays at $1.00/M | None |
| Schema Registry / Discovery | Free / $0.10/M after free tier | 5M discovery events/month |
Three fine-print items that bite, all straight from AWS’s page: payloads bill in 64 KB chunks, so one 256 KB event counts as four. Schema Discovery bills in 8 KB chunks, so auditing a production bus costs more than the headline rate suggests. And cross-region delivery adds standard data transfer charges on top. Global endpoints, at least, carry no extra fee.
At these rates, EventBridge itself is almost never your problem. Ten million custom events is ten dollars. The component-by-component breakdown with worked examples and savings levers lives in our dedicated AWS EventBridge pricing guide, so we won’t rebuild it here.
Here, we’re going to talk about the bill EventBridge doesn’t show you.
What are the hidden costs of EventBridge?
The hidden cost of EventBridge is everything it triggers: every matched event fires targets that bill on their own meters, so the bus’s $1-per-million routing fans out into Lambda, Step Functions, Kinesis, and inference charges that dwarf it.
Trace one event to make it concrete. An order-placed event costs $0.000001 to publish. Here’s what it detonates:
| What the event triggers | Billed on | Approximate cost per event |
|---|---|---|
| Fulfillment Lambda | Lambda invocations + duration | ~$0.0000035 |
| Notifications Lambda | Lambda invocations + duration | ~$0.0000030 |
| Order workflow (4 state transitions) | Step Functions | ~$0.0001000 |
| Analytics stream put | Kinesis | ~$0.0000140 |
| Fraud check calling a Bedrock model | Lambda + inference tokens | ~$0.0100000+ |
Illustrative rates, but the shape is universal: the event cost a millionth of a dollar and its consequences cost three to four orders of magnitude more, spread across five services, none of them labeled “this was the order-placed event’s fault.”
The AI pattern turbocharges it. When the fan-out target is an inference call, one over-eager rule pattern (matching all S3 uploads instead of the invoices/ prefix) doesn’t waste event dollars. It wastes inference dollars, at scale, silently.
Then there are loops. Remember the seatbelt that doesn’t cover EventBridge? A rule that triggers a Lambda that emits an event matching the same rule is a perpetual-motion billing machine, and your dead-letter queues, concurrency limits, and CloudWatch alarms are all that stand between you and a very educational month.
The structural problem underneath: per-service billing can’t see causality. Your invoice says Lambda rose 40% and Step Functions rose 25%. It does not say “the new order-enrichment rule did this.” Event-driven architecture distributes consequences across services precisely the way AWS bills can’t reassemble, which is why event-heavy shops feel like their bill is haunted.
What are EventBridge’s limits and quotas?
The constraints that shape designs, worth knowing before the architecture review rather than during the incident:
- Event size caps at 256 KB. Bigger payloads get rejected, not truncated. This enforces the send-references-not-documents rule: the S3 key rides the bus, the 40 MB PDF stays home.
- Five targets per rule. Need more fan-out? Point the rule at an SNS topic and fan out from there, usually cheaper per delivery too.
- EventBridge throughput is quota-based and regional. Default publish limits vary by region and are soft limits raisable via support. Sustained six-figure events per second means you’ve left EventBridge territory for Kinesis-or-Kafka territory; budget accordingly.
- Retries run up to 24 hours, then events die. Without a dead-letter queue on the rule, an event that exhausts retries evaporates, along with your ability to replay or explain it. DLQs everywhere isn’t paranoia; it’s accounting.
- Rules per bus start at 300. A soft limit, but approaching it usually signals rule sprawl worth auditing, since every rule is an invoice multiplier somebody forgot creating.
What happens to EventBridge in the age of AI agents?
Here’s the question nobody on page one of this topic is asking, so we will.
EventBridge’s entire value proposition is routing decisions: when X happens, send it to Y. For fifteen years, that logic lived in infrastructure you could read. A rule is a JSON pattern in a config file. An auditor, a new engineer, or a finance analyst can open it and know exactly what fans out where.
AI agents are eating that job from the inside. An agent doesn’t consult a routing table; it decides what to call next mid-reasoning, through tool use and MCP servers and orchestration loops. The routing didn’t disappear. It migrated from configuration into cognition.
That migration has a consequence every budget owner should sit with: the event bus was the legible version of distributed spend. Agents are the illegible version. An EventBridge rule fanning out to five targets is auditable; the fan-out is written down. An agent choosing its own fan-out at runtime is a routing layer whose logic is a prompt, whose paths vary per request, and whose downstream bill makes the haunted-invoice problem above look quaint.
In practice the two layers converge rather than compete. Production agentic systems still ride the bus: agents emit events as they work, EventBridge routes them to inference endpoints, queues, and humans, and Scheduler kicks off the batch runs agents depend on. The declarative layer carries the traffic; the cognitive layer decides it.
So the cost question of the AI era isn’t “what does EventBridge cost” or “what do my agents cost.” It’s whether you can trace a business outcome through both layers to a single number.
That’s an allocation problem, and it’s the same one this article has been circling all along, now wearing a smarter costume.
EventBridge vs SNS vs SQS: which should you use?
Use EventBridge when routing needs intelligence, SNS when fan-out needs raw speed and scale, and SQS when work needs buffering and retries. The comparison:
| EventBridge | SNS | SQS | |
|---|---|---|---|
| Shape | Bus: many sources, rule-routed, many targets | Fan-out: one topic, all subscribers | Queue: producers in, consumers out |
| Filtering | Rich, on the full event body | Attribute-based only | None (consumer decides) |
| Best at | Cross-service and SaaS routing, content-based decisions | Massive simple fan-out, mobile push | Buffering, retries, work distribution |
| Latency | ~Half a second typical | Milliseconds | Milliseconds |
| Rough cost | $1.00/M ingested | $0.50/M published | $0.40/M requests |
The honest heuristic: eventbridge vs sns comes down to routing intelligence versus raw throughput; eventbridge vs sqs isn’t really a versus, since the classic pattern is EventBridge routing INTO queues so SQS can absorb bursts and retry failures. Mature architectures use all three.
The Kafka question, since it always comes up: Kafka (or Confluent Cloud) is a distributed log for high-throughput streaming with replay and ordering guarantees, at cluster prices. EventBridge is integration plumbing at per-event prices. Teams that need Kafka already know, usually because someone said “a million events per second” in a planning meeting and nobody laughed.
How do you keep EventBridge costs under control?
Four habits, in impact order:
- Filter at the rule, not the target. Every event reaching a Lambda just to be discarded paid for a full invocation to do nothing. Tighten rule patterns so garbage never boards the bus. On Pipes, filtering is the difference between billing 10 million requests and billing the 25% that matter, AWS’s own pricing example shows exactly this math.
- Shrink the payloads. The 64 KB chunk rule means bloated events bill in multiples, and everything downstream parses the bloat too. Send references, not documents.
- Set archive retention like you mean it. Archives grow at $0.023 per GB-month forever until someone sets a retention policy. “Keep everything, in case” is a strategy with a subscription fee.
- Audit for circular paths. Map every rule whose target can emit events. DLQs on every consumer, concurrency limits on anything that could loop. An hour of paranoia against an open-ended invoice.
And the one that isn’t a tactic: make the fan-out visible. Tactics trim the bus bill, but “what does the order-placed flow cost end to end, and is it trending right?” can’t be answered by any per-service view. Our cloud cost optimization roundup covers the tactical layer; the visibility layer is next, and we have unusually direct experience with it.
How CloudZero sees what the event bus is hiding
Full disclosure: CloudZero doesn’t just write about event-driven cost visibility. We run a 100% serverless, event-driven platform ourselves, and we used our own product on our own bill: 54 hours of staff effort found $1.7 million in annualized savings, 88% of it surfaced by engineers seeing the cost consequences of their own architecture, including one two-hour change worth $1.1 million a year. That’s what happens when the fan-out becomes visible to the people who built it.
The mechanics that make it work on event-driven systems specifically: CloudZero ingests billing and telemetry streams, then the allocation engine assigns every downstream charge (the Lambda invocations, state transitions, stream puts, and Bedrock inference a given event flow causes) to the feature, team, and customer that flow belongs to, including the shared and untaggable costs event architectures generate by design. Not “Lambda went up.” Rather: “order enrichment costs $0.0043 per order, up 12% since the fraud rule shipped.”
That’s the same capability that found Drift the problem hiding in its event-driven architecture: an ML-powered feature reacting to live website activity was quietly destroying margins, from inside the free tier, invisible on any per-service view. Making it visible was step one of a $2.4 million reduction.
Anomaly detection closes the loop gap too: a runaway rule or accidental circular path shows up as a cost-per-flow spike within hours, which, given that AWS’s loop protection still doesn’t cover the bus, is the closest thing to an EventBridge seatbelt on the market.
Rules or reasoning loops, declarative or agentic, the money still has to map to an outcome. That mapping is the difference between knowing what EventBridge charged you (easy, small) and knowing what your events cost you (hard, large, and the number that matters).
Your event bus costs a dollar per million. The question is what the other 99.9% of that architecture costs, and whose feature it belongs to. See your cost per event flow in a demo, put a number on the fan-out with a free cloud cost assessment, or trace it yourself in the self-guided tour.
FAQs
