Amazon CloudWatch アラームの大規模なクリーンアップを自動化する

AWS リージョン全体で数千の Amazon CloudWatch アラームがある中で、リージョンを跨いで価値の低いアラームや誤設定のアラームをすばやく特定したいとお考えですか？数日間「ALARM」または「IN_SUFFICIENT」状態になっていて、再検討が必要なアラームを特定する方法をお探しですか？価値の低いアラームをリージョン全体で確認し、定期的に削除してアラームコストを最適化するクリーンアップメカニズムが必要ですか？

このブログでは、CloudWatch で価値の低いアラームのクリーンアップメカニズムを AWS アカウントのリージョン全体に大規模にデプロイする方法を探り、さまざまな種類の設定ミスや価値の低いアラームを特定することによって、お客様が CloudWatch アラームのコストを最適化するのに役立つメカニズムについて説明します。「ALARM」または「INSUFFIENT_DATA」の状態が数日間継続しているアラームは、古いアラームとして分類されます。何のアクションも実行せず、複合アラームからも参照されないアラームは、価値が低い可能性があります。これらのアラームを確認し、有用であることを確認するか、必要ないとわかった場合は削除することをお勧めします。

ソリューションの導入

このソリューションと関連リソースは、AWS CloudFormation テンプレートとしてお客様の AWS アカウントにデプロイできます。

前提条件

このチュートリアルでは、次の前提条件を満たしている必要があります。

AWS アカウントを保有していること

CloudFormation テンプレートは何をデプロイしますか?

CloudFormation テンプレートは、以下のリソースを AWS アカウントにデプロイします。

AWS Lambda のための AWS Identity and Access Management (IAM)
- CloudWatchAlarmHealthCheckerRole
- CloudWatch Logs と S3 バケットへの書き込み、および CloudWatch API へのアクセスを許可
AWS Lambda 関数
- CloudWatchAlarmHealthCheckerpy-<stackname>
Lambda関数の Amazon CloudWatch Log グループ
- 通常の命名規則、つまり「/aws/lambda/<function name>」
- 7 日間の保存設定
- スタックの削除とともに削除されるように、ここで明示的に作成
「疑わしいアラーム」と「削除するアラーム」のスプレッドシート(CSVファイル)をアップロードするための Amazon S3 バケット
- S3BucketName
- S3 バケットの DeletionPolicy は「retain」を設定
- Lambda からのアクセスを許可する S3 バケットポリシー

CloudFormation テンプレートをデプロイする方法

yaml ファイルをダウンロードします。
自身のAWSアカウントの CloudFormation コンソールに移動します。
「スタックの作成」を選択します。
「テンプレートの準備完了」と「テンプレートファイルのアップロード」を選択し、「ファイルの選択」からダウンロードした yaml ファイルを指定します。
「次へ」を選択します。
「スタックの名前」を入力します。 (30 文字以内)
作成する S3 バケット名を入力します。これが、アラームスプレッドシートをアップロードするために作成される S3 バケットです。「次へ」を選択します。
必要に応じてタグを追加し、「次へ」を選択します。
画面下部の「機能」までスクロールし、「AWS CloudFormation によって IAM リソースが作成される場合があることを承認します。」チェックボックスをオンにして、「送信」を選択します。
スタックの作成が完了するまで待ちます。
Lambda コンソール > 関数に移動します。
「CloudWatchAlarmHealthCheckerpy-<stackname>」というLambda関数を選択します。
Lambda 関数の「コード」セクションまでスクロールして、「テスト」を選択します。
テストイベントの設定を図1 のようにします。

図1. Lambda関数の入力JSON

以下のサンプル json を使用して、S3 バケットにスプレッドシートを作成します。

{ 
    "nodata_days": 7, 
    "stale_days": 30, 
    "disabled_actions_days": 60, 
    "max_iterations": 1800, 
    "operating_mode":"report_only", 
    "regions": [
        "us-east-1", 
        "us-west-1", 
        "us-east-2", 
        "us-west-2", 
        "eu-west-1"
    ] 
}

