AWS Lambda executa código em resposta a eventos sem a necessidade de gerenciar servidores.

🎯 Para a certificação

Questões sobre Lambda verificam se você conhece limites numéricos, cold starts, os três modelos de invocação (e como cada um trata falhas), integração com outros serviços e quando escolher serverless vs containers/VMs.

---

Resumo

Pense no Lambda como contratar um eletricista avulso só quando precisa de um reparo, em vez de manter um eletricista fixo em casa o tempo todo, mesmo quando não há nada para consertar. Você não gerencia "onde ele mora" nem "o que ele faz quando não está trabalhando" — só paga pelo tempo que ele efetivamente executa o serviço, e a AWS cuida de toda a infraestrutura por trás.

• Modelo: você envia código (ou uma imagem de container) e o Lambda executa em resposta a eventos (S3, API Gateway, EventBridge etc.), sem servidor para provisionar ou manter.
• Cold start: atraso inicial quando uma execução precisa inicializar um novo ambiente de execução.
• Limites: tempo máximo de execução (15 minutos), tamanho de pacote/deps, memória configurável (que também define a CPU disponível), e concorrência.

---

1. Como uma execução funciona, por dentro

Uma função Lambda é composta por um handler — a função que recebe dois objetos principais:

• event: os dados que dispararam a execução (ex: o corpo de uma requisição HTTP vinda do API Gateway, ou os metadados de um objeto criado no S3).
• context: informações sobre a própria execução (tempo restante antes do timeout, request ID, nome da função etc.).

Quando uma invocação chega e não há ambiente pronto, a AWS provisiona um novo ambiente de execução (baixa o código, inicializa o runtime, roda qualquer código fora do handler uma única vez) — isso é o cold start. Invocações seguintes que reaproveitam esse mesmo ambiente (ainda "quente") pulam essa etapa — é o warm start, muito mais rápido.

---

2. Memória, CPU e limites numéricos importantes

A configuração de memória de uma função Lambda não é só sobre RAM — a AWS aloca CPU proporcionalmente à memória configurada. Mais memória = mais CPU e mais banda de rede disponíveis, até um teto (10.240 MB de memória, que equivale a até ~6 vCPUs). Por isso, aumentar a memória às vezes reduz o custo total, mesmo custando mais por segundo, porque a função termina mais rápido.

Limites que a prova cobra com frequência:

💡 Para a prova: se o cenário descreve uma tarefa que precisa rodar por mais de 15 minutos, Lambda não é a resposta — pense em Fargate, EC2, ou Step Functions orquestrando múltiplas invocações menores.

---

3. Os três modelos de invocação — e como cada um lida com falha

Esse é o tema mais cobrado sobre Lambda na prova, e o conteúdo original nunca abordava. A forma como o Lambda é invocado muda completamente o comportamento em caso de erro.

3.1 Invocação síncrona

Quem chama espera a resposta (ex: API Gateway chamando Lambda para responder uma requisição HTTP). Se a função falhar, o erro volta imediatamente para quem chamou — não há retry automático do lado do Lambda; a responsabilidade de tentar de novo é de quem invocou.

Exemplos: API Gateway, invocação direta via SDK/CLI, ALB.

3.2 Invocação assíncrona

Quem chama dispara o evento e não espera resposta — o evento entra numa fila interna gerenciada pela AWS. Se a função falhar, o Lambda tenta novamente automaticamente (por padrão, até 2 retries adicionais, com espera entre tentativas). Se todas as tentativas falharem, o evento pode ser enviado para um destino de falha configurado (uma DLQ — dead-letter queue — ou um "on-failure destination" mais moderno, como SQS, SNS, Lambda ou EventBridge).

Exemplos: S3 (eventos de bucket), SNS, EventBridge.

3.3 Invocação baseada em polling (event source mapping)

Para fontes que não "empurram" eventos ativamente, o próprio serviço Lambda puxa (poll) os dados da fonte continuamente através de um event source mapping. O comportamento de retry aqui depende da fonte:

• SQS: o Lambda lê um lote de mensagens da fila; se o processamento falhar, as mensagens voltam a ficar visíveis na fila (não são deletadas) e são reprocessadas — até o limite de tentativas da fila (maxReceiveCount), quando então podem ir para uma DLQ da própria fila SQS.
• Kinesis / DynamoDB Streams: o Lambda processa registros em ordem, por shard. Se um registro falhar, o Lambda fica tentando o mesmo lote repetidamente até ter sucesso ou até o dado expirar da retenção do stream (não avança para o próximo enquanto isso) — por padrão, isso pode travar o processamento daquele shard indefinidamente se não houver tratamento de erro adequado (ex: configurar retries máximos, bisecting on error, ou destino de falha).

💡 Regra para a prova: síncrono → sem retry automático do Lambda. Assíncrono → até 2 retries automáticos + destino de falha opcional. Baseado em polling (streams) → retries contínuos por padrão, podendo travar o shard se não configurado corretamente.

