Apresentando buckets Amazon S3 autogerenciados para código de função AWS Lambda

Por Doug Perkes, Sr. Solutions Architect e Adam Gazaleh, Sr. Product Manager-Tech na Amazon Web Services.

Se você gerencia funções Lambda em escala, provavelmente já atingiu o limite de armazenamento de código de 75 GB ou explicou à sua equipe de segurança por que os artefatos de implantação ficam em um bucket S3 que você não controla. Hoje, estamos anunciando buckets Amazon S3 autogerenciados para pacotes de implantação do AWS Lambda. O Lambda lê seu código diretamente do seu bucket, eliminando a pressão de cota e dando a você controle total de segurança.

Anteriormente, o armazenamento de código gerenciado pela AWS padrão criava três desafios em escala. Primeiro, todas as cópias contam para sua cota de armazenamento de código de 75 GB. Segundo, você não pode aplicar sua própria criptografia, controles de acesso ou tags de conformidade ao bucket interno. Terceiro, a cópia não pode ser incorporada às suas estratégias de recuperação de desastres.

Com buckets S3 autogerenciados, o Lambda lê o código da sua função diretamente do seu bucket. Sem cópia, sem duplicação. Seu objeto S3 se torna a única fonte de verdade para suas funções. Os pacotes de implantação não contam mais para o limite de armazenamento de código da sua conta. Você gerencia a postura de segurança e conformidade do bucket: escolhendo a criptografia, definindo as políticas de acesso, gerenciando transições de ciclo de vida e mantendo a trilha de auditoria. E como você é o proprietário do bucket, pode usar a Replicação entre Regiões do S3 para manter cópias de fallback do seu código em uma Região secundária, para que suas funções permaneçam implantáveis mesmo se sua Região primária sofrer um problema. Usar buckets S3 autogerenciados também resulta em um tempo mais rápido para a primeira invocação de novas funções e após atualizações de função, porque o Lambda não precisa mais copiar seu pacote zip para um bucket S3 gerenciado pelo Lambda.

Você pode usar esse recurso hoje em todas as regiões padrão da AWS onde o Lambda está disponível, sem custo adicional além dos custos padrão de armazenamento e solicitação do Amazon S3. Vamos examinar alguns casos de uso, como funciona e como usá-lo em escala.

Casos de uso

Aqui estão alguns padrões onde possuir seu bucket de implantação faz uma diferença real.

Pipelines CI/CD e gerenciamento de artefatos

Com armazenamento autogerenciado, seu pipeline CI/CD faz upload uma vez, e o Lambda referencia o mesmo objeto. Um conjunto de regras de ciclo de vida e controles de acesso cobre todos os artefatos, e rollbacks significam apontar a função para uma versão anterior do objeto S3.

Arquiteturas multi-conta e multi-equipe

Organizações que usam AWS Organizations frequentemente separam cargas de trabalho em múltiplas contas: uma conta de desenvolvimento, uma conta de staging e uma conta de produção. Elas centralizam recursos compartilhados em uma conta de ferramentas ou serviços compartilhados.

Buckets autogerenciados se integram naturalmente com esse padrão:

Armazene todos os artefatos de implantação em um bucket de “conta de artefatos” central.
Conceda acesso s3:GetObject entre contas às funções de execução do Lambda em cada conta de carga de trabalho por meio de políticas de bucket.
Mantenha um inventário único de qual código está implantado onde, gerenciado por sua equipe de plataforma ou DevOps.
Imponha políticas consistentes de criptografia, versionamento e retenção de um único lugar.

Recuperação de desastres e continuidade de negócios

Como seus artefatos de implantação ficam em um bucket que você possui, você pode usar os recursos de replicação integrados do S3, Replicação entre Regiões (CRR) ou Replicação na Mesma Região (SRR), para manter cópias dos seus artefatos de código em locais de backup. Combinado com Versionamento S3 e Object Lock, isso fornece um arquivo de código durável e à prova de adulteração que suporta recuperação rápida se uma implantação for acidentalmente corrompida ou excluída.

Como funcionava antes

Quando você implanta uma função Lambda usando um pacote de implantação .zip armazenado no Amazon S3, o processo tradicionalmente funcionava assim:

Você faz upload do seu pacote de implantação .zip para seu bucket S3.
Você chama CreateFunction ou UpdateFunctionCode, especificando o bucket S3 e a chave S3.
O Lambda copia o artefato .zip do seu bucket para um bucket interno gerenciado pelo serviço.
O Lambda usa essa cópia para criar a versão otimizada da sua função que é executada no momento da invocação.
O artefato copiado conta para a cota de armazenamento de código de 75 GB da sua conta.

