Gerenciamento centralizado das camadas do AWS Lambda em várias contas da AWS

Esta publicação foi escrita por Debasis Rath, especialista sênior em SA-Serverless, Kanwar Bajwa, líder de enterprise suporte, Xiaoxue Xu, arquiteto de soluções (FSI) e adaptado para Português por Daniel ABIB, arquiteto sênior de soluções para Entreprise.

Clientes corporativos geralmente gerenciam um inventário de camadas (layers) do AWS Lambda, que fornecem código e bibliotecas compartilhados para outras funções do Lambda. Essas camadas do Lambda são compartilhadas entre contas da AWS e organizações da AWS para promover a uniformidade, a reutilização e a eficiência do código. No entanto, à medida que as empresas se expandem na utilização de serviços da AWS, é importante gerenciar camadas compartilhadas (layers) do Lambda para um número crescente de funções e contas com automação.

Este blog post centraliza o gerenciamento das camadas Lambda para garantir a conformidade com os padrões de governança da sua empresa e promove a consistência em toda a sua infraestrutura. Esse gerenciamento centralizado usa uma abordagem de configuração como um “detetive” para identificar funções Lambda não compatíveis usando versões desatualizadas da camada Lambda e medidas corretivas para remediar essas funções do Lambda, atualizando-as com a versão correta da camada.

Essa solução usa serviços da AWS, como AWS Config, Amazon EventBridge Scheduler, AWS Systems Manager (SSM) Automation e AWS CloudFormation StackSets.

Visão geral da solução

Essa solução oferece duas partes para o gerenciamento de camadas:

1. Visibilidade sob demanda de funções Lambda desatualizadas.
2. Remediação automatizada das funções afetadas do Lambda.

Essa é a arquitetura da primeira parte. Usuários com as permissões necessárias podem usar as consultas avançadas do AWS Config para obter uma lista de funções Lambda desatualizadas.

O estado de configuração atual de qualquer função do Lambda é capturado pelo gravador de configuração. Esses dados são então agregados pelo AWS Config Aggregator na conta de gerenciamento. Os dados agregados podem ser acessados usando consultas.

Este diagrama mostra a arquitetura da segunda parte. Os administradores da conta da AWS devem implantar manualmente os CloudFormation StackSets para iniciar a correção automática de funções Lambda desatualizadas.

O gatilho de remediação manual é usado ao invés de uma solução totalmente automatizada. Os administradores programam esse gatilho manual como parte de uma solicitação de alteração para minimizar as interrupções nos negócios. Todas as partes interessadas da empresa que possuem as funções afetadas do Lambda devem receber essa notificação e ter tempo suficiente para realizar testes unitários para avaliar o impacto.

Ao receber a confirmação das partes interessadas da empresa, o administrador implanta os CloudFormation StackSets, que, por sua vez, implantam a pilha do CloudFormation na conta membro designada e na região. Após a implantação da pilha do CloudFormation, o processo de agendamento do EventBridge invoca uma avaliação de regra personalizada do AWS Config. Essa regra identifica as funções Lambda não compatíveis e, posteriormente, as atualiza usando runbooks de automação SSM.

O passo a passo a seguir implanta a arquitetura em duas partes, usando uma abordagem centralizada para o gerenciamento de camadas, como no diagrama anterior. Uma abordagem descentralizada distribui o gerenciamento e as atualizações das camadas do Lambda pelas contas, tornando a fiscalização mais difícil e propensa a erros.

Essa solução também está disponível no GitHub.

Pré- requisitos

Para o passo a passo da solução, você deve ter os seguintes pré-requisitos:

• CloudFormation StackSets habilitados para suas organizações da AWS. Consulte a documentação para habilitar o AWS CloudFormation StackSets no nível organizacional.
• O AWS Config está habilitado para suas organizações da AWS. Consulte a documentação fornecida para habilitar o AWS Config no nível organizacional.
• Um AWS Config Aggregator configurado para coletar dados de configuração registrados de todas as contas em todas as regiões da AWS dentro de suas organizações da AWS. Consulte a documentação fornecida para criar um agregador.
• As permissões necessárias para implantar o CloudFormation StackSets e consultar o AWS Config.
• AWS CloudShell para executar scripts com a AWS Command Line Interface (CLI).

Escrevendo uma consulta sob demanda (on-demand query) para funções Lambda desatualizadas

Primeiro, você escreve e executa uma consulta avançada do AWS Config para identificar as contas e regiões onde residem as funções desatualizadas do Lambda. Isso é útil para que os usuários finais determinem o escopo do impacto e identifiquem os grupos responsáveis a serem informados com base nos recursos do Lambda afetados.

Siga esses procedimentos para entender o escopo do impacto usando o AWS CLI:

1. Abra o CloudShell na sua conta da AWS.
2. Execute o seguinte comando da AWS CLI. Substitua YOUR_AGGREGATOR_NAME pelo nome do seu agregador do AWS Config e YOUR_LAYER_ARN pelo Amazon Resource Name (ARN) desatualizado da camada Lambda.

aws configservice select-aggregate-resource-config \
--expression "SELECT accountId, awsRegion, configuration.functionName, configuration.version WHERE resourceType = 'AWS::Lambda::Function' AND configuration.layers.arn = 'YOUR_LAYER_ARN'" \
--configuration-aggregator-name 'YOUR_AGGREGATOR_NAME' \
--query "Results" \
--output json | \
jq -r '.[] | fromjson | [.accountId, .awsRegion, .configuration.functionName, .configuration.version] | @csv' > output.csv

3. Os resultados são salvos em um arquivo CSV chamado output.csv no diretório de trabalho atual. Esse arquivo contém os IDs de conta, regiões, nomes e versões das funções do Lambda que estão usando atualmente o ARN da camada Lambda especificada. Consulte a documentação sobre como baixar um arquivo do AWS CloudShell.

Para explorar mais dados de configuração e melhorar ainda mais a visualização usando serviços como Amazon Athena e Amazon QuickSight, consulte Visualização de dados do AWS Config usando o Amazon Athena e o Amazon QuickSight.

Implantação de remediação automática para atualizar funções Lambda desatualizadas

Em seguida, você implanta o CloudFormation StackSets de remediação automática nas contas e regiões afetadas onde residem as funções Lambda desatualizadas. Você pode usar a consulta descrita na seção anterior para obter os IDs da conta e as regiões.

A atualização das camadas (layers) do Lambda pode afetar a funcionalidade das funções existentes do Lambda. É essencial notificar os grupos de desenvolvimento afetados e coordenar os testes unitários para evitar interrupções não intencionais antes da remediação.

Para criar e implantar o CloudFormation StackSets a partir da sua conta de gerenciamento para remediação automática:

1. Execute o seguinte comando no CloudShell para clonar o repositório do GitHub:

git clone https://github.com/aws-samples/lambda-layer-management.git

1. Run the following CLI command to upload your template and create the stack set container.

   aws cloudformation create-stack-set \
     --stack-set-name layers-remediation-stackset \
     --template-body file://lambda-layer-management/layer_manager.yaml
   

   Bash
2. Execute o seguinte comando da CLI para carregar seu modelo e criar o contêiner do conjunto de pilhas.

   aws cloudformation create-stack-instances \
   --stack-set-name layers-remediation-stackset \
   --accounts <LIST_OF_ACCOUNTS> \
   --regions <YOUR_REGIONS> \
   --parameter-overrides ParameterKey=NewLayerArn,ParameterValue='<NEW_LAYER_ARN>' ParameterKey=OldLayerArn,ParameterValue='=<OLD_LAYER_ARN>'
   

   Bash
3. Execute o seguinte comando da CLI para adicionar instâncias de pilha nas contas e regiões desejadas aos seus CloudFormation StackSets. Substitua as IDs da conta, as regiões e os parâmetros antes de executar esse comando. Você pode consultar a sintaxe na Referência de Comandos da AWS CLI. “NewLayerArn” é o ARN da sua camada Lambda atualizada, enquanto “OldLayerArn” é o ARN original da camada Lambda.

   aws cloudformation describe-stack-set-operation \
     --stack-set-name layers-remediation-stackset \
     --operation-id <OPERATION_ID>

   Bash

4. Execute o seguinte comando da CLI para verificar se as instâncias da pilha foram criadas com êxito. O ID da operação é retornado como parte da saída da etapa

aws cloudformation describe-stack-set-operation \
  --stack-set-name layers-remediation-stackset \
  --operation-id <OPERATION_ID>

Outras considerações

A remediação fornecida pelo CloudFormation StackSet usa a API UpdateFunctionConfiguration para modificar diretamente as configurações de suas funções do Lambda. Esse método de atualização pode fazer com que você se desvie do serviço original de infraestrutura como código (IaC), como a pilha do CloudFormation que você usou para provisionar as funções Lambda desatualizadas. Nesse caso, talvez seja necessário adicionar uma etapa adicional para resolver o desvio do serviço IaC original.

Como alternativa, talvez você queira atualizar seu código IaC diretamente, referenciando a versão mais recente da camada Lambda, em vez de implantar o CloudFormation StackSet de remediação, conforme descrito na seção anterior.

Limpando

Consulte a documentação para obter instruções sobre como excluir todas as instâncias de pilha criadas da sua conta. Depois, exclua o CloudFormation StackSet.

Conclusão

Gerenciar camadas do Lambda em várias contas e regiões pode ser um desafio em grande escala. Usando uma combinação do AWS Config, do EventBridge Scheduler, do AWS Systems Manager (SSM) Automation e do CloudFormation StackSets, é possível simplificar o processo.

O exemplo fornece visibilidade sob demanda das funções afetadas do Lambda e permite a correção programada das funções afetadas. A automação do AWS SSM simplifica ainda mais as tarefas de manutenção, implantação e remediação. Com essa arquitetura, você pode gerenciar com eficiência as atualizações de suas camadas do Lambda e garantir a conformidade com as políticas da sua organização, economizando tempo e reduzindo erros em seus aplicativos Serverless.

Para saber mais sobre o uso da camada Lambda, acesse a documentação da AWS. Para obter mais recursos de aprendizado sem servidor, visite Serverless Land.

Sobre o autor

Debasis Rath é Sr. Specialist SA-Serverless

Tradutor