Amazon MQ + EventBridge Routing

Route events with EventBridge and migrate a message broker with Amazon MQ.

Introduction

30 Second Summary

Not every message in a system needs the same delivery method. Some need to reach exactly one recipient, while others need to be automatically routed to different destinations based on their content.

In this project, you will launch a managed message broker and build event routing rules that automatically direct different event types to different AWS targets. You'll work with two services side-by-side: Amazon MQ for migrating existing messaging apps to the cloud, and EventBridge for intelligent, content-based routing.

What You'll Build

You'll open your broker's built-in web console to send and browse messages through queues and topics, then switch to EventBridge and watch custom events automatically route to completely different AWS targets depending on what's inside them.

By the end of this project, you'll have:

  • A running Amazon MQ broker where you send messages through a queue (point-to-point delivery) and a topic (fan-out to all subscribers) using the built-in ActiveMQ Web Console.
  • Two EventBridge rules performing content-based routing: order events flow to CloudWatch Logs while payment failure alerts trigger an SNS email notification, all from the same event bus.
  • A live demonstration where you send an event that vanishes into nothing, then add a single routing rule and watch the same event type trigger an instant email alert.
  • Secret Mission: Enable EventBridge Archive and Replay to store past events and replay them on demand.

Are there any prerequisites?

This is Project 3 in the Application Integration series. You should have completed Project 1 (SQS + SNS) and Project 2 (Kinesis), or have equivalent understanding of those services.

Before We Start

Before We Start...

Before we dive in, let's lock in what you're about to build and why it matters for your SAA-C03 exam preparation.

Launch the Amazon MQ Broker and Create Supporting Resources

Your Amazon MQ broker takes about 15 minutes to provision. If you start it first, you can work on EventBridge in Steps 2 and 3 while the broker spins up in the background.

In this step, you will launch the broker and create the two AWS resources that EventBridge will route events to later: an SNS topic for email alerts and a CloudWatch Logs group for order event records.

In this step, get ready to:
  • Launch an Amazon MQ ActiveMQ broker with public accessibility.
  • Create an SNS topic and confirm an email subscription.
  • Create a CloudWatch Logs log group for EventBridge events.
Create an Amazon MQ ActiveMQ broker

Amazon MQ is a managed message broker service that supports standard messaging protocols like JMS, AMQP, and STOMP. It exists for one purpose: letting you migrate on-premises applications to AWS without rewriting their messaging code.

  • Open the Amazon MQ console by navigating to https://console.aws.amazon.com/amazon-mq/ in your browser.
  • Click Create brokers.
  • Under Select broker engine, choose Apache ActiveMQ.
  • Click Next.

Why ActiveMQ?

ActiveMQ is the most common open-source message broker used in enterprise on-premises systems. On the SAA-C03 exam, when a question mentions migrating an app that uses JMS, AMQP, STOMP, or MQTT, the answer is Amazon MQ with ActiveMQ.

  • Under Deployment mode, select Single-instance broker.
  • Under Storage type, select EFS.
  • Click Next.

What is EFS storage?

EFS (Elastic File System) provides shared storage that persists your messages even if the broker restarts. For a single-instance broker, EFS is the recommended choice.

  • In the Broker name field, enter exam-mq-broker.
  • For Broker instance type, select mq.t3.micro.
  • Under ActiveMQ Web Console access, enter a username of your choice.
  • Enter a password that is at least 12 characters long.

Remember your credentials

Write down your username and password somewhere safe. You will need them in Step 4 to log into the ActiveMQ Web Console and send messages.

  • Expand the Additional settings section.
  • Under Public accessibility, confirm it is set to Yes. Enable it if it is not already selected.
  • Click Deploy.

Why enable public accessibility?

Public accessibility lets you open the ActiveMQ Web Console in your browser without setting up a VPN or SSH tunnel. For a production system you would keep the broker private, but for learning it saves a lot of networking setup.

You should now see your broker listed with status Creation in progress. This takes about 15 minutes. Do not wait for it to finish.

What does mq.t3.micro cost?

If your AWS account is within its first 12 months, you get up to 750 hours per month of a single-instance mq.t3.micro broker for free under the AWS Free Tier. Outside Free Tier, the broker costs approximately $0.03 per hour while running.

