Sie haben Messaging mit vierzig Cent pro Million Requests budgetiert, dann kam die AWS-Rechnung dreimal höher als Ihre Nachrichtenzahl vermuten ließ. Der Übeltäter ist keine Preiserhöhung. Es ist die 64-KB-Chunking-Regel: AWS berechnet nicht eine logische Nachricht, sondern jeden 64-KB-Chunk der Payload bei jedem API-Aufruf, der sie berührt. Ein Order-Event von 200 KB sind vier abrechenbare Requests beim Senden, vier weitere, wenn ein Worker es empfängt, und nochmals vier, wenn der Worker es löscht. Zwölf Abrechnungen für eine Nachricht, bevor SNS-Fan-out das Ganze nochmals vervielfacht.
Dieser Beitrag erklärt, wie SQS und SNS Requests tatsächlich zählen, was das bei realistischem Volumen kostet, warum Produktions-Messaging in die Cost of Goods Sold gehört statt in die Gemeinkosten, und wie Sie es so verbuchen, dass Ihre Bruttomarge die Wahrheit erzählt.
Wie SQS aus einer Nachricht viele abrechenbare Requests macht
Die SQS-Preisgestaltung wirkt täuschend einfach: Standard-Queues kosten etwa vierzig Cent pro Million Requests, FIFO-Queues etwa fünfzig Cent pro Million, wobei die ersten Million Standard-Requests jeden Monat kostenlos sind. Die Komplexität verbirgt sich in der Definition eines Requests.
Jeder 64-KB-Chunk ist ein Request
Jeder begonnene 64-KB-Chunk der Payload zählt als eigener Request. Eine Nachricht von 30 KB ist ein Request. Eine Nachricht von 64 KB ist ein Request. Eine Nachricht von 65 KB ist zwei. Eine Nachricht von 200 KB ist vier, eine Nachricht von 256 KB ist vier, und eine Payload von 1 MB ist sechzehn.
Die letzte Zahl ist wichtiger als früher. Im August 2025 hat AWS die maximale SQS-Nachrichtengröße von 256 KB auf 1 MB für Standard- und FIFO-Queues angehoben. Der Spielraum ist praktisch für das gelegentliche große Event, aber alles, was Sie über 64 KB parken, zahlt den Chunk-Multiplikator bei jeder Berührung. Ein Team, das von durchschnittlichen Payloads von 50 KB auf 200 KB wechselt, vervierfacht seine SQS-Request-Zahl, ohne eine einzige zusätzliche Nachricht zu senden.
Jede API-Aktion zählt separat
Jede API-Aktion gegen eine Queue ist ein Request, und der Chunk-Multiplikator gilt für jede einzelne. Senden, Empfangen, Löschen und Ändern der Nachrichtensichtbarkeit werden jeweils unabhängig abgerechnet.
Gehen Sie den vollständigen Lebenszyklus einer 200-KB-Nachricht auf einer Standard-Queue durch. Das Senden sind vier abrechenbare Requests. Der Empfang durch den Worker sind vier weitere. Das Löschen nach erfolgreicher Verarbeitung sind nochmals vier. Eine logische Nachricht, zwölf abrechenbare Requests, ungefähr einen halben Cent pro Tausend zu Listenpreisen. Derselbe Lebenszyklus für eine 30-KB-Nachricht sind insgesamt drei Requests. Die Payload-Größe ist die dominierende Variable in den meisten SQS-Rechnungen, nicht die Nachrichtenzahl.
Zwei weitere Zähler überraschen Betreiber beim ersten Mal. Leere Empfänge sind abrechenbar: Jeder Poll, der keine Nachrichten zurückgibt, zählt weiterhin als Request, sodass eine aggressive Short-Poll-Schleife auf einer untätigen Queue Geld für nichts verbrennt. Und FIFO-Queues tragen einen Aufpreis von etwa 25 Prozent gegenüber Standard in jeder Volumenstufe, was schnell ins Gewicht fällt, wenn der Chunk-Multiplikator bereits gegen Sie arbeitet. Nutzen Sie FIFO dort, wo Reihenfolge und Exactly-once-Verarbeitung echte Anforderungen sind, und Standard überall sonst.
Wie SNS das Ganze ein zweites Mal multipliziert
SNS fügt eine zweite Abrechnungsdimension hinzu, weil eine veröffentlichte Nachricht einmal beim Eingang und erneut bei jeder Zustellung abgerechnet wird.
Publishes und Zustellungen sind separate Zähler
Das Veröffentlichen an ein Topic kostet etwa fünfzig Cent pro Million Requests, auf dieselbe Weise gechunkt: Ein 256-KB-Publish zählt als vier. Jede Zustellung an jeden Subscriber wird dann ebenfalls pro 64-KB-Chunk abgerechnet, wobei der Satz vom Zustellprotokoll abhängt.
Nicht alle Zustellungen kosten gleich. Zustellungen an SQS-Queues, Lambda-Funktionen und Firehose-Streams tragen keine Zustellgebühr, was SNS-zu-SQS-Fan-out auf der Zustellseite nahezu kostenlos macht. HTTP- und HTTPS-Zustellungen, E-Mail und Mobile Push werden abgerechnet, und SMS wird separat pro Nachrichtensegment bepreist. Ein 256-KB-Event, das an drei SQS-Queues und einen HTTP-Webhook verteilt wird, kostet daher vier Publish-Requests, null für die drei SQS-Zustellungen und vier HTTP-Zustellungen. Schrumpfen Sie dieses Event unter 64 KB, und dasselbe Fan-out kostet ein Publish plus eine HTTP-Zustellung.
SNS folgte SQS im September 2026 zu größeren Payloads und erlaubt 1-MB-Nachrichten hinter einer maximalen Größe auf Topic-Ebene. Topics, die über 256 KB konfiguriert sind, können nur an SQS, Lambda und Firehose zustellen, mit höchstens einhundert Subscriptions. Diese Einschränkung ist ein Hinweis auf das beabsichtigte Muster: Große Events gehören in eine queue-gestützte Pipeline, nicht an jedes Protokoll verschossen.
Warum Fan-out trotzdem gewinnt
Der Zustellzähler verleitet Teams, SNS zu überspringen und doppelte SQS-Nachrichten direkt an jeden Consumer zu senden. Widerstehen Sie dem. Doppelte Sendungen multiplizieren den teuersten Teil des Zyklus, nämlich Senden plus Empfangen plus Löschen pro Consumer, während SNS-zu-SQS-Fan-out ein Publish und null SQS-Zustellgebühren pro Subscriber zahlt. Wenn mehrere Consumer dasselbe Event brauchen, ist Fan-out sowohl die sauberere Architektur als auch die günstigere Rechnung.
Was das bei realem Volumen kostet
Listenpreise sind Pro-Million-Zahlen, die nur multipliziert Sinn ergeben, deshalb hier drei realistische Szenarien.
Ein Hobbyprojekt, das 2 Millionen kleine Nachrichten pro Monat über eine Standard-Queue sendet, zahlt fast nichts. Jede Nachricht unter 64 KB kostet ein Senden, ein Empfangen und ein Löschen, also 6 Millionen Requests. Die erste Million ist kostenlos, bleiben 5 Millionen zu vierzig Cent pro Million: etwa zwei Dollar.
Eine mittelgroße SaaS-Plattform, die 5 Millionen 10-KB-Benachrichtigungen pro Monat an ein Standard-Topic mit drei SQS-Subscribers und einem HTTP-Webhook veröffentlicht, zahlt für den SNS-Teil einen einstelligen Betrag. Publishes belaufen sich auf etwa zwei Dollar und fünfzig Cent. Die drei SQS-Zustellungen sind kostenlos. HTTP-Zustellungen kosten etwa drei Dollar zu sechs Cent pro hunderttausend. Die nachgelagerten SQS-API-Aktionen verdoppeln die Summe ungefähr, sodass die gesamte Benachrichtigungs-Pipeline unter fünfzehn Dollar pro Monat bleibt. Das ist das Szenario, in dem Messaging wirklich vernachlässigbar ist.
Spielen Sie nun dieselbe SaaS-Workload mit 200-KB-Payloads durch, weil jedes Event ein vollständiges Order-Dokument einbettet. Jeder Zähler vervierfacht sich. Publishes springen auf zehn Dollar, HTTP-Zustellungen auf zwölf, und die nachgelagerten SQS-Empfänge und -Löschungen vervierfachen sich ebenfalls. Die Pipeline landet bei etwa sechzig Dollar pro Monat, absolut immer noch klein, aber viermal die Kosten derselben Workload mit schlanken Events, und die Differenz wächst mit dem Volumen. Bei 500 Millionen gechunkten Requests pro Monat ist der Unterschied zwischen schlanken und aufgeblähten Events ein vierstelliger jährlicher Posten.
Volumenstufen existieren, sind aber für kleine Unternehmen selten relevant: Standard-Requests sinken schrittweise jenseits von 100 Milliarden und 200 Milliarden Requests pro Monat. Ihr realistischer Hebel ist nicht die Stufe, sondern der durchschnittliche Chunk-Faktor.
Warum Produktions-Messaging variable COGS ist und nicht Gemeinkosten
Messaging, das Ihr Produkt an zahlende Kunden liefert, ist ein direkter Umsatzaufwand. Es skaliert mit der Nutzung, es verschwindet, wenn nichts verkauft wird, und Investoren erwarten, es über der Bruttomargenlinie zu sehen, zusammen mit Compute, Datenbank, Speicher und Bandbreite für die Produktion.
Rechnungslegungsstandards lassen hier Spielraum: Allgemein anerkannte Grundsätze definieren die Cost of Goods Sold nicht präzise, und die SaaS-Bruttomargen-Praxis füllt die Lücke mit einem Direktkosten-Test. Fragen Sie, ob die Ausgabe existiert, um Kunden in der Produktion zu bedienen. Produktions-Queues, die Order-Events transportieren, Benachrichtigungs-Topics, die an kundenorientierte Worker verteilen, und Webhook-Zustellungen an Kunden-Endpunkte bestehen alle. Staging-Queues, Load-Test-Topics, Entwickler-Sandbox-Subscriptions und die Dead-Letter-Queue, die den Load-Test des letzten Quartals abarbeitet, bestehen nicht. Diese gehören in Forschung und Entwicklung oder allgemeine Gemeinkosten.
Die Produktionsgrenze ist das ganze Spiel. Eine AWS-Rechnung bündelt jede Queue und jedes Topic, also taggen Sie Produktionsressourcen und teilen Sie die Rechnung jeden Monat auf. Teams, die die Aufteilung überspringen, irren sich meist in die schmeichelhafte Richtung, vergraben Infrastruktur in Gemeinkosten und melden eine Bruttomarge, die ihre Unit Economics nicht verteidigen können. Eine Due-Diligence-Prüfung reklassifiziert das an einem Nachmittag, und die neu dargestellte Marge ist nie die höhere.
Verbuchen Sie den Nettobetrag, den Sie tatsächlich zahlen. Der kostenlose Kontingent ist ein Rechnungsrabatt, kein Umsatz, also gibt es nichts aufzublähen. Wenn Sie Sichtbarkeit darüber wollen, wie viel der Workload das kostenlose Kontingent absorbiert, verfolgen Sie abrechenbare Requests separat in Ihren Metriken und halten Sie den Buchungssatz zu Barzahlungskosten.
Wie Sie es verbuchen, damit Ihre Marge die Wahrheit erzählt
Geben Sie Messaging ein eigenes Cost-of-Sales-Konto, statt es in eine generische Cloud- oder Softwarezeile zu mischen. Ein dediziertes Konto wie cloud messaging lässt Sie die Monatsausgabe durch die monatlichen abrechenbaren Requests teilen und Ihre wahren Kosten pro gechunktem Request sehen, die Zahl, die Ihnen sagt, ob Payload-Wachstum die Marge auffrisst.
Die AWS-Abbuchung erfolgt erst nach Monatsende, also stellen Sie sie periodengerecht zurück. Schätzen Sie den Messaging-Anteil zum Abschluss aus Ihren Request-Metriken, gleichen Sie ihn mit der Rechnung ab, wenn sie eintrifft, und halten Sie den Sandbox-Anteil aus der Cost of Sales heraus. Hier ist ein vollständiger Zyklus für einen Monat, in dem Produktions-Messaging achtzehn Dollar und vierzig Cent kostete und die Sandbox zwei Dollar und zehn Cent hinzufügte:
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 USDStimmen Sie den zurückgestellten Betrag mindestens monatlich mit Ihrem Cost Explorer gruppiert nach Service und Nutzungstyp ab. SQS und SNS sollten als separate Zeilen erscheinen, damit ein Anstieg beim einen sich nicht im flachen Trend des anderen versteckt. Wenn Sie Ihre Bücher in Klartext führen, lassen sich die Kostenverfolgungsmuster in der Dokumentation natürlich auf eine Messaging-Aufteilung pro Service erweitern.
Eine Klassifizierungsfalle, die Sie vermeiden sollten: FIFO-Aufschläge und Speicher für verlängerte Aufbewahrung sind weiterhin Messaging-Kosten, aber verlängerte Aufbewahrung über Ihr tatsächliches Redrive-Fenster hinaus ist eine Speicherentscheidung, keine Zustellgebühr. Verkürzen Sie entweder die Aufbewahrung oder verschieben Sie den Speicheranteil dorthin, wo er hingehört, statt eine vierzehntägige Aufbewahrungsrichtlinie stillschweigend die Cost of Sales aufblähen zu lassen.
Fünf Kontrollen, die die Rechnung typischerweise um 30 bis 50 Prozent senken
Beginnen Sie mit Long Polling und Batching. Zusammen reduzieren sie die SQS-Ausgaben regelmäßig um fast die Hälfte und lassen sich an einem Nachmittag umsetzen.
1. Long Polling überall aktivieren
Setzen Sie die Empfangs-Wartezeit auf jeder Queue auf zwanzig Sekunden. Worker halten dann die Verbindung offen, statt leere Polls zu hämmern, was die Zeile für leere Empfänge, die Rechnungen für untätige Queues dominiert, zusammenbrechen lässt und CPU-Spitzen bei Consumern glättet.
2. Jeden API-Aufruf batchen, der es erlaubt
Senden, Empfangen und Löschen unterstützen alle Batches von bis zu zehn Nachrichten. Ein Worker, der eine Nachricht pro Aufruf verarbeitet, zahlt das Zehnfache der Request-Zahl eines Workers, der zehn auf einmal abarbeitet. Batch-Löschungen werden am häufigsten übersehen: Teams, die Sendungen sorgfältig batchen, löschen oft einzeln.
3. Setzen Sie die Payload auf Diät
Halten Sie jedes Event unter einem 64-KB-Chunk. Speichern Sie das vollständige Dokument im Objektspeicher und senden Sie eine Referenz mit den Identifikatoren, die der Consumer braucht, das Claim-Check-Muster. Komprimieren Sie, wo Referenzen unpraktisch sind, und entfernen Sie eingebettete Blobs, duplizierte Kundendatensätze und verbose Debug-Kontext aus dem Hot Path. Jeder Chunk, den Sie entfernen, multipliziert sich über Senden, Empfangen, Löschen, Publishes und Zustellungen.
4. Am Topic filtern
Hängen Sie Filterrichtlinien an, damit jeder Subscriber nur die Events erhält, die er verarbeitet. Ungefiltertes Fan-out zahlt Zustellung und nachgelagerte Verarbeitung für Nachrichten, die der Consumer beim Eintreffen verwirft. Das ist reine Verschwendung mit einer Ein-Zeilen-Korrektur pro Subscription.
5. FIFO reservieren, wo Reihenfolge real ist
Prüfen Sie, welche Queues wirklich Reihenfolge und Deduplizierung brauchen. Der FIFO-Aufpreis gilt für jeden gechunkten Request auf der Queue, sodass eine FIFO-Queue, die Events transportiert, die niemand ordnet, ein dauerhafter Aufschlag von 25 Prozent ist. Setzen Sie bei der Prüfung eine kurze Aufbewahrung mit einer Dead-Letter-Queue für Fehler, statt Poison-Nachrichten in eine große Request-Zahl wiederholen zu lassen.
Überwachen Sie die zwei Metriken, die die Rechnung vorhersagen: ungefähre Anzahl gesendeter Nachrichten und Anzahl leerer Empfänge. Alarmieren Sie, wenn leere Empfänge einen kleinen Anteil der gesamten Empfänge übersteigen, und überprüfen Sie die durchschnittliche Payload-Größe pro Queue vierteljährlich. Payload-Wachstum ist graduell genug, um es von Monat zu Monat zu übersehen, und groß genug, um von Jahr zu Jahr zu zählen.
Monatsabschluss-Checkliste für Messaging-Kosten
Schließen Sie den Kreis jeden Monat auf dieselbe Weise, damit die Zahlen vertrauenswürdig bleiben:
- Ziehen Sie gechunkte Request-Zahlen für SQS und SNS aus Ihrer Rechnungsaufschlüsselung, nicht logische Nachrichtenzahlen aus Anwendungslogs.
- Teilen Sie die Ausgabe jedes Service durch seine gechunkten Requests, um die wahren Stückkosten zu erhalten, und vergleichen Sie sie mit den Listen-Benchmarks von vierzig und fünfzig Cent.
- Berechnen Sie den durchschnittlichen Chunk-Faktor pro Queue, indem Sie abrechenbare Requests durch logische Nachrichten teilen; alles über 1,2 verdient eine Payload-Überprüfung.
- Trennen Sie Produktions- von Staging- und Sandbox-Ausgaben mithilfe von Ressourcen-Tags, und bestätigen Sie, dass nur Produktion in der Cost of Sales gelandet ist.
- Gleichen Sie die Rückstellung des letzten Monats mit der abgerechneten Rechnung ab und tragen Sie die Abweichung in Ihrer Schätzung vor.
- Prüfen Sie leere Empfänge als Anteil der gesamten Empfänge, und bestätigen Sie, dass Long Polling nach jeder Infrastrukturänderung noch aktiviert ist.
- Bestätigen Sie, dass jede im Monat neu erstellte Queue und jedes neue Topic die Produktions-Tags und Filterrichtlinien geerbt hat.
Ziehen Sie die SQS- und SNS-Zeilen dieses Monats heute aus Ihrer Abrechnungskonsole und berechnen Sie den durchschnittlichen Chunk-Faktor. Wenn er über 1,2 liegt, ist Ihr günstigster Margengewinn eine kleinere Payload, nicht ein größerer Plan.
