Amazon Data Lifecycle Manager によるシンプルかつ包括的なデータ保護

このブログは 2023 年 11 月 17 日に Daniel Rabinovich（Software Development Engineer）、Vyassa Baratham（Software Development Engineer）、Mahesh Goud Paruchuri（Software Development Manager）によって執筆された内容を日本語化したものです。原文はこちらを参照してください。

企業では、複数のチームやプロジェクトで使用されるワークロードや関連リソースをグループ化するために、個別のアカウントを使用することがよくあります。これにより、組織は所有権、意思決定、コストを調整し、社内のチーム間で容易に管理できるようになります。しかし、アカウント内の各チームは、重要なリソースとそうでないリソースに関して、異なる要件やプロセスを持つ場合があります。このような要件やプロセスが混在していると、バックアップの失敗によってデータが失われ、大幅なダウンタイムが発生し、目標復旧時点が達成できない可能性があります。一方、アカウントの所有者や管理者は、各チームやプロジェクトのプロセスの詳細を知らないため、アカウントレベルでバックアップの要件を決定することは困難です。

現在お客様は、Amazon Elastic Block Store（EBS）ボリュームを EBS スナップショットに、Amazon Elastic Compute Cloud（Amazon EC2）を EBS-backed Amazon Machine Images（EBS-backed AMI）に自動的にバックアップするために使用できる幅広い製品、機能、カスタムスクリプトの選択肢を持っています。これらのツールは互いに独立して動作するため、異なるチームが同じリソースをバックアップするために異なるツールを使用すると、重複したバックアップが作成され、追加コストが発生する可能性があります。

アカウントの所有者とストレージの管理者は、Amazon Data Lifecycle Manager のデフォルトポリシーを使用して、作成されるリソースの数を最小限に抑えながら、すべての重要なワークロードを保護できるようになりました。デフォルトポリシーは、インスタンスまたはボリュームに、デフォルトポリシーで設定された作成頻度を満たす最近のバックアップがない場合にのみ、新しいバックアップを作成します。それ以外のメカニズムでバックアップが正常に作成されている場合、デフォルトポリシーは対象のリソースに対して新しい AMI またはスナップショットを作成しません。

この記事では、お客様が Amazon Data Lifecycle Manager のデフォルトポリシーをどのように設定すれば、リソースの重複作成とコストを最小限に抑えながら、重要なワークロードを確実にバックアップできるかを説明します。Amazon EC2 インスタンスと Amazon EBS ボリュームに対するデフォルトポリシーのセットアップの概要を説明し、Amazon EC2 のコンソールでデフォルトポリシーが作成するリソースを検証します。デフォルトポリシーは、アカウント内のすべてのインスタンスとボリュームを自動バックアップする簡単な方法が必要なお客様にも最適なオプションです。デフォルトポリシーを使用することで、アカウントの所有者や管理者は、アカウントで動作するチームやプロジェクトが使用するさまざまなプロセスに関係なく、アカウント内のすべての重要なワークロードがバックアップされているという安心感を得ることができます。

シナリオ

以下は、バックアップが必要とされる 2 つの一般的なシナリオです:

シナリオ 1: 一人のユーザーがすべてのリソースをバックアップする簡単な方法を求めている

アリスはアカウントの所有者で、アカウント内のすべてのインスタンスとボリュームの自動バックアップを有効にする簡単な方法を求めています。Amazon EC2 のコンソールからこの機能を有効にし、「確実に動く」ことを確認したいです。

シナリオ 2: ストレージ管理者は、重要なワークロードがすべてバックアップされていることを確認したい

ボブは組織のストレージ管理者で、主要アカウントの重要なワークロードが定期的にバックアップされていることを確認する責任を負っています。このアカウントは複数のチームとユーザーによって使用されており、それぞれが独自の要件を持っています。アカウントのユーザーがデータをリストアするためのバックアップを見つけることができない場合、ボブは彼らの最初の連絡先となります。次の図は、1 つのアカウントで動作するすべてのチームとワークロードの例です。