Create an SNS topic and subscribe your email

Your second EventBridge rule (built in Step 3) will route payment failure events to an SNS topic that emails you. You need the topic and a confirmed subscription ready before that step.

  • Open the Amazon SNS console by searching for SNS in the AWS console search bar and selecting Simple Notification Service.
  • In the left navigation panel, click Topics.
  • Click Create topic.
  • For Type, select Standard.
  • In the Name field, enter payment-failure-alerts.
  • Scroll to the bottom and click Create topic.

Your topic is now created. Next, add an email subscription so you actually receive notifications.

  • On the topic detail page, click Create subscription.
  • For Protocol, select Email.
  • In the Endpoint field, enter your email address.
  • Click Create subscription.

Check your inbox now

AWS sends a confirmation email within a minute or two. Open the email and click the Confirm subscription link. If you do not confirm, EventBridge events routed to this topic will not reach your inbox.

After confirming, return to the SNS console. Your subscription status should show Confirmed.

Don't see the confirmation email?

Check your spam or junk folder. The email comes from no-reply@sns.amazonaws.com. If it still has not arrived after two minutes, delete the subscription in the console and recreate it with the correct email address.

Still stuck? Help me troubleshoot my SNS subscription confirmation.

Create a CloudWatch Logs log group

Your first EventBridge rule (built in Step 2) will send order events to a CloudWatch Logs log group. Creating the log group now means it is ready when you wire up the rule.

  • Open the CloudWatch console by searching for CloudWatch in the AWS console search bar.
  • In the left navigation pane, click Log groups (under Logs).
  • Click Create log group.
  • In the Log group name field, enter /eventbridge/order-events.
  • Click Create.

You should see /eventbridge/order-events appear in your list of log groups.

Why this naming convention?

Prefixing with /eventbridge/ makes it easy to identify which log groups are EventBridge targets. This is a common organizational pattern when your AWS account has many log groups.

Verify all three resources exist

Before you move on, take a moment to predict: what status do you expect the Amazon MQ broker to show right now, given that you started it a few minutes ago?

  • Return to the Amazon MQ console.
  • Confirm your broker exam-mq-broker shows status Creation in progress (or Running if 15 minutes have passed).
  • Open the SNS console and confirm your topic payment-failure-alerts appears with one confirmed subscription.
  • Open the CloudWatch Logs console and confirm the log group /eventbridge/order-events appears.

All three resources are in place. The broker will keep provisioning in the background while you work through the next steps.

Broker stuck on Creation in progress for over 20 minutes?

Broker creation occasionally takes longer than 15 minutes. If it has been over 20 minutes, check that you selected mq.t3.micro and Single-instance broker. Larger instance types or active/standby deployments take longer.

If the status changes to Creation failed, delete the broker and recreate it. Help me troubleshoot my Amazon MQ broker creation.

Your supporting resources are ready and the broker is on its way. Next up, you will build your first EventBridge rule and watch it route a custom event to your CloudWatch Logs group.

Create Your First EventBridge Content-Based Routing Rule

In Step 1, you launched your Amazon MQ broker and created the supporting resources that will serve as EventBridge targets. Now it's time to put EventBridge to work.

EventBridge sits idle until you define rules that tell it where to send matching events. Without a rule, custom events land on the default bus and disappear into the void.

In this step, get ready to:
  • Create an EventBridge rule that matches "Order Placed" events on the default event bus.
  • Send a custom test event through the EventBridge console.
  • Verify the event arrives in CloudWatch Logs.
Create a rule matching "Order Placed" events

An EventBridge rule watches for events that match a specific pattern and forwards them to a target. Your first rule will catch "Order Placed" events and route them to the CloudWatch Logs group you created in Step 1.

  • Open the Amazon EventBridge console at https://console.aws.amazon.com/events/.
  • In the navigation pane, choose Rules.
  • Choose Create rule.
  • For Name, enter route-order-events.
  • For Event bus, select default.
  • For Rule type, choose Rule with an event pattern.
  • Choose Next.

Now you will define the event pattern that tells EventBridge which events to match.

  • For Event source, choose Other.
  • For Creation method, choose Custom pattern (JSON editor).
  • In the Event pattern field, paste the following JSON:
{
  "source": ["custom.orderapp"],
  "detail-type": ["Order Placed"]
}

