Amazon SQSの料金を東京リージョンの実額で試算する：64KB課金・FIFO単価・ロングポーリングでの削減手順

Amazon SQSの料金は、メッセージの件数ではなくAPIを呼んだ回数で決まります。単価は小さいものの、数え方を知らないまま設計すると、空振りの受信や大きなペイロードで請求が想定の何倍にもなります。本記事では、東京リージョンの単価表、メッセージ件数から月額を出す計算式、KMS暗号化やLambdaのイベントソースで増える付帯課金、請求を下げる設定の順番を、そのまま動かせるコードとともに整理しました。SQSの仕組みそのものはAmazon SQSとは？標準キューとFIFOの違い・可視性タイムアウトとDLQ設計を解説で扱っています。単価は2026年10月時点で確認した公式情報です。

まとめ：東京の標準キューは100万リクエスト0.40ドル、請求は呼び出し回数で決まる

東京リージョンの標準キューは100万リクエストあたり0.40ドル、FIFOキューは0.50ドルです。毎月最初の100万リクエストは無料で、ペイロードは64KBごとに1リクエストと数えます。1件のメッセージには送信・受信・削除の3回の呼び出しが要るため、1日10万件を処理しても月額は数ドルに収まる計算です。

請求が跳ねる原因は、ほぼ次の3つに絞られます。メッセージが無いのに受信を呼び続けるショートポーリング、64KBを超えるペイロード、1件ずつのAPI呼び出しです。ロングポーリングを20秒にし、送受信と削除を10件のバッチにまとめれば、リクエスト数は桁単位で減ります。

東京リージョンのSQS単価を確認する｜標準・FIFO・公平キューと無料枠の一覧

まず単価と、何が1リクエストとして数えられるかを押さえます。単価はAWSのPrice List APIで取得した2026年9月11日公開版の東京リージョン（ap-northeast-1）の値で、公式の表はAmazon SQSの料金ページにあります。

標準キュー0.40ドルとFIFO0.50ドルの段階制単価と月100万件の無料枠

SQSの単価は月間のリクエスト数に応じた3段階です。境界はアカウントの月間合計で判定されます。

表の金額は100万リクエストあたりです。無料枠は全リージョン合算で、標準とFIFOを問わず月100万リクエストまでかかりません。FIFOの単価が適用されるのは送信・受信・削除・可視性の変更の4種類で、キューの作成や属性の取得といった他の呼び出しは標準の単価で数えられます。1,000億リクエストは毎秒約3.8万回の呼び出しに相当するため、一般的な業務システムでは0.40ドルの段だけで計算して差し支えありません。

64KBごとに1リクエストと数える課金単位とバッチ10件の扱い

料金ページは「SQSのアクションはすべてリクエストとして数える」と明記しています。そのうえで、ペイロードは64KBごとに1リクエストとして請求され、1MiBのペイロードを持つ呼び出しは16リクエストになります。200KBのメッセージを1件送れば、64KBの区切りで4リクエストです。メッセージの上限はSQSのメッセージのクォータで1MiBまで広がっていますが、

逆に小さなメッセージは束ねるほど得をします。SQSのバッチアクションは1回の呼び出しで最大10件、合計1MiBまで扱えます。1KBのメッセージ10件をSendMessageBatchで送ると、合計10KBで64KBに収まるため1リクエストです。同じ10件を1件ずつ送れば10リクエストかかります。

Price List APIから東京の単価をPythonで取得するスクリプト

料金ページの表はJavaScriptで描画されるため、機械的に単価を確かめるならPrice List APIを使います。Price List Bulk APIの手順どおり、リージョン索引から東京版のファイルを引き、SQSのオファーコードAWSQueueServiceを読みます。認証は不要で、実行に必要なのはPython標準ライブラリだけです。

import json
import urllib.request

BASE = "https://pricing.us-east-1.amazonaws.com"

def get(path):
    with urllib.request.urlopen(BASE + path, timeout=120) as r:
        return json.load(r)

# 1) リージョン索引から東京（ap-northeast-1）版のURLを得る
idx = get("/offers/v1.0/aws/AWSQueueService/current/region_index.json")
offer = get(idx["regions"]["ap-northeast-1"]["currentVersionUrl"])
print("公開日:", offer["publicationDate"])

# 2) 商品ごとのオンデマンド単価を段階の境界つきで表示する
for sku, prod in offer["products"].items():
    usage = prod["attributes"].get("usagetype", "")
    for term in offer["terms"]["OnDemand"].get(sku, {}).values():
        for dim in term["priceDimensions"].values():
            usd = float(dim["pricePerUnit"]["USD"]) * 1_000_000  # 100万件あたりに換算
            print(f'{usage:28} {dim["beginRange"]:>13}〜{dim["endRange"]:<13} {usd:.2f}ドル')

