Amazon MQ って結局なんなの？ メッセージブローカーの必要性から ActiveMQ / RabbitMQ との関係まで AWS 公式ドキュメントで深掘りした

どーも！shihopowerです！

今回は Amazon MQ についてまとめました。

SAP 対策をしていると「マネージドメッセージブローカーサービス」という説明が出てきて、何となくイメージはできるんですが、「そもそもメッセージブローカーって何が嬉しいの？どういう場面で使うの？」というところが曖昧なままでした。

そこで今回は根本から調べ直すことにして、以下の3つの問いに答える形でまとめています。

• そもそもメッセージブローカーはどういう場面で必要になるのか？
• Amazon MQ とはどんなサービスで、何ができるのか？
• Apache ActiveMQ・RabbitMQ と Amazon MQ はどういう関係なのか？

本記事はAWS 公式ドキュメントをもとに参照しています。

---

⏱️ 忙しい人向けの要約

Q. メッセージブローカーはどういうときに必要？
→ コンポーネント間を「直接つなぐ」と密結合になり、片方が遅い・落ちると連鎖障害になる。ブローカーを挟むことで送り手と受け手を切り離し（疎結合）、負荷の平準化・非同期処理・複数システムへの同時配信などが実現できる。

Q. Amazon MQ って何？
→ Apache ActiveMQ と RabbitMQ というオープンソースのメッセージブローカーを、AWS が代わりに運用してくれるマネージドサービス。ハードウェアのプロビジョニング・ソフトウェアのアップグレード・障害対応などをすべて AWS が担う。

Q. ActiveMQ / RabbitMQ と Amazon MQ はどう違う？
→ ActiveMQ・RabbitMQ は「ブローカーエンジン（メッセージングの本体）」、Amazon MQ は「そのエンジンを AWS 上で動かすための基盤」。エンドポイントを切り替えるだけで移行でき、アプリのコード変更は不要。

	ActiveMQ / RabbitMQ	Amazon MQ
役割	メッセージングエンジン本体	エンジンを動かすマネージド基盤
提供元	オープンソースコミュニティ	AWS
運用管理	自分で行う	AWS が代行
コードの変更	─	不要（エンドポイント変更のみ）

詳しく読みたい方は続きへどうぞ！

---

目次

1. メッセージブローカーが必要になる場面
   • 1-1. なぜ「直接つなぐ」だけでは足りないのか
   • 1-2. 必要になる具体的な場面
   • 1-3. メッセージングの3パターン整理
2. Amazon MQ とは
   • 2-1. 定義
   • 2-2. 主な機能
   • 2-3. どんな人・組織が使うべきか
3. Apache ActiveMQ・RabbitMQ と Amazon MQ の関係
   • 3-1. 「ブローカーエンジン」という概念
   • 3-2. Amazon MQ が「管理する」こと・しないこと
   • 3-3. コードを書き換えずに移行できる理由
   • 3-4. ActiveMQ と RabbitMQ の違い（Amazon MQ 上での扱い）
4. まとめ：3者の関係を整理する
5. 参考ドキュメント

---

1. メッセージブローカーが必要になる場面

1-1. なぜ「直接つなぐ」だけでは足りないのか

アプリケーションが複数のコンポーネントで構成される場合、それらはネットワークを介して通信しなければなりません。

AWS のホワイトペーパー「Implementing Microservices on AWS」では、コンポーネント間の通信手段として REST・GraphQL・gRPC などの同期通信と、非同期メッセージングが挙げられています。

同期通信（REST など）は「呼び出し元が応答を待ち続ける方式」です。シンプルで直感的ですが、規模が大きくなると次のような問題が生じます。

• 受け手が遅いと送り手も詰まる（ボトルネック）
• 受け手がダウンすると送り手も止まる（密結合）
• トラフィックが急増すると捌ききれない（バースト問題）

こうした課題が現れたとき、メッセージブローカーの出番です。

AWS の公式ドキュメントでは次のように定義されています。

非同期メッセージングはキューを通じてメッセージを送受信することでサービス間の通信を可能にし、サービスを疎結合に保ちサービスディスカバリを促進する。
（出典：Communication mechanisms - Implementing Microservices on AWS）

---

1-2. 必要になる具体的な場面

AWS 公式ドキュメントをもとに整理すると、メッセージブローカーが必要になる場面は主に以下の6つです。

① コンポーネント間を「疎結合」にしたいとき