What does this pattern do?

This pattern tells EventBridge to match only events where the source is custom.orderapp AND the detail-type is Order Placed.

Any event that does not match both fields will be ignored by this rule. This is what makes EventBridge powerful for content-based routing.

  • Choose Next to proceed to targets.
  • For Target types, choose AWS service.
  • For Select a target, choose CloudWatch log group from the drop-down list.
  • For Log Group, select /eventbridge/order-events.
  • Choose Next to skip tags.
  • Choose Next again to reach the review page.
  • Review your rule details, then choose Create rule.

You should see route-order-events listed in your rules with status Enabled.

Don't see your rule listed?

  • Make sure you selected the default event bus. Rules on other buses will not appear in the default view.
  • Check that you chose Create rule on the final review page. If you navigated away before confirming, the rule was not saved.

Why isn't my EventBridge rule showing up?

Send a matching custom event

Your rule is active but has not received any events yet. You will now send a custom event through the EventBridge console to test the routing.

  • In the EventBridge console navigation pane, choose Event buses.
  • In the Default event bus tile, choose Actions, then Send events.
  • For the event source field, enter custom.orderapp.
  • For Detail type, enter Order Placed.
  • For Event detail, paste the following JSON:
{
  "orderId": "ORD-12345",
  "customer": "jane.doe",
  "amount": 79.99,
  "region": "us-east-1"
}

What are these three fields?

Every custom event sent to EventBridge requires three fields: a source (who sent it), a detail-type (what kind of event it is), and event detail (the payload).

The source and detail-type are what your rule pattern matches against. The event detail is the actual data payload delivered to the target.

  • Choose Send.

You should see a confirmation that the event was successfully sent to the default event bus.

Verify the event in CloudWatch Logs

Before you check, predict what you expect to find. Do you think the order event JSON will appear in your log group, or will the log group be empty?

  • Open the CloudWatch console and navigate to Log groups in the left navigation pane.
  • Select the /eventbridge/order-events log group.
  • Open the latest log stream (it may take a few seconds to appear).

You should see the full event JSON payload, including your order details like ORD-12345 and jane.doe.

What does this prove?

EventBridge matched your custom event against the pattern in your rule and automatically routed it to the CloudWatch Logs target. No polling, no manual wiring.

This is the core of content-based routing: events go where they belong based on their content, not based on a subscriber list.

Log group is empty?

  • Wait 10-15 seconds and refresh the page. EventBridge delivery to CloudWatch Logs is near-instant but the console may need a manual refresh.
  • Verify the event source you typed matches exactly: custom.orderapp (no capital letters, no extra spaces).
  • Verify the detail type you typed matches exactly: Order Placed (capital O and P, with a space).

Why isn't my event showing up in CloudWatch Logs?

Your first content-based routing rule is working. Next up, you will see what happens when an event does NOT match any rule, proving why EventBridge is more powerful than simple fan-out.

Prove Content-Based Routing With a Second Event Type

In the previous step, you proved that EventBridge can route a custom event to a target. Your "Order Placed" event landed in CloudWatch Logs exactly as expected.

But here is the real question: what happens when a different event type hits the same bus? With SNS, every subscriber receives every message by default. EventBridge works the opposite way. It only delivers events that match a rule's pattern. Everything else is silently dropped. You are about to see this gap firsthand, then fix it.

In this step, get ready to:
  • Send a "Payment Failed" event and observe it get silently dropped.
  • Create a second EventBridge rule targeting your SNS topic.
  • Resend the event and receive an email notification proving content-based routing.
Send a non-matching event and observe the gap

Your only rule right now matches events with a detail-type of "Order Placed". A "Payment Failed" event has a different detail-type, so no rule should catch it.

Before you send it, predict: do you think this event will show up in CloudWatch Logs, trigger an email, or vanish entirely?

  • Return to the EventBridge console at https://console.aws.amazon.com/events/.
  • In the navigation pane, choose Event buses.
  • In the Default event bus tile, choose Actions, then Send events.
  • For Event bus, leave it set to default.
  • For Event source, enter custom.orderapp.
  • For Detail type, enter Payment Failed.
  • For Event detail, enter the following JSON:
{
  "orderId": "ORD-12345",
  "customer": "jane.doe",
  "errorCode": "CARD_DECLINED",
  "amount": 79.99
}
  • Choose Send.