• チーム A は、ボリューム 1–4（Amazon EBS io2 Block Express ボリューム）で重要なアプリケーションを実行し、1 時間ごとのバックアップが必要です。
• チーム B は、ボリューム 5–7（Amazon EBS io2 Block Express ボリューム）で重要なアプリケーションを実行し、データボリュームのみ 1 時間ごとのバックアップが必要です。
• チーム B は、ボリューム 8（Amazon EBS gp3 ボリューム）に一時データを保存し、バックアップは不要です。
• チーム C は、ボリューム 9–10（Amazon EBS io1 ボリューム、io2 Block Express ボリューム）で重要なアプリケーションを実行し、データボリュームのみ 1 時間ごとのバックアップが必要です。
• 個別ユーザーはボリューム 11–14（Amazon EBS io2 Block Express ボリューム）を作成し、テスト目的で使用する場合を除き、組織の 1 時間ごとのバックアップ要件を遵守する必要があります。

また、各チームは独自のメカニズムでデータをバックアップしています:

• チーム A は、ボリュームのタグに基づいてバックアップするリソースを決定するサードパーティツールを使用しています。
• チーム B は、Amazon Data Lifecycle Manager のカスタムポリシーを使用して、ボリュームのタグに基づいてバックアップするリソースを決定しています。
• チーム C は、ボリュームのタグに基づいてバックアップするリソースを決定するカスタムスクリプトを使用しています。
• 個別ユーザーは自由にバックアップのメカニズムを選択しています。

アプリケーションをリストアするための最近のバックアップが見つからないという理由で、ボブは何度かユーザーから連絡を受けました。手動で調査した結果、ボブは以下の原因を特定しました:

• チーム A が誤ってボリューム 1 のタグを削除し、バックアップツールがボリューム 1 のバックアップを停止しました。
• チーム B がボリューム 7 のタグを変更したため、Amazon Data Lifecycle Manager のカスタムポリシーがボリューム 7 のバックアップを停止しました。
• チーム C のカスタムスクリプトにソフトウェアの欠陥があり、スナップショットが作成されなくなりました。
• 個別ユーザーは、タグ（production:environment）を持つすべてのボリュームを保護するようにチーム B のポリシーが設定されていると思い込み、ボリュームにタグ（production:environment）を付けていました。しかし、実際にはチーム B のポリシーは別のタグ（prod:environment）を持つボリュームを対象としていました。このため、個別ユーザーのボリュームはまったくバックアップされていませんでした。

ソリューションの概要

アリスもボブも、Amazon Data Lifecycle Manager のデフォルトポリシーを使うことで、それぞれのニーズを満たすことができます:

シナリオ 1: 一人のユーザーがすべてのリソースをバックアップする簡単な方法を求めている

アリスは、Amazon EC2 のダッシュボードから数回クリックするだけで、Amazon Data Lifecycle Manager のデフォルトポリシーを有効にすることができます（ウォークスルーの Step 1）。アリスはまた、アカウント内のすべての Amazon EBS ボリュームを監視して、過去 1 日以内に作成されたバックアップがあることを確認できます（Step 6）。

シナリオ 2: ストレージ管理者は、重要なワークロードがすべてバックアップされていることを確認したい

ボブは Amazon Data Lifecycle Manager のデフォルトポリシーを簡単に有効にして、様々なチームが使用するすべての重要なアプリケーションが日次バックアップされるように設定することができます。アカウント内の一部のユーザーは、1 時間ごとにバックアップを作成するように独自のバックアップメカニズムを設定しますが、ボブは重要なボリュームが少なくとも日次バックアップされるように、デフォルトポリシーを使用することができます。デフォルトポリシーを設定する際（Step 4）、ボブは除外パラメータを設定し、重要なアプリケーションを実行するボリュームのみがデフォルトポリシーの対象となるようにします。

お客様は除外パラメータを使用して、デフォルトポリシーによる定期的なバックアップから除外したい Amazon EBS ボリュームと Amazon EC2 インスタンスの属性を定義できます。リソースが除外パラメータの少なくとも 1 つに一致する場合、デフォルトポリシーはそのリソースのバックアップを作成しません。

