Amazon Web Services ブログ

タグベースフィルタリングを利用した大規模な AWS Health モニタリングおよびアラートの管理

AWS は、お客様のルートアカウントの所有者もしくは運用、セキュリティ、請求の連絡先へ、サービス通知や計画されているアクティビティに関する定期的な更新を電子メールで提供します。AWS はまた、AWS Health を通じて粒度の高い通知もお客様に提供し、お客様に直接関係のある問題についてのアラートを微調整できるようにしています。ヘルスダッシュボードのモニタリング機能に加え、お客様はその基盤となっている API 、つまり AWS Health API の恩恵を受けることも可能です。AWS Health API を使うことにより、お客様はリソースに影響のあるすべての通知を収集し、それらの通知をお客様固有のビジネスニーズに合うようにカスタマイズすることができます。実際に使用されている AWS Health API の例としては AWS Health Aware フレームワークがあります。それにより、お客様は通知を収集し、それを電子メール、Slack、Amazon EventBridge などの複数のコミュニケーションチャネルに送信することができます。

AWS のお客様は多くの場合、Organization (AWS Organizations の組織) 全体で複数のアカウントをお持ちです。これらのアカウントはそれぞれ AWS Health イベントに基づいてアラートを生成する場合があり、お客様が Organization を数百アカウントに拡大するにつれて、それらのアラートを適切なチームに大規模にリダイレクトすることが重要になってきます。

このブログでは、AWS Health を使用して AWS インフラストラクチャのヘルスイベントに関するアラートを生成するフレームワークに関するガイダンスを提供します。そして、適切なタグ付け戦略を使用して既存のワークフローに合うように通知を微調整することで、リソースを特定しアラートを適切な担当部署に送信することができるようにします。同様のフレームワークは現在 Zoom Video Communications 社でも稼働中で、Yasin Mohammed 氏 (クラウド運用担当マネージャー) は「AWS リソースにタグベースのフィルタリングを使って AWS Health 通知を自動的に通知するメカニズムを設定することにより、複数のアカウントやリージョンにわたって Zoom のヘルスモニタリングとアラートのメカニズムを合理化することができました」と話しています。

前提条件

  1. お客様が AWS Health API を最大限に活用するには、まずビジネスサポートもしくはエンタープライズサポートに登録されていることを確認する必要があります。それらが有効になると、お客様は AWS Health API をクエリするコードを記述して AWS Health アラートをカスタマイズできるようになります。organization 全体にこのソリューションをデプロイして AWS Health アラートを収集したいお客様は、AWS Health Aware フレームワークを使用することができます。これは、それらのアラートを EventBridge や SNS、電子メールなどと統合できる無料かつオープンソースのフレームワークです。
  2. Amazon Elastic Compute Cloud (EC2)Amazon EventBridgeAWS Lambda の IAM 権限に関する中級レベルの理解
  3. Amazon EC2 および Amazon EventBridge の API に関する中級レベルの理解

ソリューションアーキテクチャ

多くのエンタープライズのお客様に当てはまるシナリオは、さまざまなビジネスユニットに多くのアカウントがあり、それらがさまざまな運用チームや開発チームによって管理されているような場合です。これらのチームは、データベースやセキュリティなど、特定の専門分野や責任範囲があるため、複数のアカウントにわたり特定のリソースに準じて編成されることもあります。たとえば、一部のリソースに予定されている変更をアカウントレベルで運用チームに通知する必要がある場合や、特定のデータベースに関する通知がある際にデータベース管理者にアラートを送る必要がある場合もあります。

