AWS Health Aware — personalize os alertas de saúde da AWS para contas organizacionais e pessoais da AWS

O que há de novo?

Temos o prazer de anunciar as seguintes duas atualizações no AHA —

1. As integrações do EventBridge já estão disponíveis! Explore o Github AHA para obter mais informações sobre a configuração.
2. Correções de bugs do Terraform para Secrets e S3 Single Region Deployment.

Benefícios da AHA

O AHA usa a API AWS Health, que só está disponível para clientes da AWS que têm um plano de suporte Business ou Enterprise.

Esses clientes podem aproveitar os seguintes recursos:

1. Integração com plataformas de comunicação como Slack, Amazon Chime, Microsoft Teams e Email para alertas automatizados e em tempo real dos incidentes da AWS.
2. Integração com o Amazon EventBridge, com capacidade de incluir alertas organizacionais e não organizacionais em um Event Bus. Isso ajuda os clientes a se integrarem com mais de 35 parceiros SaaS, como NewRelic/Datadog/PagerDuty etc.
3. Alertas agregados no Personal Health Dashboard – PHD, fornecidos pelo AWS Health.
4. Visibilidade das contas e dos recursos da AWS que são afetados pelos alertas no PHD.
5. Capacidade de filtrar alertas indesejados selecionando regiões específicas.

Escopo

Antes de começarmos a implantação, vamos analisar os recursos e a arquitetura da AHA para entender melhor como tudo funciona em conjunto. Na Figura 1, os eventos disponíveis da AWS Health API são descritos com base no fato de o cliente estar utilizando ou não o AWS Organizations.

Visão geral da arquitetura

Os diagramas abaixo apresentam a arquitetura da AHA que modela uma configuração serverless de uma ou múltiplas regiões.

Um usuário carrega um template do AWS CloudFormation (CFT) em uma conta da AWS. O CFT obtém a solução de um Amazon S3 Bucket. Em seguida, o CFT implanta Amazon IAM Roles,  scheduler do Amazon EventBridge, uma função AWS Lambda, URLs de webhook no AWS Secrets Manager e uma tabela do Amazon DynamoDB.

Região única

Essa arquitetura permite que os usuários implantem o AHA em uma determinada região da AWS.

Várias regiões

Com essa arquitetura, os usuários podem implantar o AHA em um modelo de região ativa/ativa. Isso centraliza a implantação do AHA em várias regiões para permanecer responsiva e evitar interrupções que possam ocorrer durante um evento da AWS.

Nesta tabela, listamos os recursos da arquitetura do AHA e sua finalidade.

Extensibilidade do EventBridge

O Amazon EventBridge facilita a conexão de aplicações ao fornecer um streaming de dados em tempo real de fontes personalizadas, da Amazon Web Services (AWS) e aplicações de Software as a Service (SaaS).
Em seguida, os dados podem ser enviados para vários destinos, como AWS Lambda, AWS Step Functions, Amazon Kinesis e muitos outros.
O Amazon EventBridge também permite que você conecte suas aplicações a uma variedade de parceiros SaaS sem precisar se preocupar em criar e manter uma infraestrutura personalizada. Os clientes estão usando esses recursos para melhorar a escalabilidade e a confiabilidade de suas aplicações, criando arquiteturas orientadas por eventos, em vez de um forte acoplamento de serviços.
À medida que mais clientes começarem a criar integrações de ponta a ponta com o EventBridge, o AHA gostaria de fornecer orientação aos clientes sobre a melhor maneira de começar com a variedade de diferentes possibilidades de fontes e tipos de eventos.
Esses casos de uso incluem:

1. Auditoria quase em tempo real e arquivamento de eventos históricos de operações comerciais.
2. Visualização e análise de eventos para fins operacionais e de inteligência de negócios.
3. Alertas e remediação automatizados de sistemas de aplicações, serviços de infraestrutura.
4. Conectando workflows personalizados com consumidores finais dos produtos e aplicações legadas ou on-premises.

A visualização mostrada na Figura 3 explica as opções de extensibilidade da AHA por meio das integrações do AWS EventBridge:

Figura 3

Pré-requisitos gerais

Configurando um endpoint