出力にはAPN1-Requests-Tier1（標準）とAPN1-Requests-FIFO-Tier1（FIFO）が段階ごとに並び、無料枠はGlobal-Requestsとして0ドルで出ます。もう1つ、APN1-Requests-Fair-Tier1という100万件あたり0.10ドルの行があり、これが後述する公平キューの加算分です。

月額をメッセージ件数から試算する｜送信・受信・削除の3回と空受信を数える

単価が分かれば、あとは呼び出し回数の見積もりです。メッセージを処理する回数と、メッセージが無いのに呼んだ回数を分けて数えると、見積もりと実請求のずれが小さくなります。

1日10万件の注文処理で標準とFIFOの月額をバッチの有無で計算する手順

1日10万件、月30日で300万件のメッセージを、1件ずつ送って1件ずつ受信・削除する構成を考えます。ペイロードは64KB未満とします。

1件ずつの場合は、900万回から無料枠の100万回を引いた800万回に単価を掛けます。標準なら800万×0.40ドル÷100万で3.20ドル、FIFOなら4.00ドルです。10件バッチにすると合計90万回で無料枠に収まります。ただし無料枠はアカウント全体で共有されるため、他のキューやLambdaのポーリングがあれば、その分も合算して判定します。

ペイロードが200KBなら、送信と受信がそれぞれ4倍に数えられます。料金ページは「ペイロードを持つAPIアクション」と書いており、送信だけに限っていません。1件200KBを毎日10万件流すなら、本文をS3に置いて参照だけを送る設計を先に検討します。

常駐ワーカーのショートポーリングによる空受信で請求が20倍に膨らむ条件

見積もりから漏れやすいのが、メッセージが無いときの受信です。SQSのショートポーリングとロングポーリングの説明によると、既定はショートポーリングで、一部のサーバーだけを調べてメッセージが無くても即座に応答します。応答が空でも1リクエストとして課金されます。

常駐ワーカー10台が、1秒ごとにWaitTimeSecondsを0のまま受信を呼ぶとします。1台あたり月259万2,000回、10台で2,592万回になり、メッセージが1件も来なくても約10.37ドルかかります。ロングポーリングの上限20秒で待たせると、空のときの呼び出しは1台あたり20秒に1回、10台で月129万6,000回、約0.52ドルです。ロングポーリングは空応答に加え、メッセージがあるのに返らない偽の空応答も減らすと公式に書かれています。

CloudWatchで空受信の回数を日別に実測するAWS CLIの手順

既存のキューで空受信がどれだけ発生しているかは、CloudWatchで確かめられます。SQSのCloudWatchメトリクスでは、NumberOfEmptyReceivesがメッセージを返さなかった受信の回数で、API料金を下げるためにポーリング頻度の調整へ使うよう案内されています。

# 直近の日別で、空受信と実際に受け取ったメッセージ数を並べる
for m in NumberOfEmptyReceives NumberOfMessagesReceived NumberOfMessagesSent; do
  aws cloudwatch get-metric-statistics --region ap-northeast-1 \
    --namespace AWS/SQS --metric-name "$m" \
    --dimensions Name=QueueName,Value=orders \
    --start-time 2026-10-01T00:00:00Z --end-time 2026-10-16T00:00:00Z \
    --period 86400 --statistics Sum \
    --query "Datapoints[].[Timestamp,Sum]" --output text | sort | sed "s/^/$m /"
done

空受信の回数が送信メッセージ数の何倍にもなっていれば、ショートポーリングか、受信ループの待ち時間が短すぎるかのどちらかです。公式の注記どおり再試行を含む概数のため、請求書の数字とは完全には一致しません。

付帯課金を月額に足す｜SSE-KMSの呼び出し・データ転送・S3拡張クライアント

構成によっては別サービスの請求が加わります。料金ページが挙げているのは、KMSの呼び出し、リージョン外へのデータ転送、S3の保存料金の3つです。

SSE-KMSのKMS呼び出し回数をAWS公式の計算式で見積もる

サーバー側暗号化をKMSキー（SSE-KMS）で行うと、SQSがKMSを呼んだ分の料金がかかります。SQSのキー管理のページは、キューごとのKMS呼び出し数をR = (B / D) * (2 * P + C)で見積もるよう示しています。Bは請求期間の秒数、Dはデータキーの再利用期間、Pは送信側、Cは受信側のプリンシパル数です。