Diagrama mostrando o fluxo de implantação padrão do Lambda onde o Lambda copia o pacote zip para um bucket interno

Figura 1 — Implantação padrão do Lambda

Este modelo é direto e funciona bem para a maioria das cargas de trabalho. No entanto, cria três pontos de atrito em escala:

Pressão de cota de armazenamento: Cada cópia de pacote de implantação conta para o limite total de armazenamento de código de 75 GB da sua conta. Organizações com centenas de funções e múltiplas versões publicadas podem esgotar essa cota.
Sem controle sobre artefatos armazenados: Você não pode configurar criptografia (além do padrão do serviço), registro de acesso, políticas de ciclo de vida, Object Lock ou tags de conformidade no bucket interno.
Armazenamento redundante: Seu artefato original permanece no seu bucket enquanto uma cópia fica no bucket Lambda usado para provisionar novas instâncias da sua função Lambda.

O que há de novo: modo REFERENCE

Este lançamento introduziu uma nova configuração de função, S3ObjectStorageMode. O valor padrão é COPY, que fornece o comportamento existente descrito na seção anterior. Para habilitar buckets S3 autogerenciados, defina S3ObjectStorageMode como REFERENCE ao criar ou atualizar uma função. Neste modo, o Lambda não copia mais seu pacote de implantação. Em vez disso, ele armazena uma referência ao seu objeto S3 e lê o código diretamente do seu bucket quando necessário. Se você não especificar S3ObjectStorageMode, o Lambda ainda faz uma cópia por padrão.

Diagrama mostrando implantação do Lambda com armazenamento S3 autogerenciado onde o Lambda referencia o objeto diretamente

Figura 2 — Implantação do Lambda com armazenamento autogerenciado

Isso lhe dá:

Sem consumo de cota. Pacotes de implantação no seu bucket não contam para o limite de conta de armazenamento de função e camada de 75 GB.
Desempenho aprimorado. O Lambda não copia mais o código para um bucket interno, então a criação e atualizações de função são mais rápidas.
Controle total de segurança e conformidade. Aplique suas próprias políticas de bucket, criptografia, Object Lock, versionamento, registro de acesso e tags de conformidade.
Única fonte de verdade. Seu objeto S3 é o artefato canônico sem cópias adicionais e sem desvios.
Opções de recuperação de desastres. Use a Replicação entre Regiões do S3 para manter cópias de fallback em uma Região secundária.

Como funciona

Para usar esse recurso, especifique o parâmetro S3ObjectStorageMode ao criar ou atualizar sua função.

Criando uma nova função (AWS CLI):

aws lambda create-function \
  --function-name my-function \
  --runtime python3.13 \
  --role arn:aws:iam::123456789012:role/my-lambda-role \
  --handler app.handler \
  --code S3Bucket=amzn-s3-demo-bucket,S3Key=deployments/my-function.zip,S3ObjectVersion=abc123,S3ObjectStorageMode=REFERENCE

Atualizando uma função existente:

aws lambda update-function-code \
  --function-name my-function \
  --s3-bucket amzn-s3-demo-bucket \
  --s3-key deployments/my-function.zip \
  --s3-object-version def456 \
  --s3-object-storage-mode REFERENCE

Permissões do AWS Identity and Access Management necessárias para armazenamento de código autogerenciado

Permissões do AWS Identity and Access Management (IAM)

O Lambda precisa de permissão para ler o pacote de implantação do seu bucket. Você pode conceder acesso por meio de uma política de bucket S3.

Política de bucket S3

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "LambdaSelfManagedCodeAccess",
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": [
        "s3:GetObject",
        "s3:GetObjectVersion"
      ],
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/deployments/my-function.zip",
      "Condition": {
        "ArnLike": {
          "aws:SourceArn": "arn:aws:lambda:us-east-1:123456789012:function:my-function"
        }
      }
    }
  ]
}

Recomendamos incluir a chave de condição aws:SourceArn com escopo para o ARN da sua função específica para permitir acesso com privilégio mínimo. Observe que o Resource tem escopo para a chave S3 exata em vez de um prefixo curinga. Isso segue o privilégio mínimo e corresponde a como a condição aws:SourceArn bloqueia qual função pode acessar qual objeto.

Requisitos do bucket

Seu bucket S3 deve atender aos seguintes requisitos:

Versionamento (obrigatório). Você deve habilitar o versionamento S3 para garantir que o Lambda referencie um artefato específico e imutável e para proteger contra sobrescritas acidentais.
Criptografia. Os seguintes tipos de criptografia são suportados: SSE-S3, SSE-KMS (incluindo chaves KMS gerenciadas pelo cliente) e DSSE-KMS. Se você usar SSE-KMS, o principal do Lambda deve ter permissão kms:Decrypt na chave.
Object Lock. Suportado. Você pode aplicar Object Lock no modo Compliance ou Governance para evitar exclusão acidental de artefatos de implantação.
Registro de acesso. Você pode habilitar o registro de acesso do servidor S3 ou eventos de dados do AWS CloudTrail para auditar toda vez que o Lambda lê seu código.

O que acontece quando o objeto está indisponível

O Lambda acessa periodicamente o objeto de origem do seu bucket S3 para reotimizar o código da sua função. Você deve manter o acesso ao objeto de origem para que sua função permaneça ativa.

Se o Lambda perder acesso ao objeto de origem de uma função, a função transita para o estado Inativo. Para restaurar a função, restaure o acesso ao objeto de origem e depois atualize a função.

Considerações de desempenho

Funções Lambda com armazenamento de código autogerenciado se comportam da mesma forma que funções Lambda padrão com uma diferença durante a criação e atualização da função. O Lambda não copia seu pacote de implantação para um bucket S3 gerenciado pelo Lambda. Em nossos testes com uma função Python 3.13 de 200MB, funções usando armazenamento autogerenciado mostraram tempos de criação de função aproximadamente 5s menores do que o modo COPY padrão. Ler diretamente do seu bucket S3 sem uma etapa de cópia intermediária pode fornecer uma vantagem modesta, particularmente para pacotes de implantação maiores.

Começando com infraestrutura como código

O armazenamento de código autogerenciado pode ser implementado usando ferramentas de infraestrutura como código com a AWS CLI ou AWS CloudFormation hoje.

AWS CLI

aws lambda create-function \
  --function-name my-function \
  --runtime python3.13 \
  --role arn:aws:iam::123456789012:role/my-lambda-role \
  --handler app.handler \
  --code S3Bucket=amzn-s3-demo-bucket,S3Key=deployments/my-function.zip,S3ObjectVersion=abc123,S3ObjectStorageMode=REFERENCE \
  --region us-east-1

AWS CloudFormation

MyFunction:
  Type: AWS::Lambda::Function
  Properties:
    FunctionName: my-function
    Runtime: python3.13
    Handler: app.handler
    Role: !GetAtt MyLambdaRole.Arn
    Code:
      S3Bucket: amzn-s3-demo-bucket
      S3Key: deployments/my-function.zip
      S3ObjectVersion: abc123
      S3ObjectStorageMode: REFERENCE

Usando em escala

Depois de adotar buckets S3 autogerenciados para seus pacotes de implantação do Lambda, seu bucket de artefatos cresce ao longo do tempo conforme você implanta novas versões de suas funções. Esta seção cobre estratégias para gerenciar esse crescimento de forma eficiente, manter suas versões organizadas e planejar implantações entre Regiões.

Gerenciando o ciclo de vida de artefatos com políticas de ciclo de vida do S3

Toda vez que você atualiza o código de uma função, o S3 cria uma nova versão de objeto no seu bucket. Os objetos anteriores não desaparecem. Eles se acumulam. Sem uma estratégia de limpeza, seu armazenamento cresce indefinidamente e artefatos antigos desordenam seu bucket.

As políticas de ciclo de vida do S3 permitem que você automatize isso completamente. Você define regras que fazem a transição ou excluem objetos com base na idade, e o S3 as executa em seu nome: sem scripts, sem tarefas cron, sem intervenção manual.

Estratégia 1: Arquivar versões antigas no Glacier

Se requisitos de conformidade ou auditoria exigem que você retenha todos os pacotes de implantação históricos, mas você raramente precisa acessá-los, faça a transição de versões antigas de objetos para uma classe de armazenamento de menor custo:

{
  "Rules": [
    {
      "ID": "ArchiveOldDeploymentPackages",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "deployments/"
      },
      "NoncurrentVersionTransitions": [
        {
          "NoncurrentDays": 30,
          "StorageClass": "GLACIER_FLEXIBLE_RETRIEVAL"
        }
      ]
    }
  ]
}