送り手（プロデューサー）と受け手（コンシューマー）がお互いの存在を直接知らなくてよい状態を作れます。

非同期のポーリングモデルを使うことで、バックエンドシステムはリクエストを受け取ると即座にリクエスト識別子を返し、その後非同期でリクエストを処理します。これにより疎結合なアーキテクチャを構築でき、同期通信・レイテンシ・I/O操作によるボトルネックを回避できます。
（出典：Decouple messaging pattern - AWS Prescriptive Guidance）

② 非同期処理・負荷の平準化が必要なとき

メッセージキューは送り手（プロデューサー）と受け手（コンシューマー）を切り離すバッファとして機能します。プロデューサーはキューにメッセージを入れ、コンシューマーはそれを取り出して処理します。このパターンは非同期通信・負荷の平準化・トラフィックのバーストへの対応に有効です。
（出典：Communication mechanisms - Implementing Microservices on AWS）

たとえば注文が一気に殺到したとき、キューがバッファとなり、処理能力に合わせてゆっくり消化できます。

③ 1つのイベントを複数のシステムに同時に届けたいとき（Pub/Sub）

パブリッシュ／サブスクライブパターンでは、メッセージがトピックに発行され、関心を持つ複数のサブスクライバーがそのメッセージを受け取ります。このパターンにより、複数のコンシューマーへのイベントやメッセージの非同期ブロードキャストが可能になります。
（出典：Communication mechanisms - Implementing Microservices on AWS）

AWS の公式ドキュメントはその具体例として、航空会社のフライトステータス更新が、手荷物管理やゲート業務など接続されたすべてのシステムに AMQP などのプロトコルを使って通知されるシナリオを挙げています。
（出典：Choosing an AWS application integration service）

④ イベント駆動アーキテクチャを実現したいとき

イベント駆動メッセージングは、システムで発生したイベントを捕捉しそれに反応することを意味します。イベントはメッセージブローカーに発行され、関心を持つサービスが特定のイベントタイプを購読します。このパターンは疎結合を実現し、直接依存関係なしにサービスがイベントに反応できるようにします。
（出典：Communication mechanisms - Implementing Microservices on AWS）

⑤ 異なる言語・プラットフォーム・プロトコルのシステムをつなぐとき

多くのアプリケーションは AMQP や MQTT などの特定プロトコルを使ってメッセージングサービスに接続していたり、Spring Boot・Celery・MassTransit などのフレームワーク依存があったりします。こうしたアプリケーションのポータビリティを維持するため、必要なプロトコルをサポートするメッセージングサービスの選択が重要になります。
（出典：Choosing an AWS application integration service）

⑥ 複雑なメッセージルーティングが必要なとき

AWS の公式ドキュメントでは保険会社の例が挙げられています。異なる種類（自動車・住宅・生命）のクレームを受け取り、それぞれ異なるビジネスルールに従って適切な宛先にルーティングする必要がある場合です。
（出典：Choosing an AWS application integration service）

---

1-3. メッセージングの3パターン整理

AWS のホワイトペーパーでは、非同期メッセージングを次の3種類に分類しています。
（出典：Communication mechanisms - Implementing Microservices on AWS）

パターン	概要	典型的な場面
メッセージキュー	送受信を切り離すバッファ。1対1の通信	注文処理・バッチジョブ
パブリッシュ／サブスクライブ	1つのトピックを複数のサブスクライバーへ配信	フライト状況更新・在庫変更通知
イベント駆動メッセージング	システムで発生したイベントをブローカーに発行し、関心のあるサービスが反応	マイクロサービス間のイベント伝播

---

2. Amazon MQ とは

2-1. 定義

Amazon MQ は、Apache ActiveMQ Classic および RabbitMQ 向けのマネージド型メッセージブローカーサービスであり、メッセージブローカーのセットアップ・運用・メンテナンスを管理します。業界標準のメッセージングプロトコルを使用して新規ブローカーを作成することも、既存のメッセージブローカーをコードの書き換えなしに Amazon MQ へ移行することも可能です。
（出典：What is Amazon MQ? - Amazon MQ Developer Guide）

**「ブローカー」**とは Amazon MQ 上で動作するメッセージブローカー環境のことで、Amazon MQ の基本構成単位です。

---

2-2. 主な機能

① マネージドサービス（運用負荷の軽減）

