はじめに
2021/2/3 に AWS Backup のイベントとメトリクスが Amazon EventBridge と Amazon CloudWatch で利用可能になりました。
これまでも AWS Backup Notification API により Amazon SNS を使用したイベント通知を行うことも可能でしたが、このアップデートによって、より多くのバックアッププロセスをモニタリングできるようになりました。
上記を使用して AWS Backup のモニタリングを設定する流れについて記載します。
以下には触れません。
- AWS Backup 自体の詳細や設定手順
- AWS Backup Notification API による通知の設定手順
- AWS CloudTrail による API Call のモニタリング
Amazon CloudWatch
概要
CloudWatch のメトリクスでは大きく分けるとバックアップジョブおよび復旧ポイントに関するメトリクスを取得することができます。
2021年3月時点で取得可能なメトリクスは以下のとおりです。 (AWS ドキュメントより引用)
バックアップジョブに関するメトリクス
| メトリクス | 概要 |
|---|---|
| NumberOfBackupJobsCreated | 作成されたバックアップジョブの数 |
| NumberOfBackupJobsPending | 実行しようとしているバックアップジョブの数 |
| NumberOfBackupJobsRunning | 現在実行されているバックアップジョブの数 |
| NumberOfBackupJobsAborted | スケジュールされたが、開始されなかったバックアップジョブの数 |
| NumberOfBackupJobsCompleted | 完了したバックアップジョブの数 |
| NumberOfBackupJobsFailed | 失敗したバックアップジョブの数 |
| NumberOfBackupJobsExpired | ライフサイクル設定に基づいて削除を試行したが削除できなかったバックアップジョブの数 |
| NumberOfCopyJobsCreated | クロスアカウントおよびクロスリージョンコピージョブの数 |
| NumberOfCopyJobsRunning | 現在実行されているクロスアカウントおよびクロスリージョンコピージョブの数 |
| NumberOfCopyJobsCompleted | 完了したクロスアカウントおよびクロスリージョンコピージョブの数 |
| NumberOfCopyJobsFailed | 失敗したクロスアカウントおよびクロスリージョンコピージョブの数 |
| NumberOfRestoreJobsPending | 実行しようとしている復元ジョブの数 |
| NumberOfRestoreJobsRunning | 現在実行されている復元ジョブの数 |
| NumberOfRestoreJobsCompleted | 完了した復元ジョブの数 |
| NumberOfRestoreJobsFailed | 失敗した復元ジョブの数 |
復旧ポイントに関するメトリクス
| メトリクス | 概要 |
|---|---|
| NumberOfRecoveryPointsCompleted | 作成された復旧ポイントの数 |
| NumberOfRecoveryPointsPartial | 作成を完了できなかったリカバリポイントの数 |
| NumberOfRecoveryPointsExpired | ライフサイクル設定に基づいて削除を試行したが削除できなかった復旧ポイントの数 |
| NumberOfRecoveryPointsDeleting | 削除を実行している復旧ポイントの数 |
| NumberOfRecoveryPointsCold | ライフサイクル設定に基づいてコールドストレージに移行された復旧ポイントの数 |
またディメンションには AWS Backup で取得するリソースタイプとバックアップボールト名を利用できますので、EC2 などの特定のリソースタイプや任意のバックアップボールトの単位、またはその組み合わせでアラームを設定することができます。
アラームの設定
どのメトリクスを監視すべきかについてはシステム要件によって異なるかと思いますが、NumberOfBackupJobsFailed のアラームをコンソール上から定義してみます。
CloudWatch コンソールのアラームからアラームの作成を選択します。
メトリクスの選択では AWS の名前空間 から AWS Backup を選択します。
ここでは Default のバックアップボールトかつ、EC2 のバックアップに対するアラートを設定したいと思いますので、Resource Type Metrics by Backup Vault からメトリクスを選択します。
以下のように、ResourceType: EC2, BackupVault: Default, メトリクス名: NumberOfBackupJobsFailed にチェックし、メトリクスの選択を完了します。
選択時に出力されるメトリクスの数は実際の AWS アカウント内の設定、運用状況により異なります。これまでバックアップに失敗していない場合は NumberOfBackupJobsFailed 自体が表示されない可能性があります。その場合、異なるメトリクスを選択後に手動でメトリクスを書き換えることもできます。
メトリクス選択後に条件を指定します。
ここでは統計を合計に、静的なしきい値の条件を 1 以上として次に進みます。
アクションの設定で通知先の SNS Topic を選択するか新規作成します。ここでは AWS Chatbot 用に定義済みの SNS Topic を選択し、Slack に通知してみたいと思います。
AWS Chatbot の設定例については以前書いた記事で紹介しておりますので、詳細を確認したい方は参照いただければと思います。
最後にアラーム名と説明 (オプション) を指定してアラームの作成を完了します。
今回は BackupJobFailed というアラーム名を設定しました。
以下は実際にバックアップを失敗させたときの Slack へのアラーム通知例です。CloudWatch メトリクスの通知では対象のリソース ID までは確認できないことに注意してください。
参考まですが、意図的にバックアップジョブを失敗させる方法としては、テスト用の EC2 インスタンスを起動&終了させ、終了したインスタンスを指定してオンデマンドバックアップを実行する手順が簡単かと思います。
Amazon EventBridge
概要
EventBridge ではバックアッププロセスに関するより多くのステータス変化をイベントとして検知することができます。
2021年3月現在で検知可能なイベントは以下のとおりです。 (AWS ドキュメントより引用)
| Event type | States |
|---|---|
| Backup Vault State Change | CREATED, DELETED, MODIFIED |
| Backup Plan State Change | CREATED, DELETED, MODIFIED |
| Backup Job State Change | CREATED, ABORTED, COMPLETED, FAILED, EXPIRED, PENDING, RUNNING |
| Copy Job State Change | CREATED, COMPLETED, FAILED, RUNNING |
| Restore Job State Change | CREATED, COMPLETED, FAILED, PENDING, RUNNING |
| Recovery Point State Change | MODIFIED, COMPLETED, PARTIAL, EXPIRED, DELETED |
| Region Setting State Change | MODIFIED |
バックアップジョブや復旧ポイントに関する情報だけでなく、バックアップボールトやバックアッププランなどの設定に対する状態変化を追うことができます。
AWS Backupは、5分ごとにベストエフォートでイベントを EventBridge に送信するため、リアルタイムの検知ではないことにご注意ください。
また残念ながら 2021/3/15 時点で EventBridge のスキーマレジストリにスキーマ情報の登録がありません。参考までに Backup Job State Change では以下のようなイベントが発行されます。
{
"version": "0",
"id": "12345abc-defg-6789-hijk-012345lmnopq",
"detail-type": "Backup Job State Change",
"source": "aws.backup",
"account": "123456789012",
"time": "2021-03-15T07:11:40Z",
"region": "ap-northeast-1",
"resources": [],
"detail": {
"backupJobId": "abcde012-3456-efgh-7890-ijklmn123456",
"backupVaultArn": "arn:aws:backup:ap-northeast-1:123456789012:backup-vault:Default",
"backupVaultName": "Default",
"bytesTransferred": "0",
"creationDate": "2021-03-15T07:11:37.928Z",
"iamRoleArn": "arn:aws:iam::123456789012:role/service-role/AWSBackupDefaultServiceRole",
"resourceArn": "arn:aws:ec2:ap-northeast-1:123456789012:instance/i-xxxxxxxxxxxxxxxxx",
"resourceType": "EC2",
"state": "FAILED",
"statusMessage": "Invalid value 'i-xxxxxxxxxxxxxxxxx' for instanceId. Instance is not in state 'running' or 'stopping' or 'stopped'",
"startBy": "2021-03-15T08:11:37.928Z",
"percentDone": 0.0
}
}
バックアップ対象のリソース ID やバックアップ失敗時のステータスメッセージなど CloudWatch メトリクスよりも詳細な情報を確認できます。
設定例
イベントルール作成時のイベントパターン定義でサービス毎の事前定義パターンとしてサービス名: Backup と前述のイベントタイプを選択できます。
上記で設定されるデフォルトのイベントパターンではバックアップジョブに対するすべての状態変化を検知してしまいます。FAILED と ABORTED だけなど特定のステータスのみを検知したい場合は、前述のイベント例を参考に以下のようにイベントパターンを編集します。
{
"source": ["aws.backup"],
"detail-type": ["Backup Job State Change"],
"detail": {
"state": [
"ABORTED",
"FAILED"
]
}
}
イベントパターンの定義後、任意のターゲットアクションを設定してイベントルールの作成を完了します。
動作確認例は割愛しますが、バックアップジョブ失敗時ターゲットに指定した Lambda 関数が起動されることを確認しています。
結局どれを使えばいいのか
CloudWatch メトリクスと EventBridge の AWS サービスイベントに加えて AWS Backup Notification API を含めると 3 通りの設定方法があることになります。
CloudWatch メトリクスのメリットはダッシュボードによる可視化、既存アラーム運用への統合がしやすいという点があります。
一方で EventBridge ではリソース ID やステータスメッセージなどの詳細情報を取得しつつ、Lambda 関数などの任意のアクションを設定することが可能であるため、より柔軟な対応が可能です。また意図しない構成変更等も検知できるため、基本的には CloudWatch メトリクスと併用できるものです。
AWS Backup Notification API を使用する場合でも以下のような設定を行うことでバックアップジョブ失敗のモニタリングを行うこともできますが、若干手順がわかりにくいです。
また EventBridge や CloudWatch メトリクスはバックアップボールトや、コピージョブ、リージョン設定など Notification API よりも多くの状態変化を検知できますので、新規で設定するのであれば基本的には AWS Backup Notification API は対象外として問題ないのではと考えます。
参考
公式ドキュメント
以前書いた記事
以上です。
参考になれば幸いです。