AWS Lambda ganha modo de fila para processar Kafka além do limite de partições

O que mudou

Desde 2 de novembro de 2026, o AWS Lambda suporta modo de fila (queue mode) nas event source mappings (ESM) de Kafka self-managed, tanto para clusters que o cliente opera quanto para ofertas gerenciadas como Confluent Cloud. Até aqui, toda Kafka ESM do Lambda usava o protocolo de consumer group do Kafka, que atrela cada partição a exatamente um consumidor dentro do grupo.

Essa regra sempre foi o teto de paralelismo: se o throughput precisava subir, só dava para aumentar o número de partições do tópico (reparticionamento é operação pesada) ou tirar o tráfego do Kafka e levar para um sistema de filas separado, com infraestrutura própria e código de producer para manter.

O queue mode quebra esse acoplamento usando share groups, recurso que ficou geralmente disponível no Apache Kafka 4.2. Com share groups, vários event pollers do Lambda podem consumir concorrentemente da mesma partição, e cada poller suporta até 10 invocações simultâneas. Nenhuma mudança é exigida em producer, configuração de tópico ou código da função: o ganho de paralelismo é só uma troca de modo na ESM.

O trade-off é explícito: queue mode não preserva a ordem das mensagens dentro da partição. A AWS recomenda o modo para cargas em que cada evento é uma unidade de trabalho independente e velocidade importa mais que sequência, como codificação de imagem e vídeo, detecção de fraude, entrega de notificações e ingestão de telemetria.

Onde está disponível

O recurso está em todas as regiões comerciais da AWS onde a Kafka ESM self-managed já roda, segundo o anúncio. A fonte não cita regiões específicas pelo nome, e não há confirmação explícita de que São Paulo (sa-east-1) já esteja na lista de regiões onde a Kafka ESM self-managed roda; vale checar a documentação oficial da AWS antes de assumir cobertura na região brasileira.

O pré-requisito não é de região, é de cluster: é preciso um Kafka com share groups habilitado, como Apache Kafka 4.2 ou superior. O anúncio não menciona Amazon MSK nem confirma se as versões gerenciadas pela AWS já habilitam share groups por padrão; quem roda cluster próprio ou usa Confluent Cloud precisa checar a versão antes de trocar o modo da ESM.

Quanto custa

O preço padrão do Lambda se aplica normalmente: não há taxa extra só por ligar o queue mode. A diferença fica para quem usa modo provisionado na Kafka ESM self-managed, que cobra também pelo uso de Event Poller Unit (EPU), já que rodar mais pollers concorrentes por partição consome mais unidades.

A fonte não traz valores numéricos de EPU nem conversão em real; ela aponta para a página oficial de pricing do Lambda para os números atualizados. Vale conferir essa página antes de dimensionar o modo provisionado para uma carga de pico, porque o custo de EPU escala com a concorrência que o queue mode justamente existe para liberar.

Como começar

A ativação é um parâmetro na criação (ou atualização) da ESM: definir ConsumptionMode como Queue ao configurar a self-managed Kafka event source mapping. O anúncio lista os mesmos caminhos de sempre para isso: AWS Management Console, Lambda API, AWS CLI, AWS CloudFormation, AWS SAM ou AWS CDK.

Antes de trocar o modo em produção, duas checagens valem a pena:

• Confirmar que o cluster Kafka (self-managed ou Confluent Cloud) está em versão com share groups habilitado, Apache Kafka 4.2 ou mais recente.
• Mapear quais tópicos realmente dependem de ordenação por partição, porque esses não devem migrar para ConsumptionMode=Queue.

O que muda para quem já usa

Para quem já mantém Kafka ESMs no Lambda, a mudança chega sem exigir deploy de função nova, mudança de producer ou reparticionamento de tópico: é opt-in via ConsumptionMode. Isso tira do caminho o motivo clássico de over-provisioning de partições só para ganhar paralelismo no consumo.

O trade-off ordem versus throughput é o mesmo cálculo que quem já opera SQS e SNS conhece bem, na escolha entre fila FIFO e fila padrão: ordenação garantida custa throughput, e nem toda carga de evento precisa de sequência estrita. Quem roda pipeline de fraud detection ou de ingestão de telemetria, citados pela própria AWS como casos de uso típicos, tende a se beneficiar direto, já que cada evento já é tratado como unidade independente.

Fica em aberto, porque a fonte não detalha, como o Lambda reparte o trabalho entre pollers na prática e como isso se comporta sob falha parcial de um poller durante um pico de tráfego real.

Fonte: AWS What's New