Вы заложили в бюджет обмен сообщениями по сорок центов за миллион запросов, а счёт AWS пришёл в три раза выше, чем следовало из количества ваших сообщений. Виновато не повышение цен. Виновато правило фрагментации по 64 КБ: AWS тарифицирует не логическое сообщение, а каждый фрагмент полезной нагрузки по 64 КБ в каждом вызове API, который его касается. Событие заказа на 200 КБ — это четыре оплачиваемых запроса при отправке, ещё четыре, когда воркер его получает, и ещё четыре, когда воркер его удаляет. Двенадцать списаний за одно сообщение, ещё до того, как SNS-фанаут умножит их снова.
В этой статье объясняется, как SQS и SNS на самом деле считают запросы, сколько это стоит при реалистичных объёмах, почему продакшн-обмен сообщениями относится к себестоимости продаж, а не к накладным расходам, и как его учитывать, чтобы валовая маржа говорила правду.
Как SQS превращает одно сообщение во множество оплачиваемых запросов
Цены SQS выглядят обманчиво просто: Standard-очереди стоят около сорока центов за миллион запросов, FIFO-очереди — около пятидесяти центов за миллион, причём первый миллион Standard-запросов каждый месяц бесплатен. Сложность скрывается в определении запроса.
Каждый фрагмент по 64 КБ — это запрос
Каждый начатый фрагмент полезной нагрузки по 64 КБ считается отдельным запросом. Сообщение на 30 КБ — один запрос. Сообщение на 64 КБ — один запрос. Сообщение на 65 КБ — два. Сообщение на 200 КБ — четыре, на 256 КБ — четыре, а полезная нагрузка в 1 МБ — шестнадцать.
Последнее число значит больше, чем раньше. В августе 2025 года AWS подняла максимальный размер сообщения SQS с 256 КБ до 1 МБ для очередей Standard и FIFO. Запас удобен для редких крупных событий, но всё, что вы кладёте сверх 64 КБ, платит множитель фрагментации при каждом обращении. Команда, которая переходит с полезных нагрузок в среднем 50 КБ на 200 КБ, учетверяет количество запросов SQS, не отправив ни одного дополнительного сообщения.
Каждое действие API считается отдельно
Каждое действие API к очереди — это запрос, и множитель фрагментации применяется к каждому из них. Отправка, получение, удаление и изменение видимости сообщения тарифицируются независимо.
Пройдите полный жизненный цикл одного сообщения на 200 КБ в Standard-очереди. Отправка — четыре оплачиваемых запроса. Получение воркером — ещё четыре. Удаление после успешной обработки — ещё четыре. Одно логическое сообщение, двенадцать оплачиваемых запросов, примерно полцента за тысячу по прейскуранту. Тот же жизненный цикл для сообщения на 30 КБ — три запроса всего. Размер полезной нагрузки — доминирующая переменная в большинстве счетов SQS, а не количество сообщений.
Ещё два счётчика удивляют операторов-новичков. Пустые получения оплачиваются: каждый опрос, вернувший ноль сообщений, всё равно считается запросом, поэтому агрессивный цикл коротких опросов на простаивающей очереди сжигает деньги впустую. А FIFO-очереди несут примерно 25-процентную надбавку к Standard на каждом уровне объёма, что быстро накапливается, когда множитель фрагментации уже работает против вас. Используйте FIFO там, где упорядоченность и обработка ровно один раз — это реальные требования, и Standard везде остальное.
Как SNS умножает это во второй раз
SNS добавляет второе измерение тарификации, потому что опубликованное сообщение тарифицируется один раз при поступлении и снова при каждой доставке.
Публикации и доставки — отдельные счётчики
Публикация в топик стоит около пятидесяти центов за миллион запросов, с той же фрагментацией: публикация в 256 КБ считается как четыре. Затем каждая доставка каждому подписчику тоже тарифицируется за каждый фрагмент по 64 КБ, причём ставка зависит от протокола доставки.
Не все доставки стоят одинаково. Доставки в очереди SQS, функции Lambda и потоки Firehose не тарифицируются за доставку, что делает фанаут SNS-to-SQS почти бесплатным со стороны доставки. Доставки по HTTP и HTTPS, электронная почта и мобильные push-уведомления тарифицируются, а SMS оценивается отдельно за сегмент сообщения. Таким образом, событие в 256 КБ, разосланное в три очереди SQS и один HTTP webhook, стоит четыре запроса публикации, ноль за три доставки в SQS и четыре HTTP-доставки. Ужмите это событие ниже 64 КБ — и тот же фанаут будет стоить одну публикацию плюс одну HTTP-доставку.
В сентябре 2026 года SNS последовал за SQS в сторону больших полезных нагрузок, разрешив сообщения до 1 МБ за настройкой максимального размера на уровне топика. Топики, настроенные выше 256 КБ, могут доставлять только в SQS, Lambda и Firehose, максимум на сто подписок. Это ограничение — подсказка о задуманном шаблоне: крупные события принадлежат конвейеру на основе очередей, а не веерной рассылке по всем протоколам.
Почему фанаут всё равно выигрывает
Счётчик доставки соблазняет команды отказаться от SNS и отправлять дублирующие сообщения SQS каждому потребителю напрямую. Сопротивляйтесь этому. Дублирующие отправки умножают самую дорогую часть цикла — отправку плюс получение плюс удаление на каждого потребителя, — тогда как фанаут SNS-to-SQS платит одну публикацию и ноль за доставку в SQS на подписчика. Когда нескольким потребителям нужно одно и то же событие, фанаут — это и более чистая архитектура, и более дешёвый счёт.
Сколько это стоит при реальных объёмах
Прейскурантные ставки — это цифры за миллион, которые имеют смысл только после умножения, поэтому вот три реалистичных сценария.
Пет-проект, отправляющий 2 миллиона мелких сообщений в месяц через одну Standard-очередь, платит почти ничего. Каждое сообщение до 64 КБ стоит одну отправку, одно получение и одно удаление, то есть 6 миллионов запросов. Первый миллион бесплатен, остаётся 5 миллионов по сорок центов за миллион: около двух долларов.
SaaS-платформа среднего размера, публикующая 5 миллионов уведомлений по 10 КБ в месяц в Standard-топик с тремя подписчиками SQS и одним HTTP webhook, платит однозначные суммы за часть SNS. Публикации — около двух долларов пятидесяти центов. Три доставки в SQS бесплатны. HTTP-доставки — около трёх долларов по шесть центов за сто тысяч. Последующие действия API SQS примерно удваивают итог, оставляя весь конвейер уведомлений меньше пятнадцати долларов в месяц. Это форма, где обмен сообщениями действительно незначителен.
Теперь воспроизведите ту же нагрузку SaaS с полезными нагрузками по 200 КБ, потому что каждое событие включает полный документ заказа. Каждый счётчик учетверяется. Публикации подскакивают до десяти долларов, HTTP-доставки — до двенадцати, а последующие получения и удаления в SQS тоже учетверяются. Конвейер выходит примерно на шестьдесят долларов в месяц — по-прежнему мало в абсолютных числах, но в четыре раза дороже той же нагрузки с компактными событиями, и разрыв растёт вместе с объёмом. При 500 миллионах фрагментированных запросов в месяц разница между компактными и раздутыми событиями — это четырёхзначная годовая статья расходов.
Уровни объёма существуют, но для малого бизнеса редко имеют значение: ставки за Standard-запросы снижаются после 100 миллиардов и 200 миллиардов запросов в месяц. Ваш реальный рычаг — не уровень, а средний коэффициент фрагментации.
Почему продакшн-обмен сообщениями — это переменная себестоимость, а не накладные расходы
Обмен сообщениями, который доставляет ваш продукт платящим клиентам, — это прямой расход по выручке. Он масштабируется с использованием, исчезает, когда ничего не продаётся, и инвесторы ожидают увидеть его выше строки валовой маржи наравне с вычислениями, базой данных, хранением и пропускной способностью для продакшна.
Стандарты учёта оставляют здесь пространство для манёвра: общепринятые принципы не дают точного определения себестоимости продаж, и практика валовой маржи SaaS заполняет пробел тестом на прямые затраты. Спросите, существуют ли расходы, чтобы обслуживать клиентов в продакшне. Продакшн-очереди с событиями заказов, топики уведомлений, рассылающие события ориентированным на клиентов воркерам, и доставки webhook на клиентские эндпоинты — все проходят. Staging-очереди, топики нагрузочного тестирования, подписки в песочнице разработчика и очередь недоставленных сообщений, сливающая нагрузочный тест прошлого квартала, — не проходят. Они относятся к исследованиям и разработке или общим накладным расходам.
Граница продакшна — это вся игра. Один счёт AWS объединяет все очереди и топики, поэтому помечайте продакшн-ресурсы тегами и разделяйте счёт каждый месяц. Команды, которые пропускают разделение, обычно ошибаются в льстящую сторону, закапывая инфраструктуру в накладные расходы и показывая валовую маржу, которую их юнит-экономика не может защитить. Аудит при проверке переклассифицирует это за один день, и пересчитанная маржа никогда не бывает выше.
Учитывайте чистую сумму, которую вы фактически платите. Бесплатный уровень — это скидка на счёт, а не выручка, поэтому увеличивать сумму не на что. Если вы хотите видеть, какую часть нагрузки поглощает бесплатный уровень, отслеживайте оплачиваемые запросы отдельно в своих метриках, а запись в книге держите по денежной стоимости.
Как это учитывать, чтобы маржа говорила правду
Дайте обмену сообщениями собственный счёт себестоимости продаж, а не смешивайте его с общей строкой облачных услуг или ПО. Выделенный счёт, например «облачный обмен сообщениями», позволяет разделить расходы месяца на оплачиваемые запросы месяца и увидеть вашу истинную стоимость фрагментированного запроса — это число говорит вам, съедает ли рост полезной нагрузки маржу.
Списание AWS происходит после конца месяца, поэтому начисляйте его. Оцените часть обмена сообщениями по метрикам запросов при закрытии, скорректируйте по счёту, когда он придёт, и держите часть песочницы вне себестоимости продаж. Вот полный цикл для месяца, когда продакшн-обмен сообщениями обошёлся в восемнадцать долларов сорок центов, а песочница добавила два доллара десять центов:
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 должны отображаться отдельными строками, чтобы скачок в одном не скрывался внутри ровного тренда другого. Если вы ведёте книги в plain text, шаблоны отслеживания затрат в документации естественно расширяются до разбивки обмена сообщениями по сервисам.
Одна ловушка классификации, которую стоит избегать: надбавки FIFO и хранение с продлённым сроком — это всё ещё расходы на обмен сообщениями, но продлённое хранение сверх вашего реального окна повторной обработки — это выбор в пользу хранения, а не стоимость доставки. Либо сократите срок хранения, либо перенесите часть хранения туда, где ей место, вместо того чтобы позволять политике хранения в четырнадцать дней тихо раздувать себестоимость продаж.
Пять мер контроля, которые обычно сокращают счёт на 30–50 процентов
Начните с длинного опроса и пакетной обработки. Вместе они регулярно сокращают расходы SQS почти вдвое и занимают один день на внедрение.
1. Включите длинный опрос везде
Установите время ожидания получения в двадцать секунд на каждой очереди. Тогда воркеры держат соединение открытым вместо того, чтобы долбить пустыми опросами, что сводит на нет строку пустых получений, которая доминирует в счетах простаивающих очередей, и сглаживает пики загрузки CPU у потребителей.
2. Пакетируйте каждый вызов API, который это позволяет
Отправка, получение и удаление все поддерживают пакеты до десяти сообщений. Воркер, обрабатывающий одно сообщение за вызов, платит десятикратное количество запросов по сравнению с воркером, разбирающим десять за раз. Пакетные удаления упускают чаще всего: команды, которые тщательно пакетируют отправки, часто удаляют по одному.
3. Посадите полезную нагрузку на диету
Держите каждое событие в пределах одного фрагмента по 64 КБ. Храните полный документ в объектном хранилище и отправляйте ссылку с идентификаторами, которые нужны потребителю, — шаблон claim-check. Сжимайте там, где ссылки непрактичны, и вычищайте встроенные бинарные объекты, дублирующиеся записи клиентов и многословный отладочный контекст из горячего пути. Каждый удалённый фрагмент умножается на отправки, получения, удаления, публикации и доставки.
4. Фильтруйте на уровне топика
Прикрепляйте политики фильтрации, чтобы каждый подписчик получал только те события, которые он обрабатывает. Нефильтрованный фанаут платит за доставку и последующую обработку сообщений, которые потребитель отбрасывает при поступлении. Это чистая трата с исправлением в одну строку на подписку.
5. Оставьте FIFO там, где упорядоченность реальна
Проверьте, каким очередям действительно нужны упорядоченность и дедупликация. Надбавка FIFO применяется к каждому фрагментированному запросу в очереди, поэтому FIFO-очередь с событиями, которые никто не упорядочивает, — это постоянная 25-процентная надбавка. Заодно при аудите установите короткий срок хранения с очередью недоставленных сообщений для сбоев, вместо того чтобы позволять «отравленным» сообщениям повторяться до большого количества запросов.
Отслеживайте две метрики, которые предсказывают счёт: приблизительное количество отправленных сообщений и количество пустых получений. Оповещайте, когда пустые получения превышают небольшую долю всех получений, и пересматривайте средний размер полезной нагрузки на очередь ежеквартально. Рост полезной нагрузки достаточно постепенен, чтобы его пропустить из месяца в месяц, и достаточно велик, чтобы иметь значение из года в год.
Чек-лист закрытия месяца по расходам на обмен сообщениями
Замыкайте цикл одинаково каждый месяц, чтобы цифры оставались достоверными:
- Доставайте количество фрагментированных запросов для SQS и SNS из разбивки счетов, а не количество логических сообщений из журналов приложений.
- Делите расходы каждого сервиса на его фрагментированные запросы, чтобы получить истинную удельную стоимость, и сравнивайте её с прейскурантными ориентирами в сорок и пятьдесят центов.
- Вычисляйте средний коэффициент фрагментации по каждой очереди, деля оплачиваемые запросы на логические сообщения; всё выше 1,2 заслуживает пересмотра полезной нагрузки.
- Разделяйте продакшн, staging и песочницу по тегам ресурсов и подтверждайте, что в себестоимость продаж попал только продакшн.
- Корректируйте начисление прошлого месяца по выставленному счёту и переносите отклонение в свою оценку.
- Проверяйте пустые получения как долю всех получений и подтверждайте, что длинный опрос всё ещё включён после любых изменений инфраструктуры.
- Подтверждайте, что каждая новая очередь и топик, созданные за месяц, унаследовали продакшн-теги и политики фильтрации.
Достаньте строки SQS и SNS за этот месяц из консоли выставления счетов сегодня и вычислите средний коэффициент фрагментации. Если он выше 1,2, ваша самая дешёвая победа в марже — это меньшая полезная нагрузка, а не больший тарифный план.
