2026.10.17 AWS

Amazon MQとSQSの違い：プロトコル互換・料金構造・移行判断を東京の実額で比較

Amazon MQとAmazon SQSは、どちらもAWSでメッセージを受け渡すサービスですが、中身は別物です。Amazon MQはActiveMQとRabbitMQをAWSが運用するメッセージブローカーで、SQSはAWS独自のAPIで呼ぶフルマネージドのキューです。本記事では、接続プロトコルと配信モデルの違い、同じ送受信を書いたPythonコード、東京リージョンの料金構造と損益分岐、既存のActiveMQ・RabbitMQから移すときの判断基準を整理しました。SQS単体の仕組みはAmazon SQSとは？標準キューとFIFOの違い・可視性タイムアウトとDLQ設計を解説で扱っています。版番号と単価は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のセキュリティのベストプラクティスでは、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の違い・ルーティングの仕組みで、MQTTはMQTTとは？Pub/Subの仕組み・QoS・MQTT 5.0の実装で解説しています。

ActiveMQ 5.19とRabbitMQ 4.3が動くMQのエンジン選択と版管理

Amazon MQでは、ブローカーを作るときにエンジンを選びます。ActiveMQの版管理のページでは5.19が推奨、5.18もサポート中で、5.17は2025年6月16日にサポートを終えました。サポート終了を迎えた版は、終了日から45日以内のメンテナンスウィンドウで次の版へ自動的に上げられます。

RabbitMQの版管理のページは4.3を推奨しており、4.3と4.2はmq.m7gインスタンスでのみ動きます。3.13で選べるインスタンスはmq.t3・mq.m5・mq.m7gです。RabbitMQのstreamsは非対応で、作るとデータを失うと明記されています。版の更新日程を自分で追う作業はSQSには無く、Amazon MQを選ぶと引き受ける運用の一つです。

配信モデルとSQSの上限値で比べるキュー・トピック・ルーティング

配信モデルと上限値を並べると、違いがはっきりします。SQSの値はSQSのメッセージのクォータから取りました。

観点	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通知の仕組み・配信先のトピックからSQSへファンアウトする形が定番です。

同じ送受信をコードで比べる｜pikaでAmazon MQ、boto3でSQSを操作

違いが最も表に出るのはクライアントのコードです。同じ「注文IDを1件送る」処理を両方で書きます。

Amazon MQ for RabbitMQへ5671番のTLSで接続し送信するコード

Amazon MQのpikaの手順に沿い、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で送り、受信側はロングポーリングの上限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の料金とAmazon SQSの料金にあります。

ブローカーの稼働時間とストレージで決まる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単価・ロングポーリングでの削減手順で段階制の単価と件数からの月額計算として扱っています。

ActiveMQ・RabbitMQからAWSへ移す判断｜MQへ載せ替えかSQSへ書き換えか

オンプレミスのブローカーを移すときの選択肢は、Amazon MQへそのまま載せるか、SQSに合わせてアプリを書き換えるかの2つです。

SQS Java Messaging Libraryで既存JMSアプリを動かせる範囲

JMSで書かれたJavaアプリには、中間の選択肢があります。AWSが公開するAmazon SQS Java Messaging Libraryは、SQSをJMSのプロバイダーとして使えるようにするライブラリで、READMEにはJakarta Messaging 3.1仕様に沿うこと、Mavenの依存例として2.1.4が示されています。

ただし対応範囲は狭めです。対応するJMS 1.1の実装の一覧に載っているのはConnection・Session・MessageProducer・MessageConsumerなどのキュー系で、トピックのインターフェイスは含まれていません。メッセージ型もTextMessage・ObjectMessage・バイト列の3種で、MapMessageは対象外です。トピックやメッセージセレクタ、トランザクションに頼るアプリは、このライブラリでは移せないと見ておきます。

RabbitMQ 4系はmq.m7g限定でクォーラムキューが既定になる注意点

RabbitMQをAmazon MQへ移す場合、新しくブローカーを作成する際の候補は4系です。RabbitMQ 4のページによると、3.13から4.2、4.2から4.3へのインプレース更新ができ、4.2ではキュー種別を指定しないとクォーラムキューが作られます。クラシックキューは全ての場合で耐久性が保証されないため、耐久性が要るならクォーラムキューを使うよう勧められています。

見落としやすいのは監視です。4系ではキュー単位のメトリクスがCloudWatchに出ず、ブローカー単位のメトリクスだけになります。キューごとの滞留を監視していた仕組みは、RabbitMQの管理APIを1分以上の間隔で問い合わせる形への作り直しが必要です。RabbitMQとKafkaのどちらを残すかで迷っている段階なら、RabbitMQとKafkaの違いとは？設計思想・性能・使い分けを先に読むと整理しやすくなります。

AWS CLIで移行先のエンジン版とインスタンス構成の対応を事前確認

移す前に、使いたいインスタンスでどの版と構成が選べるかをAWS CLIで確かめます。describe-broker-instance-optionsは、エンジンとインスタンスタイプで絞り込めます。

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の違いと使い分けで整理しています。

既存システムの移行でも、Amazon MQは終着点ではなく中継地点として使う考え方があります。まずMQへ載せてオンプレミスを止め、その後に新しく書く処理からSQSへ寄せていく流れです。ブローカーの移行計画やSQSへの書き換えの範囲決めはインフラ構築（AWS・Google Cloud・Azure）でご相談いただけます。

よくある質問

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までしか試せません。