Lambda profundo: cold start, layers e provisioned concurrency
⏱ 14 min·⭐ 60 XP
Pré-requisitos (0/1)0%
- ⬜🎯 DVA-C02: domínios, pesos e estratégia de estudo(AWS Developer Associate (DVA-C02))
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
Execution lifecycle
1. INIT phase (cold start):
- Baixa código + layers
- Inicia runtime (Node/Python/etc)
- Executa código FORA do handler (import, DB pool setup)
Duração típica: 200-500ms (sem VPC), 1-10s (com VPC + Java)
2. INVOKE phase:
- Executa handler (seu código)
- Paga por duração × memória
3. Container reuse ("warm"):
- Mesmo container pode servir múltiplas requests
- State em memória PERSISTE (útil pra connection pool)
- Após ~5-15min idle, AWS deallocatesChegada
EventoAPI GW, SQS, S3, agendamento
Cold start — só na primeira
1. Baixa o códigoZIP ou imagem, do S3/ECR
2. Cria o ambientemicroVM Firecracker
3. Roda o INITimport, cliente SDK, pool
Toda invocação
4. Executa o handlersó aqui roda o seu event
Ambiente quente
Reaproveitadopróxima invocação pula 1-3
Congeladothread parada entre invocações
Reduzir o cold start
Provisioned Concurrencyambientes já inicializados
SnapStartsnapshot do estado pós-INIT (Java)
- → primeira vez
- → termina
- → próximo evento pula o INIT
- → sem tráfego
- → pré-executa
- → restaura snapshot
- Integração de apps
- Armazenamento
- Compute
- Gestão e governança
- IA e machine learning
Este é um fluxo temporal, não uma topologia: os passos 1 a 3 acontecem só no cold start, e o 4 em toda invocação. Saber o que fica fora do handler é o que separa Lambda rápida de lenta.
- Cold start é a soma de três coisas. Baixar o código, criar o ambiente e rodar o INIT. Só a terceira você controla: é o seu código fora do handler. Pacote grande piora a primeira, e import pesado piora a terceira.
- O que vai FORA do handler roda uma vez. Cliente do SDK, conexão de banco, leitura de segredo: declare no escopo do módulo e será reaproveitado por todas as invocações daquele ambiente. Dentro do handler, roda a cada evento — e é o erro de desempenho nº 1 em Lambda.
- O ambiente quente é reaproveitado. Terminada a invocação, o ambiente fica disponível. A próxima pula os passos 1 a 3 e vai direto ao handler — daí a diferença de centenas de milissegundos para poucos.
- Congelado não é o mesmo que encerrado. Entre invocações a execução é congelada: thread em background e I/O pendente param. Trabalho assíncrono disparado sem await pode simplesmente não terminar — e volta a rodar na invocação seguinte, no meio de outro evento.
- As duas formas de atacar o cold start. Provisioned Concurrency mantém N ambientes já inicializados e prontos — custa por hora. SnapStart tira um snapshot pós-INIT e restaura, sem custo extra, para Java. A questão que exige latência p99 previsível pede uma das duas.
Onde isso entra no exame
📘 Domain 1 — Development with AWS Services· 32%
Lambda é o serviço mais cobrado do DVA. As questões giram em torno de três coisas: qual ajuste corta cold start (provisioned concurrency, memória, runtime), como o handler recebe o evento de cada fonte, e por que a função falha em silêncio. Espere pegadinha sobre retentativa de invocação assíncrona — são 2 tentativas automáticas antes da DLQ, e invocação síncrona não tem nenhuma.
Connection pool pattern
// DB connection FORA do handler — reusa entre invocations (warm)
import { Pool } from 'pg';
const pool = new Pool({ connectionString: process.env.DB_URL });
export const handler = async (event) => {
const client = await pool.connect();
try {
return await client.query(...);
} finally {
client.release();
}
};
// Cold start paga o setup uma vez. Warm invocations reusam.Quiz rápido
Uma Lambda abre conexão com o RDS dentro do handler, a cada invocação. Sob carga, o banco esgota o pool de conexões. Qual é a correção?
Layers
- Pacote ZIP compartilhado entre funções (até 5 layers por função).
- Deps comuns (Axios, Pandas), binários (ffmpeg), shared libs.
- Reduz package size → cold start menor.
- Versionado: layer v1, v2 — função pina versão específica.
💡
Container Image (até 10GB) virou alternativa ao ZIP + Layers em 2020. Se deps são grandes (ML models), container image é mais prático.
Perguntas frequentes
❓ Como reduzir partida a frio de verdade?
Reduzindo o que a inicialização faz e o tamanho do pacote, e usando concorrência provisionada quando a latência é requisito. O que não funciona é aquecer com chamada agendada — trata o sintoma numa instância e não escala. Mover trabalho de inicialização para fora do caminho da primeira invocação é o ganho maior.
❓ Para que servem as camadas de função?
Para separar dependência do código: a camada é empacotada uma vez e compartilhada entre funções, o que reduz o tamanho do pacote de implantação e o tempo de inicialização. O cuidado é de versionamento — camada é imutável por versão, e atualizar exige apontar a nova.
❓ O que acontece quando a função falha numa invocação assíncrona?
A plataforma tenta novamente algumas vezes e, se você configurou destino de falha ou fila de mensagem morta, entrega o evento lá — sem isso, o evento é descartado em silêncio. É a pegadinha de prova mais comum do domínio: falha assíncrona sem destino configurado desaparece.
Fixando
Quiz rápido
Uma função assíncrona (invocada por evento do S3) falha em 3 tentativas. Sem configuração adicional, o que acontece com o evento?
Quiz rápido
O time precisa de latência p99 previsível numa API de checkout, e o cold start está causando picos. Qual recurso?
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…