そのようなシナリオにおいては、AWS リソースをタグ付けするためのベストプラクティスにあるように AWS リソースにタグを付けることが重要です。いったんリソースにタグを付ければ、タグ情報に基づいて AWS Health アラートを送ることができます。AWS Health イベントは生成されると EventBridge に送られます。Amazon EventBridge では、関連する AWS リソースからタグ情報を取得することでアラートを微調整できる Lambda 関数を、トリガするように EventBridge ルールを設定することができます。リソース環境やチーム名などを追加するといった AWS Health イベントの強化も Lambda 関数を使用することにより可能です。専用のカスタムイベントバスを作成して別々のグループ/チームに通知することもできます。Lambda 関数は強化された AWS Health イベントをカスタムイベントバスに送り、そのカスタムイベントバスではメッセージを Amazon SNS に配信して適切なユーザー/アプリケーションに通知します。ここで、AWS Health はベストエフォートベースでイベントを配信することに注意してください。イベントは EventBridge に配信されることが常に保証されているわけではありません。このフレームワークは AWS Health Aware もサポートしているため、このアラートフレームワークを organization 全体にデプロイし、適切なチームが自分たちの担当するリソースについてのアラートを各自が希望する通知方法でタイムリーに受けるようにすることができます。

The figure shows architecture diagram for solution framework with health events filtered, enriched and directed using AWS Lambda

図 1: ソリューションアーキテクチャ

ユースケース例

この例では、DEV 環境の EC2 インスタンスにアラートを設定します。EC2 インスタンスの環境情報は environment タグを使って取得します。また、customEventBus タグを使用して専用のイベントバスを指定します。この専用のカスタムイベントバスは SNS トピックを使用して DEV 環境管理者に通知を行います。

Figure shows EC2 instance with AWS Tags as custom event bus, environment and name

図 2: EC2 インスタンスのタグ

EC2 インスタンスへのタグ付けに加えて、AWS アカウントAmazon RDS リソースなどのほぼすべての AWS リソースにタグを付けることができます。AWS Organizations を使用している場合には、AWS リソースにタグポリシーを強制してチームが運用上のベストプラクティスに従うようにすることができます。

EC2 インスタンスにタグが付けられると、EventBridge を使ってそのインスタンスに対する AWS Health イベントを受信します。EventBridge ルールによりトリガされる Lambda 関数をデプロイして、AWS Health イベントの JSON ペイロードを検査し、EC2 環境情報を使って AWS Health イベントペイロードを強化し、カスタムイベントバスにアラートをリダイレクトします。専用のカスタムイベントバスは SNS を使ってアラートを適切なチャネルに配信します。

ユースケースのウォークスルー

ステップ 1: インフラストラクチャチームにアラートを送信する SNS トピックを作成する

  1. Amazon SNS コンソールに移動します。
  2. 左側のパネルから [トピック] を選択し、右側のパネルから [トピックの作成] を選択します。
  3. [トピックの作成] ページの [タイプ] で [スタンダード] を選択し、[名前] に “health-alerts” のような名前を入力します。
  4. 残りの設定はそのままにして、[トピックの作成] を選択します。
  5. 電子メールでサブスクリプションの作成を行い、メールボックスの電子メール確認でそれを確認します。

ステップ 2: インフラストラクチャチーム専用のカスタムイベントバスを作成する

  1. Amazon EventBridge コンソールに移動します。
  2. 左側のパネルから [イベントバス] を選択し、右側のパネルから [イベントバスを作成] を選択します。
  3. [名前] に “health-events” のような名前を入力し、[作成] を選択します。

ステップ 3: 必要なサービスへの読み書きを行うための Lambda 関数用の実行ロールを作成する

  1. IAM コンソールに移動し、左側のパネルから [ポリシー] を選択します。
  2. 右側のパネルから、[ポリシーの作成] を選択します。
  3. ユースケースに基づいて Lambda がお客様の代わりにサービスを呼び出すために必要となる権限を追加します。この例では、基本的な Lambda 実行ポリシー (AWSLambdaBasicExecutionRole) に加えて、対象となる EventBridge にイベントを送信し EC2 のタグを読み取る必要があります。各サービスの IAM ドキュメントを参照して、このポリシーをニーズに合わせてカスタマイズしてください。
  4. 権限の追加が完了したら [次へ] を選択します。
  5. ポリシーに “EnrichHealthEventsPolicy” のような名前を付けて、オプションで [説明] に説明を入力します。
  6. [ポリシーの作成] を選択します。

