Ви заклали в бюджет сорок центів за мільйон запитів на обмін повідомленнями, а потім рахунок від AWS прийшов утричі більший, ніж мала б дати кількість ваших повідомлень. Винен не ріст цін. Винне правило нарізки по 64 КБ: AWS тарифікує не логічне повідомлення, а кожен фрагмент корисного навантаження по 64 КБ за кожного виклику API, що його торкається. Подія замовлення на 200 КБ — це чотири оплачувані запити, коли ви її надсилаєте, ще чотири, коли воркер її отримує, і ще чотири, коли воркер її видаляє. Дванадцять списань за одне повідомлення, ще до того, як SNS fan-out помножить це знову.
У цій статті пояснюється, як насправді 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 не несуть плати за доставку, що робить fan-out SNS-to-SQS майже безкоштовним з боку доставки. Доставки HTTP та HTTPS, електронна пошта та мобільні push-повідомлення тарифікуються, а SMS цінуються окремо за кожен сегмент повідомлення. Подія на 256 КБ, розіслана fan-out у три черги SQS і один HTTP вебхук, отже коштує чотири запити на публікацію, нуль за три доставки SQS і чотири доставки HTTP. Зменште цю подію до менш ніж 64 КБ, і той самий fan-out коштуватиме одну публікацію плюс одну доставку HTTP.
SNS пішла за SQS у бік більших навантажень у вересні 2026 року, дозволивши повідомлення на 1 МБ за налаштуванням максимального розміру на рівні теми. Теми, налаштовані понад 256 КБ, можуть доставляти лише в SQS, Lambda та Firehose, з щонайбільше ста підписками. Це обмеження — підказка про призначений шаблон: великі події належать конвеєру на основі черг, а не розсилці в усі протоколи.
Чому fan-out усе одно виграє
Лічильник доставок спокушає команди відмовитися від SNS і надсилати дублікати повідомлень SQS кожному споживачу напряму. Опіртеся цьому. Дубльовані надсилання множать найдорожчу частину циклу — надсилання, отримання та видалення на кожного споживача, — тоді як fan-out SNS-to-SQS платить одну публікацію і нуль плати за доставку SQS на кожного підписника. Коли кільком споживачам потрібна та сама подія, fan-out — це і чистіша архітектура, і дешевший рахунок.
Скільки це коштує за реального обсягу
Тарифні ставки — це числа за мільйон, які мають сенс лише в перемноженні, тож ось три реалістичні сценарії.
Побічний проєкт, що надсилає 2 мільйони дрібних повідомлень на місяць через одну чергу Standard, платить майже нічого. Кожне повідомлення до 64 КБ коштує одне надсилання, одне отримання й одне видалення, або 6 мільйонів запитів. Перший мільйон безкоштовний, лишається 5 мільйонів по сорок центів за мільйон: близько двох доларів.
SaaS-платформа середнього розміру, що публікує 5 мільйонів сповіщень по 10 КБ на місяць у тему Standard із трьома підписниками SQS і одним HTTP вебхуком, платить одноцифрові суми за частину SNS. Публікації — близько двох доларів п'ятдесяти центів. Три доставки SQS безкоштовні. Доставки HTTP — близько трьох доларів по шість центів за сто тисяч. Подальші дії API SQS приблизно подвоюють підсумок, лишаючи весь конвеєр сповіщень під п'ятнадцятьма доларами на місяць. Це той сценарій, де обмін повідомленнями справді незначний.
Тепер відтворіть це SaaS-навантаження з навантаженнями по 200 КБ, бо кожна подія вбудовує повний документ замовлення. Кожен лічильник учетверяється. Публікації стрибають до десяти доларів, доставки HTTP — до дванадцяти, а подальші отримання та видалення SQS також учетверяються. Конвеєр сягає близько шістдесяти доларів на місяць, усе ще мало в абсолютних величинах, але вчетверо дорожче за те саме навантаження з ощадливими подіями, і розрив накопичується зі зростанням обсягу. За 500 мільйонів нарізаних запитів на місяць різниця між ощадливими й роздутими подіями — це чотиризначна річна стаття.
Рівні обсягу існують, але рідко важать для малого бізнесу: ставки за запити Standard знижуються після 100 мільярдів і 200 мільярдів запитів на місяць. Ваш реалістичний важіль — не рівень, а середній коефіцієнт нарізки.
Чому продакшн-обмін повідомленнями — це змінні витрати на реалізовану продукцію, а не накладні витрати
Обмін повідомленнями, що доставляє ваш продукт платним клієнтам, — це пряма витрата на дохід. Він масштабується зі споживанням, зникає, коли нічого не продається, і інвестори очікують бачити його над лінією валової маржі поряд з обчисленнями, базою даних, сховищем і пропускною здатністю для продакшну.
Стандарти бухгалтерського обліку лишають тут простір: загальновизнані принципи не визначають точно собівартість реалізованої продукції, і практика валової маржі SaaS заповнює прогалину тестом на прямі витрати. Запитайте, чи існують витрати, щоб обслуговувати клієнтів у продакшні. Продакшн-черги, що несуть події замовлень, теми сповіщень, що розсилаються воркерам, орієнтованим на клієнтів, і доставки вебхуків на кінцеві точки клієнтів — усі проходять. Черги 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Звіряйте нараховану суму з вашим cost explorer, згрупованим за сервісом і типом споживання, принаймні щомісяця. SQS і SNS мають з'являтися окремими рядками, щоб сплеск в одному не ховався у плоскому тренді іншого. Якщо ви ведете книги в текстовому вигляді, шаблони відстеження витрат у документації природно поширюються на розподіл обміну повідомленнями за сервісами.
Одна пастка класифікації, якої слід уникати: надбавки FIFO та зберігання з подовженим терміном — це все ще витрати на обмін повідомленнями, але подовжене зберігання понад ваше справжнє вікно повторної доставки — це вибір щодо зберігання, а не витрата на доставку. Або скорочуйте термін зберігання, або переносьте частину зберігання туди, де їй місце, замість того щоб політика зберігання на чотирнадцять днів тихо роздувала собівартість реалізації.
П'ять заходів, що зазвичай скорочують рахунок на 30–50 відсотків
Почніть із довгого опитування та пакетної обробки. Разом вони зазвичай скорочують витрати на SQS майже вдвічі й вимагають пів дня на впровадження.
1. Увімкніть довге опитування всюди
Встановіть час очікування отримання у двадцять секунд на кожній черзі. Тоді воркери тримають з'єднання відкритим, а не бомбардують порожніми опитуваннями, що згортає рядок порожніх отримань, який домінує в рахунках за простоюючі черги, і згладжує піки CPU у споживачів.
2. Пакетуйте кожен виклик API, що це дозволяє
Надсилання, отримання та видалення підтримують пакети до десяти повідомлень. Воркер, що обробляє одне повідомлення за виклик, платить удесятеро більше запитів, ніж воркер, що вичерпує десять за раз. Пакетні видалення — найчастіше пропущене: команди, що ретельно пакетують надсилання, часто видаляють по одному.
3. Посадіть навантаження на дієту
Тримайте кожну подію в межах одного фрагмента по 64 КБ. Зберігайте повний документ в об'єктному сховищі й надсилайте посилання з ідентифікаторами, потрібними споживачу, — шаблон claim-check. Стискайте там, де посилання непрактичні, і вирізайте вбудовані блоби, дубльовані записи клієнтів і багатослівний контекст налагодження з гарячого шляху. Кожен фрагмент, який ви прибираєте, множиться на надсилання, отримання, видалення, публікації та доставки.
4. Фільтруйте на рівні теми
Прикріпіть політики фільтрації, щоб кожен підписник отримував лише ті події, які він обробляє. Нефільтрований fan-out платить за доставку й подальшу обробку повідомлень, які споживач відкидає при надходженні. Це чистий марнотрат із виправленням в один рядок на підписку.
5. Бережіть FIFO для випадків, де впорядкування справжнє
Перевірте, які черги справді потребують впорядкування й дедуплікації. Надбавка FIFO застосовується до кожного нарізаного запиту в черзі, тож черга FIFO, що несе події, які ніхто не впорядковує, — це постійна 25-відсоткова надбавка. Під час перевірки встановіть короткий термін зберігання з чергою недоставлених повідомлень для збоїв, замість того щоб дозволяти отруйним повідомленням повторюватися у велику кількість запитів.
Відстежуйте дві метрики, що передбачають рахунок: приблизну кількість надісланих повідомлень і кількість порожніх отримань. Оповіщайте, коли порожні отримання перевищують невелику частку від загальних отримань, і переглядайте середній розмір навантаження на кожну чергу щокварталу. Зростання навантаження достатньо поступове, щоб його пропустити з місяця в місяць, і достатньо значне, щоб важити з року в рік.
Чек-лист закриття місяця щодо витрат на обмін повідомленнями
Замикайте цикл однаково щомісяця, щоб цифри лишалися надійними:
- Витягніть кількості нарізаних запитів для SQS і SNS з розшифровки рахунків, а не кількості логічних повідомлень із журналів застосунку.
- Поділіть витрати кожного сервісу на його нарізані запити, щоб отримати справжню питому вартість, і порівняйте її з тарифними орієнтирами сорок і п'ятдесят центів.
- Обчисліть середній коефіцієнт нарізки на кожну чергу, поділивши оплачувані запити на логічні повідомлення; усе понад 1,2 заслуговує на перегляд навантаження.
- Розділіть продакшн від staging і пісочниці за допомогою тегів ресурсів і переконайтеся, що до собівартості реалізації потрапив лише продакшн.
- Скоригуйте нарахування минулого місяця до розрахованого рахунку й перенесіть відхилення у свою оцінку.
- Перевірте порожні отримання як частку від загальних отримань і переконайтеся, що довге опитування досі ввімкнене після будь-якої зміни інфраструктури.
- Переконайтеся, що кожна нова черга й тема, створені протягом місяця, успадкували продакшн-теги та політики фільтрації.
Витягніть рядки SQS і SNS цього місяця з вашої консолі рахунків уже сьогодні й обчисліть середній коефіцієнт нарізки. Якщо він вище 1,2, ваша найдешевша перемога над маржею — менше навантаження, а не більший тарифний план.
