--- title: "Amazon MQとSQSの違い：プロトコル互換・料金構造・移行判断を東京の実額で比較" url: "https://www.issoh.co.jp/tech/details/18445/" published: 2026-10-17 updated: 2026-10-17 categories: ["AWS"] publisher: "株式会社一創" --- # Amazon MQとSQSの違い：プロトコル互換・料金構造・移行判断を東京の実額で比較 Amazon MQとAmazon SQSは、どちらもAWSでメッセージを受け渡すサービスですが、中身は別物です。Amazon MQはActiveMQとRabbitMQをAWSが運用するメッセージブローカーで、SQSはAWS独自のAPIで呼ぶフルマネージドのキューです。本記事では、接続プロトコルと配信モデルの違い、同じ送受信を書いたPythonコード、東京リージョンの料金構造と損益分岐、既存のActiveMQ・RabbitMQから移すときの判断基準を整理しました。SQS単体の仕組みは[Amazon SQSとは？標準キューとFIFOの違い・可視性タイムアウトとDLQ設計を解説](https://www.issoh.co.jp/tech/details/17241/)で扱っています。版番号と単価は2026年10月時点で確認した公式情報です。 ## まとめ：既存のJMS・AMQP資産を残すならAmazon MQ、新規はSQSが基本 判断の軸はプロトコル互換です。JMS・AMQP・MQTT・STOMPで書かれた既存アプリを、コードをほとんど変えずにAWSへ移すならAmazon MQを選びます。プロトコルの縛りが無い新規開発なら、SQSのほうが運用も料金も軽く済みます。トピック配信やルーティングが欲しい場合も、SQSとSNSの組み合わせで足りる場面が大半です。 料金の形も違います。Amazon MQはブローカーが動いている時間で課金され、メッセージが0件でも月額が発生します。SQSは100万リクエスト単位の従量課金で、東京の標準キューは100万件あたり0.40ドルです。冗長構成のActiveMQ（mq.m5.large）の月額をSQSに置き換えると、平均で毎秒170件前後のメッセージを処理してようやく同額になります。 ## Amazon MQとSQSの設計の違い｜ブローカー型とキュー型で変わる接続と運用 両者の違いは、アプリがどの言葉で話しかけるか、誰がサーバーを持つかの2点にまとまります。 ### 標準プロトコルで話すAmazon MQと独自APIで呼ぶSQSの接続方式 Amazon MQは、VPCの中に立てたブローカーへ標準プロトコルで接続します。[Amazon MQのセキュリティのベストプラクティス](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/using-amazon-mq-securely.html)では、ActiveMQブローカーのポートとしてAMQPが5671、MQTTが8883、OpenWireが61617、STOMPが61614、WebSocketが61619と示され、使うプロトコルのポートだけをセキュリティグループで開けるよう勧めています。既存のJMSクライアントやRabbitMQクライアントが接続先を書き換えるだけで動くのは、この互換性があるためです。 SQSはHTTPSのAPIで、SDKの`SendMessage`や`ReceiveMessage`を呼びます。ActiveMQやRabbitMQのプロトコルは話せません。代わりにブローカーの台数やディスクを考える必要がなく、IAMのポリシーだけで送信元と受信側を制御できます。AMQPそのものの仕組みは[AMQPとは？0-9-1と1.0の違い・ルーティングの仕組み](https://www.issoh.co.jp/tech/details/16247/)で、MQTTは[MQTTとは？Pub/Subの仕組み・QoS・MQTT 5.0の実装](https://www.issoh.co.jp/tech/details/15819/)で解説しています。 ### ActiveMQ 5.19とRabbitMQ 4.3が動くMQのエンジン選択と版管理 Amazon MQでは、ブローカーを作るときにエンジンを選びます。[ActiveMQの版管理のページ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/activemq-version-management.html)では5.19が推奨、5.18もサポート中で、5.17は2025年6月16日にサポートを終えました。サポート終了を迎えた版は、終了日から45日以内のメンテナンスウィンドウで次の版へ自動的に上げられます。 [RabbitMQの版管理のページ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/rabbitmq-version-management.html)は4.3を推奨しており、4.3と4.2はmq.m7gインスタンスでのみ動きます。3.13で選べるインスタンスはmq.t3・mq.m5・mq.m7gです。RabbitMQのstreamsは非対応で、作るとデータを失うと明記されています。版の更新日程を自分で追う作業はSQSには無く、Amazon MQを選ぶと引き受ける運用の一つです。 ### 配信モデルとSQSの上限値で比べるキュー・トピック・ルーティング 配信モデルと上限値を並べると、違いがはっきりします。SQSの値は[SQSのメッセージのクォータ](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/quotas-messages.html)から取りました。 | 観点 | Amazon MQ | Amazon SQS | | ------- | --------- | ---------- | | 形態 | ブローカー | キュー | | 接続 | JMS・AMQP等 | 独自API | | Pub/Sub | トピック・交換機 | SNSと併用 | | 順序保証 | エンジン依存 | FIFOキュー | | 最大サイズ | エンジン依存 | 1MiB | | 保持期間 | ディスク容量次第 | 最大14日 | | 拡張 | インスタンス変更 | 自動 | | 課金 | 稼働時間 | リクエスト数 | SQSの標準キューは毎秒のAPI呼び出し数がほぼ無制限で、FIFOキューはパーティションあたり毎秒300件、10件バッチなら3,000件です。高スループットモードのFIFOなら、東京で毎秒9,000トランザクションまで伸びます。1つのメッセージを複数の受信者へ配るには、SQSだけでは足りません。[Amazon SNSとは｜Pub/Sub通知の仕組み・配信先](https://www.issoh.co.jp/tech/details/15612/)のトピックからSQSへファンアウトする形が定番です。 ## 同じ送受信をコードで比べる｜pikaでAmazon MQ、boto3でSQSを操作 違いが最も表に出るのはクライアントのコードです。同じ「注文IDを1件送る」処理を両方で書きます。 ### Amazon MQ for RabbitMQへ5671番のTLSで接続し送信するコード [Amazon MQのpikaの手順](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/amazon-mq-rabbitmq-pika.html)に沿い、TLSのコンテキストを渡して5671番へ接続します。エンドポイントと認証情報はブローカーの詳細画面の値を環境変数に入れておきます。 ``` import os import ssl import pika # Amazon MQ for RabbitMQ は AMQP over TLS（5671番）で受け付ける params = pika.ConnectionParameters( host=os.environ["MQ_HOST"], # ブローカー詳細画面のエンドポイント port=5671, virtual_host="/", credentials=pika.PlainCredentials(os.environ["MQ_USER"], os.environ["MQ_PASS"]), ssl_options=pika.SSLOptions(ssl.create_default_context()), ) with pika.BlockingConnection(params) as conn: ch = conn.channel() # RabbitMQ 4.2 以降の既定はクォーラムキュー。3.13 と揃えるなら明示する ch.queue_declare(queue="orders", durable=True, arguments={"x-queue-type": "quorum"}) ch.basic_publish(exchange="", routing_key="orders", body=b'{"order_id": 1001}', properties=pika.BasicProperties(delivery_mode=2)) ``` 接続の確立、キューの宣言、交換機とルーティングキーの指定まで、クライアント側が受け持ちます。オンプレミスのRabbitMQで動いていたコードなら、変わるのは接続パラメータの部分だけです。 ### SQSへboto3で送りロングポーリングで受信して削除するコード SQSでは接続という概念が無く、キューのURLに対してAPIを呼びます。[boto3のsend\_message](https://docs.aws.amazon.com/boto3/latest/reference/services/sqs/client/send%5Fmessage.html)で送り、受信側は[ロングポーリング](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-short-and-long-polling.html)の上限20秒で待ちます。 ``` import json import boto3 sqs = boto3.client("sqs", region_name="ap-northeast-1") url = sqs.get_queue_url(QueueName="orders")["QueueUrl"] # 送信側：1回の SendMessage が1リクエストとして課金される sqs.send_message(QueueUrl=url, MessageBody=json.dumps({"order_id": 1001})) # 受信側：最大10件・最大20秒待つロングポーリング resp = sqs.receive_message(QueueUrl=url, MaxNumberOfMessages=10, WaitTimeSeconds=20) for msg in resp.get("Messages", []): print(msg["Body"]) # 削除しないと可視性タイムアウト（既定30秒）の後に再配信される sqs.delete_message(QueueUrl=url, ReceiptHandle=msg["ReceiptHandle"]) ``` 受信後の明示的な削除が要る点が、ブローカーのack（確認応答）との違いです。送信・受信・削除の3回がそれぞれ課金対象になるため、次章の料金比較もこの回数で数えます。 ## 東京リージョンの料金構造を比較｜時間課金のMQとリクエスト課金のSQS 単価は、AWSのPrice List APIで取得した2026年9月11日公開版の東京リージョン（ap-northeast-1）の値です。公式の表は[Amazon MQの料金](https://aws.amazon.com/amazon-mq/pricing/)と[Amazon SQSの料金](https://aws.amazon.com/sqs/pricing/)にあります。 ### ブローカーの稼働時間とストレージで決まるAmazon MQの月額 Amazon MQは、選んだインスタンスと構成の時間単価に稼働時間を掛け、ストレージ代を足した額が月額になります。月730時間で計算した主な構成は次のとおりです。 | エンジンと構成 | 時間単価 | 月額の目安 | | ---------------------- | --------- | -------- | | ActiveMQ t3.micro 単一 | 0.03536ドル | 約25.8ドル | | ActiveMQ m5.large 単一 | 0.372ドル | 約271.6ドル | | ActiveMQ m5.large 冗長 | 0.744ドル | 約543.1ドル | | RabbitMQ m7g.medium 単一 | 0.1765ドル | 約128.8ドル | | RabbitMQ m7g.large 3台 | 1.0593ドル | 約773.3ドル | 表の「冗長」はアクティブ／スタンバイのマルチAZ構成、「3台」はRabbitMQの3ノードクラスターです。ストレージはActiveMQのEFS（耐久性重視）が1GB月あたり0.36ドル、EBSが0.12ドルで、RabbitMQはEBSの0.12ドルです。本番で単一インスタンスを選ぶとブローカーの停止がそのまま業務停止になるため、実際の比較対象は冗長構成の543ドルや773ドルになります。 ### 100万リクエスト0.40ドルのSQSとMQの月額が並ぶ処理量の目安 SQSは、全リージョン合算で毎月最初の100万リクエストが無料です。東京の標準キューは100万リクエストあたり0.40ドルで、月1,000億リクエストを超えた分は0.35ドル、2,000億超は0.32ドルに下がります。FIFOキューの開始単価は100万リクエストあたり0.50ドルです。ペイロードは64KBごとに1リクエストと数えます。 ActiveMQの冗長構成543.1ドルを標準キューの単価で割ると、約13.6億リクエストです。1件のメッセージに送信・受信・削除の3リクエストが要るとすれば、月4.5億件、平均で毎秒約172件になります。10件ずつのバッチで送受信すればこの数はさらに10倍近くまで伸びるため、一般的な業務システムの非同期処理では、SQSの請求額がMQの冗長構成を超える場面はまれです。データ転送料はどちらにも別途かかります。SQS単体の料金の試算は、[Amazon SQSの料金を東京リージョンの実額で試算する：64KB課金・FIFO単価・ロングポーリングでの削減手順](https://www.issoh.co.jp/tech/details/18453/)で段階制の単価と件数からの月額計算として扱っています。 ## ActiveMQ・RabbitMQからAWSへ移す判断｜MQへ載せ替えかSQSへ書き換えか オンプレミスのブローカーを移すときの選択肢は、Amazon MQへそのまま載せるか、SQSに合わせてアプリを書き換えるかの2つです。 ### SQS Java Messaging Libraryで既存JMSアプリを動かせる範囲 JMSで書かれたJavaアプリには、中間の選択肢があります。AWSが公開する[Amazon SQS Java Messaging Library](https://github.com/awslabs/amazon-sqs-java-messaging-lib)は、SQSをJMSのプロバイダーとして使えるようにするライブラリで、READMEにはJakarta Messaging 3.1仕様に沿うこと、Mavenの依存例として2.1.4が示されています。 ただし対応範囲は狭めです。[対応するJMS 1.1の実装の一覧](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/supported-implementations.html)に載っているのは`Connection`・`Session`・`MessageProducer`・`MessageConsumer`などのキュー系で、トピックのインターフェイスは含まれていません。メッセージ型も`TextMessage`・`ObjectMessage`・バイト列の3種で、`MapMessage`は対象外です。トピックやメッセージセレクタ、トランザクションに頼るアプリは、このライブラリでは移せないと見ておきます。 ### RabbitMQ 4系はmq.m7g限定でクォーラムキューが既定になる注意点 RabbitMQをAmazon MQへ移す場合、新しくブローカーを作成する際の候補は4系です。[RabbitMQ 4のページ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/rabbitmq-4.html)によると、3.13から4.2、4.2から4.3へのインプレース更新ができ、4.2ではキュー種別を指定しないとクォーラムキューが作られます。クラシックキューは全ての場合で耐久性が保証されないため、耐久性が要るならクォーラムキューを使うよう勧められています。 見落としやすいのは監視です。4系ではキュー単位のメトリクスがCloudWatchに出ず、ブローカー単位のメトリクスだけになります。キューごとの滞留を監視していた仕組みは、RabbitMQの管理APIを1分以上の間隔で問い合わせる形への作り直しが必要です。RabbitMQとKafkaのどちらを残すかで迷っている段階なら、[RabbitMQとKafkaの違いとは？設計思想・性能・使い分け](https://www.issoh.co.jp/tech/details/15305/)を先に読むと整理しやすくなります。 ### AWS CLIで移行先のエンジン版とインスタンス構成の対応を事前確認 移す前に、使いたいインスタンスでどの版と構成が選べるかをAWS CLIで確かめます。[describe-broker-instance-options](https://docs.aws.amazon.com/cli/latest/reference/mq/describe-broker-instance-options.html)は、エンジンとインスタンスタイプで絞り込めます。 ``` aws mq describe-broker-instance-options --region ap-northeast-1 \ --engine-type RABBITMQ --host-instance-type mq.m7g.large \ --query "BrokerInstanceOptions[].{Type:HostInstanceType,Storage:StorageType,Modes:SupportedDeploymentModes,Versions:SupportedEngineVersions}" \ --output json ``` `Modes`には`SINGLE_INSTANCE`・`ACTIVE_STANDBY_MULTI_AZ`・`CLUSTER_MULTI_AZ`のいずれかが入ります。`--engine-type ACTIVEMQ`に変えれば、ActiveMQで選べるストレージ（EFSかEBS）も一覧で確認できる仕組みです。オンプレミスで動いている版がこの一覧に無い場合は、移行と同時に版を上げる計画が要ります。 ## Amazon MQを選ぶ条件とSQSへ寄せる条件｜採用と見送りの判断基準 ここまでの違いを踏まえ、判断を言い切ります。迷ったときの既定値はSQSです。 ### 既存プロトコル・トピック配信・オンプレ併用ならAmazon MQを採用 次のどれかに当たるなら、Amazon MQを選びます。 - JMSのトピック、メッセージセレクタ、トランザクションに依存したアプリを、書き換えずにAWSへ移したい - 工場の機器や外部の取引先がMQTT・STOMP・AMQPでつないでおり、接続先の仕様を変えられない - オンプレミスのブローカーとAWS側を当面並行稼働させ、段階的に切り替えたい とくに1つ目は、SQS Java Messaging Libraryでも代替できない部分です。書き換えの工数がブローカーの月額数百ドルを上回るなら、Amazon MQに載せて移行を先に終わらせるほうが筋が通ります。 ### 新規開発はSQSを選びAmazon MQを見送る場面と移行の進め方 新しく作るシステムでプロトコルの縛りが無いなら、Amazon MQは採用しません。ブローカーの版の更新、インスタンスサイズの見直し、冗長構成の月額という3つの負担を、得るものが無いまま抱えることになるためです。複数の受信者への配信はSNSからSQSへのファンアウトで組めます。サービスごとの役割分担は[AWS SQS・SNS・SESの違いと使い分け](https://www.issoh.co.jp/tech/details/9310/)で整理しています。 既存システムの移行でも、Amazon MQは終着点ではなく中継地点として使う考え方があります。まずMQへ載せてオンプレミスを止め、その後に新しく書く処理からSQSへ寄せていく流れです。ブローカーの移行計画やSQSへの書き換えの範囲決めは[インフラ構築（AWS・Google Cloud・Azure）](https://www.issoh.co.jp/service/system/aws/)でご相談いただけます。 ## よくある質問 Amazon MQとSQSの違いについて、よく出る疑問に公式ドキュメントの記載をもとに答えます。 ### Amazon MQとSQSはどちらが安いですか？ 処理量が少ないうちは、ほぼ確実にSQSが安くなります。SQSは毎月100万リクエストまで無料で、東京の標準キューは100万リクエストあたり0.40ドルです。Amazon MQはメッセージが0件でもブローカーの時間料金がかかり、東京のActiveMQ冗長構成（mq.m5.large）では月約543ドルかかります。この金額にSQSが並ぶのは、平均で毎秒170件前後のメッセージを送受信し続けたときです。 ### SQSでActiveMQのトピックのような配信はできますか？ SQS単体では、1件のメッセージは1つの受信者にしか渡りません。複数の受信者へ同じメッセージを届けたい場合は、Amazon SNSのトピックにSQSキューを複数購読させるファンアウト構成を使います。SNSのサブスクリプションフィルターを使えば、メッセージ属性による配信先の絞り込みも可能です。ActiveMQのトピックを使うJMSコードをそのまま動かしたいなら、Amazon MQを選びます。 ### Amazon MQで順序保証や重複排除はできますか？ Amazon MQの順序や重複の扱いを決めるのは、選択したエンジンの仕様です。ActiveMQやRabbitMQの1つのキューを1つのコンシューマーが読む限り順序は保たれますが、複数のコンシューマーで並列に読むと処理順は入れ替わります。SQSのFIFOキューのような、メッセージ重複排除IDによる5分間の重複排除はエンジン側に同じ機能が無いため、受信側で冪等に処理する設計が要ります。 ### Amazon MQからSQSへ移行するにはどこを書き換えますか？ 書き換えるのは、接続・送信・受信と確認応答の部分です。SQSには接続という概念が無く、キューのURLに対してSendMessage・ReceiveMessage・DeleteMessageを呼びます。ブローカーのackに当たるのがDeleteMessageで、削除しないメッセージが再配信されるのは可視性タイムアウト後です。JMSのキューだけを使うJavaアプリなら、Amazon SQS Java Messaging Libraryで書き換え量を減らせます。 ### Amazon MQに無料利用枠はありますか？ あります。AWSの無料利用枠の対象は、mq.t2.microかmq.t3.microの単一インスタンスのブローカーです。ただし単一インスタンスは冗長化されていないため、検証用と割り切ります。無料枠を外れた場合の東京のmq.t3.micro単一インスタンスは、1時間0.03536ドル、月730時間で約25.8ドルです。RabbitMQ 4系はmq.m7gでしか動かないため、無料枠のインスタンスでは3.13までしか試せません。 ## 関連記事 - [Amazon SQSとは？標準キューとFIFOの違い・可視性タイムアウトとDLQ設計を解説](https://www.issoh.co.jp/tech/details/17241/)：SQSを採用した後の設計（可視性タイムアウトとDLQ）。 - [RabbitMQとKafkaの違いとは？設計思想・性能・使い分けの判断基準を実装視点で解説](https://www.issoh.co.jp/tech/details/15305/)：ブローカーを残す場合のエンジン選び。 - [AMQPとは？0-9-1と1.0の違い・ルーティングの仕組みと採用判断を実装者向けに解説](https://www.issoh.co.jp/tech/details/16247/)：Amazon MQが話すプロトコルの仕様。 - [Amazon SNSとは｜Pub/Sub通知の仕組み・配信先・FIFO/フィルタリングと採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15612/)：SQSでトピック配信を組むときの相方。 - [Amazon EventBridgeとは？仕組み・料金とCLI・Pythonでの実装手順、新Custom Event Busとの違いを解説【2026年版】](https://www.issoh.co.jp/tech/details/15513/)：キュー以外のイベント連携の選択肢。 --- 出典: [Amazon MQとSQSの違い：プロトコル互換・料金構造・移行判断を東京の実額で比較]()（株式会社一創）