SnapStart em container: o bake-off contra concorrência provisionada

O bloqueio nunca foi o mecanismo de snapshot, o Firecracker já congelava memória e disco desde o SnapStart original em Java. O bloqueio era o contrato de ciclo de vida: uma imagem de container pode carregar qualquer runtime, e o Lambda precisava de um jeito padronizado de saber quando a inicialização terminou e quando o ambiente voltou do congelamento.

Esse contrato agora é público, e vive na Runtime API. Ao fim da sua inicialização, se AWS_LAMBDA_INITIALIZATION_TYPE valer snap-start, você roda seus hooks de before-snapshot e chama GET /runtime/restore/next. A chamada bloqueia, literalmente, o processo fica parado ali, até que o Lambda restaure aquele ambiente a partir do snapshot e devolva HTTP 200. Aí você roda os hooks de after-restore e entra no loop normal de invocação. Erros vão para /runtime/init/error (falha o PublishVersion) ou /runtime/restore/error (falha a invocação em voo e derruba o ambiente).

Se você usa as imagens base da AWS para Java 11+, Python 3.12+ ou .NET 8+, o Lambda coordena tudo isso e a experiência é idêntica ao .zip. Se você traz sua própria imagem base, um Runtime Interface Client próprio, ou as imagens base de provided.al2023, Node.js e Ruby, existem dois caminhos: implementar o /restore/next ou declarar LABEL com.amazonaws.lambda.feature.snapstart="Allow" no Dockerfile. Sem uma das duas coisas, publicar a versão simplesmente falha.

O SnapStart tira do caminho da requisição três coisas caras: o download e a otimização das camadas da imagem, a carga do runtime e a sua inicialização, imports, wiring de framework, compilação de esquema, carregamento de pesos de modelo em memória. Tudo isso passa a acontecer uma vez por versão publicada, no deploy.

O que ele não remove é o que é genuinamente por ambiente. Conexões de rede abertas na init não têm estado garantido depois da retomada; o SDK da AWS costuma se reconectar sozinho, o resto é responsabilidade sua no hook de after-restore. Entropia é o caso perigoso: se você gerou um UUID, um segredo ou uma seed na init, esse valor entra no snapshot e sai idêntico em todos os ambientes restaurados. O Lambda já ajuda num ponto sensível, com SnapStart ativo o runtime passa a usar as credenciais de container (AWS_CONTAINER_CREDENTIALS_FULL_URI) em vez das variáveis de access key, justamente para que credenciais não expirem congeladas dentro do snapshot.

E há uma inversão de design que quase ninguém nota na primeira leitura: com SnapStart, o /tmp fica limitado a 512 MB, contra os 10.240 MB configuráveis de uma função normal. O padrão clássico de inferência, baixar pesos do S3 para o /tmp na init, deixa de caber. O caminho que sobra é assar os pesos na própria imagem (até 10 GB descomprimidos) e carregá-los em memória, onde o snapshot os captura já materializados. É exatamente o cenário que a AWS cita, mas ele exige reescrever o carregamento, não só ligar a flag.

Os números de us-east-1, arquitetura x86: cache do snapshot a US$ 0,0000015046 por GB-segundo, restauração a US$ 0,0001397998 por GB, concorrência provisionada a US$ 0,0000041667 por GB-s e duração sob demanda a US$ 0,0000166667 por GB-s. Para runtimes gerenciados Java a documentação isenta o preço de SnapStart; a conta abaixo vale para Python e .NET.

Uma função de 2 GB com uma versão publicada mantida ativa um mês inteiro custa cerca de US$ 7,80 só de cache. Uma única unidade de concorrência provisionada nos mesmos 2 GB custa cerca de US$ 21,60 no mês. Cada restauração de 2 GB sai por US$ 0,00028, ou seja, você precisaria de aproximadamente 77 mil restaurações mensais para que o custo variável do SnapStart alcançasse uma unidade provisionada. Para a esmagadora maioria das APIs, o SnapStart ganha por larga margem.

O problema não é o preço unitário; é a multiplicação. A cobrança de cache é por versão publicada e continua enquanto a versão existir, com mínimo de 3 horas faturadas. Uma esteira que publica versão a cada merge e nunca poda deixa dezenas de snapshots pagos rodando para trás. Vinte versões de 2 GB esquecidas no ar custam mais de US$ 150 por mês para servir absolutamente nenhum tráfego. Some a isso o fato de que o Lambda regenera snapshots periodicamente para aplicar patches de runtime, e cada re-execução da init é cobrada. Uma política de retenção de versões deixa de ser higiene e passa a ser controle financeiro.

Este é o ponto que mais me interessa como arquiteto: o SnapStart move a inicialização para o deploy, e com ela move os modos de falha.

A init e os hooks de before-snapshot compartilham um timeout combinado de max(timeout_da_função, 130 segundos). Estourou, o PublishVersion falha. Uma função de inferência que carrega 4 GB de pesos e antes só ficava lenta na primeira chamada agora quebra o pipeline de release, o que, sinceramente, é o lugar certo para quebrar, desde que a esteira trate isso como erro de deploy e não como flake.

Segundo: SnapStart só existe em versão publicada ou alias que aponte para versão. $LATEST nunca é SnapStart. Isso significa que o loop de desenvolvimento que invoca $LATEST exercita um caminho de código diferente do de produção; os testes de contrato precisam bater no alias. Terceiro: o tipo de pacote é imutável. Você não converte uma função de container em .zip, cria outra função, com outro ARN, outro alias, outros event source mappings. Planeje isso como migração, não como toggle.

E há os estados que só aparecem com tráfego raro. Uma função de container sem invocação por semanas tem a imagem otimizada recuperada, volta para Pending e rejeita a primeira invocação. Para runtimes Java, o snapshot é apagado após 14 dias sem invocação e você recebe SnapStartNotReadyException. Ambos são erros retentáveis pelo chamador, desde que o chamador tenha retry com backoff e a operação seja idempotente. Sem isso, a sua função de baixo tráfego tem um erro embutido no calendário.

O primeiro efeito colateral do SnapStart é que os seus dashboards de partida a frio param de funcionar em silêncio. O campo Init Duration some do REPORT, porque a inicialização não acontece mais na invocação; ele passa a viver num registro separado, o INIT_REPORT, junto com a duração dos hooks de before-snapshot. No REPORT aparecem dois campos novos: Restore Duration e Billed Restore Duration. Eles não são a mesma coisa, o primeiro inclui trabalho feito fora da microVM, que o usuário espera mas você não paga; o segundo é só a carga do runtime e os hooks de after-restore.

A fórmula que importa é simples e precisa entrar no seu SLO: partida a frio = Restore Duration + Duration. Se o seu alarme só olha @duration, ele vai mostrar uma melhora que não existe. No X-Ray a mudança é análoga: não há mais subsegmento Initialization, e sim Restore. Pela Telemetry API chegam platform.restoreStart, platform.restoreRuntimeDone (com status success, failure ou timeout) e platform.restoreReport.

Dois detalhes práticos. As variáveis AWS_LAMBDA_LOG_GROUP_NAME e AWS_LAMBDA_LOG_STREAM_NAME não existem em função SnapStart, bibliotecas de log que dependem delas quebram de forma discreta. E a medida honesta de impacto não é a duração da função: é a IntegrationLatency do API Gateway ou a UrlRequestLatency da function URL, em p99 e p99,9. Só ali você vê o que o cliente sentiu.