Rechner · Tooling

Was kostet deine Message-Queue wirklich?

AWS SQS, Azure Service Bus, Google Pub/Sub oder doch eigenes Kafka? Gib Nachrichten pro Monat und durchschnittliche Größe ein und sieh in Sekunden, welche Queue bei deiner Last am günstigsten ist.

4 Anbieter im direkten Vergleich·64-KB-Chunk-Logik berücksichtigt·Kafka inkl. Betriebsaufwand
live

Günstigste Queue kostet dich

3 €/Mo

Das sind 9.503 € pro Jahr weniger als die teuerste Option (Self-Managed Kafka) · 100% Unterschied.

Günstigster: Google Pub/Sub · 0,09 TiB Datenvolumen

Last-Profil

50 Mio.
1 Mio.250 Mio.500 Mio.1 Mrd.
2KB
1 KB64 KB128 KB256 KB

SQS & Service Bus rechnen pro 64-KB-Chunk ab — größere Nachrichten zählen als mehrere Anfragen.

AWS SQS

Standard-Queue, voll managed, kein Cluster

#2
18€/Mo
216 €/Jahr·managed
Basis50 Mio. Einheiten
ManagedAWS-NativeKein-Cluster
Azure Service Bus

Standard-Tier, pro Operation abgerechnet

#3
36€/Mo
430 €/Jahr·managed
Basis50 Mio. Einheiten
ManagedAzure-NativeSessions
Google Pub/Sub

Pro übertragenes Datenvolumen, 10 GB frei

BEST
3€/Mo
37 €/Jahr·managed
Basis0,09 TiB Datenvolumen
ManagedGCP-NativeGlobal
Self-Managed Kafka

3 Broker auf eigenen VMs + Betriebsaufwand

#4
795€/Mo
9.540 €/Jahr·self-managed
Basis3 Broker + 6 h Betrieb/Monat
Self-HostedKein-Lock-inBetriebsaufwand

Monatliche Kosten im Vergleich

€ pro Monat

Pub/Sub
3
SQS
18
Service Bus
36
Kafka
795
Pricing-Stand: 13. Juni 2026 · Listenpreise eu-central · USD→EUR mit Faustregel 1 USD ≈ 0.92EUR · Kafka inkl. geschätztem Betriebsaufwand. Schätzwerte ohne Egress & Storage — die echte Architektur klären wir im Gespräch.

Datenplattform statt Excel-Chaos.

AInfach Data baut euer Datenfundament — eine Wahrheit statt drei Excel-Versionen. Pragmatisch, in Sprints, ohne Buzzword-Bingo.

Kostenfreies Erstgespräch

Warum die Queue-Wahl selten am Preis hängt

Bei den meisten Mittelstands-Backends ist die monatliche Queue-Rechnung überraschend klein — ein paar Euro bis wenige hundert. Die teure Entscheidung ist nicht der Listenpreis, sondern das, was an der Queue hängt: Betreibt das Team Kafka selbst, oder soll der Cloud- Anbieter den Stress übernehmen? Genau diese Frage macht dieser Rechner sichtbar — er stellt den fixen Betriebsaufwand von self-managed Kafka neben die nutzungsbasierten Managed-Dienste.

Der zweite versteckte Hebel ist die Nachrichtengröße: Weil SQS und Service Bus pro 64-KB-Chunk abrechnen, kann dieselbe Nachrichtenmenge je nach Payload das Drei- bis Vierfache kosten. Wer große Dokumente durch die Queue schickt, zahlt schnell drauf — und merkt es erst auf der Rechnung.

Drei typische Muster

  • Viele kleine Events. Tracking, Status-Updates, IoT-Telemetrie mit 1–2 KB. Hier sind die Managed-Dienste fast geschenkt — Kafka lohnt sich erst bei extrem hohem Dauerdurchsatz.
  • Große Payloads. Dokumente, Bilder, Exporte über 64 KB. Entweder Pub/Sub (rein volumenbasiert) oder das „Claim-Check"-Muster mit Object-Storage statt voller Nutzlast in der Queue.
  • Multi-Cloud / kein Lock-in. Wer anbieterneutral bleiben will, landet bei self-managed Kafka — und muss den Betriebsaufwand ehrlich einpreisen, nicht nur die Broker-Miete.

Welche Queue für eure Architektur die richtige ist, lässt sich schnell klären — ehrlich, ohne Anbieter-Reflex.

Häufige Fragen

Wie werden die Kosten der einzelnen Anbieter berechnet?

AWS SQS rechnet pro Anfrage ab (Listenpreis ca. 0,40 USD je Mio., 1 Mio. frei), Azure Service Bus pro Operation im Standard-Tier (Grundgebühr + Staffel), Google Pub/Sub pro übertragenem Datenvolumen (ca. 40 USD/TiB, 10 GB frei) und self-managed Kafka über Broker-Infrastruktur plus geschätzten Betriebsaufwand. Wichtig: SQS und Service Bus rechnen Nachrichten in 64-KB-Chunks ab — eine 200-KB-Nachricht zählt als vier Anfragen. Genau deshalb ändert die Ø Größe das Ranking spürbar.

Ab wann lohnt sich self-managed Kafka gegenüber einer Managed-Queue?

Bei niedrigem Volumen sind die Managed-Dienste fast immer günstiger und ohne Betriebsaufwand. Kafka hat fixe Grundkosten (Broker-VMs plus Betrieb), die sich erst bei sehr hohem, dauerhaftem Durchsatz amortisieren — und auch dann nur, wenn das Team Kafka wirklich betreiben kann. Der Rechner setzt für Kafka bewusst einen Betriebsaufwand an (Patching, Monitoring, Rebalancing), weil „Broker laufen ja“ die teuerste Lüge im Infrastruktur-Budget ist.

Warum verteuern große Nachrichten die Managed-Queues so stark?

SQS und Azure Service Bus berechnen je angefangene 64 KB eine eigene Abrechnungseinheit. Bei 1–8 KB pro Nachricht ist das egal, ab ~64 KB vervielfacht es die Kosten. Das übliche Gegenmittel ist das „Claim-Check“-Muster: die eigentliche Nutzlast landet in Object-Storage (S3, Blob, GCS), durch die Queue läuft nur eine kleine Referenz. Pub/Sub rechnet rein nach Volumen und skaliert dort linearer.

Was zeigt der Rechner bewusst NICHT?

Egress zwischen Regionen, Storage für nicht verarbeitete Nachrichten, Dead-Letter-Queues, FIFO-Aufpreise und Premium-Tiers. Auch keine weichen Faktoren wie Lock-in, Ordering-Garantien oder Exactly-once-Semantik — die entscheiden in der Praxis oft mehr als der reine Preis. Der Rechner ist eine ehrliche Größenordnung für die erste Architektur-Entscheidung, kein Angebot.

Verwandte Rechner

Weiter rechnen