Vas pressupostar la missatgeria a quaranta cèntims per milió de sol·licituds, i després la factura d'AWS va arribar tres vegades més alta del que el recompte de missatges deia que hauria de ser. El culpable no és un augment de preus. És la regla de fragmentació de 64 KB: AWS no factura un missatge lògic, sinó que factura cada fragment de 64 KB de càrrega útil en cada crida d'API que el toca. Un esdeveniment de comanda de 200 KB són quatre sol·licituds facturables quan l'envies, quatre més quan un treballador el rep, i quatre més quan el treballador l'elimina. Dotze càrrecs per un sol missatge, abans que el fan-out d'SNS ho multipliqui de nou.
Aquest article explica com compten realment les sol·licituds SQS i SNS, quant costa això amb un volum realista, per què la missatgeria de producció pertany al cost dels béns venuts en lloc de les despeses generals, i com enregistrar-ho perquè el teu marge brut digui la veritat.
Com SQS converteix un missatge en moltes sol·licituds facturables
El preu d'SQS sembla enganyosament simple: les cues estàndard costen uns quaranta cèntims per milió de sol·licituds, les cues FIFO uns cinquanta cèntims per milió, amb el primer milió de sol·licituds estàndard gratuït cada mes. La complexitat s'amaga en la definició d'una sol·licitud.
Cada fragment de 64 KB és una sol·licitud
Cada fragment de 64 KB de càrrega útil iniciat compta com una sol·licitud pròpia. Un missatge de 30 KB és una sol·licitud. Un missatge de 64 KB és una sol·licitud. Un missatge de 65 KB és dues. Un missatge de 200 KB és quatre, un missatge de 256 KB és quatre, i una càrrega útil d'1 MB és setze.
Aquest darrer nombre importa més del que solia. L'agost de 2025 AWS va augmentar la mida màxima de missatge d'SQS de 256 KB a 1 MB tant per a les cues estàndard com per a les FIFO. El marge és convenient per a l'esdeveniment gran ocasional, però qualsevol cosa que deixis per sobre dels 64 KB paga el multiplicador de fragments en cada toc. Un equip que passa de càrregues útils mitjanes de 50 KB a 200 KB quadruplica el recompte de sol·licituds d'SQS sense enviar ni un sol missatge addicional.
Cada acció d'API compta per separat
Cada acció d'API contra una cua és una sol·licitud, i el multiplicador de fragments s'aplica a cadascuna. Enviar, rebre, eliminar i canviar la visibilitat del missatge es mesuren independentment.
Repassa el cicle de vida complet d'un missatge de 200 KB en una cua estàndard. L'enviament són quatre sol·licituds facturables. La recepció del treballador són quatre més. L'eliminació després del processament correcte són quatre més. Un missatge lògic, dotze sol·licituds facturables, aproximadament mig cèntim per miler a les tarifes de llista. El mateix cicle de vida per a un missatge de 30 KB és de tres sol·licituds en total. La mida de la càrrega útil és la variable dominant en la majoria de factures d'SQS, no el recompte de missatges.
Dos mesuradors més sorprenen els operadors novells. Les recepcions buides són facturables: cada sondeig que no retorna cap missatge encara compta com una sol·licitud, així que un bucle agressiu de sondeig curt en una cua inactiva consumeix diners per res. I les cues FIFO porten una prima d'aproximadament el 25 per cent sobre les estàndard a cada nivell de volum, que s'acumula ràpidament quan el multiplicador de fragments ja juga en contra teva. Utilitza FIFO on l'ordenació i el processament exactament una vegada siguin requisits genuïns, i estàndard a tota la resta.
Com SNS ho multiplica una segona vegada
SNS afegeix una segona dimensió de facturació, perquè un missatge publicat es mesura una vegada en arribar i de nou en cada lliurament.
Les publicacions i els lliuraments són mesuradors separats
Publicar en un tema costa uns cinquanta cèntims per milió de sol·licituds, fragmentat de la mateixa manera: una publicació de 256 KB compta com a quatre. Cada lliurament a cada subscriptor es mesura després també per fragment de 64 KB, amb la tarifa depenent del protocol de lliurament.
No tots els lliuraments costen el mateix. Els lliuraments a cues SQS, funcions Lambda i fluxos Firehose no comporten cap càrrec de lliurament, cosa que fa que el fan-out d'SNS a SQS sigui gairebé gratuït pel costat del lliurament. Els lliuraments HTTP i HTTPS, el correu electrònic i les notificacions push mòbils es mesuren, i l'SMS es factura per separat per segment de missatge. Un esdeveniment de 256 KB amb fan-out a tres cues SQS i un webhook HTTP costa, per tant, quatre sol·licituds de publicació, zero pels tres lliuraments SQS, i quatre lliuraments HTTP. Redueix aquest esdeveniment per sota dels 64 KB i el mateix fan-out costa una publicació més un lliurament HTTP.
SNS va seguir SQS cap a càrregues útils més grans el setembre de 2026, permetent missatges d'1 MB darrere d'una configuració de mida màxima a nivell de tema. Els temes configurats per sobre de 256 KB només poden lliurar a SQS, Lambda i Firehose, amb un màxim de cent subscripcions. La restricció és una pista sobre el patró previst: els esdeveniments grans pertanyen a un pipeline recolzat per cues, no a un enviament massiu a tots els protocols.
Per què el fan-out encara guanya
El mesurador de lliuraments tempta els equips a saltar-se SNS i enviar missatges SQS duplicats directament a cada consumidor. Resisteix-ho. Els enviaments duplicats multipliquen la part més cara del cicle, l'enviament més la recepció més l'eliminació per consumidor, mentre que el fan-out d'SNS a SQS paga una publicació i zero càrrecs de lliurament SQS per subscriptor. Quan diversos consumidors necessiten el mateix esdeveniment, el fan-out és alhora l'arquitectura més neta i la factura més barata.
Quant costa això amb un volum real
Les tarifes de llista són xifres per milió que només tenen sentit multiplicades, així que aquí tens tres formes realistes.
Un projecte secundari que envia 2 milions de missatges petits al mes a través d'una cua estàndard no paga gairebé res. Cada missatge per sota dels 64 KB costa un enviament, una recepció i una eliminació, o 6 milions de sol·licituds. El primer milió és gratuït, deixant 5 milions a quaranta cèntims per milió: uns dos dòlars.
Una plataforma SaaS mitjana que publica 5 milions de notificacions de 10 KB al mes en un tema estàndard amb tres subscriptors SQS i un webhook HTTP paga un sol dígit per la part d'SNS. Les publicacions són uns dos dòlars i cinquanta cèntims. Els tres lliuraments SQS són gratuïts. Els lliuraments HTTP són uns tres dòlars a sis cèntims per cent mil. Les accions d'API d'SQS posteriors aproximadament dupliquen el total, deixant tot el pipeline de notificacions per sota dels quinze dòlars al mes. Aquesta és la forma en què la missatgeria és genuïnament negligible.
Ara reprodueix aquella càrrega de treball SaaS amb càrregues útils de 200 KB perquè cada esdeveniment incrusta un document de comanda complet. Cada mesurador es quadruplica. Les publicacions salten a deu dòlars, els lliuraments HTTP a dotze, i les recepcions i eliminacions d'SQS posteriors també es quadrupliquen. El pipeline arriba a prop dels seixanta dòlars al mes, encara petit en termes absoluts, però quatre vegades el cost de la mateixa càrrega de treball amb esdeveniments lleugers, i la diferència es multiplica a mesura que el volum creix. Amb 500 milions de sol·licituds fragmentades al mes, la diferència entre esdeveniments lleugers i inflats és una partida anual de quatre xifres.
Els nivells de volum existeixen però poques vegades importen per a les petites empreses: les sol·licituds estàndard baixen de preu més enllà de 100.000 milions i 200.000 milions de sol·licituds al mes. La teva palanca realista no és el nivell, és el factor de fragment mitjà.
Per què la missatgeria de producció és COGS variable, no despeses generals
La missatgeria que lliura el teu producte als clients que paguen és un cost directe d'ingressos. Escala amb l'ús, desapareix quan no es ven res, i els inversors esperen veure-la per sobre de la línia de marge brut juntament amb la computació, la base de dades, l'emmagatzematge i l'amplada de banda de producció.
Els estàndards comptables deixen marge aquí: els principis generalment acceptats no defineixen amb precisió el cost dels béns venuts, i la pràctica del marge brut de SaaS omple el buit amb una prova de cost directe. Pregunta si la despesa existeix per servir clients en producció. Les cues de producció que porten esdeveniments de comanda, els temes de notificació amb fan-out a treballadors orientats al client, i els lliuraments de webhook als punts finals del client, tots passen. Les cues d'entorn de proves, els temes de proves de càrrega, les subscripcions de sandbox de desenvolupadors, i la cua de missatges morts que buida la prova de càrrega del trimestre passat, no. Aquests pertanyen a recerca i desenvolupament o a despeses generals.
La frontera de producció és tot el joc. Una factura d'AWS ho agrupa tot, cada cua i tema, així que etiqueta els recursos de producció i divideix la factura cada mes. Els equips que s'ometen la divisió normalment erren en la direcció afalagadora, enterrant la infraestructura en despeses generals i reportant un marge brut que la seva economia unitària no pot defensar. Una revisió de diligència ho reclasifica en una tarda, i el marge reformulat mai és el més alt.
Enregistra l'import net que realment pagues. El nivell gratuït és un descompte de facturació, no ingressos, així que no hi ha res a gross-up. Si vols visibilitat sobre quanta càrrega de treball absorbeix el nivell gratuït, segueix les sol·licituds facturables per separat en les teves mètriques i mantén l'assentament del llibre al cost d'efectiu.
Com enregistrar-ho perquè el teu marge digui la veritat
Dona a la missatgeria el seu propi compte de cost de vendes en lloc de barrejar-lo en una línia genèrica de núvol o programari. Un compte dedicat com ara missatgeria al núvol et permet dividir la despesa del mes pel nombre de sol·licituds facturables del mes i veure el teu cost real per sol·licitud fragmentada, que és el nombre que et diu si el creixement de la càrrega útil s'està menjant el marge.
El càrrec d'AWS es liquida després del tancament del mes, així que acumula'l. Estima la part de missatgeria a partir de les teves mètriques de sol·licituds en el tancament, ajusta-la a la factura quan arribi, i mantén la part de sandbox fora del cost de vendes. Aquí tens un cicle complet per a un mes en què la missatgeria de producció va costar divuit dòlars i quaranta cèntims i el sandbox va afegir dos dòlars i deu cèntims:
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 USDReconcilia l'import acumulat amb el teu explorador de costos agrupat per servei i tipus d'ús almenys mensualment. SQS i SNS haurien d'aparèixer com a línies separades perquè un pic en un no s'amagui dins de la tendència plana de l'altre. Si mantens els teus llibres en text pla, els patrons de seguiment de costos a la documentació s'estenen naturalment a una divisió de missatgeria per servei.
Una trampa de classificació a evitar: les primes FIFO i l'emmagatzematge de retenció estesa són encara costos de missatgeria, però la retenció estesa més enllà de la teva finestra genuïna de redrive és una elecció d'emmagatzematge, no un cost de lliurament. O escurça la retenció o mou la part d'emmagatzematge allà on pertoca en lloc de deixar que una política de retenció de catorze dies infli silenciosament el cost de vendes.
Cinc controls que normalment retallen la factura un 30 a 50 per cent
Comença amb el sondeig llarg i la lotificació. Junts normalment retallen la despesa d'SQS gairebé a la meitat i es triga una tarda a implementar-los.
1. Activa el sondeig llarg a tot arreu
Estableix el temps d'espera de recepció a vint segons a cada cua. Els treballadors llavors mantenen la connexió oberta en lloc de martellejar amb sondeigs buits, cosa que col·lapsa la línia de recepcions buides que domina les factures de cues inactives i suavitza els pics de CPU en els consumidors.
2. Lotifica cada crida d'API que ho permeti
Enviar, rebre i eliminar admeten tots lots de fins a deu missatges. Un treballador que processa un missatge per crida paga deu vegades el recompte de sol·licituds d'un treballador que buida deu alhora. Les eliminacions per lots són les més sovint oblidades: els equips que lotifiquen acuradament els enviaments sovint eliminen d'un en un.
3. Posa la càrrega útil a règim
Mantén cada esdeveniment per sota d'un fragment de 64 KB. Emmagatzema el document complet en emmagatzematge d'objectes i envia una referència amb els identificadors que el consumidor necessita, el patró de xec de reclamació. Comprimeix on les referències siguin poc pràctiques, i elimina els blobs incrustats, els registres de clients duplicats i el context de depuració verbose del camí actiu. Cada fragment que elimines es multiplica a través d'enviaments, recepcions, eliminacions, publicacions i lliuraments.
4. Filtra al tema
Adjunta polítiques de filtre perquè cada subscriptor rebi només els esdeveniments que gestiona. El fan-out sense filtre paga el lliurament i el processament posterior per missatges que el consumidor descarta en arribar. Això és pur malbaratament amb una solució d'una línia per subscripció.
5. Reserva FIFO per on l'ordenació és real
Audita quines cues necessiten genuïnament ordenació i deduplicació. La prima de FIFO s'aplica a cada sol·licitud fragmentada a la cua, així que una cua FIFO que porta esdeveniments que ningú ordena és un recàrrec permanent del 25 per cent. Mentre audites, estableix una retenció curta amb una cua de missatges morts per als errors en lloc de deixar que els missatges verinosos reintentin en un gran recompte de sol·licituds.
Monitoritza les dues mètriques que prediuen la factura: el nombre aproximat de missatges enviats i el nombre de recepcions buides. Alerta quan les recepcions buides superin una petita part de les recepcions totals, i revisa la mida mitjana de la càrrega útil per cua trimestralment. El creixement de la càrrega útil és prou gradual per passar desapercebut mes a mes i prou gran per importar any rere any.
Llista de verificació de final de mes per als costos de missatgeria
Tanca el cicle de la mateixa manera cada mes perquè les xifres segueixin sent fiables:
- Extreu els recomptes de sol·licituds fragmentades d'SQS i SNS del teu desglossament de facturació, no els recomptes de missatges lògics dels registres de l'aplicació.
- Divideix la despesa de cada servei pel seu nombre de sol·licituds fragmentades per obtenir el cost unitari real, i compara'l amb les referències de llista de quaranta i cinquanta cèntims.
- Calcula el factor de fragment mitjà per cua dividint les sol·licituds facturables pels missatges lògics; qualsevol cosa per sobre d'1,2 mereix una revisió de la càrrega útil.
- Separa la despesa de producció de la d'entorn de proves i sandbox utilitzant etiquetes de recursos, i confirma que només la producció va acabar al cost de vendes.
- Ajusta l'acumulació del mes passat a la factura liquidada i trasllada la variància a la teva estimació.
- Comprova les recepcions buides com a part de les recepcions totals, i confirma que el sondeig llarg segueix activat després de qualsevol canvi d'infraestructura.
- Confirma que cada cua i tema nous creats durant el mes van heretar les etiquetes de producció i les polítiques de filtre.
Extreu avui les línies d'SQS i SNS d'aquest mes de la teva consola de facturació i calcula el factor de fragment mitjà. Si se situa per sobre d'1,2, la teva victòria de marge més barata és una càrrega útil més petita, no un pla més gran.