O AHA pode enviar para vários endpoints (URLs de webhook, e-mail ou EventBridge). Para usar qualquer um deles, você precisará configurá-lo com antecedência, pois alguns deles são feitos em sites de terceiros. Examinaremos alguns dos mais comuns aqui.

• Criação de um URL de webhook do Amazon Chime (permissões necessárias; acesso à sala do Amazon Chime, capacidade de gerenciar webhooks)
  1. Crie uma nova sala de chat para eventos (ou seja, aws_events)
  2. Na sala de chat criada no passo 1, no ícone de engrenagem e clique em gerenciar webhooks e bots
  3. Clique em Add webhook
  4. Digite um nome para o bot (ou seja, AHA) e clique em Create
  5. Clique em Copy URL, precisaremos dele para a implantação
• Criação de um URL de webhook do Slack (permissões necessárias; adicione um novo canal e aplicativo no Slack)
  1. Crie um novo canal para eventos (ou seja, aws_events)
  2. No seu navegador, acesse: workspace-name.slack.com/apps, onde workspace-name é o nome do seu Slack Workspace
  3. Na barra de pesquisa, pesquise por: Incoming Webhooks e clique nele
  4. Clique em Add to Slack
  5. No menu suspenso, clique no canal que você criou na etapa 1 e clique em Add Received Webhooks integration
  6. Nessa página, você pode alterar o nome do webhook (ou seja, AWS Bot), o ícone/emoji a ser usado etc.
  7. Para a implantação, precisaremos da URL do Webhook
• Criação de um URL de webhook do Microsoft Teams (permissões necessárias – adicione um novo canal e aplicativo no Microsoft Teams)
  1. Crie um novo canal para eventos (ou seja, aws_events)
  2. Dentro do seu Microsoft Teams, vá para Aplicativos
  3. Na barra de pesquisa, procure por: Incoming Webhook e clique nele
  4. Clique em Adicionar à equipe
  5. Digite o nome do seu no canal criado na etapa 1 e clique em Configurar um conector
  6. Nessa página, você pode alterar o nome do webhook (ou seja, AWS Bot), o ícone/emoji a ser usado, etc. Clique em Criar quando terminar
  7. Para a implantação, precisaremos da URL do webhook que é apresentada
• Configurando um e-mail
  1. Você poderá enviar alertas por e-mail para um ou vários endereços. No entanto, você deve primeiro verificar o(s) e-mail(s) no console do Simple Email Service (SES).
  2. O AHA utiliza o Amazon Simple Email Service (SES), então tudo o que você precisa é inserir um endereço To: e um endereço From:.
  3. Talvez seja necessário criar uma regra em seu ambiente para que os e-mails não sejam rotulados como spam pelo seu cliente de e-mail.
• Criação de um Amazon EventBridge — EventBus
  1. Abra o console Amazon EventBridge em https://console.thinkwithwp.com/events/
  2. No painel de navegação, escolha Event Buses.
  3. Escolha Create event bus
  4. Insira um nome para o novo Event Bus
  5. Escolha Create

Para obter mais informações, consulte a documentação.

Configuração

Etapas detalhadas de implantação estão disponíveis no Github do AHA.

Suporte e contribuições

A solução AWS Health Aware está disponível no repositório Github AWS Samples. Os criadores desta solução podem ajudar com dúvidas ou solicitações de recursos do AHA SOMENTE com base no BEST EFFORT.

Os clientes do Enterprise Support podem entrar em contato com seus TAMs em caso de dúvidas adicionais ou solicitações de recursos. Quaisquer contribuições para este projeto no Github são bem-vindas e podem ser solicitadas por meio de pull requests do Github!

Conclusão

Neste post, você aprendeu como a API de saúde da AWS pode ser usada para alertar os clientes com informações atualizadas sobre os eventos da AWS Health que os afetam. Você implantou uma infraestrutura serverless por meio do AWS CloudFormation que envia esses alertas para os seus canais de comunicação preferidos. Agora você deve ser capaz de monitorar e reagir de forma proativa aos eventos do AWS Health para suas contas pessoais e/ou da AWS Organizations. Para começar, visite o repositório aws-samples do Github e baixe o AWS Health Aware (AHA).