Esta regra faz a transição de qualquer versão de objeto não atual para o S3 Glacier Flexible Retrieval após 30 dias. Seus pacotes de implantação ativos permanecem no S3 Standard para acesso rápido, enquanto versões históricas se movem para armazenamento de arquivamento a uma fração do custo.

Para artefatos que você precisa reter por anos, mas raramente acessará novamente, considere uma abordagem em camadas: movendo para Glacier Flexible Retrieval primeiro, depois para Deep Archive:

"NoncurrentVersionTransitions": [
  {
    "NoncurrentDays": 30,
    "StorageClass": "GLACIER_FLEXIBLE_RETRIEVAL"
  },
  {
    "NoncurrentDays": 365,
    "StorageClass": "DEEP_ARCHIVE"
  }
]

Estratégia 2: Excluir versões antigas que você não precisa mais

Se você não tem um requisito de conformidade para reter todos os artefatos históricos, pode expirar versões antigas completamente:

{
  "Rules": [
    {
      "ID": "DeleteOldDeploymentPackages",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "deployments/"
      },
      "NoncurrentVersionExpiration": {
        "NoncurrentDays": 14,
        "NewerNoncurrentVersions": 2
      }
    }
  ]
}

Esta regra mantém as 2 versões não atuais mais recentes de cada objeto (dando a você um caminho de rollback) e exclui qualquer coisa mais antiga que 14 dias além disso. Isso se alinha bem com uma estratégia de implantação onde você quer a capacidade de reverter rapidamente para suas uma ou duas versões anteriores, mas não precisa reter nada mais antigo.

Diagrama mostrando a relação entre versões de objeto S3 e versões de função Lambda

Rastreando versões de objeto e função

Com o modo REFERENCE, há uma relação direta entre sua versão de objeto S3 e sua versão de função Lambda. Recomendamos as seguintes práticas:

Marque seus objetos com metadados do seu pipeline CI/CD (SHA de commit, ID de build, ID de execução do pipeline) para que você possa rastrear qualquer função implantada de volta à fonte exata que a produziu.
Documente o mapeamento entre versões de função Lambda (ou aliases) e IDs de versão de objeto S3. Isso torna os rollbacks diretos: atualize a função para referenciar a versão anterior do objeto.

Considerações entre contas

Como você organiza seus buckets de artefatos entre contas AWS depende do seu modelo operacional:

Conta de artefatos centralizada: Um único bucket em uma conta de serviços compartilhados ou ferramentas, com políticas de bucket concedendo acesso s3:GetObject entre contas às funções de execução do Lambda em contas de carga de trabalho. Isso dá à sua equipe de plataforma um inventário único de todos os artefatos de implantação com políticas consistentes de ciclo de vida, criptografia e acesso.
Buckets por conta: Cada conta de carga de trabalho possui seu próprio bucket de artefatos. Requer menos esforço para configurar, mas mais difícil de impor governança consistente em muitas contas.

Qualquer padrão funciona com armazenamento autogerenciado. Escolha com base em como sua organização equilibra controle centralizado contra autonomia da equipe.

Considerações entre Regiões

Com o modo REFERENCE, seu objeto S3 é a cópia autoritativa para sua função. O armazenamento de código autogerenciado suporta criação de função entre Regiões dentro de uma partição para todas as Regiões padrão (Regiões sem opt-in). Você pode armazenar seus pacotes de código em uma Região e implantar suas funções em outra. Isso torna o planejamento entre Regiões crítico. Há quatro fatores a equilibrar:

Recuperação de desastres

Esta é a consideração mais crítica. Como seu objeto S3 é a única fonte de verdade no modo REFERENCE, você não quer todos os seus artefatos de implantação em uma única Região sem fallback. Um padrão recomendado:

Região primária: Seu bucket de artefatos principal onde os pipelines CI/CD depositam novos pacotes de implantação.
Região de fallback: Um bucket secundário populado via Replicação entre Regiões do S3 (CRR). Se sua Região primária ficar indisponível, você pode atualizar suas funções Lambda para referenciar os objetos replicados na Região de fallback.

Habilite o Controle de Tempo de Replicação do S3 (RTC) se você precisar de um SLA garantido (15 minutos) para conclusão da replicação.

Custo

Pese os custos de replicação + armazenamento contra a transferência de dados entre Regiões por implantação. Se você implanta com frequência, armazenar cópias replicadas em cada Região de destino geralmente é mais barato. Para implantações infrequentes, uma transferência única pode ser suficiente.

Governança e residência de dados

