Avevi messo a budget il messaging a quaranta centesimi per milione di richieste, poi è arrivata la fattura AWS tre volte più alta di quanto dicesse il tuo conteggio dei messaggi. Il colpevole non è un aumento di prezzo. È la regola del chunk da 64 KB: AWS non fattura un messaggio logico, fattura ogni chunk da 64 KB di payload su ogni chiamata API che lo tocca. Un evento ordine da 200 KB sono quattro richieste fatturabili quando lo invii, altre quattro quando un worker lo riceve e altre quattro quando il worker lo elimina. Dodici addebiti per un solo messaggio, prima che il fan-out di SNS li moltiplichi di nuovo.
Questo articolo spiega come SQS e SNS contano davvero le richieste, quanto costa a volumi realistici, perché il messaging di produzione appartiene al costo del venduto e non alle spese generali, e come contabilizzarlo affinché il tuo margine lordo dica la verità.
Come SQS trasforma un messaggio in molte richieste fatturabili
Il pricing di SQS sembra ingannevolmente semplice: le code Standard costano circa quaranta centesimi per milione di richieste, le code FIFO circa cinquanta centesimi per milione, con il primo milione di richieste Standard gratuito ogni mese. La complessità si nasconde nella definizione di richiesta.
Ogni chunk da 64 KB è una richiesta
Ogni chunk da 64 KB di payload avviato conta come una richiesta a sé. Un messaggio da 30 KB è una richiesta. Un messaggio da 64 KB è una richiesta. Un messaggio da 65 KB sono due. Un messaggio da 200 KB sono quattro, un messaggio da 256 KB sono quattro, e un payload da 1 MB sono sedici.
Quest'ultimo numero conta più di prima. Ad agosto 2025 AWS ha innalzato la dimensione massima dei messaggi SQS da 256 KB a 1 MB sia per le code Standard sia per le FIFO. Il margine è comodo per l'evento grande occasionale, ma tutto ciò che parcheggi sopra i 64 KB paga il moltiplicatore dei chunk a ogni tocco. Un team che passa da payload medi di 50 KB a 200 KB quadruplica il proprio conteggio di richieste SQS senza inviare un solo messaggio in più.
Ogni azione API conta separatamente
Ogni azione API su una coda è una richiesta, e il moltiplicatore dei chunk si applica a ciascuna. Inviare, ricevere, eliminare e modificare la visibilità di un messaggio vengono misurati indipendentemente.
Percorri l'intero ciclo di vita di un messaggio da 200 KB su una coda Standard. L'invio è quattro richieste fatturabili. La ricezione del worker sono altre quattro. L'eliminazione dopo l'elaborazione riuscita sono altre quattro. Un messaggio logico, dodici richieste fatturabili, circa mezzo centesimo per mille ai prezzi di listino. Lo stesso ciclo per un messaggio da 30 KB è di tre richieste in totale. La dimensione del payload è la variabile dominante nella maggior parte delle fatture SQS, non il numero di messaggi.
Altri due contatori sorprendono chi opera per la prima volta. Le ricezioni vuote sono fatturabili: ogni polling che non restituisce messaggi conta comunque come richiesta, quindi un loop aggressivo di short polling su una coda inattiva brucia denaro per nulla. E le code FIFO comportano un premio di circa il 25 percento rispetto alle Standard a ogni scaglione di volume, che si accumula in fretta quando il moltiplicatore dei chunk sta già lavorando contro di te. Usa FIFO dove l'ordinamento e l'elaborazione exactly-once sono requisiti reali, e Standard ovunque altrove.
Come SNS lo moltiplica una seconda volta
SNS aggiunge una seconda dimensione di fatturazione, perché un messaggio pubblicato viene misurato una volta all'arrivo e di nuovo a ogni consegna.
Pubblicazioni e consegne sono contatori separati
Pubblicare su un topic costa circa cinquanta centesimi per milione di richieste, suddivise negli stessi chunk: una pubblicazione da 256 KB conta come quattro. Ogni consegna a ogni sottoscrittore viene poi misurata anch'essa per chunk da 64 KB, con la tariffa che dipende dal protocollo di consegna.
Non tutte le consegne costano allo stesso modo. Le consegne verso code SQS, funzioni Lambda e stream Firehose non comportano addebiti di consegna, il che rende il fan-out SNS-to-SQS quasi gratuito sul lato consegna. Le consegne HTTP e HTTPS, l'email e il mobile push sono misurati, e gli SMS sono prezzati separatamente per segmento di messaggio. Un evento da 256 KB distribuito a tre code SQS e un webhook HTTP costa quindi quattro richieste di pubblicazione, zero per le tre consegne SQS e quattro consegne HTTP. Riduci quell'evento sotto i 64 KB e lo stesso fan-out costa una pubblicazione più una consegna HTTP.
SNS ha seguito SQS verso payload più grandi a settembre 2026, consentendo messaggi da 1 MB dietro un'impostazione a livello di topic per la dimensione massima. I topic configurati sopra i 256 KB possono consegnare solo a SQS, Lambda e Firehose, con al massimo cento sottoscrizioni. Il vincolo è un indizio sul pattern previsto: gli eventi grandi appartengono a una pipeline basata su coda, non diffusi a ogni protocollo.
Perché il fan-out vince comunque
Il contatore delle consegne tenta i team a saltare SNS e inviare messaggi SQS duplicati direttamente a ciascun consumer. Resisti. Gli invii duplicati moltiplicano la parte più costosa del ciclo, l'invio più la ricezione più l'eliminazione per consumer, mentre il fan-out SNS-to-SQS paga una pubblicazione e zero addebiti di consegna SQS per sottoscrittore. Quando diversi consumer hanno bisogno dello stesso evento, il fan-out è sia l'architettura più pulita sia la fattura più economica.
Quanto costa a volumi reali
Le tariffe di listino sono numeri per milione che hanno senso solo moltiplicati, quindi ecco tre scenari realistici.
Un side project che invia 2 milioni di piccoli messaggi al mese attraverso una coda Standard paga quasi nulla. Ogni messaggio sotto i 64 KB costa un invio, una ricezione e un'eliminazione, ovvero 6 milioni di richieste. Il primo milione è gratuito, lasciando 5 milioni a quaranta centesimi per milione: circa due dollari.
Una piattaforma SaaS di medie dimensioni che pubblica 5 milioni di notifiche da 10 KB al mese su un topic Standard con tre sottoscrittori SQS e un webhook HTTP paga una cifra a una sola cifra per la parte SNS. Le pubblicazioni ammontano a circa due dollari e cinquanta centesimi. Le tre consegne SQS sono gratuite. Le consegne HTTP ammontano a circa tre dollari a sei centesimi per centomila. Le azioni API SQS a valle raddoppiano all'incirca il totale, lasciando l'intera pipeline di notifiche sotto i quindici dollari al mese. Questa è la forma in cui il messaging è genuinamente trascurabile.
Ora riproduci quel carico di lavoro SaaS con payload da 200 KB perché ogni evento incorpora un documento d'ordine completo. Ogni contatore quadruplica. Le pubblicazioni salgono a dieci dollari, le consegne HTTP a dodici, e anche le ricezioni ed eliminazioni SQS a valle quadruplicano. La pipeline arriva a circa sessanta dollari al mese, ancora piccola in termini assoluti, ma quattro volte il costo dello stesso carico di lavoro con eventi snelli, e il divario si intensifica con la crescita del volume. A 500 milioni di richieste suddivise in chunk al mese, la differenza tra eventi snelli e gonfi è una voce annuale a quattro cifre.
Gli scaglioni di volume esistono ma raramente contano per le piccole imprese: le richieste Standard scendono oltre i 100 miliardi e i 200 miliardi di richieste al mese. La tua leva realistica non è lo scaglione, è il fattore medio di chunk.
Perché il messaging di produzione è COGS variabile, non spese generali
Il messaging che consegna il tuo prodotto ai clienti paganti è un costo diretto del ricavo. Scala con l'utilizzo, scompare quando non si vende nulla, e gli investitori si aspettano di vederlo sopra la linea del margine lordo insieme a compute, database, storage e larghezza di banda per la produzione.
I principi contabili lasciano spazio qui: i principi generalmente accettati non definiscono con precisione il costo del venduto, e la prassi del margine lordo SaaS colma il vuoto con un test sui costi diretti. Chiediti se la spesa esiste per servire i clienti in produzione. Le code di produzione che trasportano eventi ordine, i topic di notifica che distribuiscono ai worker rivolti al cliente e le consegne webhook verso endpoint dei clienti passano tutti il test. Le code di staging, i topic di load test, le sottoscrizioni sandbox degli sviluppatori e la dead-letter queue che drena il load test del trimestre scorso no. Quelli appartengono alla ricerca e sviluppo o alle spese generali.
Il confine della produzione è l'intero gioco. Una fattura AWS raggruppa insieme ogni coda e topic, quindi tagga le risorse di produzione e suddividi la fattura ogni mese. I team che saltano la suddivisione di solito sbagliano nella direzione lusinghiera, seppellendo l'infrastruttura nelle spese generali e riportando un margine lordo che la loro unit economics non può difendere. Una due diligence la riclassifica in un pomeriggio, e il margine rideterminato non è mai quello più alto.
Contabilizza l'importo netto che paghi effettivamente. Il livello gratuito è uno sconto di fatturazione, non un ricavo, quindi non c'è nulla da integrare. Se vuoi visibilità su quanta parte del carico di lavoro assorbe il livello gratuito, traccia le richieste fatturabili separatamente nelle tue metriche e mantieni la registrazione a conto al costo effettivo.
Come contabilizzarlo affinché il tuo margine dica la verità
Dai al messaging un proprio conto di costo del venduto invece di fonderlo in una voce generica cloud o software. Un conto dedicato come cloud messaging ti consente di dividere la spesa del mese per le richieste fatturabili del mese e vedere il tuo vero costo per richiesta suddivisa in chunk, che è il numero che ti dice se la crescita del payload sta erodendo il margine.
L'addebito AWS si regola dopo la fine del mese, quindi accantonalo. Stima la porzione di messaging dalle tue metriche di richieste alla chiusura, conguaglia alla fattura quando arriva, e tieni la porzione sandbox fuori dal costo del venduto. Ecco un ciclo completo per un mese in cui il messaging di produzione è stato di diciotto dollari e quaranta centesimi e il sandbox ha aggiunto due dollari e dieci centesimi:
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" "Gennaio SQS prod 8,2M richieste suddivise in chunk più pubblicazioni SNS e consegne HTTP"
Expenses:CostOfSales:Cloud-Messaging 18.40 USD
Liabilities:Accrued:AWS -18.40 USD
2026-02-03 * "AWS" "Si regola l'addebito AWS di gennaio, messaging di produzione più 2,10 sandbox"
Liabilities:Accrued:AWS 18.40 USD
Expenses:Research:Cloud-Sandbox 2.10 USD
Assets:Cash:Operating -20.50 USDRiconcilia l'importo accantonato con il tuo cost explorer raggruppato per servizio e tipo di utilizzo almeno mensilmente. SQS e SNS dovrebbero comparire come righe separate così un picco in uno non si nasconde dentro il trend piatto dell'altro. Se tieni i libri in testo semplice, i pattern di tracciamento dei costi nella documentazione si estendono naturalmente a una suddivisione del messaging per servizio.
Una trappola di classificazione da evitare: i premi FIFO e lo storage a retention estesa sono comunque costi di messaging, ma la retention estesa oltre la tua finestra reale di redrive è una scelta di storage, non un costo di consegna. O accorcia la retention o sposta la porzione di storage dove appartiene, invece di lasciare che una policy di retention di quattordici giorni gonfi silenziosamente il costo del venduto.
Cinque controlli che tipicamente riducono la fattura del 30-50 percento
Inizia con il long polling e il batching. Insieme riducono regolarmente la spesa SQS di quasi la metà e richiedono un pomeriggio per essere implementati.
1. Attiva il long polling ovunque
Imposta il tempo di attesa della ricezione a venti secondi su ogni coda. I worker mantengono quindi la connessione aperta invece di martellare con polling vuoti, il che fa crollare la riga delle ricezioni vuote che domina le fatture delle code inattive e appiana i picchi di CPU sui consumer.
2. Raggruppa in batch ogni chiamata API che lo consente
Invio, ricezione ed eliminazione supportano tutti batch fino a dieci messaggi. Un worker che elabora un messaggio per chiamata paga dieci volte il conteggio di richieste di un worker che ne drena dieci alla volta. Le eliminazioni in batch sono quelle più comunemente dimenticate: i team che raggruppano con cura gli invii spesso eliminano uno alla volta.
3. Metti a dieta il payload
Mantieni ogni evento sotto un chunk da 64 KB. Conserva il documento completo nello storage a oggetti e invia un riferimento con gli identificatori di cui il consumer ha bisogno, il pattern claim-check. Comprimi dove i riferimenti sono impraticabili, ed elimina dal percorso caldo blob incorporati, record cliente duplicati e contesto di debug verboso. Ogni chunk che rimuovi si moltiplica attraverso invii, ricezioni, eliminazioni, pubblicazioni e consegne.
4. Filtra a livello di topic
Allega policy di filtro così ogni sottoscrittore riceve solo gli eventi che gestisce. Il fan-out non filtrato paga la consegna e l'elaborazione a valle per messaggi che il consumer scarta all'arrivo. È puro spreco con una correzione di una riga per sottoscrizione.
5. Riserva FIFO a dove l'ordinamento è reale
Verifica quali code necessitano genuinamente di ordinamento e deduplicazione. Il premio di FIFO si applica a ogni richiesta suddivisa in chunk sulla coda, quindi una coda FIFO che trasporta eventi che nessuno ordina è un sovrapprezzo permanente del 25 percento. Durante la verifica, imposta una retention breve con una dead-letter queue per gli errori invece di lasciare che i messaggi avvelenati ritentino fino a un conteggio di richieste elevato.
Monitora le due metriche che predicono la fattura: il numero approssimativo di messaggi inviati e il numero di ricezioni vuote. Avvisa quando le ricezioni vuote superano una piccola quota delle ricezioni totali, e rivedi trimestralmente la dimensione media del payload per coda. La crescita del payload è abbastanza graduale da sfuggire di mese in mese e abbastanza grande da contare di anno in anno.
Checklist di fine mese per i costi di messaging
Chiudi il ciclo allo stesso modo ogni mese così che i numeri restino affidabili:
- Estrai i conteggi di richieste suddivise in chunk per SQS e SNS dal tuo dettaglio di fatturazione, non i conteggi di messaggi logici dai log applicativi.
- Dividi la spesa di ciascun servizio per le sue richieste suddivise in chunk per ottenere il vero costo unitario, e confrontalo con i benchmark di listino di quaranta e cinquanta centesimi.
- Calcola il fattore medio di chunk per coda dividendo le richieste fatturabili per i messaggi logici; qualsiasi valore sopra 1,2 merita una revisione del payload.
- Suddividi la spesa di produzione da quella di staging e sandbox usando i tag delle risorse, e conferma che solo la produzione sia finita nel costo del venduto.
- Conguaglia l'accantonamento del mese scorso alla fattura regolata e riporta lo scostamento nella tua stima.
- Controlla le ricezioni vuote come quota delle ricezioni totali, e conferma che il long polling sia ancora attivo dopo qualsiasi modifica all'infrastruttura.
- Conferma che ogni nuova coda e topic creato durante il mese abbia ereditato i tag di produzione e le policy di filtro.
Estrai oggi le righe SQS e SNS di questo mese dalla tua console di fatturazione e calcola il fattore medio di chunk. Se è sopra 1,2, la tua vittoria di margine più economica è un payload più piccolo, non un piano più grande.
