Cloud / Amazon EventBridge Interview questions

Amazon EventBridge is a serverless event bus from AWS. It receives events from AWS services, your own applications and SaaS partners, and routes them to targets based on rules you define. Services can react to each other without calling each other directly.

A producer publishes an event to a bus, rules compare it against event patterns, and every matching rule delivers it to its targets, such as Lambda, SQS, SNS or Step Functions. There is nothing to provision and capacity scales automatically.

The service also bundles Scheduler for time-based invocations, Pipes for point-to-point integrations, a Schema Registry, and archive and replay.

An event is a JSON document that records something that already happened, such as an EC2 instance entering the stopped state or a customer placing an order. It is a fact, not a command asking another service to do work.

Each event has a standard envelope (source, detail-type, time and so on) plus a free-form detail object that carries the payload. Producers publish without knowing who will consume the event.

Name events in the past tense, like OrderPlaced, so consumers treat them as notifications rather than instructions.

Every event shares the same envelope, and only detail is free-form. Rules usually match on the envelope fields plus values inside detail.

{
  "version": "0",
  "id": "6a7e8feb-b491-4cf7-a9f1-bf3703467718",
  "detail-type": "OrderPlaced",
  "source": "com.shop.orders",
  "account": "111122223333",
  "time": "2026-10-02T09:15:00Z",
  "region": "us-east-1",
  "resources": [],
  "detail": { "orderId": "A-1001", "total": 249.5 }
}

An event bus is the pipeline that receives events and hands them to rules. Producers send events to a bus, and the rules attached to that bus decide which targets get each event.

Each bus has its own ARN, its own set of rules and its own resource-based policy. That policy is what allows other accounts or an AWS Organization to put events on the bus.

Every account has one default bus per Region, and you can add as many custom buses as you need.

EventBridge has three kinds of event buses, and they differ mainly in who sends events to them.

Rules and resource policies work the same way on all three. Scheduled rules are the exception, since they only exist on the default bus.

A rule watches a single event bus and sends matching events to one or more targets. It is the routing logic: a filter on one side, a list of targets on the other.

There are two kinds. An event pattern rule matches events by their content. A scheduled rule fires on a rate or cron expression and only exists on the default bus.

A rule can have up to five targets, can be enabled or disabled without deleting it, and can reshape the event with an input transformer before delivery.

An event pattern is a JSON filter that mirrors the shape of the event you want to match. Each field you list must match, and each field you leave out is ignored.

Pattern values are always arrays. Several values in one array are treated as OR, while several fields are treated as AND. Matching is case-sensitive.

{
  "source": ["com.shop.orders"],
  "detail-type": ["OrderPlaced"],
  "detail": { "status": ["PAID", "SHIPPED"] }
}

A target is the resource that EventBridge calls when an event matches a rule. Common targets include Lambda, SQS, SNS, Step Functions, Kinesis, Firehose, ECS tasks, API Gateway, CloudWatch Logs, another event bus, and external HTTP endpoints through API destinations.

Permissions depend on the target type:

Each target can also have its own input settings, retry policy and dead-letter queue.

EventBridge accepts events from four main places.

1. AWS services, which publish state changes to the default bus automatically and at no charge, for example EC2, S3, CodePipeline and GuardDuty.
2. Your applications, which call PutEvents through an SDK or the CLI.
3. SaaS partners, such as Zendesk or Datadog, through partner event sources.
4. Other event buses, in the same or another account or Region.

Calls recorded by CloudTrail also arrive as events, which lets you react to almost any AWS API call.

EventBridge is the evolution of CloudWatch Events. Both use the same underlying service and the same API namespace, so the aws events CLI commands and the AWS::Events::Rule resource type are unchanged.

Rules you created in CloudWatch Events show up in EventBridge as rules on the default bus, and rules you create in the EventBridge console appear in the older console too. Nothing needs to be migrated, and existing targets keep working.

EventBridge adds the things the original did not have: custom and partner buses, the Schema Registry, archive and replay, API destinations, Pipes and Scheduler.

Call the PutEvents API from an SDK, the CLI or any service that can sign AWS requests. Each entry needs a Source, a DetailType and a Detail JSON string, and you can name the target bus with EventBusName.

