Desde que o AWS Lambda foi lançado, há mais de uma década, a liberdade do desenvolvedor serverless sempre teve um asterisco: o código das suas funções precisava morar na casa do Lambda, dentro de uma cota compartilhada que, até pouco tempo, era de apenas 75 GB por região. Quando essa cota estourava — cenário cada vez mais comum em empresas que mantêm centenas ou milhares de funções — a única saída era abrir um ticket de suporte e pedir um aumento, processo que poderia levar dias e interromper pipelines de implantação no pior momento possível. No dia 15 de julho de 2026, porém, a AWS quebrou essa corrente ao anunciar o armazenamento auto-gerenciado para funções Lambda, uma mudança que, à primeira vista, parece técnica demais, mas que carrega consequências profundas para quem constrói e opera sistemas serverless em escala.

A novidade permite que funções Lambda e suas camadas (layers) façam referência direta a pacotes de implantação armazenados em buckets Amazon S3 de propriedade do próprio cliente, sem que o Lambda crie uma cópia intermediária em seu armazenamento interno. Na prática, isso significa que o desenvolvedor agora decide onde o código vive, em vez de delegar essa decisão ao serviço de computação. O novo parâmetro que controla esse comportamento se chama S3ObjectStorageMode; quando configurado como REFERENCE (o padrão ainda é COPY, que mantém o comportamento antigo), o Lambda lê o código diretamente do bucket do cliente a cada invocação, sem duplicar dados e sem consumir a cota de armazenamento gerenciado.

Por que a cota antiga era um gargalo real

Para entender o impacto da mudança, é preciso olhar para o que vinha antes. Até julho de 2026, cada conta AWS tinha uma cota de 75 GB de armazenamento gerenciado pelo Lambda por região, limite que a própria AWS elevou para 300 GB no mesmo anúncio. Embora 300 GB pareçam generosos, organizações que adotam práticas de versionamento rigoroso, mantêm múltiplas versões de cada função e utilizam camadas compartilhadas para bibliotecas comuns sabem que esse espaço se esgota rápido — especialmente quando cada pacote .zip pode chegar a 50 MB comprimido e 250 MB descomprimido, e imagens de container podem atingir 10 GB. Antes do armazenamento auto-gerenciado, esbarrar nessa cota significava interromper deploys ou recorrer ao suporte da AWS, um processo que, segundo relatos da comunidade no Reddit, poderia levar de horas a dias dependendo do volume de solicitações.

Com o modo REFERENCE, esse problema simplesmente deixa de existir. Como Julian Wood, principal developer advocate de serverless na AWS, resumiu no LinkedIn: agora é possível armazenar tanto código de funções e camadas quanto o seu bucket permitir, com uma única fonte da verdade na sua própria conta. A frase de Wood captura a essência da mudança: o limite deixa de ser uma cota arbitrária do Lambda e passa a ser a capacidade do seu bucket S3, algo que o desenvolvedor já sabe gerenciar há anos.

Velocidade: cinco segundos a menos podem mudar um pipeline

A outra grande promessa do armazenamento auto-gerenciado é a velocidade de ativação. Quando o Lambda operava no modo COPY, cada criação ou atualização de função exigia que o serviço copiasse o pacote de código do S3 (ou de um upload direto) para o seu armazenamento interno antes de tornar a função disponível. Essa etapa de cópia, invisível para o desenvolvedor mas presente em cada deploy, adicionava latência ao processo. Nos testes realizados pela equipe de engenharia da AWS e publicados no Compute Blog em 17 de julho de 2026, a eliminação do passo de cópia resultou em uma redução de aproximadamente 5 segundos no tempo de criação e atualização para um pacote Python 3.13 de 200 MB. Em ambientes de CI/CD que dezenas ou centenas de funções em sequência, cinco segundos por função se acumulam em minutos preciosos — tempo que, em um deploy de emergência durante um incidente de produção, pode ser a diferença entre resolver o problema rapidamente ou agravá-lo.

É importante notar, no entanto, que a eliminação da cópia intermediária não altera os limites individuais de tamanho de cada função. Os pacotes .zip continuam restritos a 50 MB comprimidos e 250 MB descomprimidos, e as imagens de container seguem com o teto de 10 GB. O que mudou foi o teto coletivo — a quantidade total de código que uma conta pode ter disponível para suas funções Lambda em determinada região — e não o tamanho de cada pacote individual. Como um usuário do Reddit observou na thread de discussão do anúncio, a maioria dos desenvolvedores nunca vai cruzar a cota de 300 GB, mas para aqueles que cruzam, o armazenamento auto-gerenciado é uma alternativa nativa e elegante ao processo manual de solicitação de aumento de limite.

