アラームのコストを最適化するのに役立つメカニズムについて説明します。状態が数日間継続しているアラームは、古いアラームとして分類されます。何のアクションも実行せず、複合アラームからも参照されないアラームは、価値が低い可能性があります。これらのアラームを確認し、有用であることを確認するか、必要ないとわかった場合は削除することをお勧めします。アカウントにデプロイできます。前提条件このチュートリアルでは、次の前提条件を満たしている必要があります。アカウントにデプロイします。コンソールに移動します。「スタックの作成」を選択します。ファイルを指定します。「次へ」を選択します。「スタックの名前」を入力します。バケット名を入力します。「次へ」を選択します。リソースが作成される場合があることを承認します。スタックの作成が完了するまで待ちます。「CloudWatchAlarmHealthCheckerpy-<stackname>」というLambda関数を選択します。関数の「コード」セクションまでスクロールして、「テスト」を選択します。バケットにスプレッドシートを作成します。}「nodata_days」、「stale_days」、「disabled_actions_days」を変更することで、ユースケースや要件に応じて疑わしいアラームのリストを作成することができます。「max_iterations」は、アカウント内のアラームとメトリックの数に基づいてユーザーが設定できます。「regions」は、アカウントに存在するリージョンに基づいてユーザーが設定できます。「alarms_to_delete」スプレッドシートに記載されているすべてのアラームを削除するには、「operating_mode」を使用して「actual_delete」に設定します。実行してもアラームは削除されません。「report_only」モードでは、最初にスプレッドシート内のすべてのアラームを確認するのに役立ちます。「operating_mode」を「actual_delete」に設定すると、「alarms_to_delete」スプレッドシートに記載されているすべてのアラームを削除できます。バケットにアップロードします。以下のスプレッドシートには、削除可能なアラームと疑わしいため確認が必要なアラームのリストが含まれています。リージョンごとの削除可能なアラームのリストを含むスプレッドシート。生成されるこのスプレッドシートは、存在しないメトリック(メトリックがもう発行されていない、またはアラーム作成時にスペルが間違っている)を参照しているため、削除できる可能性のあるアラームのリストです。リージョンごとのすべての疑わしいアラームのリストを含む、別のスプレッドシート。生成されるこのスプレッドシートは、古いアラームや価値が低い可能性のあるアラームのリストです。バケットにアップロードされたスプレッドシート疑わしいアラームのスプレッドシートには、次のような、リージョンに跨るアカウント内のアラームのリストが含まれています。関数のテストイベントの設定の一部としてユーザーが指定できます。疑わしいアラームのリストはクリーンアップしても良いかを確認するためのものです。監視できるため、これらの疑わしいアラームリストを確認する必要があります。削除するアラームのスプレッドシートには、次のアラームが含まれます。バケットに保存するため、使用にはコストがかかります。コストは最小限に抑えるべきです。アラームが存在する場合は、数セント未満になります。ページをご覧ください。(デプロイ時に指定した名前の)スタックを選択し、「削除」を選択します。バケットを除き、すべてのリソースが削除されます。再度スタックを作成できます。アラームのうち、価値の低いものや古くなっているものを把握し、それらを削除するアクションを実行できます。使用して定期的に実行することもできます。お客様は、価値の低いアラームや古くなったアラームをリージョン全体ですばやく特定し、削除することで、コストを節約することができます。することを楽しんでいます。お客様がコスト最適化とオペレーションエクセレンスを実現できるよう支援することに重点を置いています。ソフトウェアエンジニアリング、クラウド運用、自動化の分野で18年以上のIT経験があります。入社し、米国西部の多数の企業顧客と仕事をしてきました。仕事以外では、家族と過ごす時間を楽しんでいます。プロジェクトのリードを行っています。彼女は、クラウドへの移行を顧客にとってシームレスなものにすることに情熱を注いでいます。彼女はイリノイ大学でコンピューター工学の修士号を取得しています。仕事以外では、旅行やさまざまな料理の探求を楽しんでいます。翻訳はテクニカルアカウントマネージャーの日平が担当しました。