SQSの保管時の暗号化のページによると、再利用期間は60秒から86,400秒の間で既定は300秒です。30日間、既定の300秒、送信側3・受信側2のIAMロールで計算すると、8,640×8で月69,120回になります。KMSの料金は東京で1万リクエストあたり0.03ドル、月2万リクエストまで無料なので、約0.15ドルです。カスタマー管理キーを使う場合の追加料金は、1キーにつき月1ドルです。再利用期間を24時間にすれば同じ条件で月240回まで減るため、鍵の更新頻度に要件が無いなら延ばす余地があります。KMSの課金体系はAWS KMSとは？仕組み・料金とキーポリシー設計・採用判断を実装者目線で解説で整理しています。

同一リージョン無料のデータ転送とS3拡張クライアントの保存料金

データ転送は、同じリージョン内のリソースとの送受信なら料金がかかりません。オンプレミスから送る場合や、別リージョンのアプリが受信する場合は、AWSの通常のデータ転送料金がかかります。

1MiBを超えるペイロードを扱う定番は、Amazon SQS Extended Client Library for Javaで本文をS3に置き、メッセージには参照だけを載せる方法です。料金ページのとおりS3の保存料金とリクエスト料金が別にかかります。S3側の単価はS3の料金を実額で計算する｜東京リージョンの単価内訳とコストを下げる設定手順で確認できます。

Lambdaのイベントソースで変わるSQSの請求｜標準モードとプロビジョンドモード

SQSをLambdaのトリガーにすると、キューを読むのはLambdaのポーラーになります。ポーラーの呼び出しもSQSの請求に乗ります。

標準モードは低トラフィック時に最小2並列まで縮めて呼び出しを減らす

LambdaのSQSイベントソースのスケーリング設定によると、既定の標準モードでは標準キューをロングポーリングで読みます。トラフィックが落ちると5並列に戻り、さらにSQSの呼び出しと料金を減らすために2並列まで縮める場合があります。

注意したいのは、この2並列への縮小が「最大同時実行数」の設定を入れると効かなくなる点です。下流のデータベースを守る目的で最大同時実行数を付けると、夜間の空き時間に読みに行く回数が増える可能性があります。Lambda側の料金の内訳はAWS Lambdaの料金を東京リージョンの実額で計算する：付帯課金の内訳と単価を下げる手順にまとめました。

プロビジョンドモードは1ポーラーが毎秒最大10回ポーリングする前提で数える

プロビジョンドモードでは、イベントポーラーの最小数と最大数を自分で決めます。同じページの記載では、1ポーラーが最大で毎秒1MB、同時実行10、SQSのポーリング呼び出し毎秒10回を処理し、各ポーラーのロングポーリングはSQSのAPI料金の対象です。

上限の毎秒10回で数えると、1ポーラーあたり月2,592万回、約10.37ドルになります。最小ポーラー数を10にしておけば、上限で数えた場合の月額は約104ドルです。ここにLambda側のプロビジョンドモードの料金が別に加わります。スケールの速さが要らないキューでは、標準モードのままにしておくほうが両方の請求を抑えられます。

請求を下げる設定を入れる手順｜バッチ化・ロングポーリング・FIFOの選び方

試算で効き目の大きい順に、設定を入れていきます。

キュー属性の20秒待機とバッチ送受信・一括削除をboto3で入れる

最初にキュー属性ReceiveMessageWaitTimeSecondsを20秒にして、受信側のコードが待ち時間を指定し忘れてもロングポーリングになるようにします。次に送信と削除を10件単位のバッチに変えます。

import json
import boto3

sqs = boto3.client("sqs", region_name="ap-northeast-1")
url = sqs.get_queue_url(QueueName="orders")["QueueUrl"]

# 1) キューの既定をロングポーリング20秒にする（呼び出し側の指定漏れを防ぐ）
sqs.set_queue_attributes(QueueUrl=url, Attributes={"ReceiveMessageWaitTimeSeconds": "20"})

# 2) 10件をまとめて送る（合計64KB以内なら1リクエスト）
entries = [{"Id": str(i), "MessageBody": json.dumps({"order_id": 1000 + i})} for i in range(10)]
sent = sqs.send_message_batch(QueueUrl=url, Entries=entries)
for f in sent.get("Failed", []):  # バッチは一部だけ失敗することがある
    print("送信失敗:", f["Id"], f["Code"])

# 3) 最大10件を受け取り、処理後にまとめて削除する
resp = sqs.receive_message(QueueUrl=url, MaxNumberOfMessages=10, WaitTimeSeconds=20)
msgs = resp.get("Messages", [])
if msgs:
    sqs.delete_message_batch(
        QueueUrl=url,
        Entries=[{"Id": str(n), "ReceiptHandle": m["ReceiptHandle"]} for n, m in enumerate(msgs)],
    )