Controle de segurança e compliance na palma da mão

Além da liberdade de escala e da velocidade, o armazenamento auto-gerenciado entrega algo que organizações reguladas há anos pediam: controle total sobre as políticas de segurança do bucket onde o código reside. No modo COPY, o Lambda criava uma cópia do pacote em um bucket interno gerenciado pelo serviço, bucket esse cujas políticas de criptografia, acesso e retenção o desenvolvedor não controlava diretamente. Para empresas sujeitas a auditorias de compliance — como instituições financeiras e provedores de saúde — essa falta de visibilidade era um obstáculo real.

Com o modo REFERENCE, o código fica no bucket do cliente, o que significa que todas as políticas de segurança do S3 se aplicam automaticamente. O desenvolvedor pode escolher entre criptografia SSE-S3, SSE-KMS ou DSSE-KMS (a opção de criptografia dupla, que criptografa os dados em duas camadas independentes), habilitar Object Lock para proteger versões contra exclusão ou substituição, configurar versionamento obrigatório (pré-requisito para o modo REFERENCE) e habilitar access logging para rastrear cada leitura realizada pelo serviço Lambda. Como Doug Perkes e Adam Gazaleh, autores do post no Compute Blog, explicaram, o modelo elimina a pressão sobre a cota e ao mesmo tempo resolve a falta de controle sobre criptografia, acesso e compliance que existia no armazenamento gerenciado.

Configurando o acesso: o que o seu bucket precisa permitir

Para que o Lambda consiga ler o código do seu bucket, é necessário configurar uma política de acesso específica. A política do bucket S3 precisa conceder permissões de s3:GetObject e s3:GetObjectVersion ao principal de serviço lambda.amazonaws.com, utilizando a condição aws:SourceArn para restringir o acesso apenas às funções Lambda autorizadas. Essa configuração garante que nem qualquer serviço da AWS, nem qualquer conta, possa ler o código armazenado no bucket, uma camada extra de segurança que se alinha com o princípio do menor privilégio.

Outro ponto técnico que merece atenção é o comportamento do Lambda quando o objeto de código referenciado se torna indisponível — seja porque foi excluído, porque a política de acesso foi alterada ou porque o bucket deixou de existir. Nesses casos, a função Lambda entra automaticamente no estado Inativo (Inactive), o que significa que ela não responderá a invocações até que o problema seja resolvido. Esse comportamento é diferente do modo COPY, onde o código fica no armazenamento interno do Lambda e permanece disponível mesmo que o objeto original no S3 seja removido. Para equipes que adotam o modo REFERENCE, portanto, é essencial implementar monitoramento sobre a existência e acessibilidade dos objetos de código no S3, utilizando os próprios metricas do S3 e as métricas de saúde do Lambda.

Casos de uso onde a mudança faz mais diferença

Nem toda função Lambda se beneficia igualmente do armazenamento auto-gerenciado. Para desenvolvedores que mantêm poucas funções e nunca se aproximaram da cota de 75 GB (ou dos novos 300 GB), o modo COPY continua sendo a opção mais simples e suficiente. Mas para três cenários específicos, o modo REFERENCE resolve problemas que antes exigiam workarounds complexos.

O primeiro caso são os pipelines de CI/CD em organizações que dezenas de funções a cada deploy. Nesses ambientes, a eliminação da etapa de cópia acelera significativamente o ciclo de implantação e reduz a janela de risco durante atualizações de produção. O segundo caso são as arquiteturas multi-conta, onde uma conta centralizada armazena os pacotes de código e várias contas de workload referenciam esses pacotes via políticas de bucket cross-account. O terceiro caso, talvez o menos óbvio, é o de recuperação de desastres: como o S3 suporta replicação entre regiões (Cross-Region Replication), o código das funções Lambda pode ser replicado automaticamente para outra região, permitindo que um ambiente de failover referencie os mesmos pacotes sem necessidade de uploads manuais ou sincronização de artefatos.

Infraestrutura como código e o futuro do Terraform

Para quem gerencia infraestrutura como código, o novo recurso já é suportado pela AWS CLI e pelo AWS CloudFormation, o que permite incorporar o modo REFERENCE em templates e scripts de deploy existentes com pouca adaptação. No entanto, o suporte no Terraform ainda está em andamento: um pedido de melhoria no provider foi registrado no mesmo dia do anúncio, 15 de julho de 2026, e permanece aberto. Para equipes que utilizam Terraform como ferramenta principal de provisionamento, essa lacuna temporária pode representar um obstáculo, já que exigirá o uso de recursos nulos (null_resource) ou execução de comandos via local-exec para aplicar a configuração até que o provider seja atualizado.