AWS Management Console、AWS CloudFormation、CLI、またはシンプルな API 呼び出しで、本番環境対応のメッセージブローカーを数分で起動できます。Amazon MQ は、ハードウェアのプロビジョニング、ブローカーのセットアップ、ソフトウェアのアップグレード、障害検知とリカバリーといった管理タスクをすべて担います。
（出典：Amazon MQ Features）

② セキュリティ

Amazon MQ は保存中・転送中のメッセージを暗号化します。ブローカーへの接続は SSL を使用し、Amazon VPC 内のプライベートエンドポイントに制限することができます。また、AWS IAM と連携することで、特定の Amazon MQ ブローカーに対して IAM ユーザー・グループが実行できる操作を制御できます。
（出典：What is Amazon MQ? - Amazon MQ Developer Guide）

③ 高可用性（HA）とメッセージ耐久性

ActiveMQ 向けの耐久性最適化ブローカーは Amazon EFS をバックエンドとし、複数のアベイラビリティーゾーン（AZ）にまたがってメッセージを冗長的に保存します。アクティブ/スタンバイブローカーは、ブローカーまたは AZ の障害発生時に自動フェイルオーバーします。

また、Amazon EBS をバックエンドとするスループット最適化ブローカーもサポートしており、大量注文処理・株式取引・テキスト処理など高スループットが必要なユースケースに対応します。
（出典：Amazon MQ Features）

④ クォーラムキュー（RabbitMQ）

クォーラムキューは、リーダーノード（プライマリレプリカ）とフォロワーノード（その他のレプリカ）で構成されたレプリケーション型のキューです。各ノードは異なるアベイラビリティーゾーンに配置されているため、あるノードが一時的に利用できなくなっても、別の AZ で新しいリーダーレプリカが選出されてメッセージ配信が継続されます。
（出典：What is Amazon MQ? - Amazon MQ Developer Guide）

⑤ クロスリージョンデータレプリケーション（ActiveMQ）

クロスリージョンデータレプリケーション（CRDR）により、プライマリリージョンのプライマリブローカーからレプリカリージョンのレプリカブローカーへ、非同期でメッセージをレプリケートできます。Amazon MQ API にフェイルオーバーリクエストを発行することで、レプリカブローカーをプライマリに昇格させることが可能です。
（出典：What is Amazon MQ? - Amazon MQ Developer Guide）

⑥ Amazon CloudWatch との統合

ブローカーやキューのメトリクスが自動的に収集され、毎分 CloudWatch にプッシュされます。Amazon MQ コンソール・CloudWatch コンソール・CLI・API から確認・分析できます。
（出典：What is Amazon MQ? - Amazon MQ Developer Guide）

⑦ 他の AWS サービスとの統合

Amazon EC2・Amazon ECS・AWS Lambda など AWS のコンピューティングサービス上で動作するすべてのアプリケーションから Amazon MQ を利用できます。また以下のサービスと統合されています。
（出典：Amazon MQ FAQs）

統合サービス	用途
Amazon CloudWatch	メトリクス監視・アラーム
Amazon CloudWatch Logs	ブローカーのログ発行
AWS CloudTrail	API 呼び出しの記録・監視
AWS CloudFormation	ブローカーの作成・更新・削除の自動化
AWS EventBridge Pipes	Amazon MQ ブローカーをイベントソースとして利用
AWS Lambda	Amazon MQ ブローカーをイベントソースとして利用
AWS IAM	サービス API の認証・認可
AWS KMS	データ暗号化キーの管理

---

2-3. どんな人・組織が使うべきか

Amazon MQ は、業界標準のメッセージング API・プロトコルを採用してクラウド上でアプリケーションを疎結合・スケールさせたいが、メッセージブローカー自体の運用負荷は負いたくないという、エンタープライズ IT 専門家・開発者・アーキテクトに適しています。
（出典：Amazon MQ FAQs）

Amazon MQ vs. EC2 上に自分でインストールする場合

Amazon MQ を使うことで、ブローカーのプロビジョニング、セキュリティパッチ、セットアップ・設定、ブローカーバージョンのアップグレード、リカバリーといった管理タスクを気にする必要がなくなります。一方、機能のカスタマイズやカスタムプラグインの利用といった、より高度な制御が必要な場合は、Amazon EC2 上に直接ブローカーをインストールして運用することを検討してください。
（出典：Amazon MQ FAQs）

---

