AWS Lambda erhält Warteschlangenmodus für selbstverwaltetes Kafka: Mehrere Poller lesen eine Partition ohne Reihenfolge, Amazon MSK wird noch nicht unterstützt

Am 2. November 2026 kündigte AWS an, dass AWS Lambda jetzt Warteschlangen für Apache Kafka in selbstverwalteten Kafka-Ereignisquellen-Zuordnungen unterstützt. Bisher nutzte eine Kafka-Ereignisquellen-Zuordnung das Consumer-Group-Protokoll von Kafka, das jede Partition genau einem Verbraucher einer Gruppe zuweist. Ein Team, das mehr Parallelität wollte, musste Topics überpartitionieren oder den Datenverkehr in ein separates Warteschlangensystem verlagern, was zusätzliche Infrastruktur und mehr Producer-Code bedeutete. Der neue Warteschlangenmodus beruht auf Kafka-Share-Groups, bei denen mehrere Event-Poller gleichzeitig aus derselben Partition lesen können.

AWS sagt, jeder Event-Poller unterstütze bis zu 10 gleichzeitige Aufrufe, die Parallelität hänge nicht mehr von der Partitionszahl ab, und Producer, Topic-Konfiguration und Funktionscode müssten nicht geändert werden. Ein langsames oder fehlgeschlagenes Ereignis hält andere Ereignisse derselben Partition nicht mehr auf. Die Ankündigung nennt den Preis offen: Der Warteschlangenmodus bewahrt die Partitionsreihenfolge nicht und ist für Workloads gedacht, die sie nicht brauchen. Als Beispiele nennt sie Fälle, in denen jedes Ereignis eine unabhängige Arbeitseinheit ist und Geschwindigkeit wichtiger ist als Reihenfolge, etwa Bild- und Videokodierung, Betrugserkennung, Benachrichtigungen und Telemetrie-Erfassung.

Die Voraussetzungen sind enger, als die Überschrift vermuten lässt. Die Ankündigung sagt, der Cluster müsse Share Groups aktiviert haben, etwa Apache Kafka 4.2 oder neuer, und die Funktion sei in allen kommerziellen AWS-Regionen verfügbar, in denen die selbstverwaltete Kafka-Zuordnung verfügbar ist. Sie nennt Cluster, die Kunden selbst betreiben, und verwaltete Angebote wie Confluent Cloud. Das Entwicklerhandbuch von Lambda geht weiter. Es sagt, Share Groups seien in Apache Kafka 4.0 erschienen, der Kafka Queue Poller erfordere aber Version 4.2 oder neuer, und der Warteschlangenmodus gelte nur für selbstverwaltete Cluster. In seinen Worten unterstützt Amazon MSK den Warteschlangenmodus derzeit nicht, und AWS ergänze die MSK-Unterstützung, sobald MSK Kafka 4.2 oder neuer mit aktivierten Share Groups anbietet. Ein Team, das Amazon MSK betreibt, sollte die Ankündigung daher nicht so lesen, als umfasse sie seinen Cluster.

Zur Nutzung erstellt man eine selbstverwaltete Kafka-Ereignisquellen-Zuordnung mit ConsumptionMode auf Queue, über die Konsole, die Lambda-API, die AWS CLI, CloudFormation, SAM oder CDK. Ohne Angabe verwendet die Zuordnung den Standardmodus Stream. Das Handbuch vergleicht beide. Stream behält die Reihenfolge je Partition und erlaubt bis zu 5 gleichzeitige Aufrufe je Poller. Queue garantiert keine Reihenfolge und erlaubt bis zu 10. Beide nennen bis zu 5 MB/s Durchsatz je Poller, doch der On-Demand-Abschnitt des Warteschlangenmodus nennt bis zu 1 MB/s je Poller bei höchstens 5 Pollern, also 5 MB/s insgesamt und 50 gleichzeitigen Aufrufen. Im bereitgestellten Modus lassen sich minimale und maximale Pollerzahlen festlegen, das Minimum von 1 bis 200 und das Maximum von 1 bis 2.000, und das Handbuch nennt dort bis zu 5 MB/s je Poller. Da die Seiten für die Modi unterschiedliche Grenzen angeben, sollte man den Modus lesen, den man tatsächlich betreibt.

Mehrere vertraute Einstellungen ändern sich. MaximumBatchingWindowInSeconds wird im Warteschlangenmodus nicht unterstützt, die Angabe führt zu einem Validierungsfehler, weil der Kafka-Share-Consumer jeden Datensatz eines Batches ausdrücklich bestätigen muss. StartingPosition und StartingPositionTimestamp werden ebenfalls nicht unterstützt, da der Warteschlangenmodus immer ab der bestätigten Position der Share Group liest. MaximumRetryAttempts ist standardmäßig 0, und der Broker wiederholt, wenn kein Fehlerziel konfiguriert ist. Ereignisfilterung mit bis zu 5 Mustern, Schemaregister, Fehlerziele und Protokollierung der Zuordnung werden unterstützt. Warteschlangen-Zuordnungen teilen Event-Poller-Einheiten nur mit anderen Warteschlangen-Zuordnungen. Das allgemeine Kafka-Handbuch warnt zudem, dass Zuordnungen jedes Ereignis mindestens einmal verarbeiten, der Funktionscode also idempotent sein sollte.

Zu den Kosten sagt die Ankündigung, es gelte die übliche Lambda-Preisgestaltung, und Kunden mit bereitgestelltem Modus zahlen zusätzlich für die Nutzung von Event-Poller-Einheiten. Ein sinnvoller Versuch beginnt mit einem unkritischen Topic: Clusterversion und aktivierte Share Groups bestätigen, in einem Testkonto eine Warteschlangen-Zuordnung anlegen, einen Schub senden und Durchsatz, Duplikate und den Umgang mit fehlgeschlagenen Datensätzen messen. Zuerst ist zu klären, ob ein Verbraucher Reihenfolge braucht, denn der Warteschlangenmodus entfernt sie. Die Ankündigung nennt keinen Benchmark für Durchsatzgewinne, jede Beschleunigungsaussage muss also aus dem eigenen Test stammen.