Now check both possible destinations to confirm the event went nowhere.

  • Open CloudWatch and navigate to Log groups.
  • Select the /eventbridge/order-events log group and open the latest log stream.
  • Confirm there is no new entry for a "Payment Failed" event.
  • Check your email inbox. No notification arrived.

The event was silently dropped because no rule on the default bus matched it. This is the designed behaviour.

Why did the event disappear?

EventBridge performs content-based filtering at the rule level. If no rule's event pattern matches an incoming event, that event is discarded. It does not get stored, queued, or retried.

This is fundamentally different from SNS, which delivers every published message to all subscribers by default. EventBridge gives you precise control over which events reach which targets.

Create a second rule for payment failures

To catch "Payment Failed" events, you need a second rule with its own event pattern and target.

  • Return to the EventBridge console.
  • In the navigation pane, choose Rules.
  • Choose Create rule.
  • For Name, enter route-payment-failures.
  • For Event bus, select default.
  • For Rule type, choose Rule with an event pattern.
  • Choose Next.
  • For Event source, choose Other.
  • For Creation method, choose Custom pattern (JSON editor).
  • Enter the following event pattern:
{
  "source": ["custom.orderapp"],
  "detail-type": ["Payment Failed"]
}

What does this pattern do?

This pattern tells EventBridge to match only events whose source field equals custom.orderapp AND whose detail-type equals Payment Failed. Both conditions must be true for the rule to fire.

  • Choose Next.
  • For Target types, choose AWS service.
  • For Select a target, choose SNS topic from the dropdown.
  • For Topic, select payment-failure-alerts.
  • Choose Next.
  • Choose Next again to skip tags.
  • Review the details, then choose Create rule.

Don't see your SNS topic in the dropdown?

Make sure you are in the same AWS Region where you created the payment-failure-alerts topic. Check the region selector in the top-right corner of the console.

Help me troubleshoot my missing SNS topic

Resend the payment failed event and verify content-based routing

The second rule is now live. Before you resend the event, predict: will the email arrive this time? Will CloudWatch Logs also get this event, or only the SNS topic?

  • Navigate back to Event buses in the EventBridge console.
  • In the Default event bus tile, choose Actions, then Send events.
  • Enter the same values as before: source custom.orderapp, detail type Payment Failed.
  • For Event detail, enter the same JSON:
{
  "orderId": "ORD-12345",
  "customer": "jane.doe",
  "errorCode": "CARD_DECLINED",
  "amount": 79.99
}
  • Choose Send.

Now verify the routing worked correctly by checking both destinations.

  • Check your email inbox. You should receive an SNS notification containing the event payload with the CARD_DECLINED error code.
  • Open CloudWatch Logs and select the /eventbridge/order-events log group.
  • Confirm there is no new entry for this event type.

The "Payment Failed" event reached your email via SNS, but did not appear in CloudWatch Logs. That proves the routing is content-specific. Same event bus, different destinations depending on the event's detail-type.

Why is this an exam-critical concept?

EventBridge provides rule-based, content-aware routing. Different events go to different targets based on their content, all from a single event bus.

SNS cannot do this natively. SNS subscription filter policies offer basic attribute filtering, but EventBridge is far more powerful for complex routing across many services and accounts. On the SAA-C03, when a scenario mentions "route events to different targets based on event content," the answer is EventBridge.

You have just proven content-based routing. Two rules on the same bus route events to completely different targets based on their content. Next up, you will explore Amazon MQ and discover why it exists for a completely different use case.

Explore Amazon MQ - Queues and Topics in the ActiveMQ Web Console

In the previous step, you proved that EventBridge routes different events to different targets based on their content. Now it's time to shift to a completely different integration service: Amazon MQ.

Amazon MQ exists for one specific reason. It lets you migrate on-premises applications that use standard messaging protocols (AMQP, OpenWire, STOMP) into AWS without rewriting their code. Your broker has been provisioning while you worked on EventBridge, and it should now show "Running" status.

In this step, get ready to:
  • Access the ActiveMQ Web Console for your running broker.
  • Send and browse a message on a queue (point-to-point delivery).
  • Send a message on a topic (pub/sub delivery).