IAM ポリシーを設定したら、ポリシーから Lambda 実行ロールを作成します。

  1. IAM コンソールに移動し、左側のパネルから [ロール] を選択します。
  2. 右側のパネルから [ロールを作成] を選択します。
  3. [AWS のサービス] を選択します。ユースケースでは [Lambda] を選択し、[次へ] を選択します。
  4. 先ほど作成した “EnrichHealthEventsPolicy” を選択し、[次へ] を選択します。
  5. ロールに “EnrichHealthEventsLambdaRole” のような名前を付けて、[ロールを作成] を選択します。

ステップ 4: Lambda 関数を追加して EC2 タグを取得し、AWS Health イベントを強化する

  1. Lambda コンソールに移動します。
  2. 右側のパネルから [関数の作成] を選択し、[一から作成] を選択します。
  3. 関数に “EnrichHealthEvents” のような名前を与えます。
  4. ランタイムを選択します (この例では、Python を使用します)。
  5. [デフォルトの実行ロールの変更] を選択し、ステップ 3 で作成した実行ロールを選択します。
  6. [関数の作成] を選択します (これで簡単な “hello world” 関数が作成され、次のステップに進むために保存しておくことができます)。
  7. [Deploy] を選択します。
  8. 後から、必要に応じて Lambda 関数を強化、反復、カスタマイズ、テストすることができます。

EC2 インスタンスの AWS_EC2_MAINTENANCE_SCHEDULED に対するテストの AWS Health Event の構造は以下の通りです:

Figure shows event schema for health event AWS_EC2_MAINTENANCE_SCHEDULED

図 3: AWS Health Event スキーマ

Python で Lambda 関数をコーディングする際の Tips:

  1. 図 3 を参照すると、以下のコードスニペット (python) を使用して affectedEntities を参照することで EC2 インスタンスのインスタンス ID を取得できます:
    ec2InstanceId= event['detail']['affectedEntities'][0]['entityValue']
  2. 影響を受けた EC2 インスタンスに関連付けられている environmentcustomEventBus のタグを取得します。これを行うために、EC2 インスタンス ID で インスタンスをフィルタリングし、タグキーをループ処理してタグ値を取得します。
  3. イベントは environment フィールドを追加するだけで強化されます:
    event['environment'] = environment
  4. 最後に、put_events API コールを使用してステップ 2 で作成したカスタムイベントバスに強化したイベントを送信します:
cloudwatch_events = boto3.client('events')
response = cloudwatch_events.put_events(
  Entries=[
            {
             'Source': 'modifiedHealthEvent',
             'EventBusName': eventBusName,
             'DetailType': 'enrichedEvent',
             'Detail': json.dumps(event)
            }
        ]
)

ステップ 5: EventBridge ルールを作成してイベントをカスタムイベントバスから SNS へ送信する

  1. EventBridge コンソールに移動します。
  2. 右側のパネルから、[使用を開始する] で [イベントブリッジルール] を選択し、[ルールを作成] を選択します。
  3. [ルールの詳細] ページで、[名前] にルールの名前 (例: “send-enriched-events”) を入力し、[イベントバス] でステップ 2 で作成したイベントバス (例:“health-events”) を選択して [次へ] を選択します。
  4. [イベントパターンを構築] ページで [イベントソース] の [イベントソース] で [すべてのイベント] を選択します。他のオプションはすべてそのままにして、[次へ] を選択します。
  5. [ターゲットを選択] ページにおいて、[AWS のサービス] を選択します。[ターゲットを選択] ではステップ 1 で作成した SNS トピック (例:“health-alerts”) を選択します。[次へ] を選択します。
  6. [タグを設定] ページはデフォルトのままにし、[次へ] を選択します。
  7. [レビューと作成] ページで [ルールの作成] を選択します。