バッチの戻り値には成功と失敗が分かれて入るため、Failedを見て再送する処理を必ず付けます。Lambdaのトリガーで動かしている場合は、受信と削除はLambdaが行うので、追加する設定は、送信側のバッチ化だけで十分です。S3のイベントからLambda経由でSQSに流す実装例はCSV一括インポートをAWS Lambda×SQSで実装｜S3イベント・部分失敗・冪等の設計にあります。

FIFOの25%割増と公平キューの0.10ドル加算で選ぶキューの種類

FIFOキューを選ぶかどうかは、料金ではなく要件で決めます。1日10万件の試算でも差は月0.80ドルで、順序の入れ替わりや重複を受信側で吸収する実装の手間のほうがはるかに高くつきます。処理順が業務の正しさに関わるならFIFO、順序が要らず受信側を冪等に作れるなら標準キューという切り分けで十分です。

見落としやすいのが公平キューです。標準キューでMessageGroupIdを付けたメッセージを送ると、テナント単位の公平な配信が自動で効きます。料金ページによると、こうしたメッセージを含むリクエストには公平キューの料金と標準の料金が両方かかり、東京では0.40ドルに0.10ドルが加わって0.50ドルです。FIFOから標準キューへ移すときにMessageGroupIdを付けたまま送ると、単価が下がらないことになります。キュー設計からコストの見直しまで含めた構築はインフラ構築（AWS・Google Cloud・Azure）でご相談いただけます。

よくある質問

Amazon SQSの料金について、見積もりの段階でよく出る疑問に公式ドキュメントの記載をもとに答えます。

Amazon SQSの無料枠はいつまで使えますか？

公式の料金ページとFAQは、すべての利用者が毎月100万リクエストまで無料で使える月単位の枠と説明しており、利用開始から何か月といった期限の記載はありません。ただし全リージョンのキューの合計で数え、使い残した分は翌月に繰り越されません。標準キューとFIFOキューのどちらのリクエストも同じ100万の枠から差し引かれます。

メッセージを受信しただけでも料金はかかりますか？

かかります。SQSは送信・受信・削除・可視性の変更を含むすべてのアクションをリクエストとして数えるため、受信は1回ごとに課金対象です。メッセージが1件も返らなかった空の受信も同じく1リクエストになります。

SSE-SQSで暗号化した場合もKMSの料金はかかりますか？

サーバー側暗号化そのものに、SQSの追加料金はありません。料金ページがKMSの呼び出し料金を挙げているのはKMSキーで暗号化する場合で、SQSが管理する鍵を使うSSE-SQSについては個別の記載がありません。請求への影響を確かめたいときは、Cost Explorerでサービス別のKMSの金額を見ます。監査や鍵の失効を自分で管理したい要件があればSSE-KMSを選び、データキーの再利用期間を延ばしてKMSの呼び出し回数を抑えます。

SQSのデッドレターキューに料金はかかりますか？

デッドレターキュー自体は通常のSQSキューなので、キューを置いておくだけの料金はありません。ただし、デッドレターキューを監視して受信したり、元のキューへ戻したりする呼び出しは、通常のリクエストとして課金されます。

AWSの料金計算ツールでSQSを見積もるときの注意点は？

入力するのはメッセージ数ではなくリクエスト数です。1件のメッセージに送信・受信・削除の最低3回が要ること、64KBを超えるペイロードは64KBごとに1回と数えること、空の受信も1回になることを、件数に掛けてから入力します。バッチを使う場合は10で割り、Lambdaのイベントソースやワーカーのポーリング回数を別に足すと、実請求に近い値になります。

関連記事

• Amazon SQSとは？標準キューとFIFOの違い・可視性タイムアウトとDLQ設計を解説：料金の前提になるSQSの仕組みと設計。
• Amazon MQとSQSの違い：プロトコル互換・料金構造・移行判断を東京の実額で比較：ブローカー型の時間課金と比べたいとき。
• AWS Lambdaの料金を東京リージョンの実額で計算する：付帯課金の内訳と単価を下げる手順：SQSのトリガー側にかかる料金。
• AWS KMSとは？仕組み・料金とキーポリシー設計・採用判断を実装者目線で解説：SSE-KMSで増える鍵とリクエストの料金。
• EventBridgeとSQS・Lambdaの非同期構成｜キューポリシー・部分バッチ応答・DLQの置き場所：SQSを挟んだ非同期構成の組み方。