さまざまなチームやユーザーの要件に基づくと、ボブのデフォルトポリシーは、すべてのブートボリュームと Amazon EBS io2 以外のボリュームタイプ（gp3、gp2、io1、sc1、st1、standard/magnetic）を除外すべきです。また、タグ（temp:storage）が設定されたテスト目的のボリュームも除外する必要があります。デフォルトポリシーを作成すると、すべてのチームとユーザーにとって重要なワークロードを実行するすべてのボリュームが、デフォルトポリシーの対象となります（以下の図で示す範囲）。各チームのバックアップメカニズムが計画通りに動作してボリュームのバックアップを 1 時間ごとに作成している場合、デフォルトポリシーは追加のスナップショットを作成しません。ただし、何らかの問題が発生し、ボリュームに過去 1 日分のスナップショットが存在しない場合は、デフォルトポリシーがそのボリュームのスナップショットを作成します。

前提条件

このウォークスルーでは、定期的にバックアップする必要がある Amazon EC2 インスタンスと Amazon EBS ボリュームがアカウントに存在することを想定します。デフォルトポリシーを適用したリソースを作成する際に、これらのリソースにタグを設定する必要はありません。

ウォークスルー

Amazon Data Lifecycle Manager のデフォルトポリシーを作成および管理するには、いくつかの方法があります。また、Amazon Data Lifecycle Manager のデフォルトポリシーとカスタムポリシーを Amazon EC2 コンソールに統合し、Amazon EC2 インスタンスの新規起動や Amazon EBS ボリュームの新規作成時にポリシーが有効になっているかどうかを確認できるようになりました。この記事では、デフォルトポリシーのすべてのタッチポイントについて説明します:

1. Amazon EC2 ダッシュボードを使用したデフォルトポリシーの確認
2. デフォルトポリシーの作成と設定
3. デフォルトポリシーとカスタムポリシーの区別
4. Amazon EBS ボリュームの作成時におけるデフォルトポリシーの設定の確認
5. Amazon EC2 インスタンス起動時におけるデフォルトポリシーの設定の確認
6. Amazon EBS ボリュームと最近のスナップショットバックアップの監視

Step 1: Amazon EC2 ダッシュボードを使用したデフォルトポリシーの確認

1. Amazon EC2 のダッシュボードに移動し、アカウントの属性の Data protection and security に進みます。

2. Data protection and security タブでは、EBS スナップショットおよび/または EBS-backed AMI に対して Amazon Data Lifecycle Manager のデフォルトポリシーが有効になっているかどうかを確認できます。作成するリソースに対応する Create policy を選択します。

この AWS リージョンのアカウントにどちらか一方でも作成されている場合、ダッシュボードにはポリシーの作成頻度と保持期間も表示されます。

Step 2: デフォルトポリシーの作成と設定

Amazon EC2 ダッシュボードから Create policy を選択すると、Amazon Data Lifecycle Manager ポリシーの作成ページに移動します。

1. ポリシーの説明を入力し、AWS Identity and Access Management（IAM）ロールを選択することで、デフォルトポリシーの設定を開始できます。どのロールを使用すべきかわからない場合は、デフォルトロールを選択することをお勧めします。正しい IAM 権限を持たない他のロールを選択した場合、ポリシーはエラー状態になります。

2. 次に、作成頻度、保持期間、および除外パラメータを設定する必要があります。

作成頻度は、ポリシーの対象となるすべての Amazon EBS ボリュームのスナップショットバックアップを作成する間隔を定義します。同じ頻度（またはそれ以上の頻度）でスナップショットを作成する他のバックアップメカニズムがある場合、デフォルトポリシーはそれらのボリュームに対してスナップショットを作成しません。ただし、他のメカニズムがスナップショットを作成する頻度が低い場合、または他のメカニズムが対象ボリュームのスナップショットの作成を停止するような問題が発生した場合は、デフォルトポリシーが介入し、作成頻度の基準を満たすようにスナップショットが作成されます。

保持期間は、デフォルトポリシーで作成されたスナップショットが保持される期間を定義します。

除外パラメータを定義して、デフォルトポリシーの対象から除くボリュームの属性を設定する必要があります。