import boto3, json
events = boto3.client("events")

resp = events.put_events(Entries=[{
    "EventBusName": "orders-bus",
    "Source": "com.shop.orders",
    "DetailType": "OrderPlaced",
    "Detail": json.dumps({"orderId": "A-1001", "total": 249.5})
}])
print(resp["FailedEntryCount"])

A request can carry up to 10 entries, and the whole request must stay under 256 KB. PutEvents can return HTTP 200 while individual entries fail, so always check FailedEntryCount and retry the failed ones. Sources starting with aws. are reserved.

Create a rule with an event pattern, add the function as a target, and let the function's resource policy allow events.amazonaws.com to invoke it. The console adds that permission for you. With the CLI or IaC you add it yourself.

aws events put-rule --name order-paid \
  --event-pattern '{"source":["com.shop.orders"],"detail-type":["OrderPaid"]}'

aws lambda add-permission --function-name process-order \
  --statement-id eb-order-paid --action lambda:InvokeFunction \
  --principal events.amazonaws.com \
  --source-arn arn:aws:events:us-east-1:111122223333:rule/order-paid

aws events put-targets --rule order-paid \
  --targets "Id"="1","Arn"="arn:aws:lambda:us-east-1:111122223333:function:process-order"

EventBridge invokes Lambda asynchronously, and the whole event becomes the function's input. Lambda's own async retry settings and failure destinations then apply.

EventBridge Scheduler is a serverless scheduler for running one-time or recurring tasks at scale. You define a schedule, a target and an optional payload, and it calls the target on time.

It supports at() one-time expressions, rate() and cron(), with time zone and daylight saving support. A flexible time window can spread invocations to avoid spikes, and schedules live in schedule groups.

Scheduler can call a very wide range of AWS API actions directly as universal targets, and it has retry policies and dead-letter queues. It is built to hold millions of schedules, such as one reminder per customer.

EventBridge Pipes connects one source to one target with optional filtering and enrichment in between. It removes the glue Lambda code you would otherwise write to move messages between services.

flowchart LR
  S[Source] --> F[Filter]
  F --> E[Enrichment]
  E --> T[Target]

Supported sources include SQS, Kinesis, DynamoDB Streams, Amazon MSK, self-managed Kafka and Amazon MQ. Enrichment can be Lambda, Step Functions, API Gateway or an API destination, and targets cover most EventBridge target types.

Pipes polls the source and handles batching and retries for you. Unlike a bus, it is strictly point-to-point.

The Schema Registry stores the structure of your events so developers can discover and reuse it. Schemas are saved in OpenAPI 3 or JSON Schema Draft 4 format and are versioned.

Schemas for AWS service events are already there. For your own events you can turn on schema discovery on a bus, and EventBridge infers a schema from the traffic it sees and creates a new version when the shape changes.

From a schema you can download code bindings for languages like Java, Python and TypeScript. That gives you typed classes for events instead of hand-written JSON parsing.

An archive stores copies of events from a bus so they can be replayed later. You create it for one bus, choose a retention period in days or keep events indefinitely, and optionally add an event pattern so only some events are kept.

Archiving is useful for recovering from a bug in a consumer, seeding a new environment with realistic traffic, or auditing what flowed through a bus.

Archives are billed for storage and ingestion, so filter with a pattern instead of archiving everything by default.

Replay re-sends archived events from a chosen time range back to the bus they came from. You can send them to all rules or limit the replay to specific rules.

Replayed events keep their original time and gain a replay-name field, so consumers and rules can tell them apart from live traffic. Replays are not instantaneous, and ordering is not guaranteed.

Because side effects will run again, consumers must be idempotent. Scoping the replay to one rule is the safest way to rerun just the consumer you fixed.

A partner event source lets a supported SaaS provider, such as Zendesk, Datadog or Auth0, send events straight to your account. The provider creates the source, you accept it, and EventBridge gives you a partner event bus, with a name that starts with aws.partner/.

You then write rules on that bus like any other. This avoids running webhooks receivers or polling the SaaS API.

Events flow one way, from the partner into your account. The partner's own AWS account is never given access to your resources.

API destinations let a rule call any HTTPS endpoint, including SaaS APIs or on-premises services, as if it were a native target. You define a connection that holds the authentication, and a destination that holds the URL, HTTP method and rate limit.