「nodata_days」、「stale_days」、「disabled_actions_days」を変更することで、ユースケースや要件に応じて疑わしいアラームのリストを作成することができます。「max_iterations」は、アカウント内のアラームとメトリックの数に基づいてユーザーが設定できます。「regions」は、アカウントに存在するリージョンに基づいてユーザーが設定できます。「alarms_to_delete」スプレッドシートに記載されているすべてのアラームを削除するには、「operating_mode」を使用して「actual_delete」に設定します。デフォルトでは、「operating_mode」は「report_only」に設定されているため、誤ってこの Lambda を実行してもアラームは削除されません。「report_only」モードでは、最初にスプレッドシート内のすべてのアラームを確認するのに役立ちます。「operating_mode」を「actual_delete」に設定すると、「alarms_to_delete」スプレッドシートに記載されているすべてのアラームを削除できます。

アカウントでこのソリューションを実行すると、このソリューションは確認用のスプレッドシートを出力し、選択した S3 バケットにアップロードします。以下のスプレッドシートには、削除可能なアラームと疑わしいため確認が必要なアラームのリストが含まれています。

リージョンごとの削除可能なアラームのリストを含むスプレッドシート。生成されるこのスプレッドシートは、存在しないメトリック（メトリックがもう発行されていない、またはアラーム作成時にスペルが間違っている）を参照しているため、削除できる可能性のあるアラームのリストです。
リージョンごとのすべての疑わしいアラームのリストを含む、別のスプレッドシート。生成されるこのスプレッドシートは、古いアラームや価値が低い可能性のあるアラームのリストです。

Spreadsheets uploaded to S3 bucket by the solution

図 2. ソリューションによって S3 バケットにアップロードされたスプレッドシート

疑わしいアラームのスプレッドシートには、次のような、リージョンに跨るアカウント内のアラームのリストが含まれています。

データなしで「ALARM」状態が「stale_days」以上経過しているアラーム
「IN_SUFFICIENT」状態が「nodata_days」以上経過しているアラーム
アクションが関連付けられておらず、複合アラームからも参照されていないアラーム
「disabled_actions_days」を超えて継続的に無効化されているアラーム

‘stale_days’、’nodata_days’、’disabled_actions_days’ は、上記のブログで紹介した Lambda 関数のテストイベントの設定の一部としてユーザーが指定できます。疑わしいアラームのリストはクリーンアップしても良いかを確認するためのものです。基本的に、アクションが関連付けられておらず、複合アラームから参照されていないアラームは疑わしいリストに含まれますが、アラームの状態変化は EventBridge でも監視できるため、これらの疑わしいアラームリストを確認する必要があります。

削除するアラームのスプレッドシートには、次のアラームが含まれます。

名前空間が無効か、存在しない名前空間を参照しているアラーム
不明なメトリクスを対象としているアラーム
メトリクスに存在しないディメンションを参照しているアラーム

コスト

このソリューションはデータを S3 バケットに保存するため、使用にはコストがかかります。ソリューションでは Lambda コードを実行し、Lambda 関数が API 呼び出しを行います。コストは最小限に抑えるべきです。たとえば、アカウントに 300,000 のメトリクスと 100,000 のアラームが存在する場合は、数セント未満になります。

すべての価格の詳細は、Amazon S3 と AWS Lambda のページをご覧ください。

クリーンアップ

Lambda と関連リソースを保持したくない場合は、AWS コンソールで CloudFormation に移動し、 (デプロイ時に指定した名前の)スタックを選択し、「削除」を選択します。削除ポリシーで保持するように設定されている S3 バケットを除き、すべてのリソースが削除されます。

このクリーンアップメカニズムを再び追加したい場合は、CloudFormation yaml から再度スタックを作成できます。

結論

このソリューションを使用すると、存在する CloudWatch アラームのうち、価値の低いものや古くなっているものを把握し、それらを削除するアクションを実行できます。一度だけ実行して削除するアラームを確認することも、Amazon EventBridge Events を使用して定期的に実行することもできます。お客様は、価値の低いアラームや古くなったアラームをリージョン全体ですばやく特定し、削除することで、コストを節約することができます。

著者について

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

Amazon Web Services ブログ