3. Apache ActiveMQ・RabbitMQ と Amazon MQ の関係

ここが個人的に一番スッキリしなかったところです。「Amazon MQ」と「ActiveMQ / RabbitMQ」は別物なのか、それとも同じものなのか？

結論から言うと、「エンジン」と「マネージドサービス」の関係です。

3-1. 「ブローカーエンジン」という概念

AWS の公式ドキュメントでは、ActiveMQ と RabbitMQ を**「ブローカーエンジン」**と呼んでいます。

ブローカーエンジン（Broker Engine）とは、Amazon MQ 上で動作するメッセージブローカーの種類のことです。
（出典：Amazon MQ Developer Guide - Supported engine versions）

ブローカーを作成する際には、エンジンの種類（ACTIVEMQ か RABBITMQ）を必須パラメーターとして指定します。バージョン（例：ActiveMQ 5.18、RabbitMQ 3.13）も指定可能で、指定しない場合は最新バージョンがデフォルトになります。
（出典：AWS::AmazonMQ::Broker - AWS CloudFormation）

つまり Amazon MQ でブローカーを作るとは、「ActiveMQ か RabbitMQ か、どちらのエンジンを使うか」を選ぶことを意味します。

Amazon MQ でブローカーを作成するとき
　　　↓
どちらのエンジンを使いますか？
　　　├── Apache ActiveMQ
　　　└── RabbitMQ

---

3-2. Amazon MQ が「管理する」こと・しないこと

Amazon MQ はメッセージブローカーのセットアップ・インフラのプロビジョニング・オープンソースのブローカーエンジンソフトウェアの管理プロセスを担います。ブローカーが稼働したあとは、継続的なソフトウェアアップグレード・セキュリティ更新・障害検知・リカバリーを管理します。
（出典：Amazon MQ FAQs）

ActiveMQ や RabbitMQ 自体のプロトコル・API・メッセージングの振る舞いは、それぞれのオープンソースソフトウェアのものがそのまま使われます。Amazon MQ はそのインフラ運用面だけを肩代わりするサービスです。

項目	Amazon MQ が担う	利用者が担う
ハードウェアのプロビジョニング	✅	─
ソフトウェアのインストール・設定	✅	─
バージョンアップグレード	✅（自動 or 手動）	─
障害検知・リカバリー	✅	─
メッセージングロジックの設計	─	✅
アプリケーションコードの実装	─	✅
カスタムプラグインの利用	❌（非対応）	EC2 直接構築なら ✅

---

3-3. コードを書き換えずに移行できる理由

Amazon MQ と ActiveMQ / RabbitMQ の関係で最も重要なポイントが「コードの互換性」です。

Amazon MQ は ActiveMQ コンソール・RabbitMQ コンソールへの直接アクセスのほか、JMS・NMS・AMQP 0.9.1・AMQP 1.0・STOMP・MQTTv3・WebSocket などの業界標準 API・プロトコルに直接アクセスできます。既存のメッセージブローカーからコードを書き換えることなく Amazon MQ へ移行することも可能です。
（出典：Amazon MQ FAQs）

AMQP・MQTT・MQTT over WebSocket・OpenWire・STOMP・STOMP over WebSocket などの業界標準プロトコルを現在使用している場合、コード変更なしにそのまま Amazon MQ へ接続できます。
（出典：What is the Amazon MQ migration guide? - Amazon MQ）

つまり、エンドポイントを切り替えるだけで既存アプリケーションをそのまま使い続けられます。

---

3-4. ActiveMQ と RabbitMQ の違い（Amazon MQ 上での扱い）

同じ Amazon MQ でも、選択するエンジンによって特性が異なります。

Apache ActiveMQ の特徴

Apache ActiveMQ はオープンソースのマルチプロトコル対応の Java ベースのメッセージブローカーです。Amazon MQ はデフォルトで ActiveMQ Classic バージョン 5.18 をサポートします。
（出典：Amazon MQ FAQs）

サポートされるプロトコル・API：

ActiveMQ は JMS v1.1・JMS v2.0・NET Message Service（NMS）など幅広いクライアントをサポートするほか、AMQP・STOMP・OpenWire・WebSocket・MQTT といった多様なワイヤレベルプロトコルもサポートします。これにより既存メッセージブローカーからの移行・ベンダー間の相互運用性の確保・ベンダー依存の回避が容易になります。
（出典：Amazon MQ Features）

JMS の標準機能も網羅：