Connections support basic auth, API keys and OAuth client credentials. Credentials are stored in AWS Secrets Manager and are not exposed in the rule.

Because the endpoint is outside AWS, the destination has a configurable invocation rate limit to protect it, and the request has a short timeout of about five seconds.

An input transformer reshapes the event before it reaches a target. You pick values with input paths and compose the output with an input template.

Input path:
{ "orderId": "$.detail.orderId", "total": "$.detail.total" }

Input template:
{ "message": "Order <orderId> paid, total <total>" }

This is handy for sending a clean message to SNS or SQS, or for shaping the body that an API destination receives, without adding a Lambda in between. The result must be valid for the target, so remember that unquoted placeholders are inserted as raw JSON.

Exact numbers differ by Region and many are adjustable in Service Quotas, so check the current values before you design around them. These are the ones that come up most often.

The 256 KB cap pushes large payloads to S3 with the event carrying a pointer (the claim-check pattern). The five-target cap is why fan-out to many consumers often uses SNS or several rules.

Both fan events out to multiple consumers, but they are tuned for different jobs. SNS is a high-throughput, low-latency pub/sub service. EventBridge is a content-based event router with a much richer ecosystem.

Pick SNS for high-volume notifications and human-facing channels. Pick EventBridge for routing domain events and reacting to AWS or SaaS events. They also combine well, for example a rule targeting an SNS topic.

SQS is a queue, and EventBridge is a router. SQS stores messages until a consumer pulls and deletes them. EventBridge pushes events to targets as they match and does not hold them for consumers.

The usual design puts them together: a rule routes events to an SQS queue so each consumer gets buffering, back-pressure and its own dead-letter queue.

Choose EventBridge when you have discrete business or infrastructure events that should be routed by content to different targets. Choose Kinesis when you have a continuous, high-volume stream where order and position matter.

They are not exclusive. EventBridge Pipes can read from a Kinesis stream, filter it and push selected records to a bus.

EventBridge compares the event's JSON to each rule's pattern field by field. All listed fields must match, and values in one array are OR-ed. Matching is on the JSON as sent, so a string "100" does not match a number 100.

Beyond exact values you can use content filters:

The $or operator combines conditions across different fields. Use it sparingly, because very complex patterns are hard to review.

Each matching rule fires independently, and the event is delivered to every target of every matching rule. There is no priority, no first-match-wins, and no ordering between rules.

That is what makes fan-out simple: add another rule and a new consumer starts receiving the same events. It is also why overlapping patterns can cause surprises, especially if two rules point at the same target and it receives the event twice.

If you want an exclusive path, write patterns that cannot overlap, for example by using anything-but on the catch-all rule.

The producer calls PutEvents and EventBridge authenticates the request and checks IAM or the bus resource policy. The event is accepted onto the bus and then evaluated against every rule on that bus.

sequenceDiagram
  participant P as Producer
  participant B as Event bus
  participant R as Rules
  participant T as Target
  participant D as DLQ
  P->>B: PutEvents
  B->>R: Evaluate patterns
  R->>T: Transform input and deliver
  alt delivery fails
    R->>T: Retry with backoff
    R->>D: Send after retries are exhausted
  end

1. Matching rules apply their input transformer or input path.
2. EventBridge invokes each target with the rule's role or the target's resource policy.
3. On failure it retries according to the retry policy.
4. If a dead-letter queue is set, the failed event goes there, otherwise it is dropped.

When a target call fails with a retriable error, EventBridge retries with exponential backoff and jitter. By default it keeps trying for up to 24 hours and up to 185 attempts, whichever limit comes first.

You can tune this per target with a retry policy: MaximumEventAgeInSeconds from 60 to 86400 and MaximumRetryAttempts from 0 to 185. Some errors, such as a deleted target or missing permission, are not worth retrying and fail quickly.

If delivery still fails and no dead-letter queue is set, the event is dropped. For Lambda, EventBridge considers the delivery complete once Lambda accepts the async invocation, so function failures are handled by Lambda's own retries and destinations.

Set a DeadLetterConfig on the target, not on the rule, pointing to a standard SQS queue. Then give EventBridge permission to send messages to it.

