メッセージングのコストを100万リクエストあたり40セントで予算化していたのに、届いたAWSの請求額はメッセージ数から想定される額の3倍でした。原因は値上げではありません。64 KBチャンクのルールです。AWSは論理的なメッセージ単位ではなく、そのメッセージに触れるすべてのAPI呼び出しにおいて、ペイロードの64 KBチャンクごとに課金します。200 KBの注文イベントなら、送信時に4リクエスト、ワーカーが受信するときにさらに4リクエスト、ワーカーが削除するときにもう4リクエスト。1つのメッセージに対して12回の課金が発生し、SNSのファンアウトでさらに倍増します。
この記事では、SQSとSNSが実際にどのようにリクエストをカウントするのか、現実的なボリュームでどれくらいのコストになるのか、本番のメッセージングがなぜ間接費ではなく売上原価に属するのか、そして粗利益率が真実を語るように計上する方法を解説します。
SQSが1つのメッセージを多数の課金リクエストに変える仕組み
SQSの料金は一見シンプルに見えます。Standardキューは100万リクエストあたり約40セント、FIFOキューは100万リクエストあたり約50セントで、Standardリクエストは毎月最初の100万件が無料です。複雑さはリクエストの定義に隠れています。
64 KBのチャンクごとに1リクエスト
ペイロードの開始された64 KBチャンクごとに、それぞれ1リクエストとしてカウントされます。30 KBのメッセージは1リクエスト、64 KBのメッセージも1リクエスト、65 KBなら2リクエストです。200 KBのメッセージは4リクエスト、256 KBは4リクエスト、1 MBのペイロードは16リクエストになります。
この最後の数字は以前よりも重要です。2025年8月、AWSはSQSの最大メッセージサイズをStandardとFIFOの両キューで256 KBから1 MBに引き上げました。たまに発生する大きなイベントには便利な余裕ですが、64 KBを超えて置かれたものは、触れるたびにチャンク倍率のコストを支払います。平均ペイロードを50 KBから200 KBに移行したチームは、メッセージを1件も増やさずにSQSリクエスト数が4倍になります。
すべてのAPIアクションが個別にカウントされる
キューに対する各APIアクションはリクエストであり、チャンク倍率はそのそれぞれに適用されます。送信、受信、削除、メッセージの可視性タイムアウトの変更は、それぞれ独立して課金されます。
Standardキュー上での200 KBメッセージ1件のライフサイクル全体を見てみましょう。送信は4課金リクエスト、ワーカーの受信はさらに4、処理成功後の削除はまた4です。論理的には1メッセージ、課金リクエストは12、リスト料金では1000件あたり約0.5セントです。30 KBメッセージの同じライフサイクルなら合計3リクエストです。ほとんどのSQS請求で支配的な変数は、メッセージ数ではなくペイロードサイズなのです。
初めて運用する人を驚かせる課金要素がさらに2つあります。空の受信も課金されます。メッセージを返さないポーリングもリクエストとしてカウントされるため、アイドル状態のキューに対する積極的なショートポーリングループは何のためにもお金を燃やします。そしてFIFOキューはどのボリューム帯でもStandardより約25パーセントの割増があり、チャンク倍率がすでに不利に働いている場合はすぐに積み上がります。順序付けとexactly-once処理が本当に必要な場合にFIFOを使い、それ以外のすべてではStandardを使いましょう。
SNSがもう一度倍増させる仕組み
SNSには2つ目の課金軸があります。パブリッシュされたメッセージは到着時に1回、そして各配信時にまた1回課金されるからです。
パブリッシュと配信は別の課金要素
トピックへのパブリッシュは100万リクエストあたり約50セントで、同じようにチャンク化されます。つまり256 KBのパブリッシュは4リクエスト分です。そして各サブスクライバーへの各配信も64 KBチャンクごとに課金され、料金は配信プロトコルによって異なります。
すべての配信が同じコストではありません。SQSキュー、Lambda関数、Firehoseストリームへの配信には配信料金がかからず、SNSからSQSへのファンアウトは配信側ではほぼ無料になります。HTTPとHTTPS配信、メール、モバイルプッシュは課金され、SMSはメッセージセグメントごとに別途料金が設定されています。したがって、256 KBのイベントを3つのSQSキューと1つのHTTPウェブフックにファンアウトすると、パブリッシュ4リクエスト、SQS配信3件はゼロ、HTTP配信4件となります。そのイベントを64 KB未満に縮めれば、同じファンアウトはパブリッシュ1回とHTTP配信1回になります。
SNSは2026年9月にSQSに続いて大きなペイロードに対応し、トピックレベルの最大サイズ設定の背後で1 MBのメッセージを許可しました。256 KBを超えて設定されたトピックは、SQS、Lambda、Firehoseにのみ配信でき、サブスクリプションは最大100件です。この制約は意図されたパターンへのヒントです。大きなイベントはキューで裏付けられたパイプラインに属し、あらゆるプロトコルに一斉送信すべきではありません。
それでもファンアウトが勝つ理由
配信の課金要素はチームをSNSを飛ばして各コンシューマーに直接SQSメッセージを複製送信させたくなりますが、それは避けましょう。複製送信はサイクルで最も高価な部分、つまりコンシューマーごとの送信＋受信＋削除を倍増させますが、SNSからSQSへのファンアウトはサブスクライバーごとにパブリッシュ1回とSQS配信料金ゼロを支払うだけです。複数のコンシューマーが同じイベントを必要とする場合、ファンアウトはよりクリーンなアーキテクチャであり、より安価な請求でもあります。
現実的なボリュームでのコスト
リスト料金は100万単位の数字なので、掛け算して初めて意味を持ちます。そこで現実的な3つの形を示します。
1つのStandardキューを通じて毎月200万件の小さなメッセージを送るサイドプロジェクトは、ほとんど何も支払いません。64 KB未満の各メッセージは送信1回、受信1回、削除1回で、600万リクエストです。最初の100万件は無料なので、残りの500万件が100万件あたり40セントで約2ドルです。
中規模のSaaSプラットフォームが毎月500万件の10 KB通知を、3つのSQSサブスクライバーと1つのHTTPウェブフックを持つStandardトピックにパブリッシュする場合、SNS側は1桁のドルです。パブリッシュは約2ドル50セント。SQS配信3件は無料。HTTP配信は10万件あたり6セントで約3ドルです。下流のSQS APIアクションが合計をほぼ倍にし、通知パイプライン全体で月15ドル未満です。これはメッセージングが本当に無視できる形です。
次に、各イベントに完全な注文ドキュメントが埋め込まれているために200 KBのペイロードで同じSaaSワークロードを再生してみましょう。すべての課金要素が4倍になります。パブリッシュは10ドル、HTTP配信は12ドルに跳ね上がり、下流のSQS受信と削除も4倍になります。パイプラインは月約60ドルになり、絶対額ではまだ小さいものの、スリムなイベントの同じワークロードの4倍であり、ボリュームが増えるにつれて差は複利で拡大します。月5000万のチャンク化リクエストでは、スリムなイベントと肥大化したイベントの差は年間4桁の費目になります。
ボリュームティアは存在しますが、小規模事業ではほとんど関係ありません。Standardリクエストは月間1000億件と2000億件を超えると段階的に下がります。現実的なレバーはティアではなく、平均チャンク係数です。
本番のメッセージングが間接費ではなく変動費COGSである理由
有料顧客に製品を届けるメッセージングは、直接的な収益コストです。使用量に応じてスケールし、何も売れなければ消え、投資家は本番用のコンピュート、データベース、ストレージ、帯域幅と並んで粗利益率の線の上に表示されることを期待します。
会計基準にはここに余地があります。一般に公正妥当と認められた原則は売上原価を正確に定義しておらず、SaaSの粗利益率の実務は直接費テストでその隙間を埋めています。支出が本番で顧客にサービスを提供するために存在するかどうかを問いましょう。注文イベントを運ぶ本番キュー、顧客向けワーカーにファンアウトする通知トピック、顧客エンドポイントへのウェブフック配信はすべて合格です。ステージングキュー、ロードテストトピック、開発者サンドボックスのサブスクリプション、前四半期のロードテストを排出するデッドレターキューは合格しません。それらは研究開発または一般間接費に属します。
本番の境界がすべてです。1つのAWS請求書はすべてのキューとトピックをまとめてしまうため、本番リソースにタグを付けて毎月請求書を分割しましょう。分割を怠るチームは通常、都合の良い方向に誤り、インフラを間接費に埋めて、ユニットエコノミクスが擁護できない粗利益率を報告します。デューデリジェンスのレビューはそれを午後のうちに再分類し、修正後の利益率が高くなることは決してありません。
実際に支払う正味額を計上しましょう。無料枠は請求上の割引であり収益ではないため、グロスアップするものはありません。無料枠がワークロードのどれだけを吸収しているかを可視化したい場合は、課金リクエストをメトリクスで別途追跡し、元帳エントリーは現金コストで維持しましょう。
利益率が真実を語るように計上する方法
メッセージングを一般的なクラウドやソフトウェアの行に混ぜるのではなく、独自の売上原価アカウントを与えましょう。cloud messagingのような専用アカウントを使えば、月の支出を月の課金リクエストで割って、チャンク化リクエストあたりの真のコストを確認でき、ペイロードの増加が利益率を蝕んでいるかどうかを教えてくれる数字になります。
AWSの請求は月末後に確定するので、見越計上します。決算時にリクエストメトリクスからメッセージング部分を推定し、請求書が届いたら修正し、サンドボックス部分は売上原価から外しておきましょう。本番メッセージングが18ドル40セント、サンドボックスが2ドル10セントだった月の完全なサイクルは次のとおりです。
2026-01-01 open Assets:Cash:Operating USD
2026-01-01 open Expenses:CostOfSales:Cloud-Messaging USD
2026-01-01 open Expenses:Research:Cloud-Sandbox USD
2026-01-01 open Liabilities:Accrued:AWS USD
2026-01-31 * "AWS" "January SQS prod 8.2M chunked requests plus SNS publishes and HTTP deliveries"
Expenses:CostOfSales:Cloud-Messaging 18.40 USD
Liabilities:Accrued:AWS -18.40 USD
2026-02-03 * "AWS" "January AWS charge settles, prod messaging plus 2.10 sandbox"
Liabilities:Accrued:AWS 18.40 USD
Expenses:Research:Cloud-Sandbox 2.10 USD
Assets:Cash:Operating -20.50 USD少なくとも毎月、見越額をサービスと使用タイプでグループ化したコストエクスプローラーで照合しましょう。SQSとSNSは別々の行として表示されるべきで、一方の急増がもう一方の横ばいトレンドに隠れないようにします。帳簿をプレーンテキストで管理しているなら、ドキュメントのコスト追跡パターンはサービスごとのメッセージング分割に自然に拡張できます。
避けるべき分類の罠が1つあります。FIFOの割増と延長保持ストレージは依然としてメッセージングコストですが、実際のリドライブウィンドウを超えた延長保持は配信コストではなくストレージの選択です。保持期間を短縮するか、ストレージ部分を適切な場所に移すかして、14日間の保持ポリシーが静かに売上原価を膨らませないようにしましょう。
通常、請求額を30〜50パーセント削減する5つのコントロール
まずロングポーリングとバッチ処理から始めましょう。これらを組み合わせればSQSの支出がほぼ半分になり、実装に午後1回かかる程度です。
1. すべての場所でロングポーリングを有効にする
すべてのキューで受信待機時間を20秒に設定しましょう。ワーカーは空のポーリングを連打する代わりに接続を開いたままにし、アイドルキューの請求を支配する空受信の行が崩れ、コンシューマーのCPUスパイクも滑らかになります。
2. 可能なすべてのAPI呼び出しをバッチ化する
送信、受信、削除はすべて最大10メッセージのバッチをサポートします。1回の呼び出しで1メッセージを処理するワーカーは、10件ずつ排出するワーカーの10倍のリクエスト数を支払います。バッチ削除は最も見落とされがちです。送信を丁寧にバッチ化するチームでも、削除は1件ずつ行うことがよくあります。
3. ペイロードをダイエットさせる
各イベントを64 KBチャンク1つ未満に保ちましょう。完全なドキュメントはオブジェクトストレージに保存し、コンシューマーが必要とする識別子を含む参照を送ります。これはクレームチェックパターンです。参照が非現実的な場合は圧縮し、埋め込まれたブロブ、重複した顧客レコード、冗長なデバッグコンテキストをホットパスから取り除きましょう。削除したチャンクは送信、受信、削除、パブリッシュ、配信すべてで倍増します。
4. トピックでフィルタリングする
フィルタポリシーを設定して、各サブスクライバーが処理するイベントだけを受け取るようにしましょう。フィルタリングされていないファンアウトは、コンシューマーが到着時に破棄するメッセージの配信と下流処理を支払います。これはサブスクリプションごとの1行の修正で済む純粋な無駄です。
5. FIFOは順序付けが本当に必要な場所に取っておく
どのキューが本当に順序付けと重複排除を必要とするかを監査しましょう。FIFOの割増はキューのすべてのチャンク化リクエストに適用されるため、誰も順序付けしないイベントを運ぶFIFOキューは常設の25パーセントの割増です。監査の際は、毒メッセージが大量のリクエスト数にリトライされないように、短い保持期間と失敗用のデッドレターキューを設定しましょう。
請求を予測する2つのメトリクスを監視しましょう。送信メッセージの概算数と空受信の数です。空受信が総受信の小さな割合を超えたらアラートを出し、四半期ごとにキューごとの平均ペイロードサイズをレビューしましょう。ペイロードの増加は月ごとには見逃すほど緩やかですが、年ごとには重要になるほど大きいのです。
メッセージングコストの月末チェックリスト
数字を信頼できるものにするために、毎月同じ方法でループを閉じましょう。
- SQSとSNSのチャンク化リクエスト数を、アプリケーションログの論理メッセージ数ではなく、請求内訳から取得しましょう。
- 各サービスの支出をそのチャンク化リクエストで割って真の単価を計算し、40セントと50セントのリスト料金ベンチマークと比較しましょう。
- 課金リクエストを論理メッセージで割って、キューごとの平均チャンク係数を計算しましょう。1.2を超えるものはペイロードのレビューに値します。
- リソースタグを使って本番とステージング、サンドボックスの支出を分け、売上原価に入ったのが本番のみであることを確認しましょう。
- 先月の見越額を確定した請求書に修正し、差異を推定値に繰り越しましょう。
- 空受信を総受信の割合として確認し、インフラ変更後もロングポーリングが有効であることを確認しましょう。
- 月中に作成されたすべての新しいキューとトピックが本番タグとフィルタポリシーを継承していることを確認しましょう。
今日、請求コンソールから今月のSQSとSNSの行を取得し、平均チャンク係数を計算しましょう。1.2を超えているなら、最も安価な利益率の改善はより大きなプランではなく、より小さなペイロードです。