É válido destacar que, embora o modo REFERENCE elimine a cópia intermediária e a cota de armazenamento, ele introduz uma nova dependência: o código da função precisa estar sempre disponível no bucket S3 referenciado. Se um pipeline de CI/CD publicar uma nova versão do pacote no S3, a função Lambda ainda precisará ser atualizada via UpdateFunctionCode para apontar para o novo objeto. Como um participante da discussão no Reddit questionou, essa chamada permanece necessária, o que significa que o fluxo de implantação não se simplifica automaticamente — ele apenas transfere o controle do armazenamento para o desenvolvedor.

O que muda no seu dia a dia como desenvolvedor serverless

Se você mantém menos de 50 funções Lambda e nunca esbarrou na cota de armazenamento, o impacto imediato desta mudança é pequeno. Mas se você trabalha em uma organização que escalou para centenas ou milhares de funções, que mantém múltiplas versões de cada uma, que utiliza camadas para compartilhar bibliotecas comuns e que precisa de controle total sobre criptografia e acesso ao código, o armazenamento auto-gerenciado resolve uma dor de cabeça que existia desde os primeiros dias do Lambda. A cota de 300 GB por região, embora maior do que os 75 GB anteriores, ainda é finita; o modo REFERENCE a torna irrelevante para quem está disvido a assumir a responsabilidade de gerenciar o próprio bucket.

Além disso, a possibilidade de utilizar as políticas de ciclo de vida do S3 (lifecycle policies) para gerenciar o crescimento dos artefatos abre caminho para estratégias de retenção mais sofisticadas. Desenvolvedores podem configurar regras que movam versões antigas de pacotes para classes de armazenamento mais baratas após um período determinado, ou que excluam automaticamente artefatos que não foram referenciados por nenhuma função nos últimos 90 dias. Esse nível de granularidade no gerenciamento de custos simplesmente não existia no modo COPY, onde o Lambda controlava o armazenamento e o desenvolvedor pagava sem visibilidade clara sobre o que estava consumindo espaço.

Para quem já utiliza o S3 como parte de seus pipelines de CI/CD — armazenando artefatos de build, logs de teste ou configurações de ambiente — a mudança é quase imperceptível na superfície, mas profundamente significativa em termos de arquitetura. O bucket de deploy que já existia no seu pipeline agora pode servir como fonte direta de código para as funções Lambda, eliminando uma camada de indireção e reduzindo a superfície de falha. Se o bucket já estava configurado com versionamento, criptografia e políticas de acesso adequadas, a transição para o modo REFERENCE pode ser feita em poucos minutos, apenas adicionando o parâmetro S3ObjectStorageMode no template de infraestrutura e atualizando a política do bucket.

Sua caixa de ferramentas para começar hoje

Se você decidiu adotar o armazenamento auto-gerenciado, o primeiro passo é garantir que o bucket S3 que pretende utilizar tenha versionamento ativado — sem essa configuração, o Lambda não permitirá a referência direta. Em seguida, crie ou atualize a política do bucket para incluir as permissões de s3:GetObject e s3:GetObjectVersion para o principal de serviço lambda.amazonaws.com, sempre com a condição aws:SourceArn para restringir o acesso. Decida qual nível de criptografia faz sentido para o seu caso: SSE-S3 para simplicidade, SSE-KMS para controle granular de chaves, ou DSSE-KMS para conformidade com requisitos que exijam criptografia dupla.

Configure seus alertas de monitoramento para acompanhar a existência e acessibilidade dos objetos de código referenciados, lembrando que qualquer indisponibilidade coloca a função no estado Inativo. Se a sua organização utiliza replicação entre regiões como estratégia de recuperação de desastres, ative o S3 Cross-Region Replication no bucket para garantir que o código esteja disponível no ambiente de failover. Por fim, teste o novo fluxo de implantação em um ambiente de desenvolvimento antes de migrar funções de produção, prestando atenção especial ao tempo de ativação e ao comportamento do Lambda quando o objeto de código é atualizado no S3 sem que a função seja reconfigurada.

O armazenamento auto-gerenciado para funções Lambda não é uma revolução que vai mudar o mundo da noite para o dia. Mas para as equipes que vivem a tensão diária entre escalar seus sistemas serverless e respeitar as limitações do serviço, a mudança representa uma liberdade que estava faltando — a liberdade de decidir onde o código mora, como ele é protegido e quanto espaço ele pode ocupar, sem depender de tickets de suporte ou de uma cota que nunca parecia suficiente.