ActiveMQ は JMS の標準機能（ポイント・ツー・ポイント、パブリッシュ／サブスクライブ、リクエスト・リプライ、永続・非永続モード、JMS トランザクション、分散（XA）トランザクション）をすべて提供します。さらに、複合デスティネーション（プロデューサーが同一メッセージを複数デスティネーションに送信）や仮想デスティネーション（パブリッシャーがキューを経由してサブスクライバーへブロードキャスト）といった複雑なパターンもサポートします。
（出典：Amazon MQ Features）

RabbitMQ の特徴

RabbitMQ はオープンソースのマルチプロトコル対応メッセージブローカーで、幅広いメッセージングユースケースをサポートします。Amazon MQ はデフォルトで RabbitMQ バージョン 3.13 をサポートします。
（出典：Amazon MQ FAQs）

メッセージルーティングの特徴：

RabbitMQ ブローカーでは、メッセージはキューに届く前にエクスチェンジを通じてルーティングされます。RabbitMQ には典型的なルーティングロジック向けに複数のビルトインエクスチェンジタイプが用意されています。また、クラシックキュー・クラシックミラーキュー・クォーラムキューなど複数のキュータイプをサポートします。
（出典：Amazon MQ Features）

2つのエンジンの比較

比較軸	ActiveMQ	RabbitMQ
主なプロトコル	JMS・OpenWire・AMQP・STOMP・MQTT	AMQP 0-9-1（メイン）
メッセージルーティング	デスティネーション（キュー・トピック）ベース	エクスチェンジを経由したルーティング
高可用性構成	Active/Standby・ブローカーネットワーク	3ノードクラスター（マルチAZ）
ストレージ	EFS（耐久性最適化）/ EBS（スループット最適化）	EBS
認証	ユーザー名・パスワード + LDAP 対応	ユーザー名・パスワード + OAuth 2.0 対応
デフォルトバージョン	5.18	3.13

---

4. まとめ：3者の関係を整理する

最後に、Amazon MQ・ActiveMQ・RabbitMQ の関係を図で整理します。

┌─────────────────────────────────────────────────────┐
│                   Amazon MQ                         │
│             （AWSのマネージドサービス層）              │
│                                                     │
│  ・インフラのプロビジョニング                         │
│  ・ソフトウェアのアップグレード                       │
│  ・障害検知・リカバリー                              │
│  ・CloudWatch / IAM / KMS 等との統合                │
│                                                     │
│    ┌──────────────┐      ┌───────────────┐          │
│    │  ActiveMQ    │      │   RabbitMQ    │          │
│    │（ブローカー  │      │（ブローカー   │          │
│    │  エンジン）  │      │  エンジン）   │          │
│    └──────────────┘      └───────────────┘          │
└─────────────────────────────────────────────────────┘
              ↑ 既存アプリは標準プロトコル・APIで接続
              　（エンドポイント変更のみ・コード変更不要）

観点	ActiveMQ / RabbitMQ	Amazon MQ
役割	メッセージングの本体（エンジン）	エンジンを動かすマネージド基盤
提供元	Apache / オープンソースコミュニティ	AWS
プロトコル	JMS・AMQP・STOMP・MQTT 等	同上（互換性を維持）
運用管理	自分で行う	AWS が代行
コードの変更	─	不要（エンドポイント変更のみ）

Amazon MQ は RabbitMQ や Apache ActiveMQ といったオープンソースのメッセージブローカーをプロビジョニング・管理するフルマネージドサービスです。インフラのプロビジョニング・ブローカーのセットアップ・ソフトウェアの更新といったタスクを処理します。
（出典：Announcing Amazon MQ for RabbitMQ - AWS）

ActiveMQ・RabbitMQ というオープンソースの資産をそのまま活かしながら、その運用負荷だけを AWS に委ねるのが Amazon MQ の本質的な役割です。

---

5. 参考ドキュメント

• What is Amazon MQ? - Amazon MQ Developer Guide
• Amazon MQ FAQs
• Amazon MQ Features
• What is the Amazon MQ migration guide? - Amazon MQ
• Communication mechanisms - Implementing Microservices on AWS
• Choosing an AWS application integration service
• Decouple messaging pattern - AWS Prescriptive Guidance
• AWS::AmazonMQ::Broker - AWS CloudFormation Template Reference
• Announcing Amazon MQ for RabbitMQ - AWS