Algumas organizações, particularmente em indústrias regulamentadas, têm requisitos rigorosos sobre onde os artefatos de código podem residir. Antes de configurar a replicação entre Regiões, confirme que seus dados têm permissão para deixar sua Região atual. Certos frameworks regulatórios (por exemplo, leis de soberania de dados, limites FedRAMP) podem restringir a replicação a pares de Região específicos.

Desempenho

Se sua carga de trabalho requer tempos rápidos de criação e ativação de função, por exemplo, em um pipeline CI/CD onde a velocidade de implantação é crítica, mantenha seus objetos S3 na mesma Região onde você está criando suas funções Lambda. Leituras entre Regiões adicionam latência ao download inicial do código, o que impacta diretamente quão rapidamente uma nova versão de função se torna ativa após a implantação.

Para cargas de trabalho onde a velocidade de criação é menos crítica (por exemplo, funções de processamento em lote que são atualizadas com pouca frequência), a latência de uma leitura entre Regiões pode ser aceitável e pode simplificar sua arquitetura.

Coisas para saber

Antes de adotar buckets S3 autogerenciados para suas funções Lambda, tenha em mente o seguinte:

Disponibilidade: Você pode usar esse recurso hoje em todas as regiões padrão da AWS onde o Lambda é suportado.
Preços: Não há cobrança adicional do Lambda. Você paga custos padrão do S3 para armazenamento e qualquer transferência de dados entre Regiões.
Tamanho máximo do pacote de implantação: Os limites existentes se aplicam: 250 MB descompactado.
Runtimes suportados: Todos os runtimes do Lambda que suportam pacotes de implantação .zip são compatíveis. Implantações de imagem de contêiner não são afetadas por esse recurso.
Migração: Você pode mudar uma função existente de armazenamento gerenciado pelo serviço para armazenamento autogerenciado chamando UpdateFunctionCode com o parâmetro --s3-object-storage-mode REFERENCE. O Lambda recria a função referenciando o objeto no seu bucket S3 e exclui a cópia salva.
Reversão: Você pode voltar para o armazenamento gerenciado pelo serviço a qualquer momento atualizando a função com --s3-object-storage-mode COPY. O Lambda retoma a cópia do artefato para seu bucket interno.
A disponibilidade do objeto é sua responsabilidade: No modo REFERENCE, o Lambda depende de seu objeto S3 estar acessível. Se o objeto for excluído, a política do bucket mudar ou a chave KMS for desabilitada, novas invocações que requerem um cold start falharão.

Conclusão

Nesta publicação, mostramos como buckets S3 autogerenciados para Lambda lhe dão mais capacidade, mais controle e conformidade mais simples, tudo sem mudar como você escreve ou invoca suas funções. Seus pacotes de implantação não contam mais para cotas de conta, sua equipe de segurança pode aplicar as mesmas políticas a artefatos de código que aplicam em todos os outros lugares, e sua história de recuperação de desastres é tão forte quanto as capacidades de replicação do S3.

Para começar:

Leia o Guia do Desenvolvedor do Lambda: Armazenamento de código S3 autogerenciado para documentação completa.
Experimente no Console do AWS Lambda. Escolha Modo de Referência em Modo de armazenamento de código ao criar sua próxima função.
Revise os exemplos de configuração de ciclo de vida do S3 para planejar sua estratégia de retenção de artefatos.
Explore a Replicação entre Regiões do S3 para planejamento de recuperação de desastres.

Este conteúdo foi traduzido do post original do blog, que pode ser encontrado aqui.

Autor

	Doug Perkes é Sr. Solutions Architect na Amazon Web Services.
	Adam Gazaleh é Sr. Product Manager-Tech na Amazon Web Services.

Tradutores

Daniel Abib é Arquiteto de Soluções Sênior e Especialista em Amazon Bedrock na AWS, com mais de 25 anos trabalhando com gerenciamento de projetos, arquiteturas de soluções escaláveis, desenvolvimento de sistemas e CI/CD, microsserviços, arquitetura Serverless & Containers e especialização em Machine Learning. Ele trabalha apoiando Startups, ajudando-os em sua jornada para a nuvem.
https://www.linkedin.com/in/danielabib/

Nicolas Tarzia é Senior Technical Account Manager na AWS, com mais de 13 anos de experiência, com ampla experiência em arquitetura cloud, engenharia e design de software. Sua área de interesse são tecnologias serverless.
https://www.linkedin.com/in/nicolastarzia

O blog da AWS