Access the ActiveMQ Web Console

The ActiveMQ Web Console is a built-in management UI that ships with every Amazon MQ broker. It lets you create queues, send messages, and browse message contents directly from your browser.

  • Navigate to the Amazon MQ console at https://console.aws.amazon.com/amazon-mq/.
  • Click on your broker name exam-mq-broker.
  • Confirm the Status shows Running.
  • Scroll down to the Connections section.
  • Find the ActiveMQ web console URL. It follows this format: https://b-<identifier>.mq.<region>.amazonaws.com:8162.
  • Open that URL in a new browser tab.
  • Log in with the username and password you created when you set up the broker in Step 1.

You should see the ActiveMQ Web Console dashboard with navigation tabs along the top, including Home, Queues, Topics, and Send.

Can't access the Web Console?

If the page won't load, confirm that Public accessibility was enabled when you created the broker. Without it, the console URL is only reachable from within the broker's VPC.

If you see a login error, double-check the username and password. The password must be at least 12 characters long.

help me troubleshoot why I can't access my Amazon MQ ActiveMQ Web Console

Send and browse a message on a queue (point-to-point)

A queue delivers each message to exactly one consumer. This is point-to-point delivery, the same pattern you saw with SQS in Project 1 of this series.

  • In the ActiveMQ Web Console, click Queues in the top navigation.
  • In the Queue Name text box, type order.queue.
  • Click Create.
  • Click the Send To link next to order.queue.
  • In the message body field, type Order ORD-99999 placed for customer john.smith.
  • Click Send.

Before you check the queue, what do you expect to find there? Will the message be gone (consumed) or still sitting in the queue waiting?

  • Click Queues in the top navigation to return to the queue list.
  • Click Browse next to order.queue.

You should see your message listed in the queue. It is still there because no consumer has picked it up yet. This is point-to-point delivery: the message waits for exactly one consumer.

What does this prove?

Browsing the queue shows the message sitting there, just like a message would sit in an SQS queue waiting for a consumer to poll it. The difference is that Amazon MQ uses industry-standard protocols (AMQP, OpenWire, STOMP) instead of AWS proprietary APIs.

This means an existing on-premises application using any of these protocols can migrate to Amazon MQ with minimal code changes. That is the entire reason this service exists.

Why would you choose Amazon MQ over SQS?

SQS is the better choice for new cloud-native applications because it scales automatically and requires no infrastructure management. Amazon MQ is for lift-and-shift migrations only, when you have an existing application built on standard messaging protocols that cannot be re-engineered.

On the SAA-C03 exam, look for keywords like "migrate existing broker", "JMS", "AMQP", "STOMP", or "on-premises messaging" as signals to choose Amazon MQ.

Send a message on a topic (pub/sub)

A topic delivers each message to every subscriber listening. This is pub/sub delivery, the same pattern you saw with SNS in Project 1.

  • Click Topics in the top navigation.
  • In the Topic Name text box, type order.notifications.
  • Click Create.
  • Click Send To next to order.notifications.
  • In the message body field, type New order notification for all subscribers.
  • Click Send.

You should see a confirmation that the message was sent. Unlike the queue, you cannot browse a topic's messages after the fact because topics deliver in real time to active subscribers only.

Queues vs topics in one broker

You just used both a queue (point-to-point) and a topic (pub/sub) within a single Amazon MQ broker. This is like having SQS and SNS combined in one managed service, using standard protocols instead of AWS APIs.

The tradeoff: Amazon MQ has lower throughput and less automatic scalability than SQS/SNS. Use it only when migrating existing applications that cannot be re-engineered to use AWS-native services.

SAA-C03 exam decision framework

You have now built with all five application integration services. Here is your complete decision framework:

  • New app, simple fan-out to multiple subscribers = SNS + SQS.
  • New app, complex event routing based on content/rules = EventBridge.
  • Migrating existing broker app using standard messaging protocols = Amazon MQ.
  • Real-time streaming with ordering, replay, and multiple consumers = Kinesis Data Streams.
  • Near-real-time delivery to S3/Redshift/OpenSearch = Kinesis Data Firehose.

