A AWS estendeu o Documentação de limites do AWS Lambda (docs.aws.amazon.com) SnapStart runtime hooks na documentação da AWS (docs.aws.amazon.com) para funções empacotadas como container images, encerrando um trade-off que orientava a forma como equipes empacotavam dependências pesadas de Python. A novidade, AWS anuncia SnapStart para container images (aws.amazon.com)da pela AWS e detalhada pelo InfoQ em, permite que funções de até 10 GB em containers passem a inicializar em menos de um segundo, sem abrir mão do SnapStart.
Até o anúncio, quem escolhia container images ganhava espaço de sobra para bibliotecas como pandas e numpy, mas perdia o SnapStart e aceitava partidas de vários segundos enquanto o Lambda baixava as camadas da imagem e inicializava o runtime. Com a mudança, esse custo deixa de existir para a maioria das bases.
# publicidade
Leia também
AWS, Azure ou Google Cloud: como escolher
O que muda no Lambda SnapStart para container images
O Lambda SnapStart é o recurso da AWS que fotografa o ambiente de execução já inicializado no momento do deploy, armazena esse snapshot em cache e o restaura a cada invocação, em vez de inicializar do zero. Segundo a AWS, os tempos de startup caem para a faixa de subsegundo.
Antes desta atualização, o recurso cobria apenas os runtimes gerenciados de Python,.NET e Java em pacotes zip, limitados a 250 MB descompactados. Container images, que comportam até 10 GB, ficavam de fora.
Info: o SnapStart para container images já pode ser ativado em funções novas ou existentes via API, console, CLI, CloudFormation, SAM, SDK e CDK, conforme o anúncio oficial da AWS.
# publicidade
Como isso funciona na prática? No deploy, o Lambda executa a função uma vez, salva o estado e reutiliza esse ponto de partida em todas as invocações subsequentes. O custo de inicialização pesada, típico de stacks com pandas e numpy, é pago uma única vez.
A discussão no Reddit que escancarou o problema
Cerca de um mês antes do anúncio, um tópico no Reddit em r/aws mostrou a dor que o limite de 250 MB causava. Uma equipe que rodava pandas e numpy no Lambda relatou ter recorrido a remover espaços em branco, comentários e docstrings do próprio código e dos pacotes instalados, recuperando cerca de 5 MB.
O autor do tópico observou que docstrings só podiam ser removidas onde nada chamava __doc__, e rejeitou sugestões de rearquitetura: o código era legado, acoplado à stack, e o mundo real tem dívida técnica. Outros participantes lembraram que, conforme a documentação do Lambda, as Lambda layers entram no mesmo orçamento de 250 MB, logo mover dependências para uma layer não resolve.
Se você precisa manter o SnapStart, a saída de emergência é montar um access point EFS e importar as bibliotecas pesadas de lá no init: paga o cold start uma vez e segue no Lambda baseado em zip.
Boa parte da thread argumentava que a ferramenta estava errada, não o empacotamento. Comentaristas sugeriram ECS Fargate, Step Functions ou AWS Batch, já que trabalho pesado com pandas tende a ser batch e o Lambda seria uma escolha ruim para esse perfil. Um participante notou que container images já podiam iniciar mais rápido que um zip de 250 MB em alguns casos, mesmo antes do SnapStart. Esses argumentos seguem válidos; o que mudou é que o tamanho das dependências não penaliza mais o startup.
Imagens suportadas, hooks e o papel das ferramentas
O suporte não é uniforme entre imagens base. Nas imagens oficiais da AWS com Java 11 ou superior, Python 3.12 ou superior e.NET 8 ou superior, a experiência equivale à dos zips. Qualquer outra imagem, incluindo Node.js, Ruby e bases customizadas, precisa incluir o rótulo LABEL com.amazonaws.lambda.feature.snapstart="Allow" no Dockerfile ou implementar os SnapStart runtime hooks. Sem uma dessas opções, a publicação da versão falha durante a inicialização.
E as ferramentas de IaC acompanharam? Sim, e rápido. O Serverless Framework 4.42.0 saiu com suporte uma semana após o anúncio, depois que um usuário abriu uma issue apontando a lacuna. Um mantenedor registrou que configurar snapStart em função baseada em imagem já fazia o deploy corretamente antes do lançamento, e a versão fechou as brechas restantes:
Validação prévia: o framework rejeita storage efêmero acima de 512 MB combinado com SnapStart antes do deploy.
Mensagem clara de erro: falha ao publicar versão em função de container agora exibe uma dica apontando para o label ou os runtime hooks, em vez de uma mensagem crua do CloudFormation.
O mesmo mantenedor observou que a própria documentação de SnapStart da AWS ainda descrevia a era em que o recurso era exclusivo de Java. Uma diferença permanece entre os dois modelos: para funções em zip, a AWS corrige o runtime; em container images, manter a imagem base atualizada é responsabilidade do cliente, e o SnapStart não muda isso.
Disponibilidade, regiões e preço
O SnapStart para container images está disponível em todas as regiões comerciais da AWS, exceto Ásia-Pacífico na Nova Zelândia e Taipei. A cobrança segue tabela própria: a AWS mantém a precificação do SnapStart separada da precificação padrão do Lambda, ponto a verificar antes de ativar em produção.
Dica: antes de migrar uma função zip para container image, confira se seu runtime está entre os suportados nativamente. Se usa Node.js ou Ruby, inclua o label com.amazonaws.lambda.feature.snapstart="Allow" no Dockerfile para evitar falha no publish.
Atenção: ao contrário dos runtimes gerenciados, imagens de container não recebem patches automáticos da AWS. Atualizações de segurança da imagem base ficam por conta da sua equipe.
Na avaliação do Mercado de TI, a mudança reduz os casos em que o limite de 250 MB sozinho forçava uma rearquitetura, o que tende a simplificar a vida de equipes brasileiras que mantêm funções legadas com dependências científicas. O debate sobre se trabalho batch com pandas deveria mesmo rodar em Lambda continua aberto, mas a decisão agora é técnica, não imposta por um teto de armazenamento. Vale acompanhar a evolução da documentação oficial e o suporte das demais ferramentas de deploy nos próximos meses.
Leia também:
Fonte: Infoq
