# Como o Lambda processa registros de origens de eventos baseadas em fluxos e filas
Um *mapeamento de origem de evento* é um recurso no Lambda que lê itens de serviços baseados em fluxo ou fila e invoca uma função com lotes de registros. Em um mapeamento da origem do evento, recursos chamados *agentes de sondagem de eventos* sondam ativamente novas mensagens e invocam funções. Por padrão, o Lambda escala automaticamente os agentes de sondagem de eventos, mas para determinados tipos de origem de eventos, você pode usar o [modo provisionado](#invocation-eventsourcemapping-provisioned-mode) para controlar o número mínimo e máximo de agentes de sondagem de eventos dedicados ao mapeamento da origem do evento.
Os serviços a seguir usam mapeamentos de origem de eventos para invocar funções do Lambda:
+ [Amazon DocumentDB (compatível com MongoDB) (Amazon DocumentDB)](with-documentdb.md)
+ [Amazon DynamoDB](with-ddb.md)
+ [Amazon Kinesis](with-kinesis.md)
+ [Amazon MQ](with-mq.md)
+ [Amazon Managed Streaming for Apache Kafka (Amazon MSK)](with-msk.md)
+ [Apache Kafka autogerenciado](with-kafka.md)
+ [Amazon Simple Queue Service (Amazon SQS)](with-sqs.md)
**Atenção**
Os mapeamentos da origem do evento do Lambda processam cada evento ao menos uma vez, podendo haver o processamento duplicado de registros. Para evitar possíveis problemas relacionados a eventos duplicados, é altamente recomendável tornar o código da função idempotente. Para saber mais, consulte [Como tornar minha função do Lambda idempotente](https://repost.aws/knowledge-center/lambda-function-idempotent) no Centro de Conhecimentos da AWS.
## Como os mapeamentos de origem de eventos diferem dos acionadores diretos
Alguns Serviços da AWS podem invocar diretamente as funções do Lambda usando *gatilhos*. Esses serviços enviam eventos para o Lambda, e a função é invocada imediatamente quando o evento especificado ocorre. Os acionadores são adequados para eventos discretos e processamento em tempo real. Quando você [cria um acionador usando o console do Lambda](lambda-services.md#lambda-invocation-trigger), o console interage com o serviço da AWS correspondente para configurar a notificação de eventos nesse serviço. Na verdade, o acionador é armazenado e gerenciado pelo serviço que gera os eventos, não pelo Lambda. Aqui estão alguns exemplos de serviços que usam acionadores para invocar funções do Lambda:
+ **Amazon Simple Storage Service (Amazon S3)**: invoca uma função quando um objeto é criado, excluído ou modificado em um bucket. Para obter mais informações, consulte [Tutorial: Usar um acionador do Amazon S3 para invocar uma função do Lambda](with-s3-example.md).
+ **Amazon Simple Notification Service (Amazon SNS)**: invoca uma função quando uma mensagem é publicada em um tópico do SNS. Para obter mais informações, consulte [Tutorial: usar o AWS Lambda com o Amazon Simple Notification Service](with-sns-example.md).
+ **Amazon API Gateway:** invoca uma função quando uma solicitação de API é feita para um endpoint específico. Para obter mais informações, consulte [Invocar uma função do Lambda usando um endpoint do Amazon API Gateway](services-apigateway.md).
Os mapeamentos de origem de eventos são recursos do Lambda criados e gerenciados dentro do serviço do Lambda. Os mapeamentos de origem de eventos são projetados para processar dados de streaming de alto volume ou mensagens de filas. O processamento de registros de um fluxo ou fila em lotes é mais eficiente do que processar registros individualmente.
## Comportamento de lotes
Por padrão, um mapeamento de fonte de evento registra em lotes em uma única carga útil que o Lambda envia para sua função. Para ajustar o comportamento de lotes, configure uma janela de lotes ([MaximumBatchingWindowInSeconds](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-MaximumBatchingWindowInSeconds)) e um tamanho de lote ([BatchSize](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-response-BatchSize)). A janela de lote é o tempo máximo para reunir registros em uma única carga útil. O tamanho de lote é o número máximo de registros em um único lote. O Lambda invoca a função quando um destes três critérios é atendido:
+ **A janela de lotes atinge o valor máximo.** O comportamento padrão da janela de lote varia conforme a fonte de evento específica.
+ **Para fontes de eventos do Kinesis, do DynamoDB e do Amazon SQS:** a janela de lote padrão é 0 segundo. Isso significa que o Lambda invoca a função assim que os registros estão disponíveis. Para definir uma janela de lotes, configure `MaximumBatchingWindowInSeconds`. É possível configurar esse parâmetro para qualquer valor de 0 a 300 segundos em incrementos de 1 segundo. Se você configurar uma janela de lote, a próxima janela começará assim que a invocação de função anterior for concluída.
+ **Para origens do evento do Amazon MSK, Apache Kafka autogerenciado, Amazon MQ e Amazon DocumentDB:** a janela em lotes padrão é de 500 ms. É possível configurar `MaximumBatchingWindowInSeconds` para qualquer valor de 0 a 300 segundos em incrementos de segundos. No modo provisionado para mapeamentos da origem do evento do Kafka, quando você configura uma janela em lote, a próxima janela começará assim que o lote anterior for concluído. No modo não provisionado para mapeamento da origem do evento do Kafka, quando você configura uma janela em lote, a próxima janela começa assim que a invocação da função anterior é concluída. Para minimizar a latência ao usar mapeamentos da origem do evento do Kafka no modo provisionado, defina `MaximumBatchingWindowInSeconds` como 0. Essa configuração garante que o Lambda comece a processar o próximo lote imediatamente após concluir a invocação da função atual. Para obter informações adicionais sobre processamento de baixa latência, consulte [Apache Kafka de baixa latência](with-kafka-low-latency.md).
+ **Para origens do evento do Amazon MQ e Amazon DocumentDB:** a janela em lotes padrão é de 500 ms. É possível configurar `MaximumBatchingWindowInSeconds` para qualquer valor de 0 a 300 segundos em incrementos de segundos. A janela de lotes começa assim que o primeiro registro chega.
**nota**
Como só é possível alterar `MaximumBatchingWindowInSeconds` em incrementos de segundos, você não pode reverter para a janela de lotes padrão de 500 ms após alterá-la. Para restaurar a janela de lotes padrão, é necessário criar um novo mapeamento de fonte de evento.
+ **O tamanho do lote é atendido.** O tamanho mínimo do lote é 1. O tamanho do lote padrão e máximo dependem da fonte de eventos. Para obter detalhes sobre esses valores, consulte a especificação de [BatchSize](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-BatchSize) para a operação da API `CreateEventSourceMapping`.
+ **O tamanho da carga útil atinge [6 MB](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html).** Não é possível modificar esse limite.
O diagrama a seguir ilustra essas três condições. Suponha que uma janela de lotes comece em `t = 7` segundos. No primeiro caso, a janela de lotes atinge seu máximo de 40 segundos em `t = 47` segundos após acumular cinco registros. No segundo caso, como o tamanho do lote chega a dez antes que a janela de lotes expire, a janela de lotes é encerrada mais cedo. No terceiro caso, como o tamanho máximo da carga útil é atingido antes que a janela de lotes expire, a janela de lotes é encerrada mais cedo.
![\[\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/batching-window.png)
Recomendamos testar com diferentes tamanhos de lote e de registro para que a frequência de sondagem de cada origem de eventos seja ajustada à rapidez com que a função pode concluir sua tarefa. O parâmetro `BatchSize` [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html) controla o número máximo de registros que podem ser enviados para sua função a cada invocação. Um tamanho de lote maior geralmente absorve de maneira mais eficiente a sobrecarga da invocação em um conjunto maior de registros aumentando o throughput.
O Lambda não espera a conclusão de nenhuma [extensão](lambda-extensions.md)configurada para enviar o próximo lote para processamento. Em outras palavras, suas extensões podem continuar sendo executadas enquanto o Lambda processa o próximo lote de registros. Isso pode causar problemas de controle de utilização se você violar quaisquer configurações ou limites de [simultaneidade](lambda-concurrency.md) de sua conta. Para detectar se esse é um problema em potencial, monitore suas funções e verifique se você está vendo [métricas de simultaneidade](monitoring-concurrency.md#general-concurrency-metrics) mais altas do que o esperado para o seu mapeamento da origem do evento. Devido ao curto intervalo entre as invocações, o Lambda pode relatar brevemente um uso de simultaneidade maior do que o número de fragmentos. Isso pode ser verdadeiro até mesmo para funções do Lambda sem extensões.
Por padrão, se a função retornar um erro, o mapeamento da origem do evento será reprocessado até que a função seja bem-sucedida ou que os itens no lote expirem. Para garantir o processamento na ordem, o mapeamento da fonte de eventos pausa o processamento do fragmento afetado até o erro ser resolvido. Em origens de fluxo (DynamoDB e Kinesis), é possível configurar o número máximo de vezes que o Lambda tentará novamente quando sua função retornar um erro. Erros de serviço ou controles de utilização nos quais o lote não atinge a função não contam para as tentativas de repetição. Também é possível configurar o mapeamento da origem do evento para enviar um registro de invocação a um [destino](invocation-async-retain-records.md#invocation-async-destinations) quando descartar um lote de eventos.
## Modo provisionado
Os mapeamentos da origem do evento do Lambda usam agentes de sondagem de eventos para sondar sua origem de eventos em busca de novas mensagens. Por padrão, o Lambda gerencia o ajuste de escala automático desses agentes de sondagem, baseado no volume de mensagens. Quando o tráfego de mensagens aumenta, o Lambda aumenta automaticamente o número de agentes de sondagem de eventos para lidar com a carga e o reduz quando o tráfego diminui.
No modo provisionado, é possível ajustar o throughput do mapeamento da origem do evento definindo limites mínimos e máximos para os recursos de sondagem dedicados que permanecem prontos para lidar com os padrões de tráfego esperados. Esses recursos fazem ajuste de escala automático 3 vezes mais rápido para lidar com picos repentinos no tráfego de eventos e fornecem maior capacidade 16 vezes maior para processar milhões de eventos. Isso ajuda você a criar workloads orientadas por eventos altamente responsivas com requisitos de performance rigorosos.
No Lambda, um agente de sondagem de eventos é uma unidade computacional com recursos de throughput que variam de acordo com o tipo da origem do evento. Para o Amazon MSK e o Apache Kafka autogerenciado, cada agente de sondagem de eventos pode lidar com até 5 MB/seg de throughput, ou até 5 invocações simultâneas. Por exemplo, se sua origem de eventos produzir uma carga útil média de 1 MB e a duração média de sua função for de 1 segundo, um único agente de sondagem de eventos do Kafka poderá oferecer suporte a um throughput de 5 MB/seg e 5 invocações do Lambda simultâneas (supondo que não haja transformação da carga útil). Para o Amazon SQS, cada agente de sondagem de eventos pode lidar com até 1 MB/s de throughput, ou até 10 invocações simultâneas. O uso do modo provisionado incorre em custos adicionais com base no uso do agente de sondagem de eventos. Para obter detalhes de preço, consulte [Definição de preço do AWS Lambda](https://aws.amazon.com/lambda/pricing/).
O modo provisionado está disponível apenas para origens de eventos do Amazon MSK, Apache Kafka autogerenciado e Amazon SQS. Enquanto as configurações de simultaneidade oferecem controle sobre a escalabilidade da função, o modo provisionado oferece controle sobre o throughput do mapeamento da origem do evento. Para garantir a performance máxima, talvez seja necessário ajustar as duas configurações de maneira independente.
O modo provisionado é ideal para aplicações em tempo real que exijam latência consistente no processamento de eventos, como empresas de serviços financeiros que processem feeds de dados de mercado, plataformas de comércio eletrônico que forneçam recomendações personalizadas em tempo real e empresas de jogos que gerenciem interações com jogadores ao vivo.
Cada agente de sondagem de eventos oferece suporte a diferentes capacidades de throughput:
+ Para o Amazon MSK e o Apache Kafka autogerenciado, até 5 MB/seg de throughput, ou até 5 invocações simultâneas.
+ Para o Amazon SQS: até 1 MB/s de throughput ou até 10 invocações simultâneas, ou até 10 chamadas de API de sondagem do Amazon SQS por segundo.
Para mapeamentos da origem do evento do Amazon SQS, é possível definir o número mínimo de sondagens entre 2 e 200, com um padrão de 2, e o número máximo entre 2 e 2.000, com um padrão de 200. O Lambda escala o número de agentes de sondagem de eventos entre o seu mínimo e o máximo configurados, adicionando rapidamente até 1.000 simultaneidades por minuto para fornecer processamento consistente e de baixa latência aos seus eventos.
Para mapeamentos da origem do evento do Kafka, é possível definir o número mínimo de agentes de sondagem entre 1 e 200, com um padrão de 1, e o número máximo entre 1 e 2.000, com um padrão de 200. O Lambda escala o número de enquetes de eventos entre o mínimo e o máximo configurados com base na lista de pendências de eventos em seu tópico para fornecer processamento de baixa latência de seus eventos.
Observe que, para origens de eventos do Amazon SQS, a configuração máxima de simultaneidade não pode ser usada com o modo provisionado. Ao usar o modo provisionado, você controla a simultaneidade máxima por meio da configuração do número máximo de agentes de sondagem de eventos.
Para obter detalhes sobre como configurar o modo provisionado, consulte as seguintes seções:
+ [Configuração do modo provisionado para mapeamentos de origens de eventos do Amazon MSK](kafka-scaling-modes.md)
+ [Configuração do modo provisionado para mapeamentos de origens de eventos do Apache Kafka autogerenciado](kafka-scaling-modes.md#kafka-provisioned-mode)
+ [Uso do modo provisionado com mapeamentos da origem do evento do Amazon SQS](with-sqs.md#sqs-provisioned-mode)
Para minimizar a latência no modo provisionado, defina `MaximumBatchingWindowInSeconds` como 0. Essa configuração garante que o Lambda comece a processar o próximo lote imediatamente após concluir a invocação da função atual. Para obter informações adicionais sobre processamento de baixa latência, consulte [Apache Kafka de baixa latência](with-kafka-low-latency.md).
Depois de configurar o modo provisionado, você pode observar o uso de pesquisadores de eventos para sua workload monitorando a métrica `ProvisionedPollers`. Para obter mais informações, consulte [Métricas de mapeamento da origem do evento](monitoring-metrics-types.md#event-source-mapping-metrics).
## API do mapeamento da fonte de eventos
Para gerenciar uma origem de eventos com a [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) ou um [SDK da AWS](https://aws.amazon.com/getting-started/tools-sdks/), use as operações de API a seguir:
+ [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)
+ [ListEventSourceMappings](https://docs.aws.amazon.com/lambda/latest/api/API_ListEventSourceMappings.html)
+ [GetEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_GetEventSourceMapping.html)
+ [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)
+ [DeleteEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteEventSourceMapping.html)
# Uso de tags em mapeamentos da origem do evento
É possível marcar mapeamentos da origem do evento para organizar e gerenciar os recursos. Tags são pares de chave-valor de formato livre associados aos recursos compatíveis com todos os Serviços da AWS. Para obter mais informações sobre casos de uso de tags, consulte [Common tagging strategies](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#tag-strategies) no *Guia do editor de tags e recursos de marcação da AWS*.
Os mapeamentos da origem do evento estão associados a funções, que podem ter suas próprias tags. Os mapeamentos da origem do evento não herdam automaticamente as tags das funções. É possível usar a API do AWS Lambda para visualizar e atualizar tags. Também é possível visualizar e atualizar tags enquanto gerencia um mapeamento da origem do evento específico no console do Lambda, incluindo aqueles que usem o modo provisionado do Amazon SQS.
## Permissões necessárias para trabalhar com tags
Para permitir que uma identidade do AWS Identity and Access Management (IAM) (usuário, grupo ou perfil) leia ou defina tags em um recurso, conceda a ela as permissões correspondentes:
+ **lambda:ListTags**: quando um recurso tiver tags, conceda essa permissão a qualquer usuário que precise chamar `ListTags` nele. Para funções marcadas, essa permissão também será necessária para `GetFunction`.
+ **lambda:TagResource**: conceda essa permissão a qualquer pessoa que precise chamar `TagResource` ou executar uma tag na criação.
Opcionalmente, considere conceder também a permissão **lambda:UntagResource** para permitir chamadas `UntagResource` ao recurso.
Para obter mais informações, consulte [Políticas do IAM baseadas em identidade para o Lambda](access-control-identity-based.md).
## Uso de tags usando o console do Lambda
É possível usar o console do Lambda para criar mapeamentos da origem do evento que tenham tags, adicionar tags a mapeamentos da origem do evento existentes e filtrar mapeamentos da origem do evento por tag, incluindo aqueles configurados no modo provisionado do Amazon SQS
Quando você adiciona um gatilho para streaming compatível e serviços baseados em fila usando o console do Lambda, o Lambda cria automaticamente um mapeamento da origem do evento. Para obter mais informações sobre essas origens de evento, consulte [Como o Lambda processa registros de origens de eventos baseadas em fluxos e filas](invocation-eventsourcemapping.md). Para criar um mapeamento da origem do evento no console, você precisará dos seguintes pré-requisitos:
+ Uma função do .
+ Uma origem do evento de um serviço afetado.
É possível adicionar as tags como parte da mesma interface de usuário usada para criar ou atualizar gatilhos.
**Para adicionar uma tag ao criar um mapeamento da origem do evento**
1. Abra a [página Funções](https://console.aws.amazon.com/lambda/home#/functions) do console do Lambda.
1. Escolha o nome da sua função.
1. Em **Visão geral da função**, escolha **Adicionar gatilho**.
1. Em **Configuração do gatilho**, na lista suspensa, escolha o nome do serviço de onde vem a origem do evento.
1. Forneça a configuração principal para a origem do evento. Para obter mais informações sobre como configurar a origem do evento, consulte a seção do serviço relacionado em [Invocando o Lambda com eventos de outros serviços da AWS](lambda-services.md).
1. Em **Configuração do mapeamento da origem do evento**, escolha **Configurações adicionais**.
1. Em **Tags**, escolha **Adicionar nova tag**.
1. No campo **Chave**, insira sua chave de tag. Para obter informações sobre restrições de marcação, consulte [Tag naming limits and requirements](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices) no *Guia do editor de tags e recursos de marcação da AWS*.
1. Escolha **Adicionar**.
**Para adicionar tags a um mapeamento da origem do evento existente**
1. Abra [Mapeamentos da origem do evento](https://console.aws.amazon.com/lambda/home#/event-source-mappings) no console do Lambda.
1. Na lista de recursos, escolha o **UUID** para o mapeamento da origem do evento correspondente à **função** e ao **ARN da origem do evento**.
1. Na lista de guias abaixo do **painel Configuração geral**, escolha **Tags**.
1. Selecione **Gerenciar tags**.
1. Selecione **Adicionar nova tag**.
1. No campo **Chave**, insira sua chave de tag. Para obter informações sobre restrições de marcação, consulte [Tag naming limits and requirements](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices) no *Guia do editor de tags e recursos de marcação da AWS*.
1. Escolha **Salvar**.
**Para filtrar mapeamentos da origem do evento por tag**
1. Abra [Mapeamentos da origem do evento](https://console.aws.amazon.com/lambda/home#/event-source-mappings) no console do Lambda.
1. Escolha a caixa Pesquisar.
1. Na lista suspensa, selecione a chave de tag abaixo do subtítulo **Tags**.
1. Selecione **Usar: “tag-name”** para ver todos os mapeamentos da origem do evento marcados com essa chave, ou escolha um **operador** para filtrar ainda mais por valor.
1. Selecione o valor da tag para filtrar por uma combinação de chave e valor da tag.
A barra de pesquisa também é compatível com a pesquisa de chaves de tag. Insira o nome de uma chave para encontrá-la na lista.
## Uso de tags com a AWS CLI
É possível adicionar e remover tags em recursos existentes do Lambda, incluindo mapeamentos da origem do evento, com a API do Lambda. Também é possível adicionar tags ao criar um mapeamento da origem do evento, o que permite manter um recurso marcado durante todo o ciclo de vida.
### Atualização de tags usando as APIs de tag do Lambda
É possível adicionar e remover tags dos recursos compatíveis do Lambda por meio das operações da API [TagResource](https://docs.aws.amazon.com/lambda/latest/api/API_TagResource.html) e [UntagResource](https://docs.aws.amazon.com/lambda/latest/api/API_UntagResource.html).
Também é possível chamar essas operações usando a AWS CLI. Para adicionar tags a um recurso existente, use o comando `tag-resource`. Este exemplo adiciona duas tags, uma com a chave *Department* e outra com a chave *CostCenter*.
```
aws lambda tag-resource \
--resource arn:aws:lambda:us-east-2:123456789012:resource-type:my-resource \
--tags Department=Marketing,CostCenter=1234ABCD
```
Para remover tags, use o comando `untag-resource`. Este exemplo remove a tag com a chave *Department*.
```
aws lambda untag-resource --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier \
--tag-keys Department
```
### Adição de tags ao criar um mapeamento da origem do evento
Para criar um novo mapeamento da origem do evento do Lambda com tags, use a operação da API [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html). Especifique o parâmetro `Tags`. É possível chamar essa operação com o comando `create-event-source-mapping` da AWS CLI e a opção `--tags`. Para obter mais informações sobre o comando da CLI, consulte [create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html) na *referência de comandos da AWS CLI*.
Antes de usar o parâmetro `Tags` com `CreateEventSourceMapping`, certifique-se de que seu perfil tenha permissão para marcar recursos junto com as permissões usuais necessárias para essa operação. Para obter mais informações sobre permissões para marcação, consulte [Permissões necessárias para trabalhar com tags](#esm-tags-required-permissions).
### Visualização de tags usando as APIs de tag do Lambda
Para visualizar as tags que são aplicadas à um recurso específico do Lambda, use a operação da API `ListTags`. Para obter mais informações, consulte [ListTags](https://docs.aws.amazon.com/lambda/latest/api/API_ListTags.html).
É possível chamar essa operação com o comando `list-tags` da AWS CLI fornecendo um ARN (nome do recurso da Amazon).
```
aws lambda list-tags --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier
```
### Filtragem de recursos por tag
É possível usar a operação de API [GetResources](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/API_GetResources.html) do AWS Resource Groups Tagging API para filtrar seus recursos por etiquetas. A operação `GetResources` aceita até 10 filtros, cada um contendo uma chave de etiquetas e até 10 valores de etiquetas. Você fornece a `GetResources` um `ResourceType` para filtrar por tipos de recursos específicos.
É possível chamar essa operação usando o comando `get-resources` da AWS CLI. Para ver exemplos de uso de `get-resources`, consulte [get-resources](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/resourcegroupstaggingapi/get-resources.html#examples) na *referência de comandos da AWS CLI*.