Acione fluxos do CloudFlow com um e-mail

Agora, todo fluxo publicado pode ter seu próprio endereço de e-mail. Envie um e-mail para ele, e o fluxo é executado. Simples assim.

O CloudFlow é a plataforma de automação da prática de FinOps integrada ao Cloud Intelligence™: você cria fluxos que chamam APIs da AWS, do Google Cloud, do Azure, da Oracle e até do próprio Cloud Intelligence™ para automatizar tarefas de FinOps e CloudOps — aplicar tags em recursos, responder a alertas, remover recursos obsoletos e muito mais. Todo fluxo começa com um gatilho, e hoje temos um novo.

Você já pode acionar um fluxo por agendamentos, webhooks e eventos do Cloud Intelligence (nova anomalia, limite de orçamento atingido etc.). Webhooks são ótimos quando o sistema de origem oferece suporte a eles. Mas muitas das ferramentas que você usa no dia a dia não oferecem. Sistemas de monitoramento legados, ferramentas de tickets, aplicativos internos, aquele dashboard de fornecedor em que ninguém quer mexer — o que todos eles conseguem fazer é enviar um e-mail. Até agora, conectar essas ferramentas ao CloudFlow significava montar um middleware ou usar uma ferramenta de automação de terceiros só para converter um e-mail em uma chamada HTTP.

Agora você pula essa etapa. Adicione um gatilho de e-mail ao seu fluxo e publique-o. O fluxo recebe um endereço único e impossível de adivinhar, como [email protected]. Aponte as notificações por e-mail da sua ferramenta para esse endereço, e cada mensagem recebida inicia uma execução — com remetente, assunto, corpo e metadados de anexos disponíveis para os nós seguintes, como qualquer outro dado de gatilho. Se o corpo do e-mail for JSON, nós fazemos o parsing para você: e-mails gerados automaticamente chegam como campos estruturados, e não como texto que você precisa destrinchar.

Dois exemplos em que isso cai como uma luva:

Remediação orientada por alertas. Sua ferramenta de monitoramento de banco de dados só envia alertas por e-mail. Aponte-os para um fluxo que extrai o serviço afetado com um nó de LLM, verifica a severidade, abre um ticket no Jira e publica o contexto no canal de plantão do Slack — antes mesmo de alguém abrir a caixa de entrada.

Ação sobre e-mails gerados automaticamente. Um sistema de fornecedor envia por e-mail um relatório JSON toda noite. Um fluxo lê o corpo já interpretado, ramifica a lógica de acordo com os números e só aciona um humano quando algo realmente exige atenção.

Como endereços de remetente podem ser falsificados, não paramos no endereço impossível de adivinhar. Você pode restringir os remetentes a endereços específicos ou a domínios inteiros, e a verificação de remetente vem ativada por padrão — e-mails que falham na autenticação SPF/DKIM do domínio do remetente são rejeitados de imediato.

Veja na prática começando pelo template que lançamos junto com o recurso: notificar os responsáveis sobre manutenções programadas do AWS Health. Aponte suas notificações do AWS Health para o endereço do fluxo, e cada e-mail de manutenção — desativação de instâncias, reinicializações programadas — vira um alerta no Slack para o responsável pela instância: um nó de LLM extrai a conta, a região, as instâncias afetadas e o prazo para agir, uma chamada EC2 DescribeTags localiza a tag de responsável de cada instância, e a mensagem informa quem é dono do quê e quanto tempo cada um tem para agir. Ele está na página de Templates no CloudFlow, e o tutorial explica cada nó em detalhes.

O e-mail é o menor denominador comum da integração entre sistemas. Às vezes, é exatamente disso que você precisa. Se alguma ferramenta do seu stack ficou de fora da sua automação porque só fala e-mail, essa é a porta de entrada — a documentação tem todos os detalhes.