{
  "Sid": "AllowEventBridgeToSendToDLQ",
  "Effect": "Allow",
  "Principal": { "Service": "events.amazonaws.com" },
  "Action": "sqs:SendMessage",
  "Resource": "arn:aws:sqs:us-east-1:111122223333:orders-dlq",
  "Condition": { "ArnEquals": { "aws:SourceArn": "arn:aws:events:us-east-1:111122223333:rule/orders-bus/order-paid" } }
}

FIFO queues are not supported as the DLQ. Failed messages arrive with attributes such as ERROR_CODE and ERROR_MESSAGE, which makes triage much easier. Alarm on the queue depth so failures do not sit unnoticed.

EventBridge is a distributed, highly available service that favours durability and scale over strict ordering. It delivers at least once, so a target can occasionally see the same event twice, and events can arrive out of order.

Retries make this worse. If event A fails and is retried while event B succeeds, B reaches the target first. Replays and overlapping rules add more duplicates.

Design for it instead of fighting it: make consumers idempotent, carry a sequence number or timestamp in detail when order matters, and use Kinesis or SQS FIFO when strict ordering is a hard requirement.

Give every business operation a stable key and make the handler safe to run twice. The EventBridge id works for deduplicating redeliveries, but a business key such as orderId also covers a producer that publishes the same fact twice.

1. Read the key from the event, for example detail.orderId plus event type.
2. Do a conditional write to a store, like a DynamoDB PutItem with attribute_not_exists.
3. If the write fails because the key exists, skip the work and return success.
4. Expire old keys with a TTL.

Powertools for AWS Lambda has an idempotency utility that does this with a DynamoDB table. Side effects that are naturally idempotent, such as setting a status to PAID, need no extra guard.

Add the FIFO queue as a rule target and set the MessageGroupId in the target's SQS parameters. The group ID is mandatory for FIFO queues. Use a static value, or take it from the event with an input path such as $.detail.customerId.

{
  "Id": "fifo-target",
  "Arn": "arn:aws:sqs:us-east-1:111122223333:orders.fifo",
  "SqsParameters": { "MessageGroupId": "orders" }
}

The queue then preserves the order of messages it receives within each group. It cannot restore the order in which events were originally published, since EventBridge itself does not guarantee ordering. Also plan deduplication, for example by enabling content-based deduplication when identical payloads should be treated as duplicates.

Cross-account delivery is bus to bus. A rule in the source account targets the event bus in the destination account, and the destination bus allows it through a resource-based policy.

flowchart LR
  A["Account A bus"] -->|rule with bus target| B["Account B bus"]
  B --> C["Rules in Account B"]
  C --> D[Targets]

1. In Account B, attach a bus policy that allows events:PutEvents from Account A, or from an AWS Organization using aws:PrincipalOrgID.
2. In Account A, create a rule whose target is Account B's bus ARN, with an IAM role allowed to call PutEvents on it.
3. In Account B, write rules that route the received events to local targets.

Account B pays for the events it receives as custom events, so agree on volume with the owning team first.

A rule in one Region can target an event bus in another Region, using the same bus-as-target feature as cross-account routing. EventBridge uses an IAM role to call PutEvents on the destination bus.

Typical uses include aggregating events from many Regions into a central bus for security analysis, or copying events to a second Region for disaster recovery.

Remember that rules and targets are Regional. A Lambda in us-east-1 cannot be a direct target of a bus in eu-west-1, so route through a bus in each Region. Cross-Region delivery adds latency and is billed per forwarded event.

A global endpoint pairs a primary and a secondary Region so event ingestion fails over automatically if the primary has a problem. Producers publish to the endpoint instead of a single Region's bus.

1. Create identically named buses with the same rules in both Regions.
2. Create the global endpoint with a Route 53 health check, usually driven by a latency metric alarm.
3. Optionally turn on event replication so events are copied to the secondary bus.
4. Publish with an SDK that supports SigV4A signing, passing the endpoint ID.

When the health check goes unhealthy, new events flow to the secondary Region. Consumers must therefore exist and be tested there, and idempotency matters even more because events can be replicated.

Both can fire on a schedule, but Scheduler is the newer, more capable service and AWS recommends it for new work.

