O blog da AWS
Processamento de eventos SQS de baixa latência e alta taxa de transferência com o modo provisionado do AWS Lambda
Por Ben Freiberg e Rahul Pisal, Software Development Engineers na Amazon Web Services.
Clientes que constroem aplicações orientadas a eventos na AWS dependem do Amazon Simple Queue Service (Amazon SQS) e dos AWS Lambda event source mappings (ESMs) para processar milhões de eventos todos os dias. A infraestrutura de polling totalmente gerenciada dos ESMs elimina a necessidade de escrever e manter código personalizado. Você pode se concentrar na lógica de negócios enquanto o Lambda lida com dimensionamento, agrupamento em lotes e tratamento de erros automaticamente.
À medida que as cargas de trabalho crescem, muitos clientes precisam atender a requisitos exigentes de processamento de mensagens de baixa latência, execução de alta concorrência e processamento de eventos de alta taxa de transferência. Casos de uso como processamento de pagamentos em tempo real, detecção de fraudes, pipelines de telemetria IoT e atendimento de pedidos em vendas relâmpago exigem que o ESM dimensione rapidamente e mantenha o desempenho máximo sem acúmulo de fila.
Para atender a essas necessidades, a AWS lançou o modo provisionado para mapeamentos de origem de eventos SQS. O modo provisionado oferece controle direto sobre o número de pollers de eventos atribuídos ao seu ESM para dimensionamento previsível e rápido. Com o modo provisionado, você pode configurar pollers de eventos até 10.000, suportando concorrência de até 100.000 execuções simultâneas do Lambda e taxa de transferência de 10 GB/s. Você pode processar até um milhão de eventos por segundo.
O modo provisionado também está disponível para mapeamentos de origem de eventos Apache Kafka, incluindo Amazon Managed Streaming for Apache Kafka (Amazon MSK) e Kafka autogerenciado.
Como funcionam os mapeamentos de origem de eventos SQS
Quando você configura uma fila SQS como origem de eventos para uma função Lambda, o Lambda cria automaticamente um recurso ESM. O ESM gerencia uma frota de pollers de eventos internos que fazem polling contínuo da fila SQS, recuperam mensagens e invocam sua função Lambda com lotes de eventos.
No modo ESM padrão, o Lambda gerencia automaticamente o número de pollers de eventos com base na profundidade da fila e na taxa de transferência de processamento. O sistema começa com cinco pollers e aumenta à medida que o acúmulo da fila cresce, suportando até 1.250 invocações simultâneas. Esse dimensionamento automático funciona bem para a maioria das cargas de trabalho de processamento de eventos. No entanto, a taxa de aumento no modo padrão (aproximadamente 300 execuções simultâneas adicionais por minuto) pode deixar cargas de trabalho sensíveis à latência com acúmulos de fila crescentes durante picos repentinos de tráfego.
O que é o modo provisionado?
O modo provisionado oferece controle explícito sobre o número mínimo e máximo de pollers de eventos atribuídos ao seu ESM. Em vez de depender apenas do dimensionamento automático, você define:
MinimumPollers: o número de pollers de eventos sempre ativos e prontos para processar mensagens (intervalo: 2–200).MaximumPollers: o limite superior de pollers de eventos para os quais o ESM pode dimensionar (intervalo: 2–10.000).
Esses pollers permanecem ativos e fazem polling contínuo da sua fila SQS, eliminando atrasos de inicialização a frio na infraestrutura de polling. Quando picos de tráfego chegam, seu ESM já tem capacidade alocada para lidar com a explosão.
Modo padrão vs. modo provisionado
| Atributo | Modo padrão | Modo provisionado |
| Pollers mínimos | 2 | 2 |
| Pollers máximos | 5 | 10.000 |
| Execuções simultâneas máximas | Até 1250 | Até 100.000 |
| Taxa de transferência máxima | N/A | 10 GB/s |
| Taxa de aumento | ~300 concorrência/min | ~1.000 concorrência/min |
| Controle de poller | Controlado pelo Lambda | Mín/Máx configurável |
| Cobrança | Incluído no preço do Lambda | Horas de EPU |
| Melhor para | Maioria das cargas de trabalho | Cargas com picos, sensíveis à latência e de alta taxa de transferência |
Ativando o modo provisionado para ESM
Você pode configurar o modo provisionado ao criar um novo ESM ou atualizar um existente. Os exemplos a seguir mostram a configuração usando o AWS CLI, AWS Serverless Application Model (SAM) e AWS CloudFormation.
AWS CLI
Crie um novo ESM com modo provisionado:
aws lambda create-event-source-mapping \
--function-name my-function \
--event-source-arn arn:aws:sqs:us-east-1:123456789012:my-queue \
--batch-size 10 \
--provisioned-poller-config '{"MinimumPollers": 50, "MaximumPollers": 500}'
Atualize um ESM existente para ativar o modo provisionado:
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" \
--provisioned-poller-config '{"MinimumPollers": 50, "MaximumPollers": 500}'
Template AWS SAM
Resources:
MyFunction:
Type: AWS::Serverless::Function
Properties:
Handler: index.handler
Runtime: python3.12
Events:
SQSEvent:
Type: SQS
Properties:
Queue: !GetAtt MyQueue.Arn
BatchSize: 10
ProvisionedPollerConfig:
MinimumPollers: 50
MaximumPollers: 500
MyQueue:
Type: AWS::SQS::Queue
AWS CloudFormation
Resources:
MyEventSourceMapping:
Type: AWS::Lambda::EventSourceMapping
Properties:
FunctionName: !Ref MyFunction
EventSourceArn: !GetAtt MyQueue.Arn
BatchSize: 10
ProvisionedPollerConfig:
MinimumPollers: 50
MaximumPollers: 500
Modo provisionado para SQS ESM em ação
Para ver o perfil de desempenho, implante uma função Lambda com uma fila SQS como gatilho. Nos cenários a seguir, um produtor grava 40 milhões de mensagens (1 KB cada) em uma fila SQS, com tamanho de lote 10 e duração da função de cerca de 200 ms.
Cenário 1: Linha de base (modo padrão)
Com o modo provisionado desativado, o Lambda leva aproximadamente 17 minutos para drenar 40 milhões de mensagens e cerca de 6 minutos para atingir as execuções simultâneas máximas.

