AWS Lambda ajoute un mode file pour Kafka autogéré : plusieurs consommateurs lisent une partition sans ordre, Amazon MSK n'est pas encore pris en charge

Le 2 novembre 2026, AWS a annoncé qu'AWS Lambda prend désormais en charge les files pour Apache Kafka dans les mappages de sources d'événements Kafka autogérés. Jusqu'ici, un mappage de source d'événements Kafka utilisait le protocole de groupe de consommateurs Kafka, qui attribue chaque partition à exactement un consommateur du groupe. Une équipe qui voulait plus de parallélisme devait surpartitionner ses rubriques ou déplacer le trafic vers un système de files distinct, ce qui ajoutait de l'infrastructure à exploiter et du code de producteur à maintenir. Le nouveau mode file repose sur les groupes de partage Kafka, qui permettent à plusieurs consommateurs d'événements de lire la même partition en même temps.

AWS indique que chaque consommateur d'événements prend en charge jusqu'à 10 invocations simultanées, que le parallélisme n'est plus lié au nombre de partitions et qu'aucune modification n'est nécessaire côté producteurs, configuration des rubriques ou code de fonction. Un événement lent ou en échec ne retient plus les autres événements de la même partition. L'annonce est claire sur le prix à payer : le mode file ne conserve pas l'ordre des partitions et convient aux charges qui n'en ont pas besoin. Elle cite des cas où chaque événement est une unité de travail indépendante et où la vitesse compte plus que l'ordre, comme l'encodage d'images et de vidéos, la détection de fraude, l'envoi de notifications et l'ingestion de télémétrie.

Les conditions sont plus étroites que le titre ne le laisse penser. L'annonce dit que le cluster doit avoir les groupes de partage activés, par exemple Apache Kafka 4.2 ou plus récent, et que la fonction est disponible dans toutes les régions AWS commerciales où le mappage autogéré est disponible. Elle indique couvrir les clusters que les clients exploitent eux-mêmes et des offres gérées comme Confluent Cloud. Le guide du développeur Lambda va plus loin. Il précise que les groupes de partage sont apparus dans Apache Kafka 4.0, mais que le Kafka Queue Poller exige la version 4.2 ou plus récente, et que le mode file ne s'applique qu'aux clusters autogérés. Selon ses termes, Amazon MSK ne prend pas actuellement en charge le mode file, et AWS ajoutera la prise en charge de MSK lorsque MSK offrira Kafka 4.2 ou plus récent avec les groupes de partage activés. Une équipe qui exploite Amazon MSK ne doit donc pas lire l'annonce comme couvrant son cluster.

Pour l'utiliser, il faut créer un mappage de source d'événements Kafka autogéré avec ConsumptionMode défini sur Queue, via la console, l'API Lambda, l'AWS CLI, CloudFormation, SAM ou CDK. Sans mode indiqué, le mappage utilise le mode Stream par défaut. Le guide compare les deux. Stream conserve l'ordre par partition et autorise jusqu'à 5 invocations simultanées par consommateur. Queue ne garantit aucun ordre et en autorise jusqu'à 10. Les deux affichent jusqu'à 5 Mo/s de débit par consommateur, mais la section à la demande du mode file indique jusqu'à 1 Mo/s par consommateur, avec au plus 5 consommateurs, soit 5 Mo/s au total et 50 invocations simultanées. Le mode provisionné permet de fixer un nombre minimal et maximal de consommateurs, de 1 à 200 pour le minimum et de 1 à 2 000 pour le maximum, et le guide y indique jusqu'à 5 Mo/s par consommateur. Comme les pages décrivent des limites différentes selon les modes, il faut lire celui que l'on fera vraiment tourner.

Plusieurs réglages familiers changent. MaximumBatchingWindowInSeconds n'est pas pris en charge en mode file et le spécifier renvoie une erreur de validation, car le consommateur de partage Kafka exige l'accusé de réception explicite de chaque enregistrement d'un lot. StartingPosition et StartingPositionTimestamp ne sont pas pris en charge non plus, puisque le mode file lit toujours à partir de la position validée du groupe de partage. MaximumRetryAttempts vaut 0 par défaut, et le courtier effectue les nouvelles tentatives lorsqu'aucune destination en cas d'échec n'est configurée. Le filtrage d'événements jusqu'à 5 motifs, les registres de schémas, les destinations en cas d'échec et la journalisation du mappage sont pris en charge. Les mappages en mode file ne partagent leurs unités de consommateurs d'événements qu'avec d'autres mappages en mode file. Le guide général Kafka avertit aussi que les mappages traitent chaque événement au moins une fois, donc le code de fonction doit être idempotent.

Côté coût, l'annonce dit que la tarification Lambda standard s'applique et que les clients qui configurent le mode provisionné paient aussi l'utilisation des unités de consommateurs d'événements. Un essai raisonnable commence par une rubrique non critique : confirmer la version du cluster et l'activation des groupes de partage, créer un mappage en mode file dans un compte de test, envoyer une rafale, puis mesurer le débit, les doublons et le traitement des enregistrements en échec. Il faut d'abord décider si un consommateur a besoin de l'ordre, car le mode file le supprime. L'annonce ne donne aucun étalon de gain de débit : toute affirmation d'accélération doit venir de votre propre test.