A AWS estendeu o Lambda SnapStart para funções empacotadas como imagens de container, removendo a escolha forçada entre usar containers de até 10 GB ou manter inicialização rápida. A mudança resolve um gargalo real enfrentado por times que trabalham com pandas e numpy.
A AWS estendeu o AWS Lambda SnapStart para containers (aws.amazon.com) SnapStart para funções empacotadas como imagens de container, eliminando uma escolha forçada que moldava a arquitetura de times com dependências pesadas em Python. Agora dá para usar containers de até 10 GB e manter inicialização abaixo de um segundo. Site Documentação oficial do AWS Lambda (docs.aws.amazon.com) da AWS (aws.amazon.com)
SnapStart funciona com imagens de container, mantendo cold start abaixo de 1 segundo.
Containers suportam até 10 GB, contra 250 MB do zip tradicional.
Leia também · há 2 semanas
AWS Lambda SnapStart chega a container images e elimina trade-off de empacotamento
Suporte nativo para Java 11+, Python 3.12+ e.NET 8+ em imagens base AWS.
Node.js, Ruby e imagens customizadas exigem LABEL ou runtime hooks no Dockerfile.
Disponível em todas as regiões comerciais, exceto Nova Zelândia e Taipei.
O que mudou no lambda SnapStart
O SnapStart tira um snapshot do ambiente de execução já inicializado no momento do deploy, armazena em cache e retoma a partir dele a cada invocação, em vez de inicializar do zero. A AWS reporta que o tempo de inicialização cai para menos de um segundo.
Até agora, esse recurso cobria apenas os runtimes gerenciados de Python,.NET e Java. Funções em container podiam carregar até 10 GB de dependências, mas abriam mão do SnapStart e aceitavam vários segundos de cold start enquanto o Lambda baixava as camadas da imagem e inicializava o runtime.
Para quem desenvolve com pandas e numpy, a limitação de 250 MB do zip era um problema real. Um mês antes do anúncio, um time descreveu no Reddit como estourou o teto e recorreu à remoção de espaços em branco, comentários e docstrings do próprio código e dos pacotes instalados para recuperar cerca de 5 MB.
O dilema real de quem usa pandas e NumPy
O autor do post no Reddit 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.
A thread corrigiu uma suposição comum. Dois comentaristas apontaram para a documentação da AWS confirmando que camadas Lambda contam no mesmo limite de 250 MB descompactados. Mover pandas e numpy para uma layer não libera espaço algum.
A posição que restava era resumida assim: para manter SnapStart, a saída era montar um access point do EFS e importar as bibliotecas pesadas de lá na inicialização. Você paga o cold start uma vez, mas continua no Lambda baseado em zip. A remoção de docstrings funciona, mas significa que qualquer atualização de dependência trava tudo de novo.
Camadas Lambda contam no mesmo limite de 250 MB descompactados.
Importar bibliotecas do EFS mantém zip, mas paga cold start uma vez.
Remover docstrings é frágil: uma atualização de dependência trava o deploy.
Sugestões de migrar para ECS Fargate, Step Functions ou AWS Batch foram frequentes.
Agora dá para manter SnapStart em containers
A mudança prática: times que escolhem containers pelo tamanho das dependências não pagam mais a penalidade de inicialização. Isso reduz os casos em que o limite de tamanho sozinho força uma rearquitetura.
O suporte não é uniforme entre imagens base. Imagens base da AWS com Java 11 ou superior, Python 3.12 ou superior e.NET 8 ou superior funcionam como arquivos zip. Qualquer outra imagem, incluindo Node.js, Ruby e bases customizadas, precisa adicionar LABEL com.amazonaws.lambda.feature.snapstart="Allow" ao Dockerfile ou implementar os SnapStart runtime hooks.
Sem uma dessas opções, a publicação da versão falha durante a inicialização. É um detalhe que pega quem migra rápido e não lê a documentação.
Uma diferença entre os dois modelos de empacotamento permanece. A AWS corrige o runtime para funções baseadas em zip. Com imagens de container, manter a imagem base atualizada é responsabilidade do cliente, e o SnapStart não muda isso.
Java 11+, Python 3.12+ e.NET 8+ em imagens base AWS: suporte nativo.
Node.js, Ruby e custom: LABEL no Dockerfile ou runtime hooks obrigatórios.
Sem configuração, a publicação da versão falha na inicialização.
Atualizar imagem base continua sendo responsabilidade do cliente.
Ferramentas e regiões já atualizadas
O Serverless Framework 4.42.0 adicionou suporte uma semana após o anúncio, depois que um usuário abriu uma issue apontando a novidade. Um maintainer notou que definir snapStart em uma função baseada em imagem já funcionava no deploy antes do release, o que fechou as lacunas restantes.
O framework agora rejeita storage efêmero acima de 512 MB combinado com SnapStart antes do deploy. E uma falha de publicação de versão em função container imprime uma dica apontando para o LABEL ou runtime hooks, em vez de uma mensagem crua do CloudFormation.
O mesmo maintainer observou que a documentação do SnapStart da própria AWS ainda descrevia a era em que o recurso era exclusivo de Java.
SnapStart para imagens de container está disponível em todas as regiões comerciais da AWS, exceto Ásia-Pacífico Nova Zelândia e Taipei. Pode ser ativado em funções novas ou existentes via API, console, CLI, CloudFormation, SAM, SDK e CDK. A AWS documenta a precificação do SnapStart separadamente da precificação padrão do Lambda.
Serverless Framework 4.42.0 com suporte uma semana após o anúncio.
Rejeição de storage efêmero acima de 512 MB com SnapStart antes do deploy.
Mensagem de erro aponta para LABEL ou runtime hooks, não para CloudFormation cru.
Ativação via API, console, CLI, CloudFormation, SAM, SDK e CDK.
| Modelo de empacotamento | Limite de tamanho | SnapStart | Responsabilidade de patch do runtime | Cenário ideal |
|---|---|---|---|---|
| Zip | 250 MB | Suportado | AWS | Funções leves, dependências compactas |
| Container | 10 GB | Suportado (com requisitos de imagem) | Cliente | Dependências pesadas como pandas e numpy |
Arraste para o lado para ver toda a tabela.
Leia também:
Mercado de TI: 15 vagas remotas em Python, Java, IA e mais com salários de até us$ 110 por hora
Cpython oficializa suporte a arquitetura risc-v como plataforma tier 3 com apoio do rise project
Python lidera dos anúncios de emprego tech nos EUA e define nova etapa na análise de dados
Fonte: Infoq
Quem escreveu
Dagmar Cirino · Editor-chefe
Especialista em tecnologia, criador de conteúdo e fundador do portal Mercado de TI e Casa do Dev. Analiso tendências de mercado, Inteligência Artificial e carreira, entregando informações precisas, transparentes e acessí...