Cenário 2: Pollers mínimos = 100, máximos = 1000
O Lambda drena 40 milhões de mensagens em aproximadamente 7 minutos — mais de 55% mais rápido. Leva apenas cerca de 1 minuto para atingir as execuções simultâneas máximas.

Cenário 3: Pollers mínimos padrão (2), dimensionamento automático
Com pollers mínimos padrão, o Lambda drena o acúmulo em aproximadamente 9 minutos — ainda mais de 45% mais rápido que a linha de base.

Melhores práticas para configurar pollers provisionados
Ao configurar o modo provisionado, tenha em mente:
Dimensione corretamente seus pollers mínimos
Cada poller suporta até 10 invocações simultâneas e ~1 MB/s de taxa de transferência. Use: MinimumPollers = max(TargetConcurrency / 10, TargetThroughputMBps / 1)
Para estimar o número de pollers necessários, siga as etapas descritas em determinando os pollers de eventos necessários.
Defina pollers máximos para capacidade de explosão
Defina MaximumPollers para o pico de tráfego. Um bom ponto de partida é 2–5x os pollers mínimos.
Alinhe com os limites de concorrência do Lambda
MaxConcurrency = MaximumPollers × 10. Se definir MaximumPollers como 5.000, sua conta precisa de pelo menos 50.000 de capacidade de execução simultânea.
Comece de forma conservadora e itere
Monitore ProvisionedPollers e ApproximateNumberOfMessagesVisible no CloudWatch. Ajuste os mínimos conforme necessário.
Use filas FIFO para cargas de trabalho ordenadas
O modo provisionado funciona com filas SQS padrão e FIFO.
Configure filas de mensagens mortas
Configure filas de mensagens mortas para gerenciar mensagens que falham após várias tentativas.
Considerações de custo
A cobrança é baseada em horas de unidade de poller de eventos (EPU). Você paga pelos pollers provisionados alocados, independentemente de estarem processando mensagens. Estratégias de otimização:
- Combine pollers mínimos com seu tráfego de linha de base para evitar provisionamento excessivo.
- Use pollers máximos para capacidade de explosão — você paga apenas pelos pollers que aumentam enquanto ativos.
Monitorando com CloudWatch
Métricas-chave para ESMs de modo provisionado:
| Métrica | Descrição |
| ProvisionedPollers | Número atual de pollers provisionados alocados |
| ConcurrentExecutions | Invocações simultâneas do Lambda geradas pelo ESM |
| ApproximateNumberOfMessagesVisible | Profundidade da fila SQS |
| Duration | Tempo de execução da função por invocação |
Para entender o fluxo de mensagens de ponta a ponta, opte pelo grupo de métricas EventCount para métricas como PolledEventCount, InvokedEventCount e DeletedEventCount.
Conclusão
O modo provisionado para mapeamentos de origem de eventos SQS oferece controle sobre o dimensionamento para suas cargas de trabalho mais exigentes. Ao configurar pollers mínimos e máximos, você obtém processamento previsível de baixa latência, dimensionamento para 100.000 execuções simultâneas e taxa de transferência de até um milhão de eventos por segundo, sem esperar pelo aumento automático.
Para começar, explore o guia de configuração do modo provisionado para mapeamentos de origem de eventos SQS. Implante o aplicativo de exemplo do padrão de referência do Serverless Land.
Autores
![]() |
Ben Freiberg é Software Development Engineer na Amazon Web Services. |
![]() |
Rahul Pisal é Software Development Engineer na Amazon Web Services. |
Este conteúdo foi traduzido do post original do blog, que pode ser encontrado aqui.
Tradutores
![]() |
Rodrigo Peres é Arquiteto de Soluções na AWS, com mais de 20 anos de experiência trabalhando com arquitetura de soluções, desenvolvimento de sistemas e modernização de sistemas legados. |
![]() |
Daniel Abib é Arquiteto de Soluções Sênior e Especialista em Amazon Bedrock na AWS, com mais de 25 anos trabalhando com gerenciamento de projetos, arquiteturas de soluções escaláveis, desenvolvimento de sistemas e CI/CD, microsserviços, arquitetura Serverless & Containers e especialização em Machine Learning. Ele trabalha apoiando Startups, ajudando-os em sua jornada para a nuvem. https://www.linkedin.com/in/danielabib/ |



