Naplánovali ste zasielanie správ na štyridsať centov za milión požiadaviek a potom prišla faktúra od AWS trikrát vyššia, než by podľa vášho počtu správ mala byť. Na vine nie je zdraženie. Je to pravidlo 64 KB blokov: AWS neúčtuje logickú správu, ale každý 64 KB blok dát pri každom volaní API, ktoré sa ho dotkne. 200 KB udalosť objednávky sú štyri spoplatnené požiadavky pri odoslaní, ďalšie štyri pri prevzatí pracovníkom a ďalšie štyri pri vymazaní pracovníkom. Dvanásť poplatkov za jednu správu, a to ešte predtým, než to SNS fan-out vynásobí znova.
Tento článok vysvetľuje, ako SQS a SNS skutočne počítajú požiadavky, koľko to stojí pri realistickom objeme, prečo produkčné zasielanie správ patrí do nákladov na predaný tovar a nie do režijných nákladov, a ako to zaúčtovať tak, aby vaša hrubá marža hovorila pravdu.
Ako SQS mení jednu správu na mnoho spoplatnených požiadaviek
Ceny SQS vyzerajú zvodne jednoducho: štandardné fronty stoja približne štyridsať centov za milión požiadaviek, FIFO fronty približne päťdesiat centov za milión, pričom prvý milión štandardných požiadaviek je každý mesiac zdarma. Zložitosť sa skrýva v definícii požiadavky.
Každý 64 KB blok je požiadavka
Každý začatý 64 KB blok dát sa počíta ako samostatná požiadavka. 30 KB správa je jedna požiadavka. 64 KB správa je jedna požiadavka. 65 KB správa sú dve. 200 KB správa sú štyri, 256 KB správa sú štyri a 1 MB dát je šestnásť.
To posledné číslo je dôležitejšie než kedysi. V auguste 2025 AWS zvýšil maximálnu veľkosť správy SQS z 256 KB na 1 MB pre štandardné aj FIFO fronty. Táto rezerva je praktická pre občasnú veľkú udalosť, ale čokoľvek, čo odošlete nad 64 KB, platí násobok počtu blokov pri každom dotyku. Tím, ktorý prejde z priemerných dát 50 KB na 200 KB, zoštvornásobí počet požiadaviek SQS bez odoslania jedinej ďalšej správy.
Každá akcia API sa počíta samostatne
Každá akcia API voči fronte je požiadavka a násobok počtu blokov sa vzťahuje na každú z nich. Odoslanie, prijatie, vymazanie a zmena viditeľnosti správy sa merajú nezávisle.
Prejdime celý životný cyklus jednej 200 KB správy v štandardnej fronte. Odoslanie sú štyri spoplatnené požiadavky. Prijatie pracovníkom sú ďalšie štyri. Vymazanie po úspešnom spracovaní sú ďalšie štyri. Jedna logická správa, dvanásť spoplatnených požiadaviek, približne pol centa za tisíc pri katalógových cenách. Rovnaký životný cyklus pre 30 KB správu sú celkovo tri požiadavky. Veľkosť dát je dominantná premenná vo väčšine faktúr SQS, nie počet správ.
Ďalšie dva merače prekvapia nováčikov. Prázdne prijatia sú spoplatnené: každé dotazovanie, ktoré nevráti žiadne správy, sa stále počíta ako požiadavka, takže agresívna slučka krátkeho dotazovania na nečinnej fronte míňa peniaze za nič. A FIFO fronty majú približne 25-percentnú prirážku oproti štandardným na každej cenovej úrovni, čo rýchlo narastá, keď už proti vám pracuje násobok počtu blokov. Používajte FIFO tam, kde sú poradie a spracovanie presne raz skutočnou požiadavkou, a štandardné všade inde.
Ako to SNS vynásobí druhýkrát
SNS pridáva druhý rozmer účtovania, pretože publikovaná správa sa meria raz pri prijatí a znova pri každom doručení.
Publikovanie a doručovanie sú samostatné merače
Publikovanie do témy stojí približne päťdesiat centov za milión požiadaviek, s rovnakým blokovaním: 256 KB publikovanie sa počíta ako štyri. Každé doručenie každému odberateľovi sa potom meria tiež za každý 64 KB blok, pričom sadzba závisí od protokolu doručenia.
Nie všetky doručenia stoja rovnako. Doručenia do front SQS, funkcií Lambda a tokov Firehose nemajú poplatok za doručenie, vďaka čomu je fan-out SNS do SQS na strane doručenia takmer zdarma. Doručenia HTTP a HTTPS, e-mail a mobilné push notifikácie sú spoplatnené a SMS sa účtuje samostatne za každý segment správy. 256 KB udalosť rozposlaná do troch front SQS a jedného HTTP webhooku teda stojí štyri požiadavky na publikovanie, nula za tri doručenia do SQS a štyri doručenia HTTP. Zmenšite túto udalosť pod 64 KB a rovnaký fan-out stojí jedno publikovanie plus jedno doručenie HTTP.
SNS nasledovalo SQS k väčším dátam v septembri 2026 a povolilo 1 MB správy za nastavením maximálnej veľkosti na úrovni témy. Témy nakonfigurované nad 256 KB môžu doručovať len do SQS, Lambda a Firehose, s najviac sto odbermi. Toto obmedzenie je náznakom zamýšľaného vzoru: veľké udalosti patria do potrubia podporeného frontou, nie do rozposielania všetkým protokolom.
Prečo fan-out stále vyhráva
Merač doručenia láka tímy vynechať SNS a posielať duplicitné správy SQS každému spotrebiteľovi priamo. Odolajte tomu. Duplicitné odoslania znásobujú najdrahšiu časť cyklu, odoslanie plus prijatie plus vymazanie pre každého spotrebiteľa, zatiaľ čo fan-out SNS do SQS platí jedno publikovanie a nulové poplatky za doručenie SQS na odberateľa. Keď viacerí spotrebitelia potrebujú rovnakú udalosť, fan-out je zároveň čistejšia architektúra aj lacnejšia faktúra.
Koľko to stojí pri realistickom objeme
Katalógové sadzby sú čísla za milión, ktoré dávajú zmysel len po vynásobení, takže tu sú tri realistické scenáre.
Vedľajší projekt odosielajúci 2 milióny malých správ mesačne cez jednu štandardnú frontu neplatí takmer nič. Každá správa pod 64 KB stojí jedno odoslanie, jedno prijatie a jedno vymazanie, teda 6 miliónov požiadaviek. Prvý milión je zdarma, zostáva 5 miliónov po štyridsať centov za milión: približne dva doláre.
SaaS platforma strednej veľkosti publikujúca 5 miliónov 10 KB notifikácií mesačne do štandardnej témy s tromi odberateľmi SQS a jedným HTTP webhookom platí za časť SNS jednociferné sumy. Publikovanie stojí približne dva doláre a päťdesiat centov. Tri doručenia SQS sú zdarma. Doručenia HTTP stoja približne tri doláre pri šiestich centoch za sto tisíc. Následné akcie API SQS približne zdvojnásobia celkovú sumu, takže celé potrubie notifikácií zostáva pod pätnásť dolárov mesačne. Toto je scenár, kde je zasielanie správ skutočne zanedbateľné.
Teraz zopakujme tú istú SaaS záťaž s 200 KB dátami, pretože každá udalosť obsahuje celý dokument objednávky. Každý merač sa zoštvornásobí. Publikovanie vyskočí na desať dolárov, doručenia HTTP na dvanásť a následné prijatia a vymazania SQS sa tiež zoštvornásobia. Potrubie sa dostane na približne šesťdesiat dolárov mesačne, stále malé v absolútnych číslach, ale štvornásobok nákladov rovnakej záťaže s úspornými udalosťami, a rozdiel sa s rastúcim objemom zväčšuje. Pri 500 miliónoch blokovaných požiadaviek mesačne je rozdiel medzi úspornými a nafúknutými udalosťami štvorciferná ročná položka.
Cenové úrovne existujú, ale pre malé podniky zriedka hrajú rolu: štandardné požiadavky klesajú po 100 miliardách a 200 miliardách požiadaviek mesačne. Vašou realistickou pákou nie je cenová úroveň, ale priemerný faktor počtu blokov.
Prečo je produkčné zasielanie správ variabilné náklady na predaný tovar, nie režijné náklady
Zasielanie správ, ktoré doručuje váš produkt platbám platiacim zákazníkom, je priamym nákladom na výnos. Rozsahom rastie s používaním, zmizne, keď sa nič nepredáva, a investori očakávajú, že ho uvidia nad líniou hrubej marže spolu s výpočtom, databázou, úložiskom a šírkou pásma pre produkciu.
Účtovné štandardy tu dávajú priestor: všeobecne uznávané zásady presne nedefinujú náklady na predaný tovar a prax hrubej marže SaaS túto medzeru vypĺňa testom priamych nákladov. Opýtajte sa, či výdavok existuje preto, aby slúžil zákazníkom v produkcii. Produkčné fronty prenášajúce udalosti objednávok, témy notifikácií rozposielané pracovníkom orientovaným na zákazníka a doručenia webhookov na koncové body zákazníkov — to všetko test spĺňa. Testovacie fronty, témy záťažových testov, vývojové sandbox odbery a fronta nedoručiteľných správ vyprázdňujúca minuloročný záťažový test — to nie. Tie patria do výskumu a vývoja alebo do všeobecných režijných nákladov.
Hranica produkcie je celá hra. Jedna faktúra AWS zlučuje každú frontu a tému dokopy, takže označte produkčné zdroje a každý mesiac rozdeľte faktúru. Tímy, ktoré rozdelenie vynechajú, zvyčajne chybujú v lichotivejšom smere, zakopú infraštruktúru do režijných nákladov a vykážu hrubú maržu, ktorú ich jednotková ekonomika nedokáže obhájiť. Revízia pri due diligence to preklasifikuje za jedno popoludnie a prepracovaná marža nikdy nie je tou vyššou.
Účtujte čistú sumu, ktorú skutočne platíte. Bezplatná úroveň je zľava z fakturácie, nie výnos, takže nie je čo navyšovať. Ak chcete viditeľnosť do toho, koľko záťaže bezplatná úroveň pokrýva, sledujte spoplatnené požiadavky samostatne vo svojich metrikách a účtovný zápis nechajte v hotovostných nákladoch.
Ako to zaúčtovať, aby vaša marža hovorila pravdu
Dajte zasielaniu správ vlastný účet nákladov na predaj, namiesto miešania do všeobecnej cloudovej alebo softvérovej položky. Vyhradený účet, napríklad cloud messaging, vám umožní vydeliť mesačné výdavky mesačnými spoplatnenými požiadavkami a vidieť skutočné náklady na jednu blokovanú požiadavku, čo je číslo, ktoré vám povie, či rast dát zožiera maržu.
Poplatok AWS sa vyrovnáva po konci mesiaca, takže ho časovo rozlíšte. Odhadnite časť za zasielanie správ z metrík požiadaviek pri uzávierke, vyrovnajte na faktúru, keď príde, a časť za sandbox držte mimo nákladov na predaj. Tu je celý cyklus za mesiac, keď produkčné zasielanie správ stálo osemnásť dolárov a štyridsať centov a sandbox pridal dva doláre a desať centov:
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 USDZosúlaďte časovo rozlíšenú sumu s vaším cost explorerom zoskupeným podľa služby a typu používania aspoň raz mesačne. SQS a SNS by sa mali zobrazovať ako samostatné riadky, aby skok v jednom neskryl plochý trend druhého. Ak vediete svoje knihy v čistom texte, vzory sledovania nákladov v dokumentácii sa prirodzene rozširujú na rozdelenie zasielania správ podľa služby.
Jedna klasifikačná pasca, ktorej sa treba vyhnúť: prirážky FIFO a úložisko s predĺženou retenciou sú stále náklady na zasielanie správ, ale predĺžená retencia nad vaše skutočné okno opakovaného doručenia je voľba úložiska, nie náklad na doručenie. Buď skráťte retenciu, alebo presuňte časť za úložisko tam, kam patrí, namiesto toho, aby štrnásťdňová politika retencie potichu nafukovala náklady na predaný tovar.
Päť kontrol, ktoré zvyčajne znížia faktúru o 30 až 50 percent
Začnite dlhým dotazovaním a dávkovaním. Spolu rutinne znížia výdavky SQS takmer o polovicu a ich zavedenie zaberie popoludnie.
1. Zapnite dlhé dotazovanie všade
Nastavte čakaciu dobu prijatia na dvadsať sekúnd vo všetkých frontách. Pracovníci potom držia spojenie otvorené namiesto búšenia prázdnymi dotazovaniami, čo zruší riadok prázdnych prijatí, ktorý dominuje faktúram nečinných front, a vyhladí špičky CPU spotrebiteľov.
2. Dávkujte každé volanie API, ktoré to umožňuje
Odoslanie, prijatie a vymazanie podporujú dávky až desiatich správ. Pracovník spracúvajúci jednu správu na volanie platí desaťnásobok počtu požiadaviek pracovníka vyberajúceho desať naraz. Dávkové vymazania sú najčastejšie prehliadané: tímy, ktoré starostlivo dávkujú odoslania, často vymazávajú po jednej.
3. Dajte dátam diétu
Držte každú udalosť pod jedným 64 KB blokom. Uložte celý dokument do objektového úložiska a pošlite referenciu s identifikátormi, ktoré spotrebiteľ potrebuje — vzor kontrolného lístka (claim-check). Komprimujte, kde sú referencie nepraktické, a odstráňte vložené binárne dáta, duplikované záznamy zákazníkov a ukecaný kontext ladenia z horúcej cesty. Každý blok, ktorý odstránite, sa násobí naprieč odoslaniami, prijatiami, vymazaniami, publikovaniami a doručeniami.
4. Filtrujte na úrovni témy
Pripojte politiky filtrovania, aby každý odberateľ dostával len udalosti, ktoré spracúva. Nefiltrovaný fan-out platí doručenie a následné spracovanie za správy, ktoré spotrebiteľ pri príchode zahodí. Je to čistý odpad s jedno-riadkovou opravou na každý odber.
5. FIFO vyhradte tam, kde je poradie skutočné
Preverte, ktoré fronty skutočne potrebujú poradie a deduplikáciu. Prirážka FIFO sa vzťahuje na každú blokovanú požiadavku vo fronte, takže FIFO fronta prenášajúca udalosti, ktoré nikto nezoraďuje, je trvalá 25-percentná prirážka. Počas auditu nastavte krátku retenciu s frontou nedoručiteľných správ pre zlyhania namiesto toho, aby otravné správy opakovali na veľký počet požiadaviek.
Sledujte dve metriky, ktoré predpovedajú faktúru: približný počet odoslaných správ a počet prázdnych prijatí. Nastavte upozornenie, keď prázdne prijatia prekročia malý podiel z celkových prijatí, a štvrťročne prehodnoťte priemernú veľkosť dát na frontu. Rast dát je dosť postupný na to, aby ste ho mesiac po mesiaci prehliadli, a dosť veľký na to, aby záležal rok po roku.
Mesačný kontrolný zoznam pre náklady na zasielanie správ
Uzavrite cyklus každý mesiac rovnako, aby čísla zostali dôveryhodné:
- Získajte počty blokovaných požiadaviek pre SQS a SNS z rozpadu fakturácie, nie počty logických správ z aplikačných logov.
- Vydeľte výdavky každej služby jej blokovanými požiadavkami, aby ste dostali skutočné jednotkové náklady, a porovnajte ich so štyridsať- a päťdesiatcentovými katalógovými referenciami.
- Vypočítajte priemerný faktor počtu blokov na frontu vydelením spoplatnených požiadaviek logickými správami; čokoľvek nad 1,2 si zaslúži revíziu dát.
- Rozdeľte produkčné výdavky od testovacích a sandbox výdavkov pomocou značiek zdrojov a potvrďte, že do nákladov na predaj sa dostala len produkcia.
- Vyrovnajte minulomesačné časové rozlíšenie na vyrovnanú faktúru a rozdiel preneste do svojho odhadu.
- Skontrolujte prázdne prijatia ako podiel z celkových prijatí a potvrďte, že dlhé dotazovanie je po každej zmeně infraštruktúry stále zapnuté.
- Potvrďte, že každá nová fronta a téma vytvorená počas mesiaca zdedila produkčné značky a politiky filtrovania.
Vytiahnite dnes z fakturačnej konzoly tohtomesačné riadky SQS a SNS a vypočítajte priemerný faktor počtu blokov. Ak je nad 1,2, vašou najlacnejšou výhrou v marži sú menšie dáta, nie väčší plán.