---

4. Cold starts — causas e mitigação

Cold starts acontecem quando a plataforma precisa provisionar um novo ambiente de execução (baixar código, iniciar o runtime, rodar inicializações fora do handler). Fatores que pioram o cold start:

• Runtime mais pesado (ex: JVM tende a ter cold start maior que Node.js/Python).
• Pacote grande ou muitas dependências para carregar.
• Função dentro de uma VPC — historicamente, isso exigia criar uma ENI (Elastic Network Interface) por execução, adicionando latência significativa. Com a melhoria de rede da AWS (Hyperplane ENI), esse impacto foi bastante reduzido, mas ainda existe alguma sobrecarga em relação a uma função fora de VPC.

Estratégias de mitigação:

• Provisioned concurrency: mantém um número configurado de ambientes já inicializados e prontos, eliminando cold start para aquela capacidade — com custo adicional, mesmo sem invocações.
• Reduzir dependências e tamanho do pacote.
• Escolher runtimes mais leves quando o cold start for crítico.
• (Para Java especificamente) SnapStart: tira um snapshot do ambiente já inicializado (incluindo estado da JVM) e o restaura em vez de inicializar do zero, reduzindo drasticamente o cold start de runtimes historicamente pesados.

---

5. Funções em VPC — quando e por quê

Por padrão, uma função Lambda roda fora de qualquer VPC específica seu, com acesso direto à Internet e a serviços públicos AWS (S3, DynamoDB etc.) através da rede gerenciada pela AWS. Você só precisa colocar a função dentro de uma VPC quando ela precisa acessar recursos que só existem lá dentro — por exemplo, um banco RDS numa subnet privada, ou um cache ElastiCache.

Ao colocar a função numa VPC, ela perde o acesso direto à Internet pública por padrão (a menos que a subnet tenha rota via NAT Gateway) — se a função também precisar chamar uma API externa, será necessário um NAT Gateway na subnet, ou um VPC Endpoint para serviços AWS específicos.

---

6. Concorrência

• Concorrência não reservada: por padrão, todas as funções da conta compartilham um limite de concorrência da conta na região (milhares de execuções simultâneas, mas é um limite compartilhado e ajustável via suporte).
• Reserved concurrency: garante um limite dedicado (mínimo garantido e máximo permitido) para uma função específica, isolando-a das demais — também impede que essa função consuma mais que o configurado, protegendo o restante da conta caso ela tenha um pico descontrolado.
• Provisioned concurrency: mantém ambientes já inicializados prontos para uso, eliminando cold starts para a capacidade provisionada (com custo adicional, cobrado mesmo sem invocações).

⚠️ Não confunda: reserved concurrency é sobre quantas execuções simultâneas são permitidas/garantidas; provisioned concurrency é sobre quantos ambientes já ficam pré-aquecidos. Você pode ter uma sem a outra, ou combinar as duas.

---

7. Versões, aliases e layers

• Versions: cada publicação de uma função gera uma versão imutável ($LATEST é a versão mutável de desenvolvimento; 1, 2, 3... são snapshots fixos).
• Aliases: um ponteiro nomeado (ex: prod, staging) que aponta para uma versão específica — permite trocar qual versão está "em produção" sem mudar a URL/ARN que os consumidores usam, e permite fazer deployments canário (ex: 90% do tráfego na versão antiga, 10% na nova, via peso configurado no alias).
• Layers: pacotes de dependências ou código compartilhado que podem ser anexados a múltiplas funções, evitando duplicar as mesmas bibliotecas em cada pacote de deploy — reduz o tamanho de cada função individual e centraliza a manutenção de dependências comuns.

---

8. Integrações e padrões

• API Gateway + Lambda: padrão para APIs sem servidor (invocação síncrona).
• S3 events: processar arquivos enviados ao bucket (invocação assíncrona).
• SQS/Kinesis/DynamoDB Streams: processamento orientado a fila/stream (invocação baseada em polling).
• EventBridge: orquestração e desacoplamento por eventos, incluindo agendamentos (cron) — invocação assíncrona.
• Step Functions: orquestra múltiplas invocações de Lambda como parte de um workflow maior, útil quando o processo total excede os 15 minutos de uma única função.

---

9. Permissões — execution role vs resource-based policy

Uma função Lambda tem duas camadas de permissão, frequentemente confundidas:

• Execution role: a IAM Role que a própria função assume para acessar outros serviços AWS (ex: permissão para escrever num bucket S3 de saída).
• Resource-based policy (function policy): define quem pode invocar a função — por exemplo, permitir que o serviço S3 ou API Gateway chame essa Lambda especificamente.

💡 Se uma integração está falhando com "acesso negado" ao invocar a função (não ao ela tentar acessar outro recurso), o problema normalmente está na resource-based policy, não na execution role.

---

10. Quando usar (e quando não usar) Lambda

