AWS libera armazenamento próprio de código no Lambda, mas o limite por função continua

A AWS anunciou o self-managed code storage para o Lambda: agora funções e layers podem referenciar o pacote de deploy diretamente em um bucket S3 do próprio cliente, em vez de ficar na storage gerenciada pela Lambda. A mudança foi divulgada pela InfoQ e, segundo a reportagem, a forma como foi comunicada acabou gerando interpretações equivocadas.

O que realmente muda

O ponto central é a cota de armazenamento por região. Times que rodam grandes frotas de funções historicamente precisavam abrir tíquetes de suporte para aumentar esse limite. Com o novo modo, essa cota agregada deixa de existir: o código passa a viver no bucket S3 do cliente, limitado apenas pelo que o bucket comporta. A AWS também elevou o padrão da storage gerenciada de 75 GB para 300 GB por região.

Julian Wood, principal developer advocate de serverless na AWS, resumiu a novidade no LinkedIn como "sem limites de armazenamento: guarde tanto código de função e layer quanto seu bucket permitir", com uma única fonte da verdade na conta do cliente e visibilidade total via métricas e regras de ciclo de vida do S3.

O limite que NÃO mudou

A frase de Wood gerou a dúvida que interessa a quem constrói de verdade: dá para embarcar modelos maiores dentro do pacote da função? A resposta de um dev na thread foi direta: "Não, os mesmos limites continuam valendo. Agora a AWS também pode te cobrar pelos custos de armazenamento e recuperação."

Na prática, os limites por função permanecem intactos:

• 50 MB compactado e 250 MB descompactado para funções baseadas em zip;
• 10 GB para imagens de container.

Quem esbarrava no teto de tamanho de uma função individual continua exatamente na mesma situação. O self-managed storage muda onde o pacote fica e remove o teto agregado da conta, não o limite de cada artefato.

O ganho operacional real

Darryl Ruggles, AWS Serverless Hero, apontou no X um efeito colateral positivo: a Lambda deixa de criar uma cópia intermediária do pacote. Segundo ele, "você pode referenciar o código-fonte direto dos seus buckets e a Lambda não cria mais uma cópia intermediária. Isso pode acelerar a ativação da função após criações e atualizações."

Ruggles acrescentou que não há cobranças extras da Lambda além do armazenamento padrão no S3 e de eventuais transferências cross-region, o que transfere o custo de uma cota invisível do lado Lambda para uma linha visível na conta do S3 do cliente.

O fluxo de deploy em si não muda: ainda é preciso chamar UpdateFunctionCode depois de trocar o objeto no S3. A referência é resolvida no momento do update, não continuamente, ou seja, apontar a Lambda para um bucket não transforma esse bucket em um feed de código ao vivo.

O que muda para quem constrói no Brasil

O recurso está disponível em todas as regiões comerciais da AWS, sem cobrança adicional da Lambda, o que inclui a região de São Paulo. Para a maioria dos times brasileiros, o efeito prático será modesto: como resumiu um comentário citado pela InfoQ, "é uma opção nativa que supera o limite de armazenamento gerenciado, e a maioria dos times nunca vai chegar lá".

O recado é para operações com muitas funções em produção que já batiam na cota por região: agora dá para escalar o número de artefatos usando o próprio S3, com visibilidade de custo e regras de lifecycle. Vale conferir se o time faz esse tipo de gestão de frota antes de adotar por adotar.

Um ponto de atenção para quem padroniza infraestrutura como código: o suporte via Terraform ainda está atrasado. Um pedido de enhancement para o atributo s3_object_storage_mode no aws_lambda_function foi aberto em 15 de julho e segue sem implementação. Quem depende de Terraform terá que esperar ou recorrer à CLI e aos SDKs, onde o parâmetro já está disponível.

Fonte: InfoQ