ソリューションのセクションにあるボブのユースケースに基づくと、デフォルトポリシーは次のスナップショットを作成しません:

• • ブートボリューム
  • gp3、gp2、io1、sc1、st1、standard/magnetic のボリュームタイプ
  • タグ（temp:storage）を設定したボリューム

チームまたはユーザーが前述の除外する基準を満たさないボリュームを作成した場合、デフォルトポリシーはそのボリュームに日次バックアップがあることを確認します。

3. 次に、デフォルトポリシーの詳細設定を行います。ここでは、削除を最新の AMI まで延長を有効にしています。このパラメータを有効にしない場合、Amazon Data Lifecycle Manager のデフォルトポリシーは、ソースボリュームが削除されたときに最後のスナップショットを削除しません。また、デフォルトポリシーが無効化/削除されたとき、またはエラー状態に遷移したときでも、デフォルトポリシーによって作成されたスナップショットは削除されません。ソースボリュームが削除されたときや、デフォルトポリシーが削除/無効化やエラー状態に遷移したときに、（保持期間に基づいて）デフォルトポリシーが最終スナップショットを削除する場合は、削除を最新の AMI まで延長を有効にする必要があります。

4. 満足のいく設定ができたら、デフォルトポリシーを作成を選択し、設定を確認することで、デフォルトポリシーの作成は完了です! 同じ手順で、EBS-backed AMI 用のデフォルトポリシーも作成できます。このポリシーは、ポリシーの除外パラメータで定義したものを除いて、アカウント/リージョン内のすべての Amazon EC2 インスタンスを対象とします。

5. お客様は、AWS Command Line Interface（AWS CLI）を一回使用するだけで、同じデフォルトポリシーを簡単に作成することもできます。

$ aws dlm create-lifecycle-policy \
--state ENABLED \
--description "EBS snapshot policy" \
--execution-role-arn “role_arn” \
--default-policy VOLUME \
--create-interval 1 \
--retain-interval 7 \
--extend-deletion \
--exclusions ExcludeBootVolumes=true, ExcludeTags=[{Key=temp,Value=storage}], ExcludeVolumeTypes="standard|gp2|gp3|io1| st1|sc1"

Step 3: デフォルトポリシーとカスタムポリシーの区別

Amazon EC2 コンソールの Amazon Data Lifecycle Manager ページから、Amazon Data Lifecycle Manager のデフォルトポリシーを作成することもできます。

1. Amazon EC2 のコンソールで Lifecycle Manager を選択してください。

2. デフォルトポリシーのラジオボタンを選択します。または、タグに基づいて対象とするリソースを選択できるカスタムポリシーを作成することもできます。

3. EBS スナップショットポリシーまたは EBS-backed AMI ポリシーのいずれかを選択します。次に、Step 2 の指示に従ってポリシーを設定します。

4. 同じアカウントの同じ AWS リージョン同じタイプのデフォルトポリシーを既に作成している場合、別のデフォルトポリシーを作成することはできず、タイルはグレーアウトされます。必要に応じて、デフォルトポリシーを表示して既存のデフォルトポリシーの変更ができます。

5. Amazon Data Lifecycle Manager のメイン画面では、デフォルトポリシーの表示、監視、フィルタリング、ソートも可能です。

Step 4: Amazon EBS ボリュームの作成時におけるデフォルトポリシーの設定の確認

Amazon EC2 コンソールを使用してボリュームを作成する際に、Amazon Data Lifecycle Manager のデフォルトおよびカスタムポリシーが Amazon EBS ボリュームをバックアップするか確認できます。

1. Amazon EC2 のコンソールで Elastic Block Store のボリュームを選択し、ボリュームの作成を選択します。

2. ページの一番下までスクロールし、バックアップの概要の更新アイコンを選択します。

3. 同じアカウントの同じ AWS リージョンに対して EBS スナップショットのデフォルトポリシーが設定されている場合、そのポリシーがそのボリュームをバックアップするかどうかを確認できます。また、Amazon Data Lifecycle Manager のカスタムポリシーがこのボリュームを（付与されたタグに基づいて）バックアップの対象にしているかどうかも確認できます。