• Use Lambda para: funções curtas orientadas a eventos (ETL curto, webhooks, processamentos assíncronos, backends de API leves).
• Evite Lambda para: workloads long-running (> 15 min), processamento que exige CPU dedicada e consistente por longos períodos, ou cenários onde o cold start é criticamente inaceitável e provisioned concurrency não resolve o custo/complexidade.

---

11. Boas práticas

• Implemente idempotência em funções que consomem eventos (principalmente assíncronos e de streams, que podem reprocessar o mesmo evento mais de uma vez).
• Evite dependências grandes que aumentem o tempo de cold start.
• Monitore duration, errors e throttles no CloudWatch.
• Configure destinos de falha (DLQ ou on-failure destination) para invocações assíncronas.
• Use reserved concurrency para isolar funções críticas de picos descontrolados de outras funções na mesma conta.
• Use layers para compartilhar dependências comuns entre funções relacionadas.

---

12. Como cai na certificação

• Cenário "tarefa que dura mais de 15 minutos" → Lambda não serve — considere Fargate/EC2/Step Functions.
• Cenário "função crítica não pode ter cold start, mesmo em pico" → Provisioned concurrency.
• Cenário "eventos que falham repetidamente precisam ser analisados depois" → DLQ / destino de falha (invocação assíncrona).
• Cenário "processamento de fila SQS travando porque mensagens continuam falhando" → verificar maxReceiveCount e configurar DLQ da fila SQS.
• Cenário "processamento de stream (Kinesis/DynamoDB Streams) parado num shard" → o Lambda tenta o mesmo lote repetidamente por padrão — ajustar retries máximos/bisect on error.
• Cenário "função precisa acessar RDS numa subnet privada" → Lambda em VPC, com atenção ao acesso à Internet (NAT) se também precisar de recursos externos.
• Cenário "erro de permissão ao S3 tentar invocar a função" (não ao ela acessar outro recurso) → checar a resource-based policy, não a execution role.
• Cenário "deploy canário gradual entre versões" → Alias com pesos entre versões.

---

13. Exercícios práticos

1. Desenhe um fluxo onde um upload para S3 aciona um Lambda que processa a imagem e armazena em outro bucket. Identifique o tipo de invocação e o que acontece se a função falhar.
2. Explique quando usar provisioned concurrency e qual trade-off de custo envolve.
3. Compare o comportamento de retry entre uma Lambda invocada via API Gateway, uma invocada por evento S3, e uma consumindo uma fila SQS.
4. Explique a diferença entre execution role e resource-based policy com um exemplo concreto de erro que cada uma causaria se mal configurada.
5. Um cliente relata que sua função Java tem cold starts de vários segundos, impactando a experiência do usuário. Liste três estratégias de mitigação, em ordem de complexidade de implementação.

---

14. Questões de Revisão

Questão 1

Questão 2

Questão 3

Questão 4

Questão 5

Questão 6

Questão 7

Questão 8

Questão 9

Questão 10

Questão 11

Questão 12

Questão 13

Questão 14

Questão 15

Questão 16

Questão 17

Questão 18

Questão 19

Questão 20

Laboratório Prático

Objetivo: criar uma função Lambda acionada de forma assíncrona por eventos S3, configurar um destino de falha, e observar o comportamento de retry.

Pré-requisitos: conta AWS com permissão para Lambda, S3, IAM e SQS.

Tempo estimado: 25 minutos

Possíveis custos: praticamente nulo dentro do free tier para poucas execuções de teste.

Passos:

1. Crie um bucket S3 de origem e uma fila SQS que servirá como destino de falha (on-failure destination).
2. Crie uma função Lambda simples (ex: Python) cujo handler sempre lance uma exceção propositalmente, para simular falha.
3. Configure o bucket S3 para invocar essa função a cada ObjectCreated (invocação assíncrona).
4. Configure, nas configurações assíncronas da função, o destino de falha (on-failure destination) apontando para a fila SQS criada.
5. Envie um objeto de teste para o bucket e observe nos logs do CloudWatch que a função tenta executar, falha, e (após os retries automáticos padrão) o evento aparece na fila SQS de destino de falha.
6. Corrija o handler para não lançar mais exceção, envie um novo objeto, e confirme que dessa vez não há mensagem na fila de falha.

Resultado esperado: você observa na prática o retry automático de invocação assíncrona e o encaminhamento para o destino de falha configurado, sem nenhuma lógica de retry escrita manualmente no seu código.

Limpeza dos recursos: delete a função Lambda, a fila SQS, o bucket S3 (esvaziando antes) e a permissão de invocação criada automaticamente para o S3.

---

Referências:

• AWS Lambda Developer Guide: https://docs.aws.amazon.com/lambda/latest/dg/welcome.html
• Lambda Quotas (limites): https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html
• Invocação assíncrona: https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html
• Event source mapping: https://docs.aws.amazon.com/lambda/latest/dg/invocation-eventsourcemapping.html
• Lambda em VPC: https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html