メールでCloudFlowのフローをトリガー

公開済みのフローごとに専用メールアドレスを持てるようになりました。そのアドレスにメールを送るだけで、フローが実行されます。機能としてはそれだけです。

CloudFlowは、Cloud Intelligence™に組み込まれたFinOpsプラクティス自動化プラットフォームです。AWS、Google Cloud、Azure、Oracle、さらにはCloud Intelligence™のAPIを呼び出すフローを構築し、リソースのタグ付け、アラートへの対応、不要リソースの削除など、FinOpsやCloudOpsの作業を自動化できます。すべてのフローはトリガーから始まりますが、本日、新しいトリガーが加わりました。

これまでも、スケジュール、Webhook、Cloud Intelligenceのイベント(新しい異常検知、予算しきい値の到達など)からフローをトリガーできました。送信側のシステムがWebhookに対応していれば便利ですが、日々頼りにしているツールの多くは対応していません。レガシーな監視システム、チケット管理ツール、社内アプリ、誰も触りたがらないあのベンダーのダッシュボード——それらすべてに共通してできることといえば、メールを送ることです。これまでは、こうしたツールをCloudFlowにつなぐには、メールをHTTP呼び出しに変換するためだけに、ミドルウェアやサードパーティの自動化ツールを用意する必要がありました。

その手間はもう不要です。フローにメールトリガーを追加して公開するだけ。フローには [email protected] のような、推測不可能な一意のアドレスが割り当てられます。ツールのメール通知の宛先をこのアドレスに設定すれば、メールが届くたびにフローが実行され、送信者、件名、本文、添付ファイルのメタデータが、他のトリガーデータと同様に後続のノードで利用できます。メール本文がJSONの場合は自動的にパースされるため、機械が生成したメールは、自力で解析が必要なテキストではなく、構造化されたフィールドとして届きます。

特に効果を発揮する例を2つご紹介します。

アラート起点の修復。 データベース監視ツールがメールアラートしか送れない場合でも、その宛先をフローに向ければ、LLMノードで影響を受けたサービスを抽出し、深刻度を確認し、Jiraチケットを起票し、オンコールのSlackチャンネルにコンテキストを投稿できます——誰かが受信トレイを開くより先に、すべてが完了します。

機械生成メールへの対応。 ベンダーのシステムが毎晩JSONレポートをメールで送ってくる場合、フローがパース済みの本文を読み取り、数値に応じて分岐し、本当に対応が必要なときだけ担当者に通知します。

メールの送信者アドレスは偽装できるため、対策は推測不可能なアドレスだけにとどまりません。送信者を特定のアドレスやドメイン単位で制限できるほか、検証済み送信者チェックがデフォルトで有効になっており、送信者ドメインのSPF/DKIM認証に失敗したメールは即座に拒否されます。

実際の動作を確認するには、同時にリリースしたテンプレート「AWS Healthの定期メンテナンスをオーナーに通知」から始めてみてください。AWS Healthの通知をフローのアドレスに向けると、インスタンスのリタイアや定期再起動といったメンテナンスメールがすべて、インスタンスのオーナー 宛のSlackアラートに変わります。LLMノードが影響を受けるアカウント、リージョン、インスタンス、対応期限を抽出し、EC2のDescribeTags呼び出しで各インスタンスのオーナータグを特定し、誰が何を所有していて、対応までの猶予がどれだけあるかをメッセージで明示します。CloudFlowのテンプレートページで利用でき、チュートリアルでは各ノードを順を追って解説しています。

メールは、システム連携における最も基本的な共通言語です。そして時には、それこそが必要なものだったりします。メールでしか連携できないという理由でスタック内のツールが自動化の枠外に置かれてきたなら、これが突破口になります。詳細はドキュメントをご覧ください。