Keep scheduled rules only where they already exist and work. For per-customer reminders, timeouts and one-off jobs, use Scheduler.

A rule sits on a bus and fans one event out to up to five targets, matching by content. A pipe connects exactly one source to one target and also polls that source for you.

Use a pipe to move queue or stream records to a target with light filtering and enrichment. Use a bus and rules when many independent consumers should react to the same event.

Authentication lives in a connection. EventBridge supports basic authentication, API key headers and OAuth client credentials, and stores the secrets in AWS Secrets Manager. For OAuth it fetches and refreshes tokens automatically.

Rate limiting is set on the API destination as an invocation rate limit per second. Events beyond that rate are held and retried instead of overwhelming the endpoint.

EventBridge treats 429 and 5xx responses as retriable and honours a Retry-After header when present. Other 4xx responses are not retried. Pair it with a dead-letter queue so rejected events can be inspected.

Security is layered, from who can publish to who can read the data.

• IAM policies restrict who can call PutEvents and who can create or change rules.
• Bus resource policies restrict cross-account senders, ideally with aws:PrincipalOrgID or specific account IDs, never a bare wildcard principal.
• Least-privilege roles for each rule target, scoped to the exact resource.
• KMS customer managed keys to encrypt events at rest on the bus.
• Interface VPC endpoints so private workloads can publish without internet access.
• CloudTrail to audit rule changes and publishers.

Also keep sensitive fields out of events. Send an identifier and let the consumer fetch the data it is entitled to see.

Management API calls recorded by CloudTrail are delivered to the default bus as events with detail-type AWS API Call via CloudTrail. You match them on detail.eventSource and detail.eventName.

{
  "source": ["aws.ec2"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["ec2.amazonaws.com"],
    "eventName": ["TerminateInstances"]
  }
}

This is a convenient way to alert on risky changes, tag new resources automatically, or trigger remediation. Data events, such as S3 object-level activity, need a CloudTrail trail that records them. Global-service events such as IAM are emitted in us-east-1, so create the rule there.

EventBridge publishes metrics under the AWS/Events namespace, usually dimensioned by RuleName and EventBusName.

Alarm on FailedInvocations, on InvocationsFailedToBeSentToDlq, and on the DLQ's queue depth. A CloudWatch Logs target on a debug rule is a handy way to see the actual events.

Use the console's sandbox or the TestEventPattern API. Both take a pattern and a sample event and tell you whether it matches, with no rule or target needed.

aws events test-event-pattern \
  --event-pattern file://pattern.json \
  --event file://event.json

The sample event must include the full envelope (id, account, source, time, region, resources, detail-type and detail), otherwise the test will not behave like a real event.

For an end-to-end check, publish a sample to a dev bus with put-events and attach a temporary CloudWatch Logs target to the rule. Keep both the pattern and sample events in version control.

Work from the producer to the target and check each hop.

1. Producer: was the event published to the right bus and Region? Check FailedEntryCount from PutEvents, and remember that custom sources cannot start with aws..
2. Rule: is it enabled and attached to that bus?
3. Pattern: test it against the real event. Common culprits are case, arrays, nested detail paths, and string versus number types.
4. Metrics: MatchedEvents without Invocations means the pattern worked but delivery did not. No MatchedEvents means the pattern, bus or producer is wrong.
5. Permissions: the target resource policy or the rule's IAM role.
6. DLQ and logs: read the DLQ error attributes and the target's own logs.

Adding a CloudWatch Logs target with the same pattern is the fastest way to see exactly what arrived.

The default bus carries AWS service events and is often already shared by many teams. A custom bus gives you a clean boundary for your own domain events.

• Isolation: one bus per domain or team keeps patterns simple and blast radius small.
• Access control: each bus has its own resource policy, so you can grant a partner account access to one bus only.
• Archive and replay: archives are per bus, so you replay one domain without touching others.
• Schema discovery: turn it on for a single bus rather than for mixed traffic.
• Clarity: your events are not mixed with CloudTrail and service events.

Scheduled rules still need the default bus, and rules for AWS service events usually live there too.

Treat each event type as a public contract. Keep changes additive so existing consumers continue to work, and make consumers tolerant by ignoring fields they do not know.