ステップ 6: AWS Health イベントを Lambda 関数に送信する EventBridge ルールを作成する

  1. EventBridge コンソールに移動します。右側のパネルから、[使用を開始する] で [イベントブリッジルール] を選択し、[ルールを作成] を選択します。
  2. [ルールの詳細] ページで、[名前] にルールの名前 (例: “health-events-rule”) を入力し、[イベントバス] で default を選択します。[次へ] を選択します。
  3. [イベントパターンを構築] ページで [作成のメソッド] まで移動し、[パターンフォームを使用する] を選択します。
  4. [イベントパターン] の [イベントソース] で [AWS のサービス] を選択し、[AWS のサービス] では [Health] を選択します。イベントタイプについては [特定のヘルスイベント] を選択します。[特定のサービス] で [EC2] を選択します。[次へ] を選択します。
Figure shows event pattern for filtering an EC2 health event in EventBridge

図 4: EC2 ヘルスイベントをフィルタリングするためのイベントパターン

  1. [ターゲットを選択] ページにおいて、[AWS のサービス] を選択します。[ターゲットを選択] では [Lambda 関数] を選択します。[関数] でステップ 4 で作成した Lambda 関数 (例:“EnrichHealthEvents”) を指定します。[次へ] を選択します。
  2. [タグを設定] ページはデフォルトのままにし、[次へ] を選択します。
  3. [レビューと作成] ページで [ルールの作成] を選択します。

ソリューションのテスト

ソリューションをテストするには、Lambda のテスト機能の使用を検討してください。

  1. Lambda コンソールに移動し、ステップ 4 で作成した Lambda 関数を選択します。
  2. [テスト] タブに移動し、図 3 のイベント構造を変更して [新しいイベントを作成] を行います。
  3. [コード] に移動し、[Test] ドロップダウンで作成したテストイベントを選択します。[Test] を選択します。

これによりテストヘルスイベントがトリガーされ、ステップ 1 で設定したメールアドレスに通知が届くはずです。

これでこの例で提供されているウォークスルーをお客様のビジネスニーズに合わせて変更できるようになりました。リソースとタグに応じて、ご利用の環境でソリューションをテストしてみてください。

まとめ

このブログ記事では、AWS リソースに関連するタグを割り当ててアラート通知を自動化し、通知ノイズを減らしながら AWS Health イベントへの応答を改善するフレームワークについて紹介しました。AWS Health イベントを解析し、関連するチーム向けにそれを強化する方法を紹介しました。AWS Health の詳細については AWS Health ドキュメントをご参照ください。

著者について

Author photograph - Pranjal Gururani

Pranjal Gururani

Pranjal Gururani はシアトルを拠点とする AWS のソリューションアーキテクトです。Pranjal はさまざまなお客様と一緒にビジネス上の課題に対処するクラウドソリューションを構築しています。彼はハイキング、カヤック、スカイダイビングを楽しみ、余暇には家族と過ごす時間を楽しんでいます。

Author photograph - John Bickle

John Bickle

John Bickle はカナダのモントリオールを拠点とするシニアテクニカルアカウントマネージャー兼エンタープライズサポートリーダーです。John はお客様と緊密に連携してオペレーショナルエクセレンスを実現し、複雑さを軽減し、ダウンタイムをなくすことに喜びを感じています。余暇には音楽、セーリング、写真撮影を楽しんでいます。

Author photograph - Ballu Singh

Ballu Singh

Ballu Singh は AWS のプリンシパルソリューションアーキテクトです。彼はサンフランシスコのベイエリアに住んでおり、お客様が AWS 上でアプリケーションを設計し最適化できるように支援しています。余暇には読書や家族との時間を楽しんでいます。

翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。原文はこちらです。