Automatize a criação de casos de suporte da AWS usando os alarmes do Amazon CloudWatch e o Amazon Bedrock

É fundamental a rapidez com que o suporte da AWS é notificado quando algo dá errado no ambiente de produção. Portanto, ter um mecanismo para criar automaticamente um caso de suporte com base em um alarme do CloudWatch pode agilizar a atenção necessária do suporte da AWS. Ele permite que você concentre seus recursos em lidar com o impacto nos negócios simultaneamente, enquanto a equipe de suporte realiza verificações primárias no recurso relatado pelo alarme.

Exemplos de casos de uso

• Solução de um problema intermitente, em que você deseja notificar a AWS assim que o problema ocorrer novamente para solução de problemas ao vivo.
• Respondendo às verificações de saúde do Amazon Route 53 que você estabelece para monitorar a integridade do aplicativo.
• Automatizando a solicitação de aumento do limite de serviço. Você pode criar um alarme do CloudWatch para notificá-lo quando estiver próximo de um limite de valor de cota.

Visão geral da solução

Essa solução é implantada como uma stack do AWS CloudFormation, que cria os seguintes recursos em sua conta da AWS:

1. Um tópico do Amazon Simple Notification Service (Amazon SNS) que pode ser usado como uma ação para que o alarme do CloudWatch acione a função AWS Lambda.
2. Uma função do AWS Lambda que contém código Python.
3. Uma tabela do Amazon DynamoDB usada para registrar os casos de suporte gerados por esse fluxo de trabalho para futuras verificações de status.
4. Um tópico do SNS para receber notificações sobre as atividades do AWS Support processadas pelo fluxo de trabalho.
5. Uma função de execução do Lambda usada pela função Lambda com todas as permissões necessárias para executar as tarefas da solução.

Figura 1: Arquitetura em alto nível para a solução

Pré-requisitos

Os seguintes pré-requisitos são necessários:

• Uma conta da AWS.
• É necessário um usuário com permissões do IAM para criar tabelas no Amazon DynamoDB, a camada do AWS Lambda, a função do AWS Lambda, a função de execução do AWS Lambda e o tópico do Amazon SNS.
• A conta da AWS deve estar inscrita no Business Support, Enterprise On-Ramp ou Enterprise Support para acessar a API do AWS Support.
• Acesso ao modelo de linguagem grande (LLM) Claude 2 da Anthropic in Bedrock.

A solução funciona da seguinte forma:

1. Um tópico do SNS é adicionado à ação de alarme do CloudWatch.
2. Se a ação de alarme for acionada, o tópico do SNS enviará um objeto JSON contendo detalhes sobre a alteração do estado do alarme para a função Lambda assinada (2).
3. A função Lambda é executada e executa as seguintes etapas:
4. 1. 1. Analisando os detalhes da alteração do estado do alarme, a função extrai o namespace de informações, metric_name, new_state_reason, alarm_arn e dimensões.
      2. Verificando a tabela do DynamoDB em busca de casos relacionados ao mesmo alarm_arn. Se existir um caso de suporte não resolvido para o mesmo alarme, a função envia uma notificação aos assinantes do Amazon SNS e inclui a atualização mais recente do caso de suporte. Caso contrário, ele prossegue para a próxima etapa e cria um novo caso de suporte. Essa etapa é essencial para evitar que alarmes ruidosos gerem casos duplicados.
      3. Realizando a classificação de incidentes. A API do AWS Support exige variáveis ServiceCode, CategoryCode e SeverityCode, que podem variar dependendo do incidente. Para classificar o incidente adequadamente, a função aproveita o modelo Anthropic Claude v2 via Bedrock para realizar uma pesquisa semântica baseada em IA. O Bedrock determina os valores de ServiceCode e CategoryCode com base nos dados analisados do evento de alarme. Posteriormente, na Etapa 5, discutiremos como o SeverityCode é determinado.
      4. Extraindo tags de recursos de alarme. O Lambda extrai as tags de alarme e as utiliza como contexto adicional nos detalhes do caso de suporte. Isso ajuda o AWS Support a entender melhor como fornecer a assistência necessária.
      5. Criação do caso de suporte usando os valores de classificação de incidentes retornados do Bedrock combinados com as tags do alarme definidas pelo usuário.
      6. Registrando o novo caso de suporte na tabela do DynamoDB para referência futura.
      7. Enviar uma notificação para todos os endpoints inscritos em um tópico do SNS.