4. ボリュームをデフォルトポリシーの対象にしない場合は、ボリュームの属性が除外パラメータの少なくとも 1 つに一致することを確認する必要があります。詳細を表示を拡張し、除外パラメータを表示を選択できます。この例では、タグ（temp:storage）を追加し、更新アイコンを再度選択すると、デフォルトポリシーがこのボリュームを対象としていないことがわかります。

Step 5: Amazon EC2 インスタンス起動時におけるデフォルトポリシーの設定の確認

Amazon EC2 コンソールでインスタンスを起動したときに、Amazon Data Lifecycle Manager のデフォルトポリシーとカスタムポリシーが Amazon EC2 インスタンスをバックアップするかどうかを確認できます。

1. Amazon EC2 コンソールでインスタンスを選択し、インスタンスを起動へと進みます。

2. EBS-backed AMI のデフォルトポリシーがタグに基づいてインスタンスを除外するように設定されていて、現在のボリュームを除外したい場合は、ここでタグを追加し、それがインスタンスに適用されることを確認する必要があります。

3. ページのストレージを設定までスクロールダウンし、更新アイコンを選択します。

4. 同じアカウントの同じ AWS リージョンに EBS-backed AMI のデフォルトポリシーが設定されている場合、インスタンスが作成されると、ポリシーがインスタンスをバックアップするかどうかを確認できます。また、Amazon Data Lifecycle Manager のカスタムポリシーが（付与されたタグに基づいて）このインスタンスをバックアップするかも確認できます。

Step 6: Amazon EBS ボリュームと最近のスナップショットバックアップの監視

Amazon Data Lifecycle Manager を使用しているかどうかに関係なく、Amazon EC2 コンソールの Amazon EBS ボリュームのページを使用して、過去 24 時間に作成されたスナップショットがあるボリュームの数を確認できます。

1. Amazon EC2 コンソールでボリュームを選択します。

2. 検索バーを使用して、ボリュームの属性に基づいてフィルタリングすることもできます。複数のボリュームを選択すると、セレクション概要タブに移動して、選択したボリュームの数と最近スナップショットが取得されたボリュームの数を表示できます。

重要なワークロードを実行している 1 つまたは複数のボリュームに最近のスナップショットが表示されない場合、デフォルトポリシーを作成することで、このギャップを迅速に解決できます。

クリーンアップ

前の手順で作成したスナップショットを削除して、ストレージ料金が発生しないようにします。スナップショットのページに移動し、ポリシーによって作成されたすべてのスナップショットを検索し、すべてのスナップショットを選択し、アクションの後にスナップショットの削除を選択します。

同様に、Amazon Data Lifecycle Manager のデフォルトポリシーを削除して、今後そのポリシーによってスナップショットが作成されないようにする必要があります。まず、デフォルトポリシーの削除を最新の AMI まで延長を有効にして、ポリシーが削除されても、ポリシーによって既に作成されたスナップショットが削除されるようにします。次に、Amazon Data Lifecycle Manager の画面に移動してポリシーを選択し、アクションを選択してライフサイクルポリシーを削除を選択すると、ポリシーを削除できます。

まとめ

この記事では、AWS リソースのアカウント所有者がアカウント内のすべてのボリュームが定期的にバックアップされていることを簡単に確認できるように、Amazon Data Lifecycle Manager のデフォルトポリシーを作成することについて説明しました。デフォルトポリシーを使用することで、ストレージ管理者は自分が管理するアカウントを使用するチームやユーザーの要件を満たすことができます。ストレージ管理者は、チームやユーザー独自のバックアップメカニズムが失敗した場合でも、アカウント内のすべての重要なワークロードが定期的にバックアップされているという保証を得ることができます。何よりも、デフォルトポリシーでは、最近のバックアップがすでに存在する場合、追加のバックアップを作成しないため、バックアップの重複による追加コストと管理オーバーヘッドを排除することができます。

最後の提案として、ご自身の環境でこの機能を試してみることをお勧めします。また、この機能の詳細については、AWS のドキュメントをご覧ください。

この記事をご覧いただきありがとうございます。