Key differentiators: EventBridge has richer filtering than SNS but lower throughput. Amazon MQ has queue + topic (like SQS + SNS combined) but does not scale as well. Kinesis supports replay via shard retention. EventBridge supports replay via Archive. SQS and SNS do not support replay.

Topic not appearing in the list?

Make sure you clicked Create after typing the topic name. Simply typing the name without clicking the button does not create the topic.

help me troubleshoot why my topic is not showing up in the ActiveMQ Web Console

Secret mission

Enable EventBridge Archive and Replay

What happens when critical events are lost before anyone notices? EventBridge Archive and Replay lets you store events and reprocess them on demand. Configure an archive with pattern filtering, then replay past events to prove recovery works.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running or delete them entirely. The Amazon MQ broker is the primary cost driver in this project, billed at ~$0.03/hr for mq.t3.micro (or free if your account is within its first 12 months of the AWS Free Tier).

Cost warning

You cannot pause or stop an Amazon MQ broker. It continues to accrue charges as long as it exists. If you are done experimenting, delete the broker now to avoid ongoing costs.

EventBridge rules have no standing cost (you pay per event). The archive is charged for storage at $0.023/GB-month, which is negligible for this project's volume. SNS and CloudWatch Logs costs are effectively zero at this scale.

Resources you used:

  • Amazon MQ broker: exam-mq-broker (ActiveMQ, mq.t3.micro).
  • EventBridge rules: route-order-events and route-payment-failures on the default event bus.
  • EventBridge archive: order-events-archive on the default event bus.
  • SNS topic: payment-failure-alerts with email subscription.
  • CloudWatch Logs log group: /eventbridge/order-events.

Keep everything running

No action needed. Choose this if you plan to continue experimenting with the broker and EventBridge today.

  • The Amazon MQ broker continues to accrue charges (~$0.03/hr, or free within the AWS Free Tier's 750 hours/month for the first year).
  • All other resources (EventBridge rules, archive, SNS topic, CloudWatch Logs) have negligible or zero cost at this scale.

Pause - I'll come back to this later

Amazon MQ does not support stopping or pausing a broker. To stop charges, you must delete the broker. The other resources (EventBridge rules, archive, SNS topic, CloudWatch Logs) are effectively free and can be left in place.

  • Delete the Amazon MQ broker (follow the Delete tab instructions for just the broker step).
  • Keep the EventBridge rules, archive, SNS topic, and CloudWatch Logs log group. They cost nothing or next to nothing while idle.
  • When you return, you can recreate the broker by following Step 1 again.

Delete - I don't want to use this again

Remove all project resources completely. Follow each step below.

  • Delete the Amazon MQ broker: Open the Amazon MQ console. Select exam-mq-broker from the broker list. Choose Delete. In the confirmation dialog, type delete and choose Delete. Deletion takes about 5 minutes.
  • Delete the EventBridge rules: Open the EventBridge console. In the navigation pane, choose Rules. Select route-order-events. Choose Delete, then confirm Delete. Repeat for route-payment-failures.
  • Delete the EventBridge archive: In the EventBridge console, navigate to Archives. Select order-events-archive. Choose Delete. Enter the archive name and choose Delete.
  • Delete the SNS topic: Open the Amazon SNS console. Select payment-failure-alerts. Choose Delete and confirm.
  • Delete the CloudWatch Logs log group: Open the CloudWatch console. Navigate to Log groups. Select /eventbridge/order-events. Choose Delete and confirm.

That's a Wrap!

That's a Wrap!

Nice work! You have just built a side-by-side demonstration of two AWS application integration services that solve fundamentally different problems.

You've learned how to:

  • Launch a managed Amazon MQ broker and send messages through both a queue (point-to-point) and a topic (pub/sub), proving the lift-and-shift migration use case for applications using standard messaging protocols.
  • Build EventBridge rules that perform content-based routing from the same default event bus, sending "Order Placed" events to CloudWatch Logs and "Payment Failed" events to SNS email automatically.
  • Complete your SAA-C03 Application Integration Decision Framework covering all five services: SQS for simple queuing, SNS for fan-out, Kinesis for real-time streaming, EventBridge for complex content-based routing, and Amazon MQ for lift-and-shift migrations.
  • Secret Mission: Enabled EventBridge Archive and Replay to store and reprocess past events on demand.

Ready to quiz yourself?