• Use a clear detail-type in the past tense, like OrderPlaced.
• Put a schemaVersion field in detail, for example "1.2".
• Adding an optional field is a minor change. Renaming or removing a field is a breaking change.
• For breaking changes, publish a new type such as OrderPlaced.v2 and run both until consumers migrate.
• Keep payloads small and send IDs plus the minimum data. Use the claim-check pattern for large payloads.

Use the Schema Registry to document each version and generate code bindings, and add contract tests so a producer change cannot silently break a consumer.

Choose it when handling the event takes several steps, needs branching, waits, retries or compensation. A single Lambda is enough for one short step, but it becomes awkward when it grows into a chain of calls.

A rule starts the state machine with the event as input. The state machine can then call services directly, so you often write less code than with a chain of Lambdas. Express workflows suit high-volume short jobs, and Standard workflows suit long-running ones.

In choreography, services react to events independently and nobody is in charge. In orchestration, one coordinator, usually Step Functions, tells each step what to do and tracks the overall result.

A common rule of thumb is choreography between bounded contexts and orchestration inside one service's business process. Use correlation IDs in events so choreographed flows can still be traced.

Custom events are billed per million published, in 64 KB chunks, while AWS service events on the default bus are free. Most savings come from sending less and filtering earlier.

• Keep events small so each one stays within a single 64 KB billing chunk.
• Batch up to 10 entries per PutEvents call and handle partial failures.
• Write precise patterns so consumers get only what they need, and avoid duplicate rules.
• Archive only what you will replay, with a pattern and a retention period.
• Use Pipes filtering to avoid invoking expensive enrichment or targets.
• Use Scheduler instead of a Lambda that polls on a timer.
• Watch cross-account and cross-Region forwarding, since each hop is billed.

For performance, back off on throttling, request quota increases early, and keep targets fast or buffered behind SQS.

Use AWS::Events::Rule with the bus name, an EventPattern and a list of Targets. Remember a separate permission resource for Lambda targets.

OrderPaidRule:
  Type: AWS::Events::Rule
  Properties:
    EventBusName: !Ref OrdersBus
    EventPattern:
      source: ["com.shop.orders"]
      detail-type: ["OrderPaid"]
    Targets:
      - Id: ProcessOrder
        Arn: !GetAtt ProcessOrderFn.Arn
        RetryPolicy:
          MaximumRetryAttempts: 5
          MaximumEventAgeInSeconds: 3600
        DeadLetterConfig:
          Arn: !GetAtt OrdersDlq.Arn

ProcessOrderPermission:
  Type: AWS::Lambda::Permission
  Properties:
    FunctionName: !Ref ProcessOrderFn
    Action: lambda:InvokeFunction
    Principal: events.amazonaws.com
    SourceArn: !GetAtt OrderPaidRule.Arn

In CDK the equivalent is events.Rule with targets.LambdaFunction, which creates the permission automatically. SAM offers an EventBridgeRule event source on a function.

Publish domain events to a dedicated custom bus, give each consumer its own queue, and design for duplicates, failures and replay from day one.

flowchart LR
  O["Order service"] -->|PutEvents| B[orders-bus]
  B -->|rule| Q1["Payment queue"]
  B -->|rule| Q2["Inventory queue"]
  B -->|rule| Q3["Email queue"]
  Q1 --> L1["Payment Lambda"]
  Q2 --> L2["Inventory Lambda"]
  Q3 --> L3["Email Lambda"]
  Q1 -.-> D[DLQs]
  B -.-> AR[Archive]

1. Producers retry PutEvents and check FailedEntryCount. For stronger guarantees, write the event and an outbox row in one DynamoDB transaction and publish from there.
2. One rule per consumer routes into an SQS queue for buffering and back-pressure, each with a DLQ and retry policy.
3. Consumers are idempotent, using the order ID as the dedup key.
4. Multi-step flows like payment and inventory reservation run as a Step Functions saga with compensations.
5. An archive on the bus allows replay after a bug fix, scoped to the repaired rule.
6. Global endpoints give regional failover when the business needs it.
7. Alarms on FailedInvocations, DLQ depth and consumer age make failures visible.

Events stay small and carry IDs, with a schemaVersion and a correlation ID so a single order can be traced across services.