Figura 2: Um caso de suporte criado usando o alarme do CloudWatch para solicitar o aumento do limite da VPC quando o uso da VPC atingiu mais de 75% da cota disponível.

Considerações sobre o uso na produção

Leve em consideração as seguintes considerações ao usar na produção:

Uso na produção: essa solução não pretende ser o único meio de geração de relatórios de incidentes. Use-o em conjunto com seus processos existentes de gerenciamento de incidentes, relatórios e notificação.

Criptografia: a melhor prática é usar a criptografia em qualquer lugar. No código de exemplo fornecido com esta postagem, os tópicos do SNS não estão criptografados. Ao usar essa solução na produção, criptografe esses recursos usando o AWS Key Management Service (AWS KMS).

Retenção de registros: o código de amostra fornecido com esta publicação tem um período de retenção codificado do Amazon CloudWatch Logs de 30 dias. É recomendável considerar as políticas de retenção de armazenamento de dados da sua organização ao usá-lo na produção.

Detalhes do caso de suporte: o código de amostra fornecido combina os valores da chave do evento de alarme e as tags de recursos do alarme do CloudWatch para fornecer mais contexto sobre a situação. Adicionar tags como SeverityCode, OwnerEmail, Details, ApplicationName, CallBack e qualquer informação adicional compartilhável ajudará o AWS Support a entender melhor o impacto desse evento.

Métricas personalizadas: o código de amostra também oferece suporte às métricas personalizadas do CloudWatch. Para receber recomendações sobre classificação de incidentes, o Bedrock exige o namespace, metric_name e os parâmetros de detalhes da métrica do CloudWatch. É essencial que esses valores sejam descritivos para correlacionar o incidente com a equipe de suporte de serviço relevante. Você pode escolher um valor de namespace na lista de serviços da AWS que publicam métricas do CloudWatch.

Passo a passo

Etapa 1: implantar a solução usando o console do CloudFormation

Siga as etapas abaixo para implantar o modelo YAML do CloudFormation.

1. Clone o repositório Git ou baixe o arquivo YAML para seu diretório local.
2. No console do AWS CloudFormation, escolha Create a stack.
3. Em Pré-requisito — Preparar modelo, selecione Template is ready. Em Specify template, selecione Upload a template file. Escolha Escolher arquivo e navegue até o local do arquivo YAML em sua máquina, selecione o arquivo YAML e escolha Abrir.
4. Escolha Avançar.

Figura 3: Etapa 1: Visualização do console de seleção de arquivos YAML da pilha do CloudFormation

5. Na página Criar stack, insira o nome da stack.

6. Em Parâmetros, insira cada um dos seguintes:

• • BedrockRegionalEndpoint — no momento de escrita deste blog, o Bedrock tinha 5 endpoints regionais de API. Para selecionar entre os endpoints de API padrão disponíveis, acesse este link. A solução utiliza endpoints padrão e não endpoints FIPS. O endpoint regional da API deve estar na seguinte sintaxe, incluindo o protocolo HTTPS:
    protocol: //bedrock-runtime.region-code.amazonaws.com
  • BedrockRegion — insira o código da região com base no BedrockRegionalEndpoint selecionado na etapa anterior.

Figura 4: Exibição do console de requisitos de parâmetros da stack do CloudFormation, página 2

7. Selecione os padrões para o resto das páginas e escolha Avançar.

8. Na página Revisar, confirme e selecione o aviso de Capacidades. Escolha Create Stack para continuar.