Планирахте budget за messaging на четиридесет цента на милион заявки, а после сметката от AWS дойде три пъти по-висока, отколкото броят на съобщенията ви подсказваше. Виновникът не е увеличение на цените. Това е правилото за 64 KB блокове: AWS не таксува логическо съобщение, а таксува всеки 64 KB блок от payload-а при всяко API извикване, което го докосва. Събитие за поръчка от 200 KB е четири таксувани заявки, когато го изпратите, още четири, когато worker го получи, и още четири, когато worker го изтрие. Дванадесет такси за едно съобщение, преди SNS fan-out да го умножи отново.
Тази публикация обяснява как SQS и SNS всъщност броят заявки, какво струва това при реалистичен обем, защо продукционният messaging принадлежи към себестойността на продадените стоки, а не към режийните разходи, и как да го отчитате така, че брутният ви марж да казва истината.
Как SQS превръща едно съобщение в много таксувани заявки
Ценообразуването на SQS изглежда подвеждащо просто: Standard опашките струват около четиридесет цента на милион заявки, FIFO опашките — около петдесет цента на милион, като първият милион Standard заявки всеки месец е безплатен. Сложността се крие в дефиницията на заявка.
Всеки 64 KB блок е заявка
Всеки започнат 64 KB блок от payload-а се брои за отделна заявка. Съобщение от 30 KB е една заявка. Съобщение от 64 KB е една заявка. Съобщение от 65 KB е две. Съобщение от 200 KB е четири, съобщение от 256 KB е четири, а payload от 1 MB е шестнадесет.
Последното число има по-голямо значение, отколкото преди. През август 2025 г. AWS увеличи максималния размер на съобщение в SQS от 256 KB на 1 MB както за Standard, така и за FIFO опашките. Допълнителното пространство е удобно за случайни големи събития, но всичко, което оставите над 64 KB, плаща множителя на блоковете при всяко докосване. Екип, който премине от средни payload-и от 50 KB към 200 KB, учетворява броя на SQS заявките си, без да изпрати нито едно допълнително съобщение.
Всяко API действие се брои отделно
Всяко API действие срещу дадена опашка е заявка и множителят на блоковете се прилага към всяко от тях. Изпращането, получаването, изтриването и промяната на видимостта на съобщение се измерват независимо.
Проследете целия жизнен цикъл на едно съобщение от 200 KB в Standard опашка. Изпращането е четири таксувани заявки. Получаването от worker е още четири. Изтриването след успешна обработка е още четири. Едно логическо съобщение, дванадесет таксувани заявки, приблизително половин цент на хиляда при цени по тарифа. Същият жизнен цикъл за съобщение от 30 KB е общо три заявки. Размерът на payload-а е доминиращата променлива в повечето сметки за SQS, а не броят на съобщенията.
Още два измервателя изненадват операторите за първи път. Празните получавания се таксуват: всяко запитване, което не връща съобщения, все още се брои за заявка, така че агресивен цикъл на short polling върху бездействаща опашка изгаря пари за нищо. А FIFO опашките носят около 25 процента премия над Standard при всяко ниво на обем, което се натрупва бързо, когато множителят на блоковете вече работи срещу вас. Използвайте FIFO там, където подредбата и обработката exactly-once са истински изисквания, и Standard навсякъде другаде.
Как SNS го умножава втори път
SNS добавя второ измерение на таксуването, защото публикуваното съобщение се измерва веднъж при пристигането и отново при всяка доставка.
Публикуванията и доставките са отделни измерватели
Публикуването в topic струва около петдесет цента на милион заявки, блокирано по същия начин: публикуване от 256 KB се брои за четири. След това всяка доставка до всеки абонат се измерва също на 64 KB блокове, като цената зависи от протокола за доставка.
Не всички доставки струват еднакво. Доставките до SQS опашки, Lambda функции и Firehose потоци не носят такса за доставка, което прави SNS-to-SQS fan-out почти безплатен от страна на доставката. HTTP и HTTPS доставките, имейлът и mobile push се таксуват, а SMS се ценообразува отделно на сегмент от съобщение. Събитие от 256 KB, разпръснато към три SQS опашки и един HTTP webhook, следователно струва четири заявки за публикуване, нула за трите SQS доставки и четири HTTP доставки. Свийте това събитие под 64 KB и същият fan-out струва едно публикуване плюс една HTTP доставка.
SNS последва SQS към по-големи payload-и през септември 2026 г., позволявайки съобщения от 1 MB зад настройка за максимален размер на ниво topic. Topics, конфигурирани над 256 KB, могат да доставят само до SQS, Lambda и Firehose, с най-много сто абонамента. Ограничението е подсказка за предвидения модел: големите събития принадлежат в pipeline, подкрепен от опашка, а не разпръснати към всеки протокол.
Защо fan-out все още печели
Измервателят за доставки изкушава екипите да пропуснат SNS и да изпращат дублирани SQS съобщения директно до всеки консуматор. Устояйте на това. Дублираните изпращания умножават най-скъпата част от цикъла — изпращане, получаване и изтриване за всеки консуматор — докато SNS-to-SQS fan-out плаща едно публикуване и нула такси за SQS доставка на абонат. Когато няколко консуматора се нуждаят от едно и също събитие, fan-out е едновременно по-чистата архитектура и по-евтината сметка.
Какво струва това при реален обем
Цените по тарифа са числа за милион, които имат смисъл само умножени, затова ето три реалистични форми.
Страничен проект, изпращащ 2 милиона малки съобщения месечно през една Standard опашка, плаща почти нищо. Всяко съобщение под 64 KB струва едно изпращане, едно получаване и едно изтриване, или 6 милиона заявки. Първият милион е безплатен, оставяйки 5 милиона при четиридесет цента на милион: около два долара.
SaaS платформа със среден размер, публикуваща 5 милиона известия от 10 KB месечно към Standard topic с три SQS абоната и един HTTP webhook, плаща едноцифрена сума за SNS частта. Публикуванията са около два долара и петдесет цента. Трите SQS доставки са безплатни. HTTP доставките са около три долара при шест цента на сто хиляди. Последващите SQS API действия приблизително удвояват общата сума, оставяйки целия pipeline за известия под петнадесет долара месечно. Това е формата, при която messaging е наистина незначителен.
Сега преиграйте това SaaS натоварване с payload-и от 200 KB, защото всяко събитие вгражда пълен документ за поръчка. Всеки измервател се учетворява. Публикуванията скачат до десет долара, HTTP доставките до дванадесет, а последващите SQS получавания и изтривания също се учетворяват. Pipeline-ът се приземява близо до шестдесет долара месечно, все още малко в абсолютни стойности, но четири пъти цената на същото натоварване с леки събития, и разликата се натрупва с растежа на обема. При 500 милиона блокови заявки месечно разликата между леки и раздути събития е четирицифрена годишна позиция.
Нивата на обем съществуват, но рядко имат значение за малкия бизнес: Standard заявките намаляват след 100 милиарда и 200 милиарда заявки месечно. Вашият реалистичен лост не е нивото, а средният фактор на блоковете.
Защо продукционният messaging е променлива себестойност на продадените стоки, а не режийни разходи
Messaging, който доставя вашия продукт до плащащи клиенти, е пряк разход за приходи. Той се мащабира с използването, изчезва, когато нищо не се продава, и инвеститорите очакват да го видят над линията на брутния марж, заедно с compute, база данни, съхранение и bandwidth за продукция.
Счетоводните стандарти оставят пространство тук: общоприетите принципи не дефинират точно себестойността на продадените стоки и практиката за брутен марж при SaaS запълва празнината с тест за пряк разход. Попитайте дали разходът съществува, за да обслужва клиенти в продукция. Продукционните опашки, пренасящи събития за поръчки, topics за известия, разпръсквани към worker-и, обърнати към клиенти, и webhook доставките до клиентски endpoint-и — всички преминават теста. Staging опашки, topics за тестове за натоварване, абонаменти за developer sandbox и dead-letter опашката, източваща теста за натоварване от миналото тримесечие, не преминават. Те принадлежат към research and development или общи режийни разходи.
Границата на продукцията е цялата игра. Една сметка от AWS смесва всяка опашка и topic заедно, затова маркирайте продукционните ресурси с тагове и разделяйте фактурата всеки месец. Екипите, които пропускат разделянето, обикновено грешат в ласкателната посока, заравяйки инфраструктурата в режийни разходи и отчитайки брутен марж, който тяхната unit economics не може да защити. Преглед при due diligence го прекласифицира за един следобед, а преизчислената граница никога не е по-високата.
Отчитайте нетната сума, която действително плащате. Безплатният tier е отстъпка при фактуриране, а не приход, така че няма какво да се gross up. Ако искате видимост върху това каква част от натоварването поема безплатният tier, проследявайте таксуваните заявки отделно в метриките си и дръжте счетоводното записване на парична стойност.
Как да го отчитате, така че маржът ви да казва истината
Дайте на messaging собствена сметка за себестойност на продажбите, вместо да го смесвате в обща линия за cloud или софтуер. Отделна сметка, например cloud messaging, ви позволява да разделите месечния разход на месечните таксувани заявки и да видите истинската си цена на блокова заявка, което е числото, което ви казва дали растежът на payload-а изяжда маржа.
Таксата от AWS се урежда след края на месеца, затова я начислявайте. Оценете messaging частта от метриките си за заявки при приключване, изравнете я към фактурата, когато пристигне, и дръжте sandbox частта извън себестойността на продажбите. Ето пълен цикъл за месец, в който продукционният messaging е струвал осемнадесет долара и четиридесет цента, а sandbox-ът е добавил два долара и десет цента:
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 трябва да се появяват като отделни линии, за да не се скрие скок в едната в плоския тренд на другата. Ако водите книгите си в plain text, моделите за проследяване на разходи в документацията се разширяват естествено към разделяне на messaging по услуги.
Един капан за класификация, който да избегнете: FIFO премиите и съхранението с удължено задържане все още са разходи за messaging, но удълженото задържане извън истинския ви прозорец за redrive е избор за съхранение, а не разход за доставка. Или скъсете задържането, или преместете частта за съхранение там, където ѝ е мястото, вместо да позволите политика за четиринадесетдневно задържане тихо да надува себестойността на продажбите.
Пет контрола, които обикновено намаляват сметката с 30 до 50 процента
Започнете с long polling и batching. Заедно те рутинно намаляват разхода за SQS с почти половина и отнемат един следобед за внедряване.
1. Включете long polling навсякъде
Задайте време за изчакване при получаване от двадесет секунди на всяка опашка. Тогава worker-ите държат връзката отворена, вместо да удрят празни запитвания, което сгъва линията на празните получавания, доминираща сметките за бездействащи опашки, и изглажда CPU скоковете при консуматорите.
2. Обединявайте в batch всяко API извикване, което позволява
Изпращането, получаването и изтриването поддържат batch-ове до десет съобщения. Worker, обработващ едно съобщение на извикване, плаща десет пъти броя заявки на worker, източващ десет наведнъж. Batch изтриванията са най-често пропусканите: екипи, които внимателно обединяват изпращанията, често изтриват едно по едно.
3. Подложете payload-а на диета
Дръжте всяко събитие под един 64 KB блок. Съхранявайте пълния документ в object storage и изпращайте референция с идентификаторите, от които консуматорът се нуждае — моделът claim-check. Компресирайте там, където референциите са непрактични, и премахнете вградените blob-ове, дублираните клиентски записи и подробния debug контекст от горящия път. Всеки блок, който премахнете, се умножава през изпращания, получавания, изтривания, публикувания и доставки.
4. Филтрирайте на ниво topic
Прикачете filter policies, така че всеки абонат да получава само събитията, които обработва. Нефилтрираният fan-out плаща доставка и последваща обработка за съобщения, които консуматорът изхвърля при пристигане. Това е чиста загуба с поправка от един ред на абонамент.
5. Запазете FIFO там, където подредбата е реална
Одитирайте кои опашки наистина се нуждаят от подредба и дедупликация. Премията на FIFO се прилага към всяка блокова заявка на опашката, така че FIFO опашка, пренасяща събития, които никой не подрежда, е постоянна 25 процента надценка. Докато одитирате, задайте кратко задържане с dead-letter опашка за неуспехи, вместо да позволявате на отровни съобщения да се преповтарят до голям брой заявки.
Следете двете метрики, които предсказват сметката: приблизителен брой изпратени съобщения и брой празни получавания. Алармирайте, когато празните получавания надвишат малък дял от общите получавания, и преглеждайте средния размер на payload-а на опашка на тримесечие. Растежът на payload-а е достатъчно постепенен, за да се пропусне от месец на месец, и достатъчно голям, за да има значение от година на година.
Контролен списък за края на месеца за разходи за messaging
Затворете цикъла по същия начин всеки месец, за да останат числата надеждни:
- Извлечете броя блокови заявки за SQS и SNS от разбивката на фактурирането си, а не логическите бройки съобщения от логовете на приложението.
- Разделете разхода на всяка услуга на нейните блокови заявки, за да получите истинската единична цена, и я сравнете с базовите стойности по тарифа от четиридесет и петдесет цента.
- Изчислете средния фактор на блоковете на опашка, като разделите таксуваните заявки на логическите съобщения; всичко над 1.2 заслужава преглед на payload-а.
- Разделете продукционните разходи от тези за staging и sandbox с помощта на тагове за ресурси и потвърдете, че само продукционните са попаднали в себестойността на продажбите.
- Изравнете миналомесечното начисление към уредената фактура и пренесете разликата напред в оценката си.
- Проверете празните получавания като дял от общите получавания и потвърдете, че long polling все още е включен след всяка промяна в инфраструктурата.
- Потвърдете, че всяка нова опашка и topic, създадени през месеца, са наследили продукционни тагове и filter policies.
Извлечете днешните линии за SQS и SNS от конзолата си за фактуриране и изчислете средния фактор на блоковете. Ако е над 1.2, най-евтината ви печалба за маржа е по-малък payload, а не по-голям план.
