翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# Amazon Data Lifecycle Manager でバックアップを自動化
<a name="snapshot-lifecycle"></a>

Amazon Data Lifecycle Manager を使用して、EBS スナップショットと EBS-backed AMI の作成、保持、削除を自動化できます。スナップショットと AMI 管理を自動化すると、次のことができるようになります。
+ 定期的なバックアップスケジュールを実施して貴重なデータを保護する。
+ 定期的に更新できる標準化された AMI を作成する。
+ 監査担当者または社内のコンプライアンスが必要とするバックアップを保持する。
+ 古いバックアップを削除してストレージコストを削減する。
+ 分離されたリージョンまたはアカウントにデータをバックアップするディザスタリカバリ用バックアップポリシーを作成します。

Amazon EventBridge と のモニタリング機能と組み合わせると AWS CloudTrail、Amazon Data Lifecycle Manager は Amazon EC2 インスタンスと個々の EBS ボリュームの完全なバックアップソリューションを追加料金なしで提供します。

**重要**  
Amazon Data Lifecycle Manager では、他の方法で作成されたスナップショットまたは AMI を管理することはできません。
Amazon Data Lifecycle Manager では、instance store-backed AMI の作成、保持、および削除を自動化することはできません。

Amazon Data Lifecycle Manager は、Amazon Elastic Block Store (Amazon EBS) のサービス機能として評価されます。Amazon EBS がリストされた[コンプライアンスプログラムによるAWS 対象範囲内のサービス](https://aws.amazon.com/compliance/services-in-scope/) (FedRAMP、HIPAA BAA、SOC など) はすべて、Amazon Data Lifecycle Manager にも適用されます。

**Topics**
+ [クォータ](#dlm-quotas)
+ [仕組み](dlm-elements.md)
+ [デフォルトポリシーとカスタムポリシー](policy-differences.md)
+ [デフォルトポリシーを作成する](default-policies.md)
+ [スナップショット用のカスタムポリシーを作成](snapshot-ami-policy.md)
+ [AMI 用のカスタムポリシーを作成](ami-policy.md)
+ [クロスアカウントのスナップショットコピーの自動化](event-policy.md)
+ [ポリシーの変更](modify.md)
+ [ポリシーを削除](delete.md)
+ [アクセス制御](dlm-prerequisites.md)
+ [ポリシーをモニタリング](dlm-monitor-lifecycle.md)
+ [サービスエンドポイント](dlm-service-endpoints.md)
+ [インターフェイス VPC エンドポイント](dlm-vpc-endpoints.md)
+ [トラブルシューティング](dlm-troubleshooting.md)

## クォータ
<a name="dlm-quotas"></a>

 AWS アカウントには、Amazon Data Lifecycle Manager に関連する次のクォータがあります。


| 説明 | クォータ | 
| --- | --- | 
| リージョンごとのカスタムライフサイクルポリシー | 100 | 
| リージョンごとの EBS スナップショットのデフォルトポリシー | 1 | 
| リージョンごとの EBS-backed AMI のデフォルトポリシー | 1 | 
| リソースあたりのタグ | 45 | 

# Amazon Data Lifecycle Manager の仕組み
<a name="dlm-elements"></a>

以下はAmazon Data Lifecycle Managerの主要な要素です。

**Topics**
+ [ポリシー](#dlm-policies)
+ [ポリシースケジュール](#dlm-lifecycle-schedule)
+ [ターゲットリソースタグ](#dlm-tagging-volumes)
+ [スナップショット](#dlm-ebs-snapshots)
+ [EBS-backed AMI](#dlm-ebs-amis)
+ [Amazon Data Lifecycle Manager のタグ](#dlm-tagging-snapshots)

## ポリシー
<a name="dlm-policies"></a>

Amazon Data Lifecycle Manager で、バックアップの作成と保持の要件を定義するポリシーを作成します。これらのポリシーでは通常、以下を指定できます。
+ **ポリシータイプ** – ポリシーで管理するバックアップリソースのタイプ (スナップショットまたは EBS-backed AMI) を定義します。
+ **ターゲットリソース** – ポリシーのターゲットとなるリソースのタイプ (インスタンスまたは EBS ボリューム) を定義します。
+ **作成頻度** – ポリシーを実行し、スナップショットまたは AMI を作成する頻度を定義します。
+ **保持しきい値** – スナップショットまたは AMI の作成後、ポリシーで保持する期間を定義します。
+ **追加アクション** – クロスリージョンでのコピー、アーカイブ、リソースのタグ付けなど、ポリシーで実行する必要がある追加アクションを定義します。

Amazon Data Lifecycle Manager には、デフォルトポリシーとカスタムポリシーが用意されています。

**デフォルトポリシー**  
デフォルトポリシーでは、最近のバックアップがないリージョン内のすべてのボリュームとインスタンスをバックアップします。必要に応じて、除外パラメータを指定してボリュームとインスタンスを除外できます。

Amazon Data Lifecycle Manager は、次のポリシーをサポートします。
+ EBS スナップショットのデフォルトポリシー – ボリュームをターゲットとし、スナップショットの作成、保持、および削除を自動化します。
+ EBS-backed AMI のデフォルトポリシー – インスタンスをターゲットし、EBS-backed AMI の作成、保持、および登録解除を自動化します。

デフォルトポリシーは、各アカウントおよび AWS リージョンのリソースタイプごとに 1 つしか設定できません。

**カスタムポリシー**  
カスタムポリシーは、割り当てられたタグに基づく特定のリソースをターゲットとしており、高速スナップショット復元、スナップショットアーカイブ、クロスアカウントコピー、事前スクリプトと事後スクリプトなどの高度な機能をサポートします。カスタムポリシーには最大 4 つのスケジュールを含めることができ、各スケジュールには独自の作成頻度、保持しきい値、および高度な機能設定を設定できます。

Amazon Data Lifecycle Manager は、次のカスタムポリシーをサポートします。
+ EBS スナップショットポリシー – ボリュームまたはインスタンスをターゲットとし、EBS スナップショットの作成、保持、および削除を自動化します。
+ EBS-backed AMI ポリシー – インスタンスをターゲットし、EBS-backed AMI の作成、保持、および登録解除を自動化します。
+ クロスアカウントコピーのイベントポリシー – 共有されているスナップショットのクロスリージョンコピーアクションを自動化します。

詳細については、「[Amazon Data Lifecycle Manager のデフォルトポリシーとカスタムポリシー](policy-differences.md)」を参照してください。

## ポリシースケジュール (*カスタムポリシーのみ*)
<a name="dlm-lifecycle-schedule"></a>

ポリシースケジュールは、ポリシーによってスナップショットまたは AMI が作成されるタイミングを定義します。ポリシーは、最大 4 つのスケジュール — (1 つの必須スケジュールと、最大 3 つのオプションのスケジュール) を持つことができます。

1 つのポリシーに複数のスケジュールを追加すると、同じポリシーを使用して異なる頻度でスナップショットまたは AMI を作成できます。例えば、毎日、毎週、毎月、および毎年のスナップショットを作成する単一のポリシーを作成できます。これにより、複数のポリシーを管理する必要がなくなります。

スケジュールごとに、頻度、高速スナップショット復元設定 (スナップショットライフサイクルポリシーのみ)、クロスリージョンのコピールール、およびタグを定義できます。スケジュールに割り当てられているタグは、そのスケジュールが初期化された時点で作成される、スナップショットまたは AMI に自動的に割り当てられます。さらに、Amazon Data Lifecycle Manager は、スケジュールの頻度に基づいて、システム生成タグを各スナップショットまたは AMI に自動的に割り当てます。

各スケジュールは、その頻度に基づいて個別に初期化されます。複数のスケジュールが同時に初期化された場合、Amazon Data Lifecycle Manager はスナップショットまたは AMI を 1 つだけ作成し、保持期間が最も長いスケジュールのスナップショット保持設定を適用します。初期化されたすべてのスケジュールのタグがスナップショットまたは AMI に適用されます。
+ (スナップショットライフサイクルポリシーのみ) 初期化された 1 つ以上のスケジュールで高速スナップショット復元が有効になっている場合、初期化されたすべてのスケジュールで指定されている、すべてのアベイラビリティーゾーンで、スナップショットの高速スナップショット復元が有効化されます。初期化されたスケジュールの最も長い保持設定が、各アベイラビリティーゾーンに対して使用されます。
+ 初期化された複数のスケジュールでクロスリージョンコピーが有効化されている場合は、それらのスケジュール全体で指定されているすべてのリージョンに対し、スナップショットもしくは AMI がコピーされます。初期化されたスケジュールの最も長い保存期間が適用されます。

## ターゲットリソースタグ (*カスタムポリシーのみ*)
<a name="dlm-tagging-volumes"></a>

Amazon Data Lifecycle Manager カスタムポリシーでは、バックアップするリソースを識別するためのリソースタグが使用されます。スナップショットまたは EBS-backed AMI ポリシーの作成時に、複数のターゲットリソースタグを指定することができます。指定されたタイプのリソース (インスタンスまたはボリューム) のうち、指定されたターゲットリソースタグの少なくとも 1 つを持つすべてのリソースがポリシーのターゲットになります。例えば、ボリュームをターゲットとするスナップショットポリシーを作成し、`purpose=prod`、`costcenter=prod`、`environment=live` をターゲットリソースタグとして指定した場合、ポリシーは、これらのタグとキー値のペアのいずれかを持つすべてのボリュームをターゲットとします。

リソースで複数のポリシーを実行する場合は、ターゲットリソースに複数のタグを割り当ててから、それぞれが特定のリソースタグをターゲットとする個別のポリシーを作成できます。

タグキーに `\` や `=` の文字を使用することはできません。ターゲットリソースタグでは大文字と小文字が区別されます。詳細については、「[リソースのタグ付け](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html)」を参照してください。

## スナップショット
<a name="dlm-ebs-snapshots"></a>

スナップショットは、EBS ボリュームからデータをバックアップするための主な手段です。ストレージコストを節約するために、連続するスナップショットは増分で、以前のスナップショット以降に変更されたボリュームデータのみが含まれています。ボリュームの一連のスナップショットでスナップショットを 1 つ削除すると、そのスナップショットに固有のデータだけが削除されます。キャプチャされたボリュームの残りの部分は保存されます。詳細については、「[Amazon EBS スナップショット](ebs-snapshots.md)」を参照してください。

## EBS-backed AMI
<a name="dlm-ebs-amis"></a>

Amazon マシンイメージ (AMI) には、インスタンスの起動に必要な情報が用意されています。同じ設定で複数のインスタンスが必要な場合は、1 つの AMI から複数のインスタンスを起動できます。Amazon Data Lifecycle Manager は、EBS-backed AMI のみをサポートします。EBS-backed AMI には、ソースインスタンスにアタッチされた各 EBS ボリュームのスナップショットが含まれます。詳細については、「[Amazon マシンイメージ (AMI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html)」を参照してください。

## Amazon Data Lifecycle Manager のタグ
<a name="dlm-tagging-snapshots"></a>

Amazon Data Lifecycle Manager は、ポリシーによって作成されたすべてのスナップショットと AMI に対し以下のようなタグを適用することで、他の方法で作成されたスナップショットや AMI と区別します。
+ `aws:dlm:lifecycle-policy-id`
+ `aws:dlm:lifecycle-schedule-name`
+ `aws:dlm:expirationTime` – 期間ベースのスケジュールにより作成されたスナップショット用。スナップショットを標準階層から削除する時期を表します。
+ `dlm:managed`
+ `aws:dlm:archived` – スケジュールによりアーカイブされたスナップショット用。
+ `aws:dlm:pre-script` – 事前スクリプトにより作成されたスナップショット用。
+ `aws:dlm:post-script` – 事後スクリプトにより作成されたスナップショット用。

作成時に、スナップショットと AMI に適用するカスタムタグを指定することもできます。タグキーに `\` や `=` の文字を使用することはできません。

Amazon Data Lifecycle Manager がボリュームをスナップショットポリシーに関連付けるために使用するターゲットタグは、オプションで、ポリシーによって作成されたスナップショットに適用できます。同様に、インスタンスを AMI ポリシーに関連付けるために使用するターゲットタグは、ポリシーによって作成された AMI にオプションで適用できます。

# Amazon Data Lifecycle Manager のデフォルトポリシーとカスタムポリシー
<a name="policy-differences"></a>

このセクションでは、デフォルトポリシーとカスタムポリシーを比較し、それぞれの類似点と相違点に焦点を当てます。

**Topics**
+ [EBS スナップショットポリシーの比較](#snapshot-policy-diffs)
+ [EBS-backed AMI ポリシーの比較](#ami-policy-diffs)

## EBS スナップショットポリシーの比較
<a name="snapshot-policy-diffs"></a>

次の表は、EBS スナップショットのデフォルトポリシーとカスタム EBS スナップショットポリシーの違いを示しています。


| 機能 | EBS スナップショットのデフォルトポリシー | カスタム EBS スナップショットポリシー | 
| --- | --- | --- | 
| マネージドバックアップリソース | EBS スナップショット | EBS スナップショット | 
| ターゲットリソースタイプ | ボリューム | ボリュームまたはインスタンス | 
| リソースターゲット設定 | 最新のスナップショットがないリージョン内のすべてのボリュームをターゲットとします。除外パラメータを指定して特定のボリュームを除外できます。 | 特定のタグを持つボリュームまたはインスタンスのみをターゲットとします。 | 
| 除外パラメータ | はい。ブートボリューム、特定のボリュームタイプ、特定のタグが付いたボリュームは除外できます。 | はい。インスタンスをターゲットにするときに、ブートボリュームと特定のタグが付いたボリュームを除外できます。 | 
| サポート AWS Outposts | いいえ | はい | 
| 複数のスケジュールのサポート | いいえ | はい。ポリシーごとに最大 4 つのスケジュールまで | 
| サポートされている保持タイプ | 経過期間ベースの保持のみ | 経過期間ベースの保持とカウントベースの保持 | 
| スナップショットの作成頻度 | 1～7 日おき。 | 毎日、毎週、毎月、毎年、または cron 式を使用したカスタム頻度。 | 
| スナップショット保持期限 | 2～14 日。 | 最大 1,000 スナップショット (カウントベース) または最大 100 年 (経過期間ベース)。 | 
| アプリケーション整合性のあるスナップショットのサポート | いいえ | はい。事前スクリプトと事後スクリプトを使用する | 
| スナップショットアーカイブのサポート | いいえ | はい | 
| 高速スナップショット復元のサポート | いいえ | はい | 
| クロスリージョンでのコピーのサポート  | はい。デフォルト設定を使用 1 | はい。カスタム設定を使用 | 
| クロスアカウント共有のサポート | いいえ | はい | 
| 拡張削除のサポート 2 | はい | いいえ | 

1 デフォルトポリシーの場合:
+ タグをクロスリージョンコピーにコピーすることはできません。
+ コピーには、ソーススナップショットと同じ保持期間が使用されます。
+ コピーは、ソーススナップショットと同じ暗号化状態を取得します。送信先リージョンで暗号化がデフォルトで有効になっている場合、ソーススナップショットが暗号化されていなくても、コピーは常に暗号化されます。コピーは、送信先リージョンのデフォルト KMS キーで常に暗号化されます。

2 デフォルトポリシーとカスタムポリシーの場合:
+ ターゲットインスタンスまたはボリュームが削除された場合、Amazon Data Lifecycle Manager は、保持期間に基づいて、最後の 1 つ前のスナップショットまで削除し続けます。デフォルトポリシーでは、削除を拡張して、最後のスナップショットを含めるようにできます。
+ ポリシーが削除されるか、エラーまたは無効状態になると、Amazon Data Lifecycle Manager はスナップショットの削除を停止します。デフォルトポリシーでは、削除を拡張して、最後の 1 つを含むスナップショットの削除を続行できます。

## EBS-backed AMI ポリシーの比較
<a name="ami-policy-diffs"></a>

次の表は、EBS-backed AMI のデフォルトポリシーとカスタム EBS-backed AMI ポリシーの違いを示しています。


| 機能 | EBS-backed AMI のデフォルトポリシー | カスタム EBS-backed AMI ポリシー | 
| --- | --- | --- | 
| マネージドバックアップリソース | EBS-backed AMI | EBS-backed AMI | 
| ターゲットリソースタイプ | インスタンス | インスタンス | 
| リソースターゲット設定 | 最新の AMI がないリージョン内のすべてのインスタンスをターゲットとします。除外パラメータを指定して特定のインスタンスを除外できます。 | 特定のタグを持つインスタンスのみをターゲットとします。 | 
| AMI 作成前のインスタンスの再起動 | いいえ | はい | 
| 除外パラメータ | はい。特定のタグが付いたインスタンスを除外できます。 | いいえ | 
| 複数のスケジュールのサポート | いいえ | はい。ポリシーごとに最大 4 つのスケジュールまで。 | 
| AMI の作成頻度 | 1～7 日おき。 | 毎日、毎週、毎月、毎年、または cron 式を使用したカスタム頻度。 | 
| サポートされている保持タイプ | 経過期間ベースの保持のみ。 | 経過期間ベースの保持とカウントベースの保持。 | 
| AMI 保持 | 2～14 日。 | 最大 1000 個 の AMI (カウントベース) または最大 100 年 (経過期間ベース)。 | 
| AMI の非推奨サポート | いいえ | はい | 
| クロスリージョンでのコピーのサポート | はい。デフォルト設定を使用 1 | はい。カスタム設定を使用 | 
| 拡張削除のサポート 2 | はい | いいえ | 

1 デフォルトポリシーの場合:
+ タグをクロスリージョンコピーにコピーすることはできません。
+ コピーには、ソース AMI と同じ保持期間が使用されます。
+ コピーには、ソース AMI と同じ暗号化状態を適用します。送信先リージョンで暗号化がデフォルトで有効になっている場合、ソース AMI が暗号化されていない場合でも、コピーは常に暗号化されます。コピーは、送信先リージョンのデフォルト KMS キーで常に暗号化されます。

2 デフォルトポリシーとカスタムポリシーの場合:
+ ターゲットインスタンスが終了した場合、Amazon Data Lifecycle Manager は、保持期間に基づいて、最後の 1 つ前の AMI まで登録解除し続けます。デフォルトポリシーでは、登録解除を拡張して、最後の AMI を含めるようにできます。
+ ポリシーが削除されるか、エラーまたは無効状態になると、Amazon Data Lifecycle Manager は AMI の登録解除を停止します。デフォルトポリシーでは、削除を拡張して、最後の 1 つを含む AMI の登録解除を続行できます。

# Amazon Data Lifecycle Manager のデフォルトポリシーを作成する
<a name="default-policies"></a>

インスタンスから EBS-backed AMI を定期的に作成する場合、EBS-backed AMI のデフォルトポリシーを使用します。アタッチ状態に関係なくすべてのボリュームのスナップショットを作成する場合、または特定のボリュームを除外する場合は、EBS スナップショットのデフォルトポリシーを使用します。

このセクションでは、デフォルトポリシーを作成する方法について説明します。

**Topics**
+ [デフォルトポリシーに関する考慮事項](#default-policy-considerations)
+ [Amazon EBS スナップショットのデフォルトポリシーを作成する](#default-snapshot-policy)
+ [EBS-backed AMI のデフォルトポリシーを作成する](#default-ami-policy)
+ [アカウントとリージョン間でデフォルトポリシーを有効にする](dlm-stacksets.md)

## デフォルトポリシーに関する考慮事項
<a name="default-policy-considerations"></a>

デフォルトポリシーを使用する際には、次の点に注意してください。
+ デフォルトポリシーでは、最近のバックアップ (スナップショットまたは AMI) があるターゲットリソース (インスタンスまたはボリューム) をバックアップしません。作成頻度によって、どのリソースがバックアップされるかが決まります。ボリュームまたはインスタンスは、最新のスナップショットまたは AMI がポリシーの作成頻度よりも古い場合にのみバックアップされます。例えば、作成頻度を 3 日に指定した場合、EBS スナップショットのデフォルトポリシーでは、最新のスナップショットが 3 日より前のボリュームのスナップショットのみが作成されます。
+ デフォルトでは、除外パラメータが指定されていない限り、デフォルトポリシーはそのリージョン内のすべてのインスタンスまたはボリュームをターゲットとします。
+ デフォルトポリシーでは、一意のスナップショットの最小セットを作成します。例えば、EBS-backed AMI ポリシーと EBS スナップショットポリシーを有効にした場合、スナップショットポリシーでは、EBS-backed AMI ポリシーで既にバックアップされているボリュームのスナップショットを複製しません。
+ デフォルトポリシーでは、24 時間以上経過したリソースのみをターゲットにし始めます。
+ ボリュームを削除するか、デフォルトポリシーのターゲットとなるインスタンスを終了すると、Amazon Data Lifecycle Manager は、保持期間に従って、それまで作成されたバックアップ (スナップショットまたは AMI) を最後の 1 つ前のバックアップまで削除し続けます。必要がない場合は、このバックアップを手動で削除する必要があります。

  Amazon Data Lifecycle Manager で最後のバックアップを削除する場合は、*[削除を延長]* を有効にします。
+ デフォルトポリシーが削除されるか、エラーまたは無効状態になると、Amazon Data Lifecycle Manager は以前に作成されたバックアップ (スナップショットまたは AMI) の削除を停止します。Amazon Data Lifecycle Manager で、最後の 1 つを含むバックアップの削除を続行する場合は、ポリシーを削除する前、またはポリシーの状態が「無効」または「削除済み」に変わる前に、*[削除を延長]* を有効にする必要があります。
+ デフォルトポリシーを作成して有効にすると、Amazon Data Lifecycle Manager はターゲットリソースを 4 時間の時間ウィンドウにランダムに割り当てます。ターゲットリソースは、割り当てられたウィンドウ中に、指定した作成頻度でバックアップされます。例えば、ポリシーの作成頻度が 3 日で、ターゲットリソースが 12 時～16 時のウィンドウに割り当てられている場合、そのリソースは 3 日ごとに 12 時～16 時の間にバックアップされます。

## Amazon EBS スナップショットのデフォルトポリシーを作成する
<a name="default-snapshot-policy"></a>

次の手順では、EBS スナップショットのデフォルトポリシーを作成する方法を示します。

------
#### [ Console ]

**EBS スナップショットのデフォルトポリシーを作成するには**

1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。

1. ナビゲーションパネルで、**[ライフサイクルマネージャー]**、**[ライフサイクルポリシーの作成]** の順に選択します。

1. **[ポリシータイプ]** で **[デフォルトポリシー]** を選択し、次に **[EBS スナップショットポリシー]** を選択します。

1. [**説明**] にポリシーの簡単な説明を入力します。

1. **[IAM ロール]** で、スナップショットを管理する許可を持つ IAM ロールを選択します。

   Amazon Data Lifecycle Manager が提供するデフォルトの IAM ロールを使用する場合は、**[デフォルト]** を選択することをお勧めします。ただし、以前に作成したカスタム IAM ロールを使用することもできます。

1. **[作成頻度]** で、ポリシーを実行してボリュームのスナップショットを作成する頻度を指定します。

   指定する頻度によって、どのボリュームをバックアップするかも決まります。このポリシーにより、指定した頻度内に他の手段でバックアップされていないボリュームのみがバックアップされます。例えば、作成頻度を 3 日に指定した場合、このポリシーでは、過去 3 日以内にバックアップされていないボリュームのスナップショットのみが作成されます。

1. **[保持期間]** には、作成されたスナップショットをポリシーで保持する期間を指定します。スナップショットが保持しきい値に達すると、自動的に削除されます。保持期間は、作成頻度と同じか長くする必要があります。

1. (*オプション*) **[除外パラメータ]** を設定すると、スケジュールされたバックアップから特定のボリュームを除外できます。除外されたボリュームは、ポリシー実行時にバックアップされません。

   1. ブートボリュームを除外するには、**[ブート・ボリュームを除外]** を選択します。ブートボリュームを除外すると、データ (非ブート) ボリュームのみがポリシーでバックアップされます。つまり、インスタンスにブートボリュームとしてアタッチされているボリュームのスナップショットは作成されません。

   1. 特定のボリュームタイプを除外するには、**[特定のボリュームタイプを除外]** を選択し、除外するボリュームタイプを選択します。残りのタイプのボリュームのみがポリシーでバックアップされます。

   1. 特定のタグを持つボリュームを除外するには、**[タグを追加]** を選択し、タグのキーと値を指定します。このポリシーでは、指定したタグのいずれかを持つボリュームのスナップショットは作成されません。

1. (*オプション*) **[詳細設定]** で、ポリシーで実行する必要があるその他のアクションを指定します。

   1. 割り当てられたタグをソースボリュームからスナップショットにコピーするには、**[ボリュームからタグをコピー]** を選択します。

   1. **[拡張削除]** を無効にした場合:
      + ソースボリュームが削除された場合、Amazon Data Lifecycle Manager は、保持期間に基づいて、それまで作成された、最後の 1 つ前のスナップショットまで削除し続けます。Amazon Data Lifecycle Manager で、最後の 1 つを含むすべてのスナップショットを削除する場合は、**[拡張削除]** を選択します。
      + ポリシーが削除されるか、`error` または `disabled` 状態になると、Amazon Data Lifecycle Manager はスナップショットの削除を停止します。Amazon Data Lifecycle Manager で、最後の 1 つを含むスナップショットの削除を続行する場合は、**[拡張削除]** を選択します。
**注記**  
[拡張削除] を有効にすると、上記の両方の動作が同時にオーバーライドされます。

   1. ポリシーによって作成されたスナップショットを他のリージョンにコピーするには、**[クロスリージョンコピーを作成]** を選択し、送信先リージョンを最大 3 つ選択します。
      + ソーススナップショットが暗号化されている場合、または送信先リージョンで暗号化がデフォルトで有効になっている場合には、コピーされたスナップショットは、送信先リージョンの EBS 暗号化用のデフォルト KMS キーを使用して暗号化されます。
      + ソーススナップショットが暗号化されておらず、送信先リージョンで暗号化がデフォルトで無効になっている場合、コピーされたスナップショットは暗号化されません。

1. (*オプション*) ポリシーにタグを追加するには、**[タグを追加]** を選択し、タグのキーと値のペアを指定します。

1. **[デフォルトポリシーの作成]** を選択します。
**注記**  
`Role with name AWSDataLifecycleManagerDefaultRole already exists` エラーが発生した場合、詳細については「[Amazon Data Lifecycle Manager の問題のトラブルシューティング](dlm-troubleshooting.md)」を参照してください。

------
#### [ AWS CLI ]

**EBS スナップショットのデフォルトポリシーを作成するには**  
[create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html) コマンドを使用します。ユースケースやプリファレンスに応じて、次の 2 つの方式のいずれかでリクエストパラメータを指定できます。
+ **方式 1**

  ```
  $ aws dlm create-lifecycle-policy \
  --state ENABLED | DISABLED \
  --description "policy_description" \
  --execution-role-arn role_arn \
  --default-policy VOLUME \
  --create-interval creation_frequency_in_days (1-7) \
  --retain-interval retention_period_in_days (2-14) \
  --copy-tags | --no-copy-tags \
  --extend-deletion | --no-extend-deletion \
  --cross-region-copy-targets TargetRegion=destination_region_code \
  --exclusions ExcludeBootVolumes=true | false, ExcludeTags=[{Key=tag_key,Value=tag_value}], ExcludeVolumeTypes="standard | gp2 | gp3 | io1 | io2 | st1 | sc1"
  ```

  例えば、リージョン内のすべてのボリュームをターゲットとし、デフォルトの IAM ロールを使用し、毎日実行し (デフォルト)、スナップショットを 7 日間保持する (デフォルト) という設定の EBS スナップショットのデフォルトポリシーを作成する場合は、次のパラメータを指定する必要があります。

  ```
  $ aws dlm create-lifecycle-policy \
  --state ENABLED \
  --description "Daily default snapshot policy" \
  --execution-role-arn arn:aws:iam::account_id:role/AWSDataLifecycleManagerDefaultRole \
  --default-policy VOLUME
  ```
+ **方式 2**

  ```
  $ aws dlm create-lifecycle-policy \
  --state ENABLED | DISABLED \
  --description "policy_description" \
  --execution-role-arn role_arn \
  --default-policy VOLUME \
  --policy-details file://policyDetails.json
  ```

  ここで `policyDetails.json` には以下が含まれます。

  ```
  {
      "PolicyLanguage": "SIMPLIFIED",
      "PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
      "ResourceType": "VOLUME",
      "CopyTags": true | false,
      "CreateInterval": creation_frequency_in_days (1-7),
      "RetainInterval": retention_period_in_days (2-14),
      "ExtendDeletion": true | false, 
      "CrossRegionCopyTargets": [{"TargetRegion":"destination_region_code"}],
      "Exclusions": {
          "ExcludeBootVolume": true | false,
  		"ExcludeVolumeTypes": ["standard | gp2 | gp3 | io1 | io2 | st1 | sc1"],
          "ExcludeTags": [{ 
              "Key": "exclusion_tag_key",
              "Value": "exclusion_tag_value"
          }]
      }
  }
  ```

------

## EBS-backed AMI のデフォルトポリシーを作成する
<a name="default-ami-policy"></a>

次の手順では、EBS-backed AMI のデフォルトポリシーを作成する方法を示します。

------
#### [ Console ]

**EBS-backed AMI のデフォルトポリシーを作成するには**

1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。

1. ナビゲーションパネルで、**[ライフサイクルマネージャー]**、**[ライフサイクルポリシーの作成]** の順に選択します。

1. **[ポリシータイプ]** に **[デフォルトポリシー]** を選択し、次に **[EBS-backed AMI ポリシー]** を選択します。

1. [**説明**] にポリシーの簡単な説明を入力します。

1. **[IAM ロール]** で、AMI を管理する許可を持つ IAM ロールを選択します。

   Amazon Data Lifecycle Manager が提供するデフォルトの IAM ロールを使用する場合は、**[デフォルト]** を選択することをお勧めします。ただし、以前に作成したカスタム IAM ロールを使用することもできます。

1. **[作成頻度]** では、ポリシーを実行してインスタンスから AMI を作成する頻度を指定します。

   指定する頻度によって、どのインスタンスがバックアップされるかも決まります。このポリシーにより、指定した頻度内に他の手段でバックアップされていないインスタンスのみがバックアップされます。例えば、作成頻度を 3 日に指定した場合、このポリシーでは、過去 3 日以内にバックアップされていないインスタンスからのみ AMI が作成されます。

1. **[保持期間]** には、作成された AMI をポリシーで保持する期間を指定します。AMI が保持しきい値に達すると、その AMI は自動的に登録解除され、関連付けられているスナップショットが削除されます。保持期間は、作成頻度と同じか長くする必要があります。

1. (*オプション*) **[除外パラメータ]** を設定すると、スケジュールされたバックアップから特定のインスタンスを除外できます。除外されたインスタンスは、ポリシー実行時にバックアップされません。

   1. 特定のタグを持つインスタンスを除外するには、**[タグを追加]** を選択し、タグのキーと値を指定します。このポリシーでは、指定したタグのいずれかを持つインスタンスからは AMI が作成されません。

1. (*オプション*) **[詳細設定]** で、ポリシーで実行する必要があるその他のアクションを指定します。

   1. 割り当てられたタグをソースインスタンスからその AMI にコピーするには、**[インスタンスからタグをコピー]** を選択します。

   1. **[拡張削除]** を無効にした場合:
      + ソースインスタンスが終了した場合、Amazon Data Lifecycle Manager は、保持期間に基づいて、それまで作成された、最後の 1 つ前の AMI まで登録解除し続けます。Amazon Data Lifecycle Manager で、最後の 1 つを含むすべての AMI の登録を解除する場合は、**[拡張削除]** を選択します。
      + ポリシーが削除されるか、`error` または `disabled` 状態になると、Amazon Data Lifecycle Manager は AMI の登録解除を停止します。Amazon Data Lifecycle Manager で、最後の 1 つを含む AMI の登録解除を続行する場合は、**[拡張削除]** を選択します。
**注記**  
拡張削除を有効にすると、上記の両方の動作が同時にオーバーライドされます。

   1. ポリシーによって作成された AMI を他のリージョンにコピーするには、**[クロスリージョンコピーを作成]** を選択し、送信先リージョンを最大 3 つ選択します。
      + ソース AMI が暗号化されている場合、または送信先リージョンで暗号化がデフォルトで有効になっている場合には、コピーされた AMI は、送信先リージョンの EBS 暗号化用のデフォルト KMS キーを使用して暗号化されます。
      + ソース AMI が暗号化されておらず、送信先リージョンで暗号化がデフォルトで無効になっている場合、コピーされた AMI は暗号化されません。

1. (*オプション*) ポリシーにタグを追加するには、**[タグを追加]** を選択し、タグのキーと値のペアを指定します。

1. **[デフォルトポリシーの作成]** を選択します。
**注記**  
`Role with name AWSDataLifecycleManagerDefaultRoleForAMIManagement already exists` エラーが発生した場合、詳細については「[Amazon Data Lifecycle Manager の問題のトラブルシューティング](dlm-troubleshooting.md)」を参照してください。

------
#### [ AWS CLI ]

**EBS-backed AMI のデフォルトポリシーを作成するには**  
[create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html) コマンドを使用します。ユースケースやプリファレンスに応じて、次の 2 つの方式のいずれかでリクエストパラメータを指定できます。
+ **方式 1**

  ```
  $ aws dlm create-lifecycle-policy \
  --state ENABLED | DISABLED \
  --description "policy_description" \
  --execution-role-arn role_arn \
  --default-policy INSTANCE \
  --create-interval creation_frequency_in_days (1-7) \
  --retain-interval retention_period_in_days (2-14) \
  --copy-tags | --no-copy-tags \
  --extend-deletion | --no-extend-deletion \
  --cross-region-copy-targets TargetRegion=destination_region_code \
  --exclusions ExcludeTags=[{Key=tag_key,Value=tag_value}]
  ```

  例えば、リージョン内のすべてのインスタンスをターゲットとし、デフォルトの IAM ロールを使用し、毎日実行し (デフォルト)、AMI を 7 日間保持する (デフォルト) という設定の EBS-backed AMI のデフォルトポリシーを作成する場合は、次のパラメータを指定する必要があります。

  ```
  $ aws dlm create-lifecycle-policy \
  --state ENABLED \
  --description "Daily default AMI policy" \
  --execution-role-arn arn:aws:iam::account_id:role/AWSDataLifecycleManagerDefaultRoleForAMIManagement \
  --default-policy INSTANCE
  ```
+ **方式 2**

  ```
  $ aws dlm create-lifecycle-policy \
  --state ENABLED | DISABLED \
  --description "policy_description" \
  --execution-role-arn role_arn \
  --default-policy INSTANCE \
  --policy-details file://policyDetails.json
  ```

  ここで `policyDetails.json` には以下が含まれます。

  ```
  {
      "PolicyLanguage": "SIMPLIFIED",
      "PolicyType": "IMAGE_MANAGEMENT",
      "ResourceType": "INSTANCE",
      "CopyTags": true | false,
      "CreateInterval": creation_frequency_in_days (1-7),
      "RetainInterval": retention_period_in_days (2-14),
      "ExtendDeletion": true | false, 
  	"CrossRegionCopyTargets": [{"TargetRegion":"destination_region_code"}],
      "Exclusions": {
          "ExcludeTags": [{ 
              "Key": "exclusion_tag_key",
              "Value": "exclusion_tag_value"
          }]
      }
  }
  ```

------

# アカウントとリージョン間で Data Lifecycle Manager のデフォルトポリシーを有効にする
<a name="dlm-stacksets"></a>

 CloudFormation StackSets を使用すると、1 回のオペレーションで複数のアカウントと AWS リージョンで Amazon Data Lifecycle Manager のデフォルトポリシーを有効にできます。

StackSets を使用して、次のいずれかの方法でデフォルトポリシーを有効にすることができます。
+ ** AWS 組織全体** — 組織全体または AWS 組織内の特定の組織単位にわたって、デフォルトのポリシーが一貫して有効になり、設定されていることを確認します。これは、*サービス管理のアクセス許可*を使用して行われます。 CloudFormation StackSets は、ユーザーに代わって必要な IAM ロールを作成します。
+ **特定の AWS アカウント全体** — 特定のターゲットアカウント間でデフォルトポリシーが一貫して有効になり、設定されていることを確認します。これには、*セルフマネージドアクセス許可*が必要です。StackSet 管理者アカウントとターゲットアカウント間の信頼関係を確立するために必要な IAM ロールを作成します。

詳細については、「*AWS CloudFormation ユーザーガイド*」の「[スタックセット用のアクセス許可モデル](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html#stacksets-concepts-stackset-permission-models)」を参照してください。

次の手順を使用して、 AWS 組織全体、特定の OUs、または特定のターゲットアカウントで Amazon Data Lifecycle Manager のデフォルトポリシーを有効にします。

**前提条件**

デフォルトポリシーを有効にする方法に応じて、以下のいずれかを実行します。
+ ( AWS 組織全体) [組織内のすべての機能を有効に](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html)し、 [で信頼されたアクセスを有効にする AWS Organizations](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-activate-trusted-access.html)必要があります。組織の管理アカウントまたは[委任管理者アカウント](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-delegated-admin.html)にサインインする必要があります。
+ (特定のターゲットアカウント全体) StackSet 管理者アカウントとターゲットアカウントの間に信頼関係を確立するために必要なロールを作成して、[セルフマネージドアクセス許可を付与](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-prereqs-self-managed.html)する必要があります。

------
#### [ Console ]

**AWS 組織全体または特定のターゲットアカウントでデフォルトポリシーを有効にするには**

1. [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) で CloudFormation コンソールを開きます。

1. ナビゲーションペインで **[StackSets]**、**[StackSet を作成]** の順に選択します。

1. **[アクセス許可]** で、デフォルトのポリシーを有効にする方法に応じて、次のいずれかを実行します。
   + ( AWS 組織全体) **サービス管理のアクセス許可**を選択します。
   + (特定のターゲットアカウント全体) **[セルフサービスアクセス許可]** を選択します。次に、**[IAM 管理ロール ARN]** で管理者アカウント用に作成した IAM サービスロールを選択し、**[IAM 実行ロール名]** にターゲットアカウントで作成した IAM サービスロールの名前を入力します。

1. **[テンプレートの準備]** で **[サンプルテンプレートを使用]** を選択します。

1. **[サンプルテンプレート]** で次のいずれかを実行します。
   + (EBS スナップショットのデフォルトポリシー) **[EBS スナップショットの Amazon Data Lifecycle Manager デフォルトポリシーの作成]** を選択します。
   + (EBS-backed AMI のデフォルトポリシー) **[EBS-backed AMI の Amazon Data Lifecycle Manager デフォルトポリシーの作成]** を選択します。

1. [**次へ**] を選択します。

1. **[StackSet 名]** と **[StackSet の説明]** に、わかりやすい名前と簡単な説明を入力します。

1. **[パラメータ]** セクションで、必要に応じてデフォルトのポリシー設定を設定します。
**注記**  
重要なワークロードの場合、**CreateInterval = 1 日**、**RetainInterval = 7 日**をお勧めします。

1. [**次へ**] を選択します。

1. (オプション) **[タグ]** では、StackSet とスタックリソースを識別するのに役立つタグを指定します。

1. **[マネージド型の実行]** の場合は、**[アクティブ]** を選択します。

1. [**次へ**] を選択します。

1. **[Add stacks to stack set]** (スタックセットにスタックを追加) で、**[Deploy new stacks]** (新しいスタックのデプロイ) を選択します。

1. デフォルトポリシーを有効にする方法に応じて、以下のいずれかを実行します。
   + ( AWS 組織全体) **デプロイターゲット**では、次のいずれかのオプションを選択します。
     +  AWS 組織全体にデプロイするには、**組織へのデプロイ**を選択します。
     + 特定の組織単位 (OU) にデプロイするには、**[組織単位 (OU) へのデプロイ]** を選択し、**[OU ID]** に OU ID を入力します。OU を追加するには、**[別の OU を追加]** を選択します。
   + (特定のターゲットアカウント全体) **[アカウント]** の場合は、次のいずれかを実行します。
     + 特定のターゲットアカウントにデプロイするには、**[スタックをアカウントにデプロイ]** を選択し、**[アカウント番号]** にターゲットアカウントの ID を入力します。
     + 特定の OU 内のすべてのアカウントにデプロイするには、**[スタックを組織単位内のすべてのアカウントにデプロイ]** を選択し、**[組織番号]** にターゲット OU の ID を入力します。

1. **[自動デプロイ]** で、**[アクティブ化済み]** を選択します。

1. **[アカウント削除の動作]** で、**[スタックを保持]** を選択します。

1. **[リージョンの指定]** では、デフォルトポリシーを有効にする特定のリージョンを選択するか、**[すべてのリージョンを追加]** を選択してすべてのリージョンでデフォルトポリシーを有効にします。

1. [**次へ**] を選択します。

1. スタックセット設定を確認し、 **が IAM リソースを作成する CloudFormation 可能性があることを確認**してから、**送信**を選択します。

------
#### [ AWS CLI ]

**AWS 組織全体でデフォルトポリシーを有効にするには**

1. スタックセットを作成します。[create-stack-set](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/create-stack-set.html) コマンドを使用します。

   `--permission-model` の場合、`SERVICE_MANAGED` を指定します。

   `--template-url` で、次のいずれかのテンプレート URL を指定します。
   + (EBS-backed AMI のデフォルトポリシー) `https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/DataLifecycleManagerAMIDefaultPolicy.yaml`
   + (EBS スナップショットのデフォルトポリシー) `https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/DataLifecycleManagerEBSSnapshotDefaultPolicy.yaml`

   `--parameters` で、デフォルトポリシーの設定を指定します。サポートされているパラメータ、パラメータの説明、および有効な値については、URL を使用してテンプレートをダウンロードし、テキストエディタを使用してテンプレートを表示します。

   `--auto-deployment` の場合、`Enabled=true, RetainStacksOnAccountRemoval=true` を指定します。

   ```
   $ aws cloudformation create-stack-set \
   --stack-set-name stackset_name \
   --permission-model SERVICE_MANAGED \
   --template-url template_url \
   --parameters "ParameterKey=param_name_1,ParameterValue=param_value_1" "ParameterKey=param_name_2,ParameterValue=param_value_2" \
   --auto-deployment "Enabled=true, RetainStacksOnAccountRemoval=true"
   ```

1. スタックセットをデプロイします。[create-stack-instances](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/create-stack-instances.html) コマンドを使用します。

   `--stack-set-name` で、前のステップで作成したスタックセットの名前を指定します。

   `--deployment-targets OrganizationalUnitIds` で、組織全体にデプロイするルート OU の ID、または組織内の特定の OU にデプロイする OU ID を指定します。

   で`--regions`、デフォルトポリシーを有効にする AWS リージョンを指定します。

   ```
   $ aws cloudformation create-stack-instances \
   --stack-set-name stackset_name \
   --deployment-targets OrganizationalUnitIds='["root_ou_id"]' | '["ou_id_1", "ou_id_2]' \
   --regions '["region_1", "region_2"]'
   ```

**特定のターゲットアカウント間でデフォルトポリシーを有効にするには**

1. スタックセットを作成します。[create-stack-set](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/create-stack-set.html) コマンドを使用します。

   `--template-url` で、次のいずれかのテンプレート URL を指定します。
   + (EBS-backed AMI のデフォルトポリシー) `https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/DataLifecycleManagerAMIDefaultPolicy.yaml`
   + (EBS スナップショットのデフォルトポリシー) `https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/DataLifecycleManagerEBSSnapshotDefaultPolicy.yaml`

   `--administration-role-arn` で、スタックセット管理者用に以前に作成した IAM サービスロールの ARN を指定します。

   `--execution-role-name` で、ターゲットアカウントで作成した IAM サービスロールの名前を指定します。

   `--parameters` で、デフォルトポリシーの設定を指定します。サポートされているパラメータ、パラメータの説明、および有効な値については、URL を使用してテンプレートをダウンロードし、テキストエディタを使用してテンプレートを表示します。

   `--auto-deployment` の場合、`Enabled=true, RetainStacksOnAccountRemoval=true` を指定します。

   ```
   $ aws cloudformation create-stack-set \
   --stack-set-name stackset_name \
   --template-url template_url \
   --parameters "ParameterKey=param_name_1,ParameterValue=param_value_1" "ParameterKey=param_name_2,ParameterValue=param_value_2" \
   --administration-role-arn administrator_role_arn \
   --execution-role-name target_account_role \									
   --auto-deployment "Enabled=true, RetainStacksOnAccountRemoval=true"
   ```

1. スタックセットをデプロイします。[create-stack-instances](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/create-stack-instances.html) コマンドを使用します。

   `--stack-set-name` で、前のステップで作成したスタックセットの名前を指定します。

   には`--accounts`、ターゲット AWS アカウントの IDs を指定します。

   で`--regions`、デフォルトポリシーを有効にする AWS リージョンを指定します。

   ```
   $ aws cloudformation create-stack-instances \
   --stack-set-name stackset_name \
   --accounts '["account_ID_1","account_ID_2"]' \
   --regions '["region_1", "region_2"]'
   ```

------

# EBS スナップショット用の Amazon Data Lifecycle Manager カスタムポリシーを作成
<a name="snapshot-ami-policy"></a>

以下の手順では、Amazon Data Lifecycle Manager を使用して Amazon EBS スナップショットのライフサイクルを自動化する方法を示します。

**Topics**
+ [スナップショットライフサイクルポリシーを作成する](#create-snap-policy)
+ [スナップショットライフサイクルポリシーに関する考慮事項](#snapshot-considerations)
+ [その他のリソース](#snapshot-additional-resources)
+ [アプリケーション整合性のあるスナップショットを自動化](automate-app-consistent-backups.md)
+ [事前スクリプトと事後スクリプトのその他のユースケース](script-other-use-cases.md)
+ [事前スクリプトと事後スクリプトの仕組み](script-flow.md)
+ [事前スクリプトと事後スクリプトで作成されたスナップショットの識別](dlm-script-tags.md)
+ [事前スクリプトと事後スクリプトをモニタリング](dlm-script-monitoring.md)

## スナップショットライフサイクルポリシーを作成する
<a name="create-snap-policy"></a>

スナップショットのライフサイクルポリシーを作成するには、次のいずれかの手順を使用します。

------
#### [ Console ]

**スナップショットのポリシーを作成するには**

1. Amazon EC2 コンソール ([https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)) を開きます。

1. ナビゲーションペインで、[**Elastic Block Store**]、[**ライフサイクルマネージャー**]、[**ライフサイクルポリシーの作成**] の順に選択します。

1. リポジトリの [**ポリシータイプの選択**] 画面で、[**EBS スナップショットポリシー**] を選択し、[**次へ**] をクリックします。

1. **[Target resources]** (ターゲットリソース) セクションで、以下の操作を行います。

   1. **[Target resource types]** (ターゲットリソースタイプ) で、バックアップするリソースの種類を選択します。`Volume` を選択して個々のボリュームのスナップショットを作成するか、`Instance` を選択してインスタンスにアタッチされたボリュームからマルチボリュームスナップショットを作成します。

   1. (*Outpost およびローカルゾーンのお客様のみ*) ターゲットリソースが存在する場所を指定します。

      **[ターゲットリソースの場所]** で、ターゲットリソースが存在する場所を指定します。
      + リージョン内のリソースをターゲットにするには、[**AWS リージョン**] を選択します。Amazon Data Lifecycle Manager は、現在のリージョン内で、一致するターゲットタグを持つ、指定されたタイプのすべてのリソースをバックアップします。スナップショットは同じリージョンに作成されます。
      + ローカルゾーン内のリソースをターゲットにするには、[**AWS ローカルゾーン**] を選択します。Amazon Data Lifecycle Manager は、現在のリージョン内のすべてのローカルゾーンで、一致するターゲットタグを持つ、指定されたタイプのすべてのリソースをバックアップします。スナップショットは、ソースリソースと同じローカルゾーン、またはその親リージョンに作成できます。
      + Outpost のリソースをターゲットにするには、[**AWS Outpost**] を選択します。Amazon Data Lifecycle Manager は、アカウントのすべての Outposts で、一致するターゲットタグを持つ、指定されたタイプのすべてのリソースをバックアップします。スナップショットは、ソースリソースと同じ Outpost、またはその親リージョンに作成できます。

   1. **[Target resource tags]** (ターゲットリソースタグ) で、バックアップするボリュームもしくはインスタンスを識別する、リソースタグを選択します。ポリシーでは、指定されたタグキーと値のペアを持つリソースのみがバックアップされます。

1. [**説明**] にポリシーの簡単な説明を入力します。

1. [**IAM ロール**] では、スナップショットの管理、ならびにボリュームとインスタンスの記述に必要な、アクセス許可を持つ IAM ロールを選択します。Amazon Data Lifecycle Manager が提供するデフォルトのロールを使用するには、[**デフォルトのロール**] を選択します。以前に作成したカスタム IAM ロールを使用する場合には、[**別のロールを選択**] をクリックした上で、使用するロールを選択します。

1. [**ポリシータグ**] に、ライフサイクルポリシーに適用されるタグを追加します。これらのタグは、ポリシーを識別および分類するために使用することができます。

1. **[Policy status]** (ポリシーステータス) では、**[Enable]** (有効化) を選択すると、次のスケジュールした時刻にポリシーが実行されます。ポリシーが実行されないようにするには、**[Disable policy]** (ポリシーの無効化) を選択します。ここでポリシーを有効にしない場合、作成後に手動で有効にするまで、スナップショットの作成は開始されません。

1. (*インスタンスのみをターゲットとするポリシー*) ボリュームをマルチボリュームスナップショットセットから除外します。

   デフォルトでは、Amazon Data Lifecycle Manager は、ターゲットインスタンスにアタッチされたすべてのボリュームのスナップショットを作成します。ただし、アタッチされたボリュームのサブセットのスナップショットを作成することもできます。**[Parameters]** (パラメータ) セクションで、次を実行します。
   + ターゲットインスタンスにアタッチされたルートボリュームのスナップショットを作成しない場合は、**[Exclude root volume]** (ルートボリュームを除外) を選択します。このオプションを選択すると、ターゲットインスタンスにアタッチされているデータ (非ルート) ボリュームのみがマルチボリュームスナップショットセットに含まれます。
   + ターゲットインスタンスにアタッチされたデータ (非ルート) ボリュームのサブセットのスナップショットを作成する場合は、**[Exclude specific data volumes]** (特定のデータボリュームを除外) を選択し、スナップショットを作成しないデータボリュームを識別するために使用するタグを指定します。Amazon Data Lifecycle Manager は、指定されたタグのいずれかを含むデータボリュームのスナップショットを作成しません。Amazon Data Lifecycle Manager は、指定されたタグを持たないデータボリュームのスナップショットのみを作成します。

1. [**次へ**] を選択します。

1. [**スケジュールの設定**] 画面で、ポリシースケジュールを設定します。ポリシーには、最大 4 つのスケジュールを含めることができます。スケジュール 1 は必須です。スケジュール 2、3、および 4 はオプションです。追加したポリシースケジュールごとに、以下の操作を行います。

   1. [**スケジュールの詳細**] セクションで、次の操作を行います。

      1. [**スケジュール名**] で、スケジュールの分かりやすい名前を指定します。

      1. [**頻度**]とそれに関連するフィールドで、ポリシーの実行間隔を設定します。

         ポリシーの実行は、日次、週次、月次、年次のいずれかのスケジュールで設定できます。または、[**カスタム cron 式**] をクリックし、最長 1 年の間隔を指定します。詳細については、「*Amazon EventBridge ユーザーガイド*」の「[Setting a schedule pattern for scheduled rules (legacy) in Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-scheduled-rule-pattern.html)」を参照してください。
**注記**  
スケジュールに対し**スナップショットのアーカイブ**を有効にする必要がある場合は、その頻度に、**[monthly]** (毎月) または **[yearly]** (毎年) のいずれかを選択する必要があります。または、作成頻度が 28 日以上の CRON 式を指定します。  
頻度を毎月とし、特定の週の特定の日 (例えば、その月の第 2 木曜日) にスナップショットを作成する場合、カウントベースのスケジュールでは、アーカイブ階層の保存回数は 4 以上にする必要があります。

      1. [**開始時刻**] では、ポリシー実行の開始予定時刻を指定します。初回のポリシー実行は、予定時刻から 1 時間以内に開始されます。時刻は、`hh:mm` UTC 形式で入力する必要があります。

      1. [**保持タイプ**] では、スケジュールによって作成されるスナップショットの保持ポリシーを指定します。

         スナップショットは、総数または期間に基づいて保持できます。
         + カウントベースの保持
           + スナップショットアーカイブを無効にすると、範囲は `1`～`1000` になります。保持期間がしきい値に達すると、最も古いスナップショットは完全に削除されます。
           + スナップショットアーカイブを有効にすると、範囲は `0` (作成直後にアーカイブ) ～`1000` になります。保持期間がしきい値に達すると、最も古いスナップショットは完全なスナップショットに変換され、アーカイブ階層に移動します。
         + 年齢に基づく保持
           + スナップショットアーカイブを無効にすると、範囲は `1` 日～`100` 年になります。保持期間がしきい値に達すると、最も古いスナップショットは完全に削除されます。
           + スナップショットアーカイブを有効にすると、範囲は `0` 日 (作成直後にアーカイブ) ～`100` 年になります。保持期間がしきい値に達すると、最も古いスナップショットは完全なスナップショットに変換され、アーカイブ階層に移動します。
**注記**  
すべてのスケジュールは、同じ保持タイプ (期間ベースまたはカウントベース) にする必要があります。保持タイプを指定できるのは、スケジュール 1 のみです。スケジュール 2、3、4 は、スケジュール 1 から保持タイプを継承します。各スケジュールには、独自の保持回数または期間を設定できます。
高速スナップショット復元、クロスリージョンコピー、またはスナップショットの共有を有効にする場合は、保持回数で `1`　以上を、または保持期間で `1` 日以上を指定する必要があります。

      1. (*AWS Outposts および Local Zone のお客様のみ*) スナップショットの送信先を指定します。

         **[スナップショットの送信先]** で、ポリシーによって作成されるスナップショットの送信先を指定します。
         + ポリシーがリージョン内のリソースを対象とする場合、スナップショットは同じリージョンに作成する必要があります。 AWS リージョンは自動的に選択されます。
         + ポリシーでローカルゾーン内のリソースがターゲットになっている場合は、ソースリソースと同じローカルゾーン、またはその親リージョンにスナップショットを作成する必要があります。
         + ポリシーで Outpost 上のリソースがターゲットになっている場合は、ソースリソースと同じ Outpost、またはその親リージョンにスナップショットを作成する必要があります。

   1. スナップショットのタグ付けを設定します。

      [**タグ付け**] セクションで、以下を実行します。

      1. ソースボリュームのすべてのユーザー定義タグを、スケジュールにより作成されたスナップショットにコピーするには、[**ソースからタグをコピー**] を選択します。

      1. 他のタグを指定し、このスケジュールによって作成されたスナップショットに割り当てるには、[**タグを追加**] をクリックします。

   1. アプリケーション整合性のあるスナップショット用の事前スクリプトと事後スクリプトを設定します。

      詳細については、「[Data Lifecycle Manager を使用してアプリケーション整合性のあるスナップショットを自動化](automate-app-consistent-backups.md)」を参照してください。

   1. (*ボリュームのみをターゲットとするポリシー*) スナップショットアーカイブを設定します。

      **[スナップショットのアーカイブ]** セクションで、次の操作を行います。
**注記**  
スナップショットのアーカイブを有効にできるのは、ポリシー内で 1 つのスケジュールのみです。

      1. スケジュールのスナップショットアーカイブを有効にするには、**[Archive snapshots created by this schedule]** (このスケジュールで作成されたスナップショットをアーカイブする) を選択します。
**注記**  
スナップショットのアーカイブを有効にできるのは、スナップショットの作成頻度に毎月または毎年を設定した場合、または作成頻度が 28 日以上の cron 式を指定した場合のみです。

      1. アーカイブ層のスナップショットのための保存ルールを指定します。
         + **[count-based schedules]** (カウントベースのスケジュール) で、アーカイブ層に保持するスナップショットの数を指定します。保持数のしきい値に達した場合は、最も古いスナップショットが完全にアーカイブ階層から削除されます。例えば、3 を指定した場合、スケジュールは最大 3 つのスナップショットをアーカイブ階層に保持します。4 番目のスナップショットをアーカイブする際には、アーカイブ階層に既存の 3 つのスナップショットのうち、最も古いものが削除されます。
         + **[age-based schedules]** (期間ベースのスケジュール) で、アーカイブ階層でのスナップショットの保持期間を指定します。保持数のしきい値に達した場合は、最も古いスナップショットが完全にアーカイブ階層から削除されます。例えば、120 日間を指定した場合、その期間に達したスナップショットは、スケジュールによりアーカイブ階層から自動的に削除されます。
**重要**  
アーカイブされたスナップショットの最小保持期間は 90 日です。スナップショットを少なくとも 90 日間保持する保存ルールを指定する必要があります。

   1. 高速スナップショット復元を有効にします。

      スケジュールによって作成されたスナップショットで高速スナップショット復元を有効化するには、[**高速スナップショット復元**] セクションで、[**スナップショットの高速復元を有効化する**] を選択します。高速スナップショット復元を有効にする場合は、特定のアベイラビリティーゾーンを選択する必要があります。保存期間に基づく保持スケジュールを使用する場合は、各スナップショットに対して高速スナップショット復元を有効にする期間を指定する必要があります。スケジュールでカウントベースの保持を使用する場合は、高速スナップショット復元を有効にするスナップショットの最大数を指定する必要があります。

      スケジュールで Outpost にスナップショットを作成している場合、高速スナップショット復元を有効にすることはできません。高速スナップショット復元は、Outpost に保存されているローカルスナップショットではサポートされません。
**注記**  
特定のアベイラビリティーゾーンでスナップショットの高速スナップショット復元を有効にしている時間中は、請求が発生します。料金は 1 時間を最小として時間単位で計算されます。

   1. クロスリージョンコピーを設定します。

      スケジュールによって作成されたスナップショットを、Outpost または別のリージョンにコピーするには、**[クロスリージョンコピー]** セクションで、**[クロスリージョンコピーを有効化する]** 選択します。

      スケジュールによってリージョンにスナップショットが作成されている場合は、アカウント内で最大 3 つの異なるリージョンあるいは Outposts に対し、そのスナップショットをコピーできます。送信先となるリージョンまたは Outpost ごとに、個別のクロスリージョンコピーのためのルールを指定する必要があります。

      リージョンまたは Outpost ごとに、異なる保持ポリシーを選択できます。また、すべてのタグをコピーするか、いずれのタグもコピーしないかを選択できます。ソーススナップショットが暗号化されている場合、またはデフォルトの暗号化が有効化されている場合には、コピーされたスナップショットも暗号化されます。ソーススナップショットが暗号化されていない場合には、暗号化できます。KMS キー を指定しない場合、スナップショットは、各送信先リージョンにおける EBS 暗号化用のデフォルト KMS キー を使用して暗号化されます。送信先リージョンで KMS キー を指定する場合、選択した IAM ロールには KMS キー へのアクセス権が必要です。
**注記**  
リージョンごとのスナップショットの同時コピー数を超えないようにする必要があります。

       ポリシーが Outpost にスナップショットを作成している場合、リージョンまたは別の Outpost に対し、そのスナップショットをコピーすることはできません。また、クロスリージョンコピー設定は使用できません。

   1. クロスアカウントの共有を設定します。

      **クロスアカウント共有**で、スケジュールによって作成されたスナップショットを他の AWS アカウントと自動的に共有するようにポリシーを設定します。以下の操作を実行します。

      1. 他の AWS アカウントとの共有を有効にするには、**クロスアカウント共有を有効にする**を選択します。

      1. スナップショットを共有するアカウントを追加するには、[**アカウントを追加**] をクリックし、12 桁の AWS アカウント ID を入力した後、[**追加**] をクリックします。

      1. スナップショットの共有を特定の期間後に自動的に解除するには、**[Unshare automatically]** (共有を自動解除する) を選択します。スナップショットの共有の自動解除を選択した場合、自動的な共有解除が実行されるまでの期間は、ポリシーがスナップショットを保持する期間より長くすることはできません。例えば、ポリシーの保存設定でスナップショットが 5 日間保持される場合、スナップショットの共有を自動的に解除するまでの期間としてポリシーに設定できるのは、最大 4 日間です。これは、期間ベースおよび数値ベースのスナップショット保持設定を持つポリシーに適用されます。

         自動的な共有解除を有効にしない場合、スナップショットは削除されるまで共有されます。
**注記**  
共有できるのは、暗号化されていないスナップショットまたはカスタマーマネージド型キーを使用して暗号化されたスナップショットだけです。デフォルトの EBS 暗号化 KMS キー で暗号化されたスナップショットを共有することはできません。暗号化されたスナップショットを共有する場合は、ソースボリュームの暗号化に使用された KMS キー も、ターゲットアカウントと共有する必要があります。詳細については、「AWS Key Management Service デベロッパーガイド**」の「[他のアカウントのユーザーに KMS キーの使用を許可する](https://docs.aws.amazon.com//kms/latest/developerguide/key-policy-modifying-external-accounts.html)」を参照してください。

   1. 新たにスケジュールを追加するには、画面の上部にある [**他のスケジュールを追加する**] をクリックします。追加スケジュールごとに、このトピックの説明にならってフィールドを設定します。

   1. 必要なスケジュールを追加したら、[**ポリシーをレビュー**] をクリックします。

1. ポリシーの概要を確認した後、[**ポリシーを作成**] をクリックします。
**注記**  
`Role with name AWSDataLifecycleManagerDefaultRole already exists` エラーが発生した場合、詳細については「[Amazon Data Lifecycle Manager の問題のトラブルシューティング](dlm-troubleshooting.md)」を参照してください。

------
#### [ Command line ]

スナップショットのライフサイクルポリシーを作成するには、[create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html) コマンドを使用します。`PolicyType` で、`EBS_SNAPSHOT_MANAGEMENT` を指定する。

**注記**  
構文を簡略化するために、次の例では、ポリシーの詳細を含む JSON ファイル、`policyDetails.json` を使用しています。

**例 1 – 2 つのスケジュールを持つスナップショットライフサイクルポリシー**  
この例では、値が `115` で `costcenter` のタグキーを持つすべてのボリュームのスナップショットを作成するスナップショットライフサイクルポリシーを作成します。ポリシーには、2 つのスケジュールが含まれます。最初のスケジュールでは、毎日 03:00 UTC にスナップショットが作成されます。2 番目のスケジュールでは、毎週金曜日の 17:00 (UTC) に週次のスナップショットが作成されます。

```
aws dlm create-lifecycle-policy \
    --description "My volume policy" \
    --state ENABLED \
    --execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole \
    --policy-details file://policyDetails.json
```

次は、`policyDetails.json` ファイルの例です。

```
{
    "PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
    "ResourceTypes": [
        "VOLUME"
    ],
    "TargetTags": [{
        "Key": "costcenter",
        "Value": "115"
    }],
    "Schedules": [{
        "Name": "DailySnapshots",
        "TagsToAdd": [{
            "Key": "type",
            "Value": "myDailySnapshot"
        }],
        "CreateRule": {
            "Interval": 24,
            "IntervalUnit": "HOURS",
            "Times": [
                "03:00"
            ]
        },
        "RetainRule": {
            "Count": 5
        },
        "CopyTags": false
    },
    {
        "Name": "WeeklySnapshots",
        "TagsToAdd": [{
            "Key": "type",
            "Value": "myWeeklySnapshot"
        }],
        "CreateRule": {
            "CronExpression": "cron(0 17 ? * FRI *)"
        },
        "RetainRule": {
            "Count": 5
        },
        "CopyTags": false
    }
]}
```

リクエストが成功すると、コマンドは新しく作成されたポリシーの ID を返します。以下は出力の例です。

```
{
   "PolicyId": "policy-0123456789abcdef0"
}
```

**例 2 - インスタンスをターゲットとし、データ (非ルート) ボリュームのサブセットのスナップショットを作成するスナップショットライフサイクルポリシー**  
この例では、`code=production` でタグ付けされたインスタンスからマルチボリュームスナップショットセットを作成するスナップショットライフサイクルポリシーを作成します。ポリシーには 1 つのスケジュールのみが含まれます。スケジュールでは、`code=temp` でタグ付けされたデータボリュームのスナップショットは作成されません。

```
aws dlm create-lifecycle-policy \
    --description "My volume policy" \
    --state ENABLED \
    --execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole \
    --policy-details file://policyDetails.json
```

次は、`policyDetails.json` ファイルの例です。

```
{
    "PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
    "ResourceTypes": [
        "INSTANCE"
    ],
    "TargetTags": [{
        "Key": "code",
        "Value": "production"
    }],
    "Parameters": {
        "ExcludeDataVolumeTags": [{
            "Key": "code",
            "Value": "temp"
        }]
    },
    "Schedules": [{
        "Name": "DailySnapshots",
        "TagsToAdd": [{
            "Key": "type",
            "Value": "myDailySnapshot"
        }],
        "CreateRule": {
            "Interval": 24,
            "IntervalUnit": "HOURS",
            "Times": [
                "03:00"
            ]
        },
        "RetainRule": {
            "Count": 5
        },
        "CopyTags": false
    }
]}
```

リクエストが成功すると、コマンドは新しく作成されたポリシーの ID を返します。以下は出力の例です。

```
{
   "PolicyId": "policy-0123456789abcdef0"
}
```

**例 3 — Outpost リソースでのローカルスナップショットを自動化する、スナップショットライフサイクルポリシー**  
この例では、すべての Outposts について、`team=dev` によりタグ付けされたボリュームのスナップショットを作成する、スナップショットライフサイクルポリシーを作成します。このポリシーにより、ソースボリュームと同じ Outposts にスナップショットが作成されます。このポリシーによるスナップショットの作成は、`00:00` UTCから開始され、その後 `12` 時間ごとに実行されます。

```
aws dlm create-lifecycle-policy \
    --description "My local snapshot policy" \
    --state ENABLED \
    --execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole \
    --policy-details file://policyDetails.json
```

次は、`policyDetails.json` ファイルの例です。

```
{
    "PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
    "ResourceTypes": "VOLUME",
	"ResourceLocations": "OUTPOST",
    "TargetTags": [{
        "Key": "team",
        "Value": "dev"
    }],
    "Schedules": [{
        "Name": "on-site backup",
        "CreateRule": {
            "Interval": 12,
            "IntervalUnit": "HOURS",
            "Times": [
                "00:00"
            ],
	"Location": [
		"OUTPOST_LOCAL"
	]
        },
        "RetainRule": {
            "Count": 1
        },
        "CopyTags": false
    }
]}
```

**例 4 — リージョンにスナップショットを作成し、それを Outpost にコピーするスナップショットライフサイクルポリシー**  
次のポリシー例では、`team=dev` によりタグ付けされたボリュームのスナップショットを作成します。スナップショットは、ソースボリュームと同じリージョンに作成されます。スナップショットの作成は、`00:00` UTC から開始され、その後 `12` 時間ごとに実行されます。スナップショットは最大 `1` 個まで保持されます。また、このポリシーでは、スナップショットを Outpost `arn:aws:outposts:us-east-1:123456789012:outpost/op-1234567890abcdef0` にコピーし、デフォルトの暗号化 KMS キー を使用しながら、コピーされたスナップショットの暗号化も行います。コピーの保持期間は `1` か月間です。

```
aws dlm create-lifecycle-policy \
    --description "Copy snapshots to Outpost" \
    --state ENABLED \
    --execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole \
    --policy-details file://policyDetails.json
```

次は、`policyDetails.json` ファイルの例です。

```
{
    "PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
    "ResourceTypes": "VOLUME",
    "ResourceLocations": "CLOUD",
    "TargetTags": [{
        "Key": "team",
        "Value": "dev"
    }],
    "Schedules": [{
        "Name": "on-site backup",
        "CopyTags": false,
        "CreateRule": {
            "Interval": 12,
            "IntervalUnit": "HOURS",
            "Times": [
                "00:00"
            ],
            "Location": "CLOUD"
        },
        "RetainRule": {
            "Count": 1
        },
        "CrossRegionCopyRules" : [
        {
            "Target": "arn:aws:outposts:us-east-1:123456789012:outpost/op-1234567890abcdef0",
            "Encrypted": true,
            "CopyTags": true,
            "RetainRule": {
                "Interval": 1,
                "IntervalUnit": "MONTHS"
            }
        }]
    }
]}
```

**例 5 - アーカイブが有効な期間ベースのスケジュールを持つスナップショットライフサイクルポリシー**  
この例では、`Name=Prod` によりタグ付けされたボリュームを対象とする、スナップショットライフサイクルポリシーを作成します。このポリシーには、毎月の初日の午前 9 時にスナップショットを作成する、期間ベースのスケジュールが 1 つあります。スケジュールは、各スナップショットをアーカイブ階層に移動した後も、そのスナップショットを標準階層に 1 日間保持します。スナップショットは、90 日間アーカイブ階層に保持された後に削除されます。

```
aws dlm create-lifecycle-policy \
    --description "Copy snapshots to Outpost" \
    --state ENABLED \
    --execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole \
    --policy-details file://policyDetails.json
```

次は、`policyDetails.json` ファイルの例です。

```
{
    "ResourceTypes": [ "VOLUME"],
    "PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
    "Schedules" : [
      {
        "Name": "sched1",
        "TagsToAdd": [
          {"Key":"createdby","Value":"dlm"}
        ],
        "CreateRule": {
          "CronExpression": "cron(0 9 1 * ? *)"
        },
        "CopyTags": true,
        "RetainRule":{
          "Interval": 1,
          "IntervalUnit": "DAYS"
        },
        "ArchiveRule": {
            "RetainRule":{
              "RetentionArchiveTier": {
                 "Interval": 90,
                 "IntervalUnit": "DAYS"
              }
            }
        }
      }
    ],
    "TargetTags": [
      {
        "Key": "Name",
        "Value": "Prod"
      }
    ]
}
```

**例 6 - アーカイブが有効なカウントベースのスケジュールを持つスナップショットライフサイクルポリシー**  
この例では、`Purpose=Test` によりタグ付けされたボリュームを対象とする、スナップショットライフサイクルポリシーを作成します。このポリシーには、毎月の初日の午前 9 時にスナップショットを作成する、カウントベースのスケジュールが 1 つあります。スケジュールは、作成直後にスナップショットをアーカイブし、最大 3 つのスナップショットをアーカイブ階層に保持します。

```
aws dlm create-lifecycle-policy \
    --description "Copy snapshots to Outpost" \
    --state ENABLED \
    --execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole \
    --policy-details file://policyDetails.json
```

次は、`policyDetails.json` ファイルの例です。

```
{
    "ResourceTypes": [ "VOLUME"],
    "PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
    "Schedules" : [
      {
        "Name": "sched1",
        "TagsToAdd": [
          {"Key":"createdby","Value":"dlm"}
        ],
        "CreateRule": {
          "CronExpression": "cron(0 9 1 * ? *)"
        },
        "CopyTags": true,
        "RetainRule":{
          "Count": 0
        },
        "ArchiveRule": {
            "RetainRule":{
              "RetentionArchiveTier": {
                 "Count": 3
              }
            }
        }
      }
    ],
    "TargetTags": [
      {
        "Key": "Purpose",
        "Value": "Test"
      }
    ]
}
```

------

## スナップショットライフサイクルポリシーに関する考慮事項
<a name="snapshot-considerations"></a>

スナップショットのライフサイクルポリシーには、次の**一般的な考慮事項**が適用されます。
+ スナップショットライフサイクルポリシーは、ポリシーと同じリージョンにあるインスタンスまたはボリュームのみを対象としています。
+ 最初のスナップショット作成オペレーションは、指定された開始時刻から 1 時間以内に開始されます。その後に続くスナップショット作成オペレーションは、スケジュールされた時刻の 1 時間以内に開始されます。
+ ボリュームまたはインスタンスをバックアップするために複数のポリシーを作成できます。例えば、ボリュームに 2 つのタグがあり、タグ *A* が 12 時間ごとにスナップショットを作成するポリシー *A* のターゲットであり、タグ *B* が 24 時間ごとにスナップショットを作成するポリシー *B* のターゲットである場合、Amazon Data Lifecycle Manager は両方のポリシーのスケジュールに従ってスナップショットを作成します。または、複数のスケジュールを持つ単一のポリシーを作成することで、同じ結果を得ることができます。例えば、タグ *A* のみをターゲットとするポリシーを 1 つ作成し、スケジュールを 2 つ指定できます (1 つは 12 時間ごと、1 つは 24 時間ごと)。
+ ターゲットリソースタグでは大文字と小文字が区別されます。
+ ポリシーによってターゲットにされたリソースからターゲットタグを削除した場合、以降、Amazon Data Lifecycle Manager では、標準階層とアーカイブ層に既に存在するスナップショットの管理は行いません。不要になった場合は手動で削除する必要があります。
+ インスタンスをターゲットとするポリシーを作成し、ポリシーの作成後に新しいボリュームがターゲットインスタンスにアタッチされた場合、新しく追加されたボリュームは、次回のポリシー実行時にバックアップに含まれます。ポリシー実行時にインスタンスにアタッチされたすべてのボリュームが含まれます。
+ スナップショットを 1 つだけ作成するように設定されているカスタム cron ベースのスケジュールを持つポリシーを作成した場合、そのポリシーでは、保持のしきい値に達しても、そのスナップショットは自動的に削除されません。スナップショットが不要になった場合は、手動で削除する必要があります。
+ 保持期間が作成頻度よりも短い経過日ベースのポリシーを作成した場合、Amazon Data Lifecycle Manager は次のスナップショットが作成されるまで常に最新のスナップショットを保持します。例えば、経過日ベースのポリシーで保存期間が 7 日間のスナップショットが毎月 1 つ作成される場合、Amazon Data Lifecycle Manager は、保持期間が 7 日間であっても、各スナップショットを 1 か月間保持します。

**[スナップショットの共有](snapshot-archive.md)**には、次の考慮事項が適用されます。
+ スナップショットのアーカイブは、ボリュームをターゲットとするスナップショットポリシーに対してのみ有効にできます。
+ アーカイブルールは、ポリシーごとに 1 つのスケジュールでのみ指定が可能す。
+ コンソールを使用している場合、スケジュールに設定されている作成頻度が、毎月または毎年、または 28 日以上の cron 式の場合にのみ、スナップショットアーカイブを有効にできます。

   AWS CLI、 AWS API、または AWS SDK を使用している場合、スケジュールに作成頻度が 28 日以上の cron 式がある場合にのみ、スナップショットのアーカイブを有効にできます。
+ アーカイブ階層における最小保持期間は 90 日です。
+ アーカイブされるスナップショットは、アーカイブ階層に移動される際に完全なスナップショットに変換されます。これにより、スナップショットのストレージコストが高くなる可能性があります。詳細については、「[Amazon EBS スナップショットをアーカイブするための料金と請求](snapshot-archive-pricing.md)」を参照してください。
+ スナップショットのアーカイブを使用する場合、スナップショットの高速復元とスナップショット共有は無効になります。
+ うるう年のために、保持ルールによるアーカイブの保持期間が 90 日到達できない場合、Amazon Data Lifecycle Manager が、スナップショットの保持期間が最低 90 日間になるように調整します。
+ Amazon Data Lifecycle Manager によって作成されたスナップショットを手動でアーカイブし、スケジュールによる保持期間のしきい値を超えても依然としてアーカイブされている場合には、そのスナップショットに対して Amazon Data Lifecycle Manager による管理は行われません。ただし、スケジュールによる保持期間のしきい値に達する前にスナップショットを標準階層に復元すれば、そのスナップショットに対し、引き続きスケジュールの保存ルールに従った管理が行われます。
+ 標準階層に永続的または一時的に復元された (Amazon Data Lifecycle Manager がアーカイブを行った) スナップショットが、スケジュールでの保持期間のしきい値に達した後も標準階層に残っている場合、そのスナップショットに対する Amazon Data Lifecycle Manager による管理は行われなくなります。ただし、保持期間のしきい値に達する前にスナップショットを再アーカイブすると、この保持期間が終了した時点で、スナップショットはスケジュールにより削除されます。
+ Amazon Data Lifecycle Manager によってアーカイブされたスナップショットは、`Archived snapshots per volume` および `In-progress snapshot archives per account` のクォータにカウントされます。
+ 24 時間再試行した後も、スケジュールがスナップショットをアーカイブできない場合、スナップショットは標準階層に残されます。その後、アーカイブ層から削除される予定時刻に基づいて削除されるようにスケジュールされます。例えば、スナップショットを 120 日間アーカイブするスケジュールでは、アーカイブが失敗してもスナップショットが 120 日間は標準階層に残され、その後完全に削除されます。カウントベースのスケジュールの場合、スナップショットはスケジュールによるの保持回数にカウントされません。
+ スナップショットは、それが作成されたリージョンと同じリージョンにアーカイブされる必要があります。クロスリージョンコピーとスナップショットアーカイブを有効にしている場合、このスナップショットのコピーは Amazon Data Lifecycle Manager によりアーカイブされません。
+ Amazon Data Lifecycle Manager によってアーカイブされたスナップショットには、`aws:dlm:archived=true` システムタグが付けられます。さらに、アーカイブが有効な期間ベースのスケジュールで作成されたスナップショットには、`aws:dlm:expirationTime` システムタグ (スナップショットがアーカイブされる予定の日付と時刻を示します) が付けられます。

**ルートボリュームとデータ (非ルート) ボリュームの除外**には、次の考慮事項が適用されます。
+ ブートボリュームを除外することを選択し、結果としてインスタンスにアタッチされたすべての追加データボリュームを除外するタグを指定した場合、Amazon Data Lifecycle Manager は、影響を受けるインスタンスのスナップショットを作成せず、`SnapshotsCreateFailed` CloudWatch メトリクスを発行します。詳細については、「[CloudWatch を使用して、ポリシーをモニタリング](monitor-dlm-cw-metrics.md)」を参照してください。

**スナップショットライフサイクルポリシーによってターゲットにされたボリュームを削除したり、インスタンスを終了したりする場合**の考慮事項は次のとおりです。
+ 数値ベースの保持期間が設定されたポリシーでターゲットされているボリュームの削除やインスタンスの終了を行った場合、以後 Amazon Data Lifecycle Manager では、これらのボリュームまたはインスタンスで作成されたスナップショットの管理は行いません。前に作成されたこれらのスナップショットが不要になった場合、手動で削除する必要があります。
+ 期間ベースの保持スケジュールが設定されたポリシーによってターゲットされているボリュームの削除やインスタンスの終了を行っても、ポリシーは、削除されたボリュームまたは終了されたインスタンスから以前に作成されたスナップショットを、 定義されたスケジュールに基づいて順番にすべて (ただし、最新のものは除き) 削除し続けます。最後のスナップショットが不要になった場合は、手動で削除する必要があります。

スナップショットライフサイクルポリシーや**[高速スナップショット復元](ebs-fast-snapshot-restore.md)**に関する考慮事項は次のとおりです。
+ Amazon Data Lifecycle Manager は、サイズが 16 TiB 以下のスナップショットに対してのみ高速スナップショット復元を有効にできます。詳細については、「[Amazon EBS 高速スナップショット復元](ebs-fast-snapshot-restore.md)」を参照してください。
+ 高速スナップショット復元が有効化されているスナップショットについては、対応するポリシーを削除もしくは無効化した場合、対応するポリシーの高速スナップショット復元を無効化した場合、または対応するアベイラビリティーゾーンの高速スナップショット復元を無効化した場合であっても、当該復元は有効に保たれます。このようなスナップショットについては、手動で高速スナップショット復元を無効化する必要があります。
+ ポリシーの高速スナップショット復元の有効化中に、有効化できるスナップショットの最大数を超えると、Amazon Data Lifecycle Manager はスケジュールに沿ったスナップショット作成は行うものの、作成したスナップショットの高速スナップショット復元は有効化しません。高速スナップショット復元が有効化されているスナップショットが削除されると、その次にAmazon Data Lifecycle Managerが作成するスナップショットの高速スナップショット復元が有効化されます。
+ あるスナップショットの高速スナップショット復元を有効化すると、当該スナップショットが最適化されるまでに、1 TiB あたり 60 分の時間がかかります。Amazon Data Lifecycle Manager が次のスナップショットを作成する前に各スナップショットが完全に最適化されるようなスケジュールの設定をお勧めします。
+ インスタンスを対象とするポリシーの高速スナップショット復元を有効にすると、Amazon Data Lifecycle Manager は、マルチボリュームスナップショットセット内の各スナップショットの高速スナップショット復元を個別に有効にします。Amazon Data Lifecycle Manager が、マルチボリュームスナップショットセット内のスナップショットの 1 つに対して高速スナップショット復元を有効にできない場合でも、スナップショットセット内の残りのスナップショットに対して高速スナップショット復元を有効にしようとします。
+ 特定のアベイラビリティーゾーンでスナップショットの高速スナップショット復元を有効にしている時間中は、請求が発生します。料金は 1 時間を最小として時間単位で計算されます。詳細については、「[料金と請求](ebs-fast-snapshot-restore.md#fsr-pricing)」を参照してください。
**注記**  
ライフサイクルポリシーの設定によっては、複数のスナップショットに対して同時に複数のアベイラビリティーゾーンで高速スナップショット復元を有効にすることができます。

スナップショットライフサイクルポリシーおよび**[マルチアタッチ](ebs-volumes-multi.md)が有効なボリューム**に関する考慮事項は次のとおりです。
+ マルチアタッチが有効な同じボリュームを持つインスタンスをターゲットとするライフサイクルポリシーを作成する場合、Amazon Data Lifecycle Manager はアタッチされたインスタンスごとにボリュームのスナップショットを開始します。*timestamp* タグを使用して、アタッチされたインスタンスから作成された時間整合性のあるスナップショットのセットを識別します。

**アカウント間でスナップショットを共有する**場合の考慮事項は次のとおりです。
+ 共有できるのは、暗号化されていないスナップショットまたは カスタマーマネージド型キー を使用して暗号化されたスナップショットだけです。
+ デフォルトの EBS 暗号化 KMS キーで暗号化されたスナップショットを共有することはできません。
+ 暗号化されたスナップショットを共有する場合は、ソースボリュームの暗号化に使用された KMS キーも、ターゲットアカウントと共有する必要があります。詳細については、*AWS Key Management Service デベロッパーガイド*の「[他のアカウントのユーザーに KMS キーの使用を許可する](https://docs.aws.amazon.com//kms/latest/developerguide/key-policy-modifying-external-accounts.html)」を参照してください。

スナップショットのポリシーや**[スナップショットのアーカイブ](snapshot-archive.md)**に関する考慮事項は次のとおりです。
+ ポリシーによって作成されたスナップショットを手動でアーカイブし、ポリシーの保持しきい値に達したときにそのスナップショットがアーカイブ階層にある場合、Amazon Data Lifecycle Manager はスナップショットを削除しません。Amazon Data Lifecycle Manager は、スナップショットがアーカイブ階層に保存されている間は、スナップショットを管理しません。アーカイブ階層に保存されているスナップショットが不要になった場合は、手動で削除する必要があります。

次の考慮事項は、スナップショットポリシーおよび[ごみ箱](recycle-bin.md)に適用されます。
+ Amazon Data Lifecycle Manager がポリシーの保持しきい値に達したときにスナップショットを削除してごみ箱に移動し、そのスナップショットをごみ箱から手動で復元した場合は、スナップショットが不要になったら手動で削除する必要があります。Amazon Data Lifecycle Manager は、スナップショットを管理しなくなります。
+ ポリシーによって作成されたスナップショットを手動で削除し、ポリシーの保持しきい値に達したときにそのスナップショットがごみ箱にある場合、Amazon Data Lifecycle Manager はスナップショットを削除しません。Amazon Data Lifecycle Manager は、スナップショットがごみ箱に保存されている間は、スナップショットを管理しません。

  ポリシーの保持しきい値に達する前にスナップショットがごみ箱から復元された場合、Amazon Data Lifecycle Manager は、ポリシーの保持しきい値に達したときにスナップショットを削除します。

  ポリシーの保持しきい値に達した後にスナップショットがごみ箱から復元された場合、Amazon Data Lifecycle Manager はそのスナップショットを削除しません。スナップショットが不要になった場合は、手動で削除する必要があります。

以下は、**エラー**状態にあるスナップショットライフサイクルポリシーに関する考慮事項です。
+ 期間ベースの保持スケジュールを持つポリシーの場合、ポリシーが `error` 状態の間に有効期限を迎えるスナップショットは無期限に保持されます。これらのスナップショットは手動で削除する必要があります。ポリシーを再度有効にすると、Amazon Data Lifecycle Manager は保持期間が終了した時にスナップショットの削除を再開します。
+ カウントベースの保存スケジュールが設定されているポリシーの場合、ポリシーが `error` 状態の間はスナップショットの作成と削除が停止されます。ポリシーを再度有効にすると、Amazon Data Lifecycle Manager はスナップショットの作成を再開し、保持しきい値に達した時にスナップショットの削除を再開します。

スナップショットポリシーと**[スナップショットロック](ebs-snapshot-lock.md)**に関する考慮事項は次のとおりです。
+ Amazon Data Lifecycle Manager によって作成されたスナップショットを手動でロックし、その後保持しきい値を超えても依然としてロックされている場合、そのスナップショットについては Amazon Data Lifecycle Manager による管理は行われません。スナップショットが不要になった場合は、手動で削除する必要があります。
+ Amazon Data Lifecycle Manager によって作成され、高速スナップショット復元が有効化されているスナップショットを手動でロックし、その後保持しきい値を超えても依然としてロックされている場合、そのスナップショットについては Amazon Data Lifecycle Manager による高速スナップショット復元の無効化または削除は行われません。スナップショットが不要になった場合は、手動で高速スナップショット復元を無効にして削除する必要があります。
+ Amazon Data Lifecycle Manager によって作成されたスナップショットを AMI に手動で登録してからロックし、その後保持しきい値を超えても依然としてロックされた状態で AMI に関連付けられている場合、そのスナップショットについては Amazon Data Lifecycle Manager による削除の試行が続行されます。AMI の登録が解除され、スナップショットのロックが解除されると、Amazon Data Lifecycle Manager はスナップショットを自動的に削除します。

## その他のリソース
<a name="snapshot-additional-resources"></a>

詳細については、[「Amazon Data Lifecycle Manager ストレージを使用した Amazon EBS スナップショットと AMI 管理の自動化](https://aws.amazon.com/blogs/storage/automating-amazon-ebs-snapshot-and-ami-management-using-amazon-dlm/) AWS 」ブログを参照してください。

# Data Lifecycle Manager を使用してアプリケーション整合性のあるスナップショットを自動化
<a name="automate-app-consistent-backups"></a>

Amazon Data Lifecycle Manager では、インスタンスをターゲットとするスナップショットライフサイクルポリシーで事前スクリプトと事後スクリプトを有効にすることで、アプリケーション整合性のあるスナップショットを自動化できます。

Amazon Data Lifecycle Manager は AWS Systems Manager (Systems Manager) と統合され、アプリケーション整合性のあるスナップショットをサポートします。Amazon Data Lifecycle Manager は、事前スクリプトと事後スクリプトを含む Systems Manager (SSM) コマンドドキュメントを使用して、アプリケーション整合性のあるスナップショットを完成させるために必要なアクションを自動化します。Amazon Data Lifecycle Manager は、スナップショットの作成を開始する前に、事前スクリプト内のコマンドを実行して I/O をフリーズおよびフラッシュします。Amazon Data Lifecycle Manager はスナップショットの作成を開始した後に、事後スクリプト内のコマンドを実行して I/O を解凍します。

Amazon Data Lifecycle Manager を使用すると、以下のアプリケーション整合性のあるスナップショットを自動化できます。
+ Volume Shadow Copy Service (VSS) を使用した Windows アプリケーション
+  AWS マネージド SSDM ドキュメントを使用する SAP HANA。詳細については、「[SAP HANA 用 Amazon EBS スナップショット](https://docs.aws.amazon.com/sap/latest/sap-hana/ebs-sap-hana.html)」を参照してください。
+ SSM ドキュメントテンプレートを使用した MySQL、PostgreSQL、InterSystems IRIS などのセルフマネージドデータベース

**Topics**
+ [事前スクリプトと事後スクリプトを使用するための要件](#app-consistent-prereqs)
+ [アプリケーション整合性のあるスナップショットの使用開始](#app-consistent-get-started)
+ [Amazon Data Lifecycle Manager での VSS バックアップに関する考慮事項](#app-consistent-vss)
+ [アプリケーション整合性のあるスナップショットの責任共有](#shared-responsibility)

## 事前スクリプトと事後スクリプトを使用するための要件
<a name="app-consistent-prereqs"></a>

次の表は、Amazon Data Lifecycle Manager で事前スクリプトと事後スクリプトを使用する際の要件の概要を示しています。


|  | アプリケーションコンシステントなスナップショット |  | 
| --- |--- |--- |
| 要件 | VSS バックアップ | カスタム SSM ドキュメント | その他のユースケース | 
| --- |--- |--- |--- |
| SSM Agent installed and running on target instances | ✓ | ✓ | ✓ | 
| VSS system requirements met on target instances | ✓ |  |  | 
| VSS enabled instance profile associated with target instances | ✓ |  |  | 
| VSS components installed on target instances | ✓ |  |  | 
| Prepare SSM document with pre and post script commands |  | ✓ | ✓ | 
| Prepare Amazon Data Lifecycle Manager IAM role run pre and post scripts | ✓ | ✓ | ✓ | 
| Create snapshot policy that targets instances and is configured for pre and post scripts | ✓ | ✓ | ✓ | 

## アプリケーション整合性のあるスナップショットの使用開始
<a name="app-consistent-get-started"></a>

このセクションでは、Amazon Data Lifecycle Manager を使用してアプリケーション整合性のあるスナップショットを自動化するために必要な手順について説明します。

### ステップ 1: ターゲットインスタンスを準備する
<a name="prep-instances"></a>

Amazon Data Lifecycle Manager を使用して、ターゲットインスタンスをアプリケーション整合性のあるスナップショット用に準備する必要があります。ユースケースに応じて、以下のいずれかを実行します。

------
#### [ Prepare for VSS Backups ]

**ターゲットインスタンスを VSS バックアップ用に準備するには**

1. SSM Agent がまだインストールされていない場合は、ターゲットインスタンスにインストールします。SSM Agent がターゲットインスタンスに既にインストールされている場合は、このステップをスキップしてください。

   詳細については、「[Windows Server 用 EC2 インスタンスで SSM Agent を使用する](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-windows.html)」を参照してください。

1. SSM Agent が実行中であることを確認します。詳細については、「[SSM Agent ステータスの確認とエージェントの起動](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html)」を参照してください。

1. Systems Manager の Amazon EC2 インスタンスをセットアップします。詳細については、「*AWS Systems Manager ユーザーガイド*」の「[Systems Manager を利用した EC2 インスタンスの管理](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html)」を参照してください。

1. [VSS バックアップのシステム要件が満たされていることを確認します](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots-prereqs.html)。

1. [VSS 対応インスタンスプロファイルをターゲットインスタンスにアタッチします](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/vss-iam-reqs.html)。

1. [VSS コンポーネントをインストールします](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots-getting-started.html)。

------
#### [ Prepare for SAP HANA backups ]

**ターゲットインスタンスを SAP HANA バックアップ用に準備するには**

1. ターゲットインスタンス上に SAP HANA 環境を準備します。

   1. SAP HANA と一緒にインスタンスをセットアップします。既存の SAP HANA 環境がない場合は、「[AWSでの SAP HANA 環境設定](https://docs.aws.amazon.com/sap/latest/sap-hana/std-sap-hana-environment-setup.html)」を参照してください。

   1. SystemDB に適切な管理者ユーザーとしてログインします。

   1. Amazon Data Lifecycle Manager で使用するデータベースバックアップユーザーを作成します。

      ```
      CREATE USER username PASSWORD password NO FORCE_FIRST_PASSWORD_CHANGE;
      ```

      例えば、次のコマンドは、名前が `dlm_user` でパスワードが `password` のユーザーを作成します。

      ```
      CREATE USER dlm_user PASSWORD password NO FORCE_FIRST_PASSWORD_CHANGE;
      ```

   1. 前のステップで作成したデータベースバックアップユーザーに `BACKUP OPERATOR` ロールを割り当てます。

      ```
      GRANT BACKUP OPERATOR TO username
      ```

      例えば、次のコマンドは、`dlm_user` という名前のユーザーにロールを割り当てます。

      ```
      GRANT BACKUP OPERATOR TO dlm_user
      ```

   1. オペレーティングシステムに管理者 (例: `sidadm`) としてログインします。

   1. 接続情報を保存する `hdbuserstore` エントリを作成して、ユーザーが情報を入力しなくても SAP HANA SSM ドキュメントが SAP HANA に接続できるようにします。

      ```
      hdbuserstore set DLM_HANADB_SNAPSHOT_USER localhost:3hana_instance_number13 username password
      ```

      例えば、次のようになります。

      ```
      hdbuserstore set DLM_HANADB_SNAPSHOT_USER localhost:30013 dlm_user password
      ```

   1. 接続をテストします。

      ```
      hdbsql -U DLM_HANADB_SNAPSHOT_USER "select * from dummy"
      ```

1. SSM Agent がまだインストールされていない場合は、ターゲットインスタンスにインストールします。SSM Agent がターゲットインスタンスに既にインストールされている場合は、このステップをスキップしてください。

   詳細については、「[Linux 用 EC2 インスタンスに SSM Agent を手動でインストールおよびアンインストールする](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html)」を参照してください。

1. SSM Agent が実行中であることを確認します。詳細については、「[SSM Agent ステータスの確認とエージェントの起動](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html)」を参照してください。

1. Systems Manager の Amazon EC2 インスタンスをセットアップします。詳細については、「*AWS Systems Manager ユーザーガイド*」の「[Systems Manager を利用した EC2 インスタンスの管理](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html)」を参照してください。

------
#### [ Prepare for custom SSM documents ]

**ターゲットインスタンスのカスタム SSM ドキュメントを準備するには**

1. SSM Agent がまだインストールされていない場合は、ターゲットインスタンスにインストールします。SSM Agent がターゲットインスタンスに既にインストールされている場合は、このステップをスキップしてください。
   + (Linux インスタンス) [Linux 用 EC2 インスタンスに SSM Agent を手動でインストールおよびアンインストールする](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html)
   + (Windows インスタンス) [Windows Server 用 EC2 インスタンスで SSM Agent を使用する](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-windows.html)

1. SSM Agent が実行中であることを確認します。詳細については、「[SSM Agent ステータスの確認とエージェントの起動](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html)」を参照してください。

1. Systems Manager の Amazon EC2 インスタンスをセットアップします。詳細については、「*AWS Systems Manager ユーザーガイド*」の「[Systems Manager を利用した EC2 インスタンスの管理](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html)」を参照してください。

------

### ステップ 2: SSM ドキュメントを準備する
<a name="prep-ssm-doc"></a>

**注記**  
このステップはカスタム SSM ドキュメントの場合にのみ必要です。VSS バックアップや SAP HANA には必要ありません。VSS Backups と SAP HANA の場合、Amazon Data Lifecycle Manager は AWS マネージド SSM ドキュメントを使用します。

MySQL や PostgreSQL、または InterSystems IRIS などのセルフマネージドデータベースのアプリケーション整合性のあるスナップショットを自動化している場合は、スナップショットの作成を開始する前に I/O をフリーズおよびフラッシュするための事前スクリプトと、スナップショットの作成を開始した後に I/O を解凍するための事後スクリプトを含む SSM コマンドドキュメントを作成する必要があります。

MySQL や PostgreSQL、または InterSystems IRIS データベースが標準設定を使用している場合は、以下のサンプル SSM ドキュメントコンテンツを使用して SSM コマンドドキュメントを作成できます。MySQL や PostgreSQL、または InterSystems IRIS データベースが非標準設定を使用している場合は、以下のサンプルコンテンツを SSM コマンドドキュメントの開始点として使用し、要件に合わせてカスタマイズできます。あるいは、新しい SSM ドキュメントを最初から作成する場合は、以下の空の SSM ドキュメントテンプレートを使用して、該当するドキュメントセクションに事前コマンドと事後コマンドを追加できます。

**次の点に注意してください。**  
データベース設定に対して SSM ドキュメントが適切かつ必要なアクションを実行していることを確認するのは、ユーザーの責任になります。
SSM ドキュメント内の事前スクリプトと事後スクリプトが I/O を正常にフリーズ、フラッシュ、および解凍できた場合にのみ、スナップショットのアプリケーション整合性が保証されます。
SSM ドキュメントには、`pre-script`、`post-script`、`dry-run` などの `allowedValues` の必須フィールドが含まれている必要があります。Amazon Data Lifecycle Manager は、これらのセクションのコンテンツに基づいてインスタンス上でコマンドを実行します。SSM ドキュメントにこれらのセクションがない場合、Amazon Data Lifecycle Manager は、そのドキュメントを実行に失敗したものとして扱います。

------
#### [ MySQL sample document content ]

```
###===============================================================================###
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.

# Permission is hereby granted, free of charge, to any person obtaining a copy of this
# software and associated documentation files (the "Software"), to deal in the Software
# without restriction, including without limitation the rights to use, copy, modify,
# merge, publish, distribute, sublicense, and/or sell copies of the Software, and to
# permit persons to whom the Software is furnished to do so.

# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
# INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
# PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
# HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
# OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
# SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
###===============================================================================###
schemaVersion: '2.2'
description: Amazon Data Lifecycle Manager Pre/Post script for MySQL databases
parameters:
  executionId:
    type: String
    default: None
    description: (Required) Specifies the unique identifier associated with a pre and/or post execution
    allowedPattern: ^(None|[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12})$
  command:
  # Data Lifecycle Manager will trigger the pre-script and post-script actions during policy execution. 
  # 'dry-run' option is intended for validating the document execution without triggering any commands
  # on the instance. The following allowedValues will allow Data Lifecycle Manager to successfully 
  # trigger pre and post script actions.
    type: String
    default: 'dry-run'
    description: (Required) Specifies whether pre-script and/or post-script should be executed.
    allowedValues:
    - pre-script
    - post-script
    - dry-run

mainSteps:
- action: aws:runShellScript
  description: Run MySQL Database freeze/thaw commands
  name: run_pre_post_scripts
  precondition:
    StringEquals:
    - platformType
    - Linux
  inputs:
    runCommand:
    - |
      #!/bin/bash

      ###===============================================================================###
      ### Error Codes
      ###===============================================================================###
      # The following Error codes will inform Data Lifecycle Manager of the type of error 
      # and help guide handling of the error. 
      # The Error code will also be emitted via AWS Eventbridge events in the 'cause' field.
      # 1 Pre-script failed during execution - 201
      # 2 Post-script failed during execution - 202
      # 3 Auto thaw occurred before post-script was initiated - 203
      # 4 Pre-script initiated while post-script was expected - 204
      # 5 Post-script initiated while pre-script was expected - 205
      # 6 Application not ready for pre or post-script initiation - 206

      ###=================================================================###
      ### Global variables
      ###=================================================================###
      START=$(date +%s)
      # For testing this script locally, replace the below with OPERATION=$1.
      OPERATION={{ command }}
      FS_ALREADY_FROZEN_ERROR='freeze failed: Device or resource busy'
      FS_ALREADY_THAWED_ERROR='unfreeze failed: Invalid argument'
      FS_BUSY_ERROR='mount point is busy'

      # Auto thaw is a fail safe mechanism to automatically unfreeze the application after the 
      # duration specified in the global variable below. Choose the duration based on your
      # database application's tolerance to freeze.
      export AUTO_THAW_DURATION_SECS="60"

      # Add all pre-script actions to be performed within the function below
      execute_pre_script() {
          echo "INFO: Start execution of pre-script"
          # Check if filesystem is already frozen. No error code indicates that filesystem 
          # is not currently frozen and that the pre-script can proceed with freezing the filesystem.
          check_fs_freeze
          # Execute the DB commands to flush the DB in preparation for snapshot
          snap_db
          # Freeze the filesystem. No error code indicates that filesystem was succefully frozen
          freeze_fs

          echo "INFO: Schedule Auto Thaw to execute in ${AUTO_THAW_DURATION_SECS} seconds."
          $(nohup bash -c execute_schedule_auto_thaw  >/dev/null 2>&1 &)
      }

      # Add all post-script actions to be performed within the function below
      execute_post_script() {
          echo "INFO: Start execution of post-script"
          # Unfreeze the filesystem. No error code indicates that filesystem was successfully unfrozen.
          unfreeze_fs
          thaw_db
      }

      # Execute Auto Thaw to automatically unfreeze the application after the duration configured 
      # in the AUTO_THAW_DURATION_SECS global variable.
      execute_schedule_auto_thaw() {
          sleep ${AUTO_THAW_DURATION_SECS}
          execute_post_script
      }

      # Disable Auto Thaw if it is still enabled
      execute_disable_auto_thaw() {
          echo "INFO: Attempting to disable auto thaw if enabled"
          auto_thaw_pgid=$(pgrep -f execute_schedule_auto_thaw | xargs -i ps -hp {} -o pgid)
          if [ -n "${auto_thaw_pgid}" ]; then
              echo "INFO: execute_schedule_auto_thaw process found with pgid ${auto_thaw_pgid}"
              sudo pkill -g ${auto_thaw_pgid}
              rc=$?
              if [ ${rc} != 0 ]; then
                  echo "ERROR: Unable to kill execute_schedule_auto_thaw process. retval=${rc}"
              else
                  echo "INFO: Auto Thaw  has been disabled"
              fi
          fi
      }

      # Iterate over all the mountpoints and check if filesystem is already in freeze state.
      # Return error code 204 if any of the mount points are already frozen.
      check_fs_freeze() {
          for target in $(lsblk -nlo MOUNTPOINTS)
          do
              # Freeze of the root and boot filesystems is dangerous and pre-script does not freeze these filesystems.
              # Hence, we will skip the root and boot mountpoints while checking if filesystem is in freeze state.
              if [ $target == '/' ]; then continue; fi
              if [[ "$target" == *"/boot"* ]]; then continue; fi

              error_message=$(sudo mount -o remount,noatime $target 2>&1)
              # Remount will be a no-op without a error message if the filesystem is unfrozen.
              # However, if filesystem is already frozen, remount will fail with busy error message.
              if [ $? -ne 0 ];then
                  # If the filesystem is already in frozen, return error code 204
                  if [[ "$error_message" == *"$FS_BUSY_ERROR"* ]];then
                      echo "ERROR: Filesystem ${target} already frozen. Return Error Code: 204"
                      exit 204
                  fi
                  # If the check filesystem freeze failed due to any reason other than the filesystem already frozen, return 201
                  echo "ERROR: Failed to check_fs_freeze on mountpoint $target due to error - $errormessage"
                  exit 201
              fi
          done
      } 

      # Iterate over all the mountpoints and freeze the filesystem.
      freeze_fs() {
          for target in $(lsblk -nlo MOUNTPOINTS)
          do
              # Freeze of the root and boot filesystems is dangerous. Hence, skip filesystem freeze 
              # operations for root and boot mountpoints.
              if [ $target == '/' ]; then continue; fi
              if [[ "$target" == *"/boot"* ]]; then continue; fi
              echo "INFO: Freezing $target"
              error_message=$(sudo fsfreeze -f $target 2>&1)
              if [ $? -ne 0 ];then
                  # If the filesystem is already in frozen, return error code 204
                  if [[ "$error_message" == *"$FS_ALREADY_FROZEN_ERROR"* ]]; then
                      echo "ERROR: Filesystem ${target} already frozen. Return Error Code: 204"
                      sudo mysql -e 'UNLOCK TABLES;'
                      exit 204
                  fi
                  # If the filesystem freeze failed due to any reason other than the filesystem already frozen, return 201
                  echo "ERROR: Failed to freeze mountpoint $targetdue due to error - $errormessage"
                  thaw_db
                  exit 201
              fi
              echo "INFO: Freezing complete on $target"
          done
      }

      # Iterate over all the mountpoints and unfreeze the filesystem.
      unfreeze_fs() {
          for target in $(lsblk -nlo MOUNTPOINTS)
          do
              # Freeze of the root and boot filesystems is dangerous and pre-script does not freeze these filesystems.
              # Hence, will skip the root and boot mountpoints during unfreeze as well.
              if [ $target == '/' ]; then continue; fi
              if [[ "$target" == *"/boot"* ]]; then continue; fi
              echo "INFO: Thawing $target"
              error_message=$(sudo fsfreeze -u $target 2>&1)
              # Check if filesystem is already unfrozen (thawed). Return error code 204 if filesystem is already unfrozen.
              if [ $? -ne 0 ]; then
                  if [[ "$error_message" == *"$FS_ALREADY_THAWED_ERROR"* ]]; then
                      echo "ERROR: Filesystem ${target} is already in thaw state. Return Error Code: 205"
                      exit 205
                  fi
                  # If the filesystem unfreeze failed due to any reason other than the filesystem already unfrozen, return 202
                  echo "ERROR: Failed to unfreeze mountpoint $targetdue due to error - $errormessage"
                  exit 202
              fi
              echo "INFO: Thaw complete on $target"
          done    
      }

      snap_db() {
          # Run the flush command only when MySQL DB service is up and running
          sudo systemctl is-active --quiet mysqld.service
          if [ $? -eq 0 ]; then
              echo "INFO: Execute MySQL Flush and Lock command."
              sudo mysql -e 'FLUSH TABLES WITH READ LOCK;'
              # If the MySQL Flush and Lock command did not succeed, return error code 201 to indicate pre-script failure
              if [ $? -ne 0 ]; then
                  echo "ERROR: MySQL FLUSH TABLES WITH READ LOCK command failed."
                  exit 201
              fi
              sync
          else 
              echo "INFO: MySQL service is inactive. Skipping execution of MySQL Flush and Lock command."
          fi
      }

      thaw_db() {
          # Run the unlock command only when MySQL DB service is up and running
          sudo systemctl is-active --quiet mysqld.service
          if [ $? -eq 0 ]; then
              echo "INFO: Execute MySQL Unlock"
              sudo mysql -e 'UNLOCK TABLES;'
          else 
              echo "INFO: MySQL service is inactive. Skipping execution of MySQL Unlock command."
          fi
      }

      export -f execute_schedule_auto_thaw
      export -f execute_post_script
      export -f unfreeze_fs
      export -f thaw_db

      # Debug logging for parameters passed to the SSM document
      echo "INFO: ${OPERATION} starting at $(date) with executionId: ${EXECUTION_ID}"

      # Based on the command parameter value execute the function that supports 
      # pre-script/post-script operation
      case ${OPERATION} in
          pre-script)
              execute_pre_script
              ;;
          post-script)
              execute_post_script
              execute_disable_auto_thaw
              ;;
          dry-run)
              echo "INFO: dry-run option invoked - taking no action"
              ;;
          *)
              echo "ERROR: Invalid command parameter passed. Please use either pre-script, post-script, dry-run."
              exit 1 # return failure
              ;;
      esac

      END=$(date +%s)
      # Debug Log for profiling the script time
      echo "INFO: ${OPERATION} completed at $(date). Total runtime: $((${END} - ${START})) seconds."
```

------
#### [ PostgreSQL sample document content ]

```
###===============================================================================###
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.

# Permission is hereby granted, free of charge, to any person obtaining a copy of this
# software and associated documentation files (the "Software"), to deal in the Software
# without restriction, including without limitation the rights to use, copy, modify,
# merge, publish, distribute, sublicense, and/or sell copies of the Software, and to
# permit persons to whom the Software is furnished to do so.

# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
# INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
# PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
# HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
# OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
# SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
###===============================================================================###
schemaVersion: '2.2'
description: Amazon Data Lifecycle Manager Pre/Post script for PostgreSQL databases
parameters:
  executionId:
    type: String
    default: None
    description: (Required) Specifies the unique identifier associated with a pre and/or post execution
    allowedPattern: ^(None|[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12})$
  command:
  # Data Lifecycle Manager will trigger the pre-script and post-script actions during policy execution. 
  # 'dry-run' option is intended for validating the document execution without triggering any commands
  # on the instance. The following allowedValues will allow Data Lifecycle Manager to successfully 
  # trigger pre and post script actions.
    type: String
    default: 'dry-run'
    description: (Required) Specifies whether pre-script and/or post-script should be executed.
    allowedValues:
    - pre-script
    - post-script
    - dry-run

mainSteps:
- action: aws:runShellScript
  description: Run PostgreSQL Database freeze/thaw commands
  name: run_pre_post_scripts
  precondition:
    StringEquals:
    - platformType
    - Linux
  inputs:
    runCommand:
    - |
      #!/bin/bash

      ###===============================================================================###
      ### Error Codes
      ###===============================================================================###
      # The following Error codes will inform Data Lifecycle Manager of the type of error 
      # and help guide handling of the error. 
      # The Error code will also be emitted via AWS Eventbridge events in the 'cause' field.
      # 1 Pre-script failed during execution - 201
      # 2 Post-script failed during execution - 202
      # 3 Auto thaw occurred before post-script was initiated - 203
      # 4 Pre-script initiated while post-script was expected - 204
      # 5 Post-script initiated while pre-script was expected - 205
      # 6 Application not ready for pre or post-script initiation - 206

      ###===============================================================================###
      ### Global variables
      ###===============================================================================###
      START=$(date +%s)
      OPERATION={{ command }}
      FS_ALREADY_FROZEN_ERROR='freeze failed: Device or resource busy'
      FS_ALREADY_THAWED_ERROR='unfreeze failed: Invalid argument'
      FS_BUSY_ERROR='mount point is busy'

      # Auto thaw is a fail safe mechanism to automatically unfreeze the application after the 
      # duration specified in the global variable below. Choose the duration based on your
      # database application's tolerance to freeze.
      export AUTO_THAW_DURATION_SECS="60"

      # Add all pre-script actions to be performed within the function below
      execute_pre_script() {
          echo "INFO: Start execution of pre-script"
          # Check if filesystem is already frozen. No error code indicates that filesystem 
          # is not currently frozen and that the pre-script can proceed with freezing the filesystem.
          check_fs_freeze
          # Execute the DB commands to flush the DB in preparation for snapshot
          snap_db
          # Freeze the filesystem. No error code indicates that filesystem was succefully frozen
          freeze_fs

          echo "INFO: Schedule Auto Thaw to execute in ${AUTO_THAW_DURATION_SECS} seconds."
          $(nohup bash -c execute_schedule_auto_thaw  >/dev/null 2>&1 &)
      }

      # Add all post-script actions to be performed within the function below
      execute_post_script() {
          echo "INFO: Start execution of post-script"
          # Unfreeze the filesystem. No error code indicates that filesystem was successfully unfrozen
          unfreeze_fs
      }

      # Execute Auto Thaw to automatically unfreeze the application after the duration configured 
      # in the AUTO_THAW_DURATION_SECS global variable.
      execute_schedule_auto_thaw() {
          sleep ${AUTO_THAW_DURATION_SECS}
          execute_post_script
      }

      # Disable Auto Thaw if it is still enabled
      execute_disable_auto_thaw() {
          echo "INFO: Attempting to disable auto thaw if enabled"
          auto_thaw_pgid=$(pgrep -f execute_schedule_auto_thaw | xargs -i ps -hp {} -o pgid)
          if [ -n "${auto_thaw_pgid}" ]; then
              echo "INFO: execute_schedule_auto_thaw process found with pgid ${auto_thaw_pgid}"
              sudo pkill -g ${auto_thaw_pgid}
              rc=$?
              if [ ${rc} != 0 ]; then
                  echo "ERROR: Unable to kill execute_schedule_auto_thaw process. retval=${rc}"
              else
                  echo "INFO: Auto Thaw  has been disabled"
              fi
          fi
      }

      # Iterate over all the mountpoints and check if filesystem is already in freeze state.
      # Return error code 204 if any of the mount points are already frozen.
      check_fs_freeze() {
          for target in $(lsblk -nlo MOUNTPOINTS)
          do
              # Freeze of the root and boot filesystems is dangerous and pre-script does not freeze these filesystems.
              # Hence, we will skip the root and boot mountpoints while checking if filesystem is in freeze state.
              if [ $target == '/' ]; then continue; fi
              if [[ "$target" == *"/boot"* ]]; then continue; fi

              error_message=$(sudo mount -o remount,noatime $target 2>&1)
              # Remount will be a no-op without a error message if the filesystem is unfrozen.
              # However, if filesystem is already frozen, remount will fail with busy error message.
              if [ $? -ne 0 ];then
                  # If the filesystem is already in frozen, return error code 204
                  if [[ "$error_message" == *"$FS_BUSY_ERROR"* ]];then
                      echo "ERROR: Filesystem ${target} already frozen. Return Error Code: 204"
                      exit 204
                  fi
                  # If the check filesystem freeze failed due to any reason other than the filesystem already frozen, return 201
                  echo "ERROR: Failed to check_fs_freeze on mountpoint $target due to error - $errormessage"
                  exit 201
              fi
          done
      } 

      # Iterate over all the mountpoints and freeze the filesystem.
      freeze_fs() {
          for target in $(lsblk -nlo MOUNTPOINTS)
          do
              # Freeze of the root and boot filesystems is dangerous. Hence, skip filesystem freeze 
              # operations for root and boot mountpoints.
              if [ $target == '/' ]; then continue; fi
              if [[ "$target" == *"/boot"* ]]; then continue; fi
              echo "INFO: Freezing $target"
              error_message=$(sudo fsfreeze -f $target 2>&1)
              if [ $? -ne 0 ];then
                  # If the filesystem is already in frozen, return error code 204
                  if [[ "$error_message" == *"$FS_ALREADY_FROZEN_ERROR"* ]]; then
                      echo "ERROR: Filesystem ${target} already frozen. Return Error Code: 204"
                      exit 204
                  fi
                  # If the filesystem freeze failed due to any reason other than the filesystem already frozen, return 201
                  echo "ERROR: Failed to freeze mountpoint $targetdue due to error - $errormessage"
                  exit 201
              fi
              echo "INFO: Freezing complete on $target"
          done
      }

      # Iterate over all the mountpoints and unfreeze the filesystem.
      unfreeze_fs() {
          for target in $(lsblk -nlo MOUNTPOINTS)
          do
              # Freeze of the root and boot filesystems is dangerous and pre-script does not freeze these filesystems.
              # Hence, will skip the root and boot mountpoints during unfreeze as well.
              if [ $target == '/' ]; then continue; fi
              if [[ "$target" == *"/boot"* ]]; then continue; fi
              echo "INFO: Thawing $target"
              error_message=$(sudo fsfreeze -u $target 2>&1)
              # Check if filesystem is already unfrozen (thawed). Return error code 204 if filesystem is already unfrozen.
              if [ $? -ne 0 ]; then
                  if [[ "$error_message" == *"$FS_ALREADY_THAWED_ERROR"* ]]; then
                      echo "ERROR: Filesystem ${target} is already in thaw state. Return Error Code: 205"
                      exit 205
                  fi
                  # If the filesystem unfreeze failed due to any reason other than the filesystem already unfrozen, return 202
                  echo "ERROR: Failed to unfreeze mountpoint $targetdue due to error - $errormessage"
                  exit 202
              fi
              echo "INFO: Thaw complete on $target"
          done
      }

      snap_db() {
          # Run the flush command only when PostgreSQL DB service is up and running
          sudo systemctl is-active --quiet postgresql
          if [ $? -eq 0 ]; then
              echo "INFO: Execute Postgres CHECKPOINT"
              # PostgreSQL command to flush the transactions in memory to disk
              sudo -u postgres psql -c 'CHECKPOINT;'
              # If the PostgreSQL Command did not succeed, return error code 201 to indicate pre-script failure
              if [ $? -ne 0 ]; then
                  echo "ERROR: Postgres CHECKPOINT command failed."
                  exit 201
              fi
              sync
          else 
              echo "INFO: PostgreSQL service is inactive. Skipping execution of CHECKPOINT command."
          fi
      }

      export -f execute_schedule_auto_thaw
      export -f execute_post_script
      export -f unfreeze_fs

      # Debug logging for parameters passed to the SSM document
      echo "INFO: ${OPERATION} starting at $(date) with executionId: ${EXECUTION_ID}"

      # Based on the command parameter value execute the function that supports 
      # pre-script/post-script operation
      case ${OPERATION} in
          pre-script)
              execute_pre_script
              ;;
          post-script)
              execute_post_script
              execute_disable_auto_thaw
              ;;
          dry-run)
              echo "INFO: dry-run option invoked - taking no action"
              ;;
          *)
              echo "ERROR: Invalid command parameter passed. Please use either pre-script, post-script, dry-run."
              exit 1 # return failure
              ;;
      esac

      END=$(date +%s)
      # Debug Log for profiling the script time
      echo "INFO: ${OPERATION} completed at $(date). Total runtime: $((${END} - ${START})) seconds."
```

------
#### [ InterSystems IRIS sample document content ]

```
###===============================================================================###
# MIT License
# 
# Copyright (c) 2024 InterSystems
# 
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to deal
# in the Software without restriction, including without limitation the rights
# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
# copies of the Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:
# 
# The above copyright notice and this permission notice shall be included in all
# copies or substantial portions of the Software.
# 
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.
###===============================================================================###
schemaVersion: '2.2'
description: SSM Document Template for Amazon Data Lifecycle Manager Pre/Post script feature for InterSystems IRIS.
parameters:
  executionId:
    type: String
    default: None
    description: Specifies the unique identifier associated with a pre and/or post execution
    allowedPattern: ^(None|[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12})$
  command:
    type: String
    # Data Lifecycle Manager will trigger the pre-script and post-script actions. You can also use this SSM document with 'dry-run' for manual testing purposes.
    default: 'dry-run'
    description: (Required) Specifies whether pre-script and/or post-script should be executed.
    #The following allowedValues will allow Data Lifecycle Manager to successfully trigger pre and post script actions.
    allowedValues:
    - pre-script
    - post-script
    - dry-run

mainSteps:
- action: aws:runShellScript
  description: Run InterSystems IRIS Database freeze/thaw commands
  name: run_pre_post_scripts
  precondition:
    StringEquals:
    - platformType
    - Linux
  inputs:
    runCommand:
    - |
      #!/bin/bash
      ###===============================================================================###
      ### Global variables
      ###===============================================================================###
      DOCKER_NAME=iris
      LOGDIR=./
      EXIT_CODE=0
      OPERATION={{ command }}
      START=$(date +%s)
      
      # Check if Docker is installed
      # By default if Docker is present, script assumes that InterSystems IRIS is running in Docker
      # Leave only the else block DOCKER_EXEC line, if you run InterSystems IRIS non-containerised (and Docker is present).
      # Script assumes irissys user has OS auth enabled, change the OS user or supply login/password depending on your configuration.
      if command -v docker &> /dev/null
      then
        DOCKER_EXEC="docker exec $DOCKER_NAME"
      else
        DOCKER_EXEC="sudo -i -u irissys"
      fi
      
                    
      # Add all pre-script actions to be performed within the function below
      execute_pre_script() {
        echo "INFO: Start execution of pre-script"
        
        # find all iris running instances
        iris_instances=$($DOCKER_EXEC iris qall 2>/dev/null | tail -n +3 | grep '^up' | cut -c5-  | awk '{print $1}')
        echo "`date`: Running iris instances $iris_instances"
      
        # Only for running instances
        for INST in $iris_instances; do
      
          echo "`date`: Attempting to freeze $INST"
      
          # Detailed instances specific log
          LOGFILE=$LOGDIR/$INST-pre_post.log
          
          #check Freeze status before starting
          $DOCKER_EXEC irissession $INST -U '%SYS' "##Class(Backup.General).IsWDSuspendedExt()"
          freeze_status=$?
          if [ $freeze_status -eq 5 ]; then
            echo "`date`:   ERROR: $INST IS already FROZEN"
            EXIT_CODE=204
          else
            echo "`date`:   $INST is not frozen"
            # Freeze
            # Docs: https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic.cls?LIBRARY=%25SYS&CLASSNAME=Backup.General#ExternalFreeze
            $DOCKER_EXEC irissession $INST -U '%SYS' "##Class(Backup.General).ExternalFreeze(\"$LOGFILE\",,,,,,600,,,300)"
            status=$?
      
            case $status in
              5) echo "`date`:   $INST IS FROZEN"
                ;;
              3) echo "`date`:   $INST FREEZE FAILED"
                EXIT_CODE=201
                ;;
              *) echo "`date`:   ERROR: Unknown status code: $status"
                EXIT_CODE=201
                ;;
            esac
            echo "`date`:   Completed freeze of $INST"
          fi
        done
        echo "`date`: Pre freeze script finished"
      }
                    
      # Add all post-script actions to be performed within the function below
      execute_post_script() {
        echo "INFO: Start execution of post-script"
      
        # find all iris running instances
        iris_instances=$($DOCKER_EXEC iris qall 2>/dev/null | tail -n +3 | grep '^up' | cut -c5-  | awk '{print $1}')
        echo "`date`: Running iris instances $iris_instances"
      
        # Only for running instances
        for INST in $iris_instances; do
      
          echo "`date`: Attempting to thaw $INST"
      
          # Detailed instances specific log
          LOGFILE=$LOGDIR/$INST-pre_post.log
      
          #check Freeze status befor starting
          $DOCKER_EXEC irissession $INST -U '%SYS' "##Class(Backup.General).IsWDSuspendedExt()"
          freeze_status=$?
          if [ $freeze_status -eq 5 ]; then
            echo "`date`:  $INST is in frozen state"
            # Thaw
            # Docs: https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic.cls?LIBRARY=%25SYS&CLASSNAME=Backup.General#ExternalFreeze
            $DOCKER_EXEC irissession $INST -U%SYS "##Class(Backup.General).ExternalThaw(\"$LOGFILE\")"
            status=$?
      
            case $status in
              5) echo "`date`:   $INST IS THAWED"
                  $DOCKER_EXEC irissession $INST -U%SYS "##Class(Backup.General).ExternalSetHistory(\"$LOGFILE\")"
                ;;
              3) echo "`date`:   $INST THAW FAILED"
                  EXIT_CODE=202
                ;;
              *) echo "`date`:   ERROR: Unknown status code: $status"
                  EXIT_CODE=202
                ;;
            esac
            echo "`date`:   Completed thaw of $INST"
          else
            echo "`date`:   ERROR: $INST IS already THAWED"
            EXIT_CODE=205
          fi
        done
        echo "`date`: Post thaw script finished"
      }
      
      # Debug logging for parameters passed to the SSM document
        echo "INFO: ${OPERATION} starting at $(date) with executionId: ${EXECUTION_ID}"
                    
      # Based on the command parameter value execute the function that supports 
      # pre-script/post-script operation
      case ${OPERATION} in
        pre-script)
          execute_pre_script
          ;;
        post-script)
          execute_post_script
            ;;
        dry-run)
          echo "INFO: dry-run option invoked - taking no action"
          ;;
        *)
          echo "ERROR: Invalid command parameter passed. Please use either pre-script, post-script, dry-run."
          # return failure
          EXIT_CODE=1
          ;;
      esac
                    
      END=$(date +%s)
      # Debug Log for profiling the script time
      echo "INFO: ${OPERATION} completed at $(date). Total runtime: $((${END} - ${START})) seconds."
      exit $EXIT_CODE
```

詳細については、[GitHub リポジトリ](https://github.com/intersystems-community/aws/blob/master/README.md)を参照してください。

------
#### [ Empty document template ]

```
###===============================================================================###
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.

# Permission is hereby granted, free of charge, to any person obtaining a copy of this
# software and associated documentation files (the "Software"), to deal in the Software
# without restriction, including without limitation the rights to use, copy, modify,
# merge, publish, distribute, sublicense, and/or sell copies of the Software, and to
# permit persons to whom the Software is furnished to do so.

# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
# INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
# PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
# HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
# OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
# SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
###===============================================================================###
schemaVersion: '2.2'
description: SSM Document Template for Amazon Data Lifecycle Manager Pre/Post script feature
parameters:
  executionId:
    type: String
    default: None
    description: (Required) Specifies the unique identifier associated with a pre and/or post execution
    allowedPattern: ^(None|[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12})$
  command:
  # Data Lifecycle Manager will trigger the pre-script and post-script actions during policy execution. 
  # 'dry-run' option is intended for validating the document execution without triggering any commands
  # on the instance. The following allowedValues will allow Data Lifecycle Manager to successfully 
  # trigger pre and post script actions.
    type: String
    default: 'dry-run'
    description: (Required) Specifies whether pre-script and/or post-script should be executed.
    allowedValues:
    - pre-script
    - post-script
    - dry-run

mainSteps:
- action: aws:runShellScript
  description: Run Database freeze/thaw commands
  name: run_pre_post_scripts
  precondition:
    StringEquals:
    - platformType
    - Linux
  inputs:
    runCommand:
    - |
      #!/bin/bash

      ###===============================================================================###
      ### Error Codes
      ###===============================================================================###
      # The following Error codes will inform Data Lifecycle Manager of the type of error 
      # and help guide handling of the error. 
      # The Error code will also be emitted via AWS Eventbridge events in the 'cause' field.
      # 1 Pre-script failed during execution - 201
      # 2 Post-script failed during execution - 202
      # 3 Auto thaw occurred before post-script was initiated - 203
      # 4 Pre-script initiated while post-script was expected - 204
      # 5 Post-script initiated while pre-script was expected - 205
      # 6 Application not ready for pre or post-script initiation - 206

      ###===============================================================================###
      ### Global variables
      ###===============================================================================###
      START=$(date +%s)
      # For testing this script locally, replace the below with OPERATION=$1.
      OPERATION={{ command }}

      # Add all pre-script actions to be performed within the function below
      execute_pre_script() {
          echo "INFO: Start execution of pre-script"
      }

      # Add all post-script actions to be performed within the function below
      execute_post_script() {
          echo "INFO: Start execution of post-script"
      }

      # Debug logging for parameters passed to the SSM document
      echo "INFO: ${OPERATION} starting at $(date) with executionId: ${EXECUTION_ID}"

      # Based on the command parameter value execute the function that supports 
      # pre-script/post-script operation
      case ${OPERATION} in
          pre-script)
              execute_pre_script
              ;;
          post-script)
              execute_post_script
              ;;
          dry-run)
              echo "INFO: dry-run option invoked - taking no action"
              ;;
          *)
              echo "ERROR: Invalid command parameter passed. Please use either pre-script, post-script, dry-run."
              exit 1 # return failure
              ;;
      esac

      END=$(date +%s)
      # Debug Log for profiling the script time
      echo "INFO: ${OPERATION} completed at $(date). Total runtime: $((${END} - ${START})) seconds."
```

------

SSM ドキュメントコンテンツを取得したら、以下のいずれかの手順でカスタム SSM ドキュメントを作成します。

------
#### [ Console ]

**SSM コマンドドキュメント を作成するには**

1. [ https://console.aws.amazon.com//systems-manager/ ](https://console.aws.amazon.com//systems-manager/)で AWS Systems Manager コンソールを開きます。

1. ナビゲーションペインで **[ドキュメント]** を選択し、**[ドキュメントの作成]**、**[コマンドまたはセッション]** の順に選択します。

1. [**名前**] に、ドキュメントのわかりやすい名前を入力します。

1. **[ターゲットタイプ]** に、**[/AWS::EC2::Instance]** を選択します。

1. **[ドキュメントタイプ]** に、**[コマンド]** を選択します。

1. **[コンテンツ]** フィールドで **[YAML]** を選択し、ドキュメントコンテンツを貼り付けます。

1. **[ドキュメントタグ]** セクションで、タグキーが `DLMScriptsAccess` でタグ値が `true` のタグを追加します。
**重要**  
`DLMScriptsAccess:true` タグは、*ステップ 3: Amazon Data Lifecycle Manager IAM ロールを準備する*で使用される **AWSDataLifecycleManagerSSMFullAccess** AWS 管理ポリシーで必要です。このポリシーでは `aws:ResourceTag` 条件キーが使用されており、このタグを持つ SSM ドキュメントへのアクセスを制限します。

1. [**ドキュメントの作成**] を選択します。

------
#### [ AWS CLI ]

**SSM コマンドドキュメント を作成するには**  
[create-document](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-document.html) コマンドを使用します。`--name` には、ドキュメントのわかりやすい名前を指定します。`--document-type` の場合、`Command` を指定します。`--content` には、SSM ドキュメントコンテンツを含む .yaml ファイルへのパスを指定します。`--tags` の場合、`"Key=DLMScriptsAccess,Value=true"` を指定します。

```
$ aws ssm create-document \
--content file://path/to/file/documentContent.yaml \
--name "document_name" \
--document-type "Command" \
--document-format YAML \
--tags "Key=DLMScriptsAccess,Value=true"
```

------

### ステップ 3: Amazon Data Lifecycle Manager の IAM ロールを準備する
<a name="prep-iam-role"></a>

**注記**  
このステップは次の場合に必要です。  
カスタム IAM ロールを使用する、事前/事後スクリプト対応のスナップショットポリシーを作成または更新します。
コマンドラインを使用して、デフォルトを使用する、事前/事後スクリプト対応のスナップショットポリシーを作成または更新します。
コンソールを使用して、スナップショットを管理するためのデフォルトロール (**AWSDataLifecycleManagerDefaultRole**) を使用する、事前/事後スクリプト対応のスナップショットポリシーを作成または更新する場合は、このステップをスキップしてください。この場合、**AWSDataLifecycleManagerSSMFullAccess** ポリシーが自動的にそのロールにアタッチされます。

ポリシーに使用する IAM ロールが、ポリシーのターゲットとなるインスタンスで事前スクリプトと事後スクリプトを実行するために必要な SSM アクションを実行する権限を Amazon Data Lifecycle Manager に付与していることを確認する必要があります。

Amazon Data Lifecycle Manager には、必要なアクセス許可を含むマネージドポリシー (**AWSDataLifecycleManagerSSMFullAccess**) が用意されています。スナップショットを管理するための IAM ロールにこのポリシーをアタッチすると、確実にアクセス許可を含めることができます。

**重要**  
AWSDataLifecycleManagerSSMFullAccess マネージドポリシーでは、事前スクリプトと事後スクリプトを使用するときに、`aws:ResourceTag` 条件キーを使って特定の SSM ドキュメントへのアクセスを制限します。Amazon Data Lifecycle Manager が SSM ドキュメントにアクセスできるようにするには、SSM ドキュメントに `DLMScriptsAccess:true` のタグが付けられていることを確認する必要があります。

あるいは、カスタムポリシーを手動で作成するか、使用する IAM ロールに必要なアクセス許可を直接割り当てることもできます。AWSDataLifecycleManagerSSMFullAccess マネージドポリシーで定義されているのと同じアクセス許可を使用できますが、`aws:ResourceTag` 条件キーはオプションです。その条件キーを含めない場合は、SSM ドキュメントに `DLMScriptsAccess:true` のタグを付ける必要はありません。

以下のいずれかの方法を使用して、**AWSDataLifecycleManagerSSMFullAccess** ポリシーを IAM ロールに追加します。

------
#### [ Console ]

**マネージドポリシーをカスタムロールにアタッチするには**

1. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) で IAM コンソールを開きます。

1. ナビゲーションパネルで [**Roles (ロール) **] を選択します。

1. スナップショットを管理するためのカスタムロールを検索し、選択します。

1. **[アクセス許可]** タブで、**[アクセス許可の追加]**、**[ポリシーをアタッチ]** の順に選択します。

1. **[AWSDataLifecycleManagerSSMFullAccess]** マネージドポリシーを検索して選択し、**[アクセス許可の追加]** を選択します。

------
#### [ AWS CLI ]

**マネージドポリシーをカスタムロールにアタッチするには**  
[attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html) コマンドを使用します。`---role-name` には、カスタムロールの名前を指定します。`--policy-arn` の場合、`arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess` を指定します。

```
$ aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess \
--role-name your_role_name
```

------

### ステップ 4: スナップショットライフサイクルポリシーを作成する
<a name="prep-policy"></a>

アプリケーション整合性のあるスナップショットを自動化するには、インスタンスをターゲットとするスナップショットライフサイクルポリシーを作成し、そのポリシーの事前スクリプトと事後スクリプトを設定する必要があります。

------
#### [ Console ]

**スナップショットライフサイクルポリシーを作成するには**

1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。

1. ナビゲーションペインで、[**Elastic Block Store**]、[**ライフサイクルマネージャー**]、[**ライフサイクルポリシーの作成**] の順に選択します。

1. リポジトリの [**ポリシータイプの選択**] 画面で、[**EBS スナップショットポリシー**] を選択し、[**次へ**] をクリックします。

1. **[Target resources]** (ターゲットリソース) セクションで、以下の操作を行います。

   1. **[ターゲットリソースタイプ]** で、[`Instance`] を選択します。

   1. **[ターゲットリソースタグ]** で、バックアップするインスタンスを識別するリソースタグを指定します。指定したタグを持つリソースのみがバックアップされます。

1. **[IAM ロール]** には、**AWSDataLifecycleManagerDefaultRole** (スナップショットを管理するためのデフォルトロール) を選択するか、事前スクリプトおよび事後スクリプト用に作成して準備したカスタムロールを選択します。

1. 必要に応じて、スケジュールと追加のオプションを設定します。メンテナンスウィンドウ中など、ワークロードに合った期間にスナップショット作成時刻をスケジュールすることをお勧めします。

   SAP HANA では、高速スナップショット復元を有効にすることをお勧めします。
**注記**  
VSS バックアップのスケジュールを有効にすると、**[特定のデータボリュームを除外]** または **[ソースからタグをコピー]** を有効にすることはできません。

1. **[事前スクリプトと事後スクリプト]** セクションで **[事前スクリプトと事後スクリプトを有効にする]** を選択し、ワークロードに応じて次の操作を行います。
   + Windows アプリケーションのアプリケーション整合性のあるスナップショットを作成するには、**[VSS バックアップ]** を選択します。
   + SAP HANA ワークロードのアプリケーション整合性のあるスナップショットを作成するには、**[SAP HANA]** を選択します。
   + カスタム SSM ドキュメントを使用して、セルフマネージドの MySQL、PostgreSQL、または InterSystems IRIS データベースを含む、他のすべてのデータベースとワークロードのアプリケーション整合性のあるスナップショットを作成するには、**[カスタム SSM ドキュメント]** を選択します。

     1. **[自動化オプション]** に、**[事前スクリプトと事後スクリプト]** を選択します。

     1. **[SSM ドキュメント]** に、準備した SSM ドキュメントを選択します。

1. 選択したオプションに応じて、以下の追加オプションを設定します。
   + **[スクリプトタイムアウト]** — (*カスタム SSM ドキュメントのみ*) Amazon Data Lifecycle Manager がスクリプトの実行試行を完了していない場合に、その試行が失敗するまでのタイムアウト期間。スクリプトがタイムアウト期間内に完了しない場合、Amazon Data Lifecycle Manager はその試行に失敗します。タイムアウト期間は、事前スクリプトと事後スクリプトに個別に適用されます。デフォルトのタイムアウト期間は 10 秒です。また、最大タイムアウト期間は 120 秒です。
   + **[失敗したスクリプトの再試行]** — タイムアウト期間内に完了しなかったスクリプトを再試行する場合は、このオプションを選択します。事前スクリプトが失敗した場合、Amazon Data Lifecycle Manager は、事前スクリプトと事後スクリプトの実行を含め、スナップショット作成プロセス全体を再試行します。事後スクリプトが失敗した場合、Amazon Data Lifecycle Manager は、事後スクリプトのみを再試行します。この場合、事前スクリプトは完了し、スナップショットが作成された可能性があります。
   + **Crash-consistent スナップショットをデフォルトで作成** – このオプションを選択すると、事前スクリプトの実行に失敗した場合に、Crash-consistent スナップショットがデフォルトで作成されます。これは、事前スクリプトと事後スクリプトが有効になっていない場合の、Amazon Data Lifecycle Manager のデフォルトのスナップショット作成動作です。再試行を有効にした場合、Amazon Data Lifecycle Manager は、再試行回数をすべて使い切った後にのみ、Crash-consistent スナップショットをデフォルトで作成します。事前スクリプトが失敗し、Crash-consistent スナップショットがデフォルトで作成されなかった場合、Amazon Data Lifecycle Manager は、そのスケジュールの実行中にインスタンスのスナップショットを作成しません。
**注記**  
SAP HANA のスナップショットを作成する場合は、このオプションを無効にすることをお勧めします。SAP HANA ワークロードのCrash-consistent スナップショットは、同じ方法では復元できません。

1. **[デフォルトポリシーの作成]** を選択します。
**注記**  
`Role with name AWSDataLifecycleManagerDefaultRole already exists` エラーが発生した場合、詳細については「[Amazon Data Lifecycle Manager の問題のトラブルシューティング](dlm-troubleshooting.md)」を参照してください。

------
#### [ AWS CLI ]

**スナップショットライフサイクルポリシーを作成するには**  
[create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html) コマンドを使用して、`CreateRule` に `Scripts` パラメータを含めます。パラメータの詳細については、「[https://docs.aws.amazon.com/dlm/latest/APIReference/API_Script.html](https://docs.aws.amazon.com/dlm/latest/APIReference/API_Script.html)」を参照してください。

```
$ aws dlm create-lifecycle-policy \
--description "policy_description" \
--state ENABLED \
--execution-role-arn iam_role_arn \
--policy-details file://policyDetails.json
```

ユースケースに応じて、ここで `policyDetails.json` には以下のいずれかが含まれます。
+ **VSS バックアップ**

  ```
  {
      "PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
      "ResourceTypes": [
          "INSTANCE"
      ],
      "TargetTags": [{
          "Key": "tag_key",
          "Value": "tag_value"
      }],
      "Schedules": [{
          "Name": "schedule_name",
          "CreateRule": {
              "CronExpression": "cron_for_creation_frequency", 
              "Scripts": [{ 
                  "ExecutionHandler":"AWS_VSS_BACKUP",
                  "ExecuteOperationOnScriptFailure":true|false,
                  "MaximumRetryCount":retries (0-3)
              }]
          },
          "RetainRule": {
              "Count": retention_count
          }
      }]
  }
  ```
+ **SAP HANA バックアップ**

  ```
  {
      "PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
      "ResourceTypes": [
          "INSTANCE"
      ],
      "TargetTags": [{
          "Key": "tag_key",
          "Value": "tag_value"
      }],
      "Schedules": [{
          "Name": "schedule_name",
          "CreateRule": {
              "CronExpression": "cron_for_creation_frequency", 
              "Scripts": [{ 
                  "Stages": ["PRE","POST"],
                  "ExecutionHandlerService":"AWS_SYSTEMS_MANAGER",
                  "ExecutionHandler":"AWSSystemsManagerSAP-CreateDLMSnapshotForSAPHANA",
                  "ExecuteOperationOnScriptFailure":true|false,
                  "ExecutionTimeout":timeout_in_seconds (10-120), 
                  "MaximumRetryCount":retries (0-3)
              }]
          },
          "RetainRule": {
              "Count": retention_count
          }
      }]
  }
  ```
+ **カスタム SSM ドキュメント**

  ```
  {
      "PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
      "ResourceTypes": [
          "INSTANCE"
      ],
      "TargetTags": [{
          "Key": "tag_key",
          "Value": "tag_value"
      }],
      "Schedules": [{
          "Name": "schedule_name",
          "CreateRule": {
              "CronExpression": "cron_for_creation_frequency", 
              "Scripts": [{ 
                  "Stages": ["PRE","POST"],
                  "ExecutionHandlerService":"AWS_SYSTEMS_MANAGER",
                  "ExecutionHandler":"ssm_document_name|arn",
                  "ExecuteOperationOnScriptFailure":true|false,
                  "ExecutionTimeout":timeout_in_seconds (10-120), 
                  "MaximumRetryCount":retries (0-3)
              }]
          },
          "RetainRule": {
              "Count": retention_count
          }
      }]
  }
  ```

------

## Amazon Data Lifecycle Manager での VSS バックアップに関する考慮事項
<a name="app-consistent-vss"></a>

Amazon Data Lifecycle Manager では、Amazon EC2 インスタンスで実行されている VSS (Volume Shadow Copy Service) 対応の Windows アプリケーションをバックアップおよび復元できます。アプリケーションに Windows VSS に登録された VSS ライターがある場合、Amazon Data Lifecycle Manager は、そのアプリケーションに対してアプリケーションと整合性のあるスナップショットを作成します。

**注記**  
Amazon Data Lifecycle Manager は現在、Amazon EC2 で実行されているリソースのアプリケーション整合性のあるスナップショットのみをサポートしています。特に、既存のインスタンスをバックアップから作成された新しいインスタンスに置き換えることでアプリケーションデータを復元できるバックアップシナリオを対象としています。VSS バックアップでは、すべてのインスタンスタイプまたはアプリケーションがサポートされているわけではありません。詳細については、「*Amazon EC2 ユーザーガイド*」の「[アプリケーションと整合性のある、Windows VSS ベースの Amazon EBS スナップショット](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots.html)」を参照してください。

**サポートされていない インスタンスタイプ**  
以下の Amazon EC2 インスタンスタイプは、VSS バックアップではサポートされていません。ポリシーがこれらのインスタンスタイプのいずれかをターゲットにしている場合、Amazon Data Lifecycle Manager は引き続き VSS バックアップを作成できますが、スナップショットには必要なシステムタグがタグ付けされていない可能性があります。これらのタグがないと、スナップショットは作成後に Amazon Data Lifecycle Manager によって管理されません。これらのスナップショットは手動で削除する必要がある場合があります。
+ T3: `t3.nano` \$1 `t3.micro`
+ T3a: `t3a.nano` \$1 `t3a.micro`
+ T2: `t2.nano` \$1 `t2.micro`

## アプリケーション整合性のあるスナップショットの責任共有
<a name="shared-responsibility"></a>

**次の点を確認する必要があります。**
+ SSM Agent がインストールされ、最新の状態で、ターゲットインスタンスで実行されている
+ Systems Manager には、ターゲットインスタンスで必要なアクションを実行する権限があります。
+ Amazon Data Lifecycle Manager には、ターゲットインスタンスでの事前スクリプトと事後スクリプトの実行に必要な Systems Manager アクションを実行する権限があります。
+ カスタムワークロード (MySQL や PostgreSQL、または InterSystems IRIS などのセルフマネージド型データベース) の場合、使用する SSM ドキュメントには、データベース設定の I/O をフリーズ、フラッシュ、および解凍するための適切で必要なアクションが含まれています。
+ スナップショット作成時刻はワークロードのスケジュールに合わせて調整されます。例えば、スケジュールされたメンテナンスウィンドウ中にスナップショットの作成をスケジュールしようとします。

**Amazon Data Lifecycle Manager では以下の動作が保証されます。**
+ スナップショットの作成は、スケジュールされたスナップショット作成時刻から 60 分以内に開始されます。
+ 事前スクリプトは、スナップショットの作成が開始される前に実行されます。
+ 事後スクリプトは、事前スクリプトが成功し、スナップショットの作成が開始された後に実行されます。Amazon Data Lifecycle Manager は、事前スクリプトが成功した場合にのみ事後スクリプトを実行します。事前スクリプトが失敗した場合、Amazon Data Lifecycle Manager は事後スクリプトを実行しません。
+ スナップショットは作成時に適切なタグでタグ付けされます。
+ CloudWatch メトリクスおよびイベントは、スクリプトが開始されたとき、およびスクリプトが失敗または成功したときに発生します。

# Data Lifecycle Manager の事前スクリプトと事後スクリプトのその他のユースケース
<a name="script-other-use-cases"></a>

事前スクリプトと事後スクリプトを使用してアプリケーション整合性のあるスナップショットを自動化するだけでなく、事前スクリプトと事後スクリプトを一緒に、または個別に使用して、スナップショット作成前または作成後の他の管理タスクを自動化できます。例えば、次のようになります。
+ スナップショットを作成する前に、事前スクリプトを使用してパッチを適用します。これにより、毎週または毎月の定期的なソフトウェアアップデートを適用した後にスナップショットを作成できます。
**注記**  
事前スクリプトのみを実行することを選択した場合は、**[Crash-consistent スナップショットをデフォルトで作成]** がデフォルトで有効になります。
+ スナップショットを作成した後に、事後スクリプトを使用してパッチを適用します。これにより、毎週または毎月の定期的なソフトウェアアップデートを適用する前にスナップショットを作成できます。

## 他のユースケースで使用を開始する
<a name="dlm-script-other"></a>

このセクションでは、**アプリケーション整合性のあるスナップショット以外のユースケース**で事前スクリプトまたは事後スクリプトを使用する場合に実行する必要がある手順について説明します。

### ステップ 1: ターゲットインスタンスを準備する
<a name="dlm-script-other-prep-instance"></a>

**ターゲットインスタンスを事前スクリプトまたは事後スクリプト用に準備するには**

1. SSM Agent がまだインストールされていない場合は、ターゲットインスタンスにインストールします。SSM Agent がターゲットインスタンスに既にインストールされている場合は、このステップをスキップしてください。
   + (Linux インスタンス) [Linux 用 EC2 インスタンスに SSM Agent を手動でインストールおよびアンインストールする](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html)
   + (Windows インスタンス) [Windows Server 用 EC2 インスタンスで SSM Agent を使用する](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-windows.html)

1. SSM Agent が実行中であることを確認します。詳細については、「[SSM Agent ステータスの確認とエージェントの起動](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html)」を参照してください。

1. Systems Manager の Amazon EC2 インスタンスをセットアップします。詳細については、「*AWS Systems Manager ユーザーガイド*」の「[Systems Manager を利用した EC2 インスタンスの管理](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html)」を参照してください。

### ステップ 2: SSM ドキュメントを準備する
<a name="dlm-script-other-prep-document"></a>

実行するコマンドを使った事前スクリプトまたは事後スクリプトを含む SSM コマンドドキュメントを作成する必要があります。

以下の空の SSM ドキュメントテンプレートを使用して SSM ドキュメントを作成し、事前スクリプトコマンドと事後スクリプトコマンドを該当するドキュメントセクションに追加できます。

**次の点に注意してください。**  
SSM ドキュメントがユーザーのワークロードに対して適切かつ必要なアクションを実行していることを確認するのは、ユーザーの責任になります。
SSM ドキュメントには、`pre-script`、`post-script`、`dry-run` などの `allowedValues` の必須フィールドが含まれている必要があります。Amazon Data Lifecycle Manager は、これらのセクションのコンテンツに基づいてインスタンス上でコマンドを実行します。SSM ドキュメントにこれらのセクションがない場合、Amazon Data Lifecycle Manager は、そのドキュメントを実行に失敗したものとして扱います。

```
###===============================================================================###
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.

# Permission is hereby granted, free of charge, to any person obtaining a copy of this
# software and associated documentation files (the "Software"), to deal in the Software
# without restriction, including without limitation the rights to use, copy, modify,
# merge, publish, distribute, sublicense, and/or sell copies of the Software, and to
# permit persons to whom the Software is furnished to do so.

# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
# INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
# PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
# HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
# OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
# SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
###===============================================================================###
schemaVersion: '2.2'
description: SSM Document Template for Amazon Data Lifecycle Manager Pre/Post script feature
parameters:
  executionId:
    type: String
    default: None
    description: (Required) Specifies the unique identifier associated with a pre and/or post execution
    allowedPattern: ^(None|[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12})$
  command:
  # Data Lifecycle Manager will trigger the pre-script and post-script actions during policy execution. 
  # 'dry-run' option is intended for validating the document execution without triggering any commands
  # on the instance. The following allowedValues will allow Data Lifecycle Manager to successfully 
  # trigger pre and post script actions.
    type: String
    default: 'dry-run'
    description: (Required) Specifies whether pre-script and/or post-script should be executed.
    allowedValues:
    - pre-script
    - post-script
    - dry-run

mainSteps:
- action: aws:runShellScript
  description: Run Database freeze/thaw commands
  name: run_pre_post_scripts
  precondition:
    StringEquals:
    - platformType
    - Linux
  inputs:
    runCommand:
    - |
      #!/bin/bash

      ###===============================================================================###
      ### Error Codes
      ###===============================================================================###
      # The following Error codes will inform Data Lifecycle Manager of the type of error 
      # and help guide handling of the error. 
      # The Error code will also be emitted via AWS Eventbridge events in the 'cause' field.
      # 1 Pre-script failed during execution - 201
      # 2 Post-script failed during execution - 202
      # 3 Auto thaw occurred before post-script was initiated - 203
      # 4 Pre-script initiated while post-script was expected - 204
      # 5 Post-script initiated while pre-script was expected - 205
      # 6 Application not ready for pre or post-script initiation - 206

      ###===============================================================================###
      ### Global variables
      ###===============================================================================###
      START=$(date +%s)
      # For testing this script locally, replace the below with OPERATION=$1.
      OPERATION={{ command }}

      # Add all pre-script actions to be performed within the function below
      execute_pre_script() {
          echo "INFO: Start execution of pre-script"
      }

      # Add all post-script actions to be performed within the function below
      execute_post_script() {
          echo "INFO: Start execution of post-script"
      }

      # Debug logging for parameters passed to the SSM document
      echo "INFO: ${OPERATION} starting at $(date) with executionId: ${EXECUTION_ID}"

      # Based on the command parameter value execute the function that supports 
      # pre-script/post-script operation
      case ${OPERATION} in
          pre-script)
              execute_pre_script
              ;;
          post-script)
              execute_post_script
              ;;
          dry-run)
              echo "INFO: dry-run option invoked - taking no action"
              ;;
          *)
              echo "ERROR: Invalid command parameter passed. Please use either pre-script, post-script, dry-run."
              exit 1 # return failure
              ;;
      esac

      END=$(date +%s)
      # Debug Log for profiling the script time
      echo "INFO: ${OPERATION} completed at $(date). Total runtime: $((${END} - ${START})) seconds."
```

### ステップ 3: Amazon Data Lifecycle Manager の IAM ロールを準備する
<a name="dlm-script-other-prep-role"></a>

**注記**  
このステップは次の場合に必要です。  
カスタム IAM ロールを使用する、事前/事後スクリプト対応のスナップショットポリシーを作成または更新します。
コマンドラインを使用して、デフォルトを使用する、事前/事後スクリプト対応のスナップショットポリシーを作成または更新します。
コンソールを使用して、スナップショットを管理するためのデフォルトロール (**AWSDataLifecycleManagerDefaultRole**) を使用する、事前/事後スクリプト対応のスナップショットポリシーを作成または更新する場合は、このステップをスキップしてください。この場合、**AWSDataLifecycleManagerSSMFullAccess** ポリシーが自動的にそのロールにアタッチされます。

ポリシーに使用するその IAM ロールが、ポリシーのターゲットとなるインスタンスで事前スクリプトと事後スクリプトを実行するために必要な SSM アクションを実行する権限を Amazon Data Lifecycle Manager に付与していることを確認する必要があります。

Amazon Data Lifecycle Manager には、必要なアクセス許可を含むマネージドポリシー (**AWSDataLifecycleManagerSSMFullAccess**) が用意されています。スナップショットを管理するための IAM ロールにこのポリシーをアタッチすると、確実にアクセス許可を含めることができます。

**重要**  
AWSDataLifecycleManagerSSMFullAccess マネージドポリシーでは、事前スクリプトと事後スクリプトを使用するときに、`aws:ResourceTag` 条件キーを使って特定の SSM ドキュメントへのアクセスを制限します。Amazon Data Lifecycle Manager が SSM ドキュメントにアクセスできるようにするには、SSM ドキュメントに `DLMScriptsAccess:true` のタグが付けられていることを確認する必要があります。

あるいは、カスタムポリシーを手動で作成するか、使用する IAM ロールに必要なアクセス許可を直接割り当てることもできます。AWSDataLifecycleManagerSSMFullAccess マネージドポリシーで定義されているのと同じアクセス許可を使用できますが、`aws:ResourceTag` 条件キーはオプションです。この条件キーを使用しない場合は、SSM ドキュメントに `DLMScriptsAccess:true` のタグを付ける必要はありません。

以下のいずれかの方法を使用して、**AWSDataLifecycleManagerSSMFullAccess** ポリシーを IAM ロールに追加します。

------
#### [ Console ]

**マネージドポリシーをカスタムロールにアタッチするには**

1. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) で IAM コンソールを開きます。

1. ナビゲーションパネルで [**Roles (ロール) **] を選択します。

1. スナップショットを管理するためのカスタムロールを検索し、選択します。

1. **[アクセス許可]** タブで、**[アクセス許可の追加]**、**[ポリシーをアタッチ]** の順に選択します。

1. **[AWSDataLifecycleManagerSSMFullAccess]** マネージドポリシーを検索して選択し、**[アクセス許可の追加]** を選択します。

------
#### [ AWS CLI ]

**マネージドポリシーをカスタムロールにアタッチするには**  
[attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html) コマンドを使用します。`---role-name` には、カスタムロールの名前を指定します。`--policy-arn` の場合、`arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess` を指定します。

```
$ aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess \
--role-name your_role_name
```

------

### スナップショットライフサイクルポリシーを作成する
<a name="dlm-script-other-prep-policy"></a>

------
#### [ Console ]

**スナップショットライフサイクルポリシーを作成するには**

1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。

1. ナビゲーションペインで、[**Elastic Block Store**]、[**ライフサイクルマネージャー**]、[**ライフサイクルポリシーの作成**] の順に選択します。

1. リポジトリの [**ポリシータイプの選択**] 画面で、[**EBS スナップショットポリシー**] を選択し、[**次へ**] をクリックします。

1. **[Target resources]** (ターゲットリソース) セクションで、以下の操作を行います。

   1. **[ターゲットリソースタイプ]** で、[`Instance`] を選択します。

   1. **[ターゲットリソースタグ]** で、バックアップするインスタンスを識別するリソースタグを指定します。指定したタグを持つリソースのみがバックアップされます。

1. **[IAM ロール]** には、**AWSDataLifecycleManagerDefaultRole** (スナップショットを管理するためのデフォルトロール) を選択するか、事前スクリプトおよび事後スクリプト用に作成して準備したカスタムロールを選択します。

1. 必要に応じて、スケジュールと追加のオプションを設定します。メンテナンスウィンドウ中など、ワークロードに合った期間にスナップショット作成時刻をスケジュールすることをお勧めします。

1. **[事前スクリプトと事後スクリプト]** セクションで、**[事前スクリプトと事後スクリプトを有効にする]** を選択し、次の操作を行います。

   1. **[カスタム SSM ドキュメント]** を選択します。

   1. **[自動化]** オプションで、実行するスクリプトに一致するオプションを選択します。

   1. **[SSM ドキュメント]** に、準備した SSM ドキュメントを選択します。

1. 必要に応じて、次の追加オプションを設定します。
   + **[スクリプトタイムアウト]** — Amazon Data Lifecycle Manager がスクリプトの実行試行を完了していない場合に、その試行が失敗するまでのタイムアウト期間。スクリプトがタイムアウト期間内に完了しない場合、Amazon Data Lifecycle Manager はその試行に失敗します。タイムアウト期間は、事前スクリプトと事後スクリプトに個別に適用されます。デフォルトのタイムアウト期間は 10 秒です。また、最大タイムアウト期間は 120 秒です。
   + **[失敗したスクリプトの再試行]** — タイムアウト期間内に完了しなかったスクリプトを再試行する場合は、このオプションを選択します。事前スクリプトが失敗した場合、Amazon Data Lifecycle Manager は、事前スクリプトと事後スクリプトの実行を含め、スナップショット作成プロセス全体を再試行します。事後スクリプトが失敗した場合、Amazon Data Lifecycle Manager は、事後スクリプトのみを再試行します。この場合、事前スクリプトは完了し、スナップショットが作成された可能性があります。
   + **Crash-consistent スナップショットをデフォルトで作成** – このオプションを選択すると、事前スクリプトの実行に失敗した場合に、Crash-consistent スナップショットがデフォルトで作成されます。これは、事前スクリプトと事後スクリプトが有効になっていない場合の、Amazon Data Lifecycle Manager のデフォルトのスナップショット作成動作です。再試行を有効にした場合、Amazon Data Lifecycle Manager は、再試行回数をすべて使い切った後にのみ、Crash-consistent スナップショットをデフォルトで作成します。事前スクリプトが失敗し、Crash-consistent スナップショットがデフォルトで作成されなかった場合、Amazon Data Lifecycle Manager は、そのスケジュールの実行中にインスタンスのスナップショットを作成しません。

1. **[デフォルトポリシーの作成]** を選択します。
**注記**  
`Role with name AWSDataLifecycleManagerDefaultRole already exists` エラーが発生した場合、詳細については「[Amazon Data Lifecycle Manager の問題のトラブルシューティング](dlm-troubleshooting.md)」を参照してください。

------
#### [ AWS CLI ]

**スナップショットライフサイクルポリシーを作成するには**  
[create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html) コマンドを使用して、`CreateRule` に `Scripts` パラメータを含めます。パラメータの詳細については、「[https://docs.aws.amazon.com/dlm/latest/APIReference/API_Script.html](https://docs.aws.amazon.com/dlm/latest/APIReference/API_Script.html)」を参照してください。

```
$ aws dlm create-lifecycle-policy \
--description "policy_description" \
--state ENABLED \
--execution-role-arn iam_role_arn \
--policy-details file://policyDetails.json
```

ここで `policyDetails.json` には以下が含まれます。

```
{
    "PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
    "ResourceTypes": [
        "INSTANCE"
    ],
    "TargetTags": [{
        "Key": "tag_key",
        "Value": "tag_value"
    }],
    "Schedules": [{
        "Name": "schedule_name",
        "CreateRule": {
            "CronExpression": "cron_for_creation_frequency", 
            "Scripts": [{ 
                "Stages": ["PRE" | "POST" | "PRE","POST"],
                "ExecutionHandlerService":"AWS_SYSTEMS_MANAGER",
                "ExecutionHandler":"ssm_document_name|arn",
                "ExecuteOperationOnScriptFailure":true|false,
                "ExecutionTimeout":timeout_in_seconds (10-120), 
                "MaximumRetryCount":retries (0-3)
            }]
        },
        "RetainRule": {
            "Count": retention_count
        }
    }]
}
```

------

# Amazon Data Lifecycle Manager の事前スクリプトと事後スクリプトの仕組み
<a name="script-flow"></a>

次の図は、カスタム SSM ドキュメントを使用する場合の事前スクリプトと事後スクリプトのプロセスフローを示しています。これは、VSS バックアップには適用されません。

![\[Amazon Data Lifecycle Manager での事前スクリプトと事後スクリプトのプロセスフロー\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/images/dlm-scripts.png)


スケジュールされたスナップショット作成時刻に、以下のアクションおよびクロスサービスインタラクションが発生します。

1. Amazon Data Lifecycle Manager は、SSM ドキュメントを呼び出して `pre-script` パラメータを渡すことにより、事前スクリプトアクションを開始します。
**注記**  
ステップ 1～3 は、事前スクリプトを実行する場合にのみ発生します。事後スクリプトのみを実行する場合、ステップ 1～3 はスキップされます。

1. Systems Manager は、ターゲットインスタンスで実行されている SSM Agent に事前スクリプトコマンドを送信します。SSM Agent はインスタンス上でコマンドを実行し、ステータス情報を Systems Manager に送り返します。

   例えば、SSM ドキュメントを使用してアプリケーション整合性のあるスナップショットを作成する場合、スナップショットの取得前にバッファリングされたすべてのデータがボリュームに書き込まれるように、事前スクリプトは I/O をフリーズおよびフラッシュする場合があります。

1. Systems Manager は、事前スクリプトコマンドのステータス更新を Amazon Data Lifecycle Manager に送信します。事前スクリプトが失敗した場合、Amazon Data Lifecycle Manager は、事前スクリプトオプションと事後スクリプトオプションの設定方法に応じて、以下のいずれかのアクションを実行します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/script-flow.html)

1. Amazon Data Lifecycle Manager がスナップショットの作成を開始します。

1. Amazon Data Lifecycle Manager は、SSM ドキュメントを呼び出して `post-script` パラメータを渡すことにより、事後スクリプトアクションを開始します。
**注記**  
ステップ 5～7 は、事前スクリプトを実行する場合にのみ発生します。事後スクリプトのみを実行する場合、ステップ 1～3 はスキップされます。

1. Systems Manager は、ターゲットインスタンスで実行されている SSM Agent に事後スクリプトコマンドを送信します。SSM Agent はインスタンス上でコマンドを実行し、ステータス情報を Systems Manager に送り返します。

   例えば、SSM ドキュメントでアプリケーション整合性のあるスナップショットが有効になっている場合、スナップショットの取得後にデータベースが通常の I/O 操作を再開できるように、この事後スクリプトは I/O を凍結する場合があります。

1. 事後スクリプトを実行し、Systems Manager で正常に完了したことが表示されれば、処理は完了します。

   事後スクリプトが失敗した場合、Amazon Data Lifecycle Manager は、事前スクリプトオプションと事後スクリプトオプションの設定方法に応じて、以下のいずれかのアクションを実行します。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/script-flow.html)

   事後スクリプトが失敗しても、事前スクリプト (有効な場合) は正常に完了し、スナップショットが作成された可能性があることに注意してください。インスタンスが期待どおりに動作していることを確認するために、インスタンスに対してさらにアクションを実行する必要がある場合があります。例えば、事前スクリプトが I/O を一時停止してフラッシュしたが、事後スクリプトが I/O の解凍に失敗した場合は、I/O を自動解凍するようにデータベースを設定するか、I/O を手動で解凍する必要があります。

1. スナップショットの作成プロセスは、事後スクリプトの完了後に完了することがあります。スナップショットの完了にかかる時間は、スナップショットのサイズによって異なります。

# Data Lifecycle Manager の事前スクリプトと事後スクリプトで作成されたスナップショットを特定
<a name="dlm-script-tags"></a>

Amazon Data Lifecycle Manager は、事前スクリプトと事後スクリプトで作成されたスナップショットに、以下のシステムタグを自動的に割り当てます。
+ キー: `aws:dlm:pre-script`、値: `SUCCESS`\$1`FAILED`

  タグ値 `SUCCESS` は、事前スクリプトが正常に実行されたことを示します。タグ値 `FAILED` は、事前スクリプトが正常に実行されなかったことを示します。
+ キー: `aws:dlm:post-script`、値: `SUCCESS`\$1`FAILED`

  タグ値 `SUCCESS` は、事後スクリプトが正常に実行されたことを示します。タグ値 `FAILED` は、事後スクリプトが正常に実行されなかったことを示します。

カスタム SSM ドキュメントと SAP HANA バックアップでは、スナップショットに `aws:dlm:pre-script:SUCCESS` と `aws:dlm:post-script:SUCCESS` の両方のタグが付けられている場合、アプリケーション整合性のあるスナップショットが正常に作成されたと推測できます。

さらに、VSS バックアップを使用して作成されたアプリケーション整合性のあるスナップショットには、自動的に次のタグが付けられます。
+ キー: `AppConsistent tag`、値: `true`\$1`false`

  タグ値 `true` は、VSS バックアップが成功し、スナップショットとアプリケーションの整合性が保たれていることを示します。タグ値 `false` は、VSS バックアップが成功せず、スナップショットとアプリケーションの整合性が保たれていないことを示します。

# Amazon Data Lifecycle Manager の事前スクリプトと事後スクリプトをモニタリング
<a name="dlm-script-monitoring"></a>

**Amazon CloudWatch メトリクス**  
Amazon Data Lifecycle Manager は、事前スクリプトと事後スクリプトが失敗した場合と成功した場合、および VSS バックアップが失敗した場合と成功した場合に、次の CloudWatch メトリクスを発行します。
+ `PreScriptStarted`
+ `PreScriptCompleted`
+ `PreScriptFailed`
+ `PostScriptStarted`
+ `PostScriptCompleted`
+ `PostScriptFailed`
+ `VSSBackupStarted`
+ `VSSBackupCompleted`
+ `VSSBackupFailed`

詳細については、「[CloudWatch を使用して、Data Lifecycle Manager のポリシーをモニタリング](monitor-dlm-cw-metrics.md)」を参照してください。

**Amazon EventBridge**  
Amazon Data Lifecycle Manager は、事前スクリプトまたは事後スクリプトが開始、成功、または失敗したときに、次の Amazon EventBridge イベントを発行します。
+ `DLM Pre Post Script Notification`

詳細については、「[EventBridge を使用した Data Lifecycle Manager ポリシーのモニタリング](monitor-cloudwatch-events.md)」を参照してください。

# EBS-backed AMI 用の Amazon Data Lifecycle Manager カスタムポリシーを作成
<a name="ami-policy"></a>

以下の手順では、Amazon Data Lifecycle Manager を使用して EBS-backed AMI のライフサイクルを自動化する方法を示します。

**Topics**
+ [AMI ライフサイクルポリシーを作成する](#create-ami-policy)
+ [AMI ライフサイクルポリシーに関する考慮事項](#ami-considerations)
+ [その他のリソース](#ami-additional-resources)

## AMI ライフサイクルポリシーを作成する
<a name="create-ami-policy"></a>

AMI ライフサイクルポリシーを作成するには、次のいずれかの手順に従います。

------
#### [ Console ]

**AMI ポリシーを作成するには**

1. Amazon EC2 コンソール ([https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)) を開きます。

1. ナビゲーションペインで、[**Elastic Block Store**]、[**ライフサイクルマネージャー**]、[**ライフサイクルポリシーの作成**] の順に選択します。

1. [**ポリシータイプの選択**] 画面で、[**EBS-backed AMI ポリシー**] を選択した後、[**次**] をクリックします。

1. **[Target resources]** (ターゲットのリソース) セクションの **[Target resource tags]** (ターゲットリソースタグ) で、バックアップするボリュームまたはインスタンスを識別するリソースタグを選択します。ポリシーでは、特定のタグキーと値のペアを持つリソースのみがバックアップされます。

1. [**説明**] にポリシーの簡単な説明を入力します。

1. [**IAM ロール**] で、AMI とスナップショットを管理しインスタンスを記述するためのアクセス許可を持つ、IAM ロールを選択します。Amazon Data Lifecycle Manager から提供されるデフォルトのロールを使用するには、[**デフォルトロール**] を選択します。以前に作成したカスタム IAM ロールを使用するには、[**別のロールを選択**] をクリックした上で、使用するロールを選択します。

1. [**ポリシータグ**] に、ライフサイクルポリシーに適用されるタグを追加します。これらのタグは、ポリシーを識別および分類するために使用することができます。

1. [**作成後のポリシーの状態**] で、[**ポリシーの有効化**] を選択すると、次にスケジュールした時刻でポリシーが実行されます。ポリシーが実行されないようにするには、[**ポリシーの無効化**] を選択します。ここでポリシーを有効にしない場合、作成後に手動で有効にするまで AMI の作成は開始されません。

1. [**インスタンスの再起動**] セクションに、AMI の作成前にインスタンスを再起動するかどうかが表示されています。ターゲットのインスタンスが再起動されないようにするには、[**いいえ**] を選択します。[**いいえ**] を選択することで、データの整合性に問題が発生する場合があります。AMI の作成前にインスタンスを再起動するには、[**はい**] を選択します。これを選択すると、データの整合性が保証されます。ただし、複数のターゲットインスタンスが同時に再起動する可能性があります。

1. [**次へ**] を選択します。

1. [**スケジュールの設定**] 画面で、ポリシースケジュールを設定します。1 つのポリシーには、最大 4 つのスケジュールを含めることができます。スケジュール 1 は必須です。スケジュール 2、3、および 4 はオプションです。追加したポリシースケジュールごとに、以下の操作を行います。

   1. [**スケジュールの詳細**] セクションで、次の操作を行います。

      1. [**スケジュール名**] で、スケジュールの分かりやすい名前を指定します。

      1. [**頻度**]とそれに関連するフィールドで、ポリシーの実行間隔を設定します。

         ポリシーの実行は、日次、週次、月次、年次のいずれかのスケジュールで設定できます。または、[**カスタム cron 式**] をクリックし、最長 1 年の間隔を指定します。詳細については、「*Amazon EventBridge ユーザーガイド*」の「[Setting a schedule pattern for scheduled rules (legacy) in Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-scheduled-rule-pattern.html)」を参照してください。

      1. [**開始時刻**] では、ポリシー実行の開始予定時刻を指定します。初回のポリシー実行は、スケジュールした時刻から 1 時間以内に開始されます。時刻は、`hh:mm` UTC 形式で入力する必要があります。

      1. [**保持タイプ**] で、スケジュールで作成された AMI の保持ポリシーを指定します。

         AMI は、総数または期間に基づいて保持できます。

         カウントベースの保持の場合、指定できる範囲は `1`～`1000` です。このカウントが最大数に達すると、新しい AMI が作成される時点で、最も古いスナップショットの登録が解除されます。

         保存期間に基づく保持の場合、指定できる範囲は `1` 日～`100` 年です。各 AMI の保存期間が終了すると、その AMI は削除されます。
**注記**  
すべてのスケジュールは、同じ保持タイプである必要があります。保持タイプを指定できるのは、スケジュール 1 のみです。スケジュール 2、3、4 は、スケジュール 1 から保持タイプを継承します。各スケジュールには、独自の保持回数または期間を設定できます。

   1. AMI のタグ付けを設定します。

      [**タグ付け**] セクションで、以下を実行します。

      1. ソースインスタンスからスケジュールにより作成された AMI に対し、すべてのユーザー定義タグをコピーするには、[**ソースからタグをコピー**] を選択します。

      1. デフォルトで、スケジュールによって作成された AMI には、ソースインスタンスの ID を使用して自動的にタグ付けが行われます。この自動タグ付けが行われないようにするには、[**可変タグ**] から、`instance-id:$(instance-id)` タイルを削除します

      1. 他のタグを指定し、このスケジュールによって作成された AMI に割り当てるには、[**タグを追加**] をクリックします。

   1. AMI の非推奨を設定します。

      使用しなくなったAMI を非推奨にするには、**AMI 非推奨**セクションで、**このスケジュールの AMI 非推奨を有効にする**を選択し、AMI 非推奨ルールを指定します。AMI の非推奨ルールでは、AMI を非推奨にするタイミングを指定します。

      スケジュールでカウントベースの AMI 保持を使用する場合は、非推奨にする最も古い AMI の数を指定する必要があります。非推奨カウントは、スケジュールの AMI 保持カウント以下である必要があり、また1000 を超えることはできません。例えば、最大 5 つの AMI を保持するようにスケジュールが設定されている場合、最も古い5 つの AMI を非推奨にするようにスケジュールを設定することができます。

      スケジュールで年齢ベースの AMI 保持を使用する場合は、AMI が非推奨になるまでの期間を指定する必要があります。非推奨カウントは、スケジュールの AMI 保持期間以下である必要があり、10年 (120か月、520 週、または3650日) を超えることはできません。例えば、AMI を10 日間保持するようにスケジュールが設定されている場合、作成後 10 日経過後に AMIを非推奨にするようにスケジュールを設定できます。

   1. クロスリージョンでのコピーを設定します。

      スケジュールによって作成された AMI を別のリージョンにコピーするには、[**クロスリージョンのコピー**] セクションで、[**クロスリージョンコピーを有効化する**] を選択します。AMI は、アカウント内で最大 3 つの異なるリージョンにコピーできます。送信先となるリージョンごとに、個別のクロスリージョンコピーのためのルールを指定する必要があります。

      送信先リージョンごとに、以下を指定できます。
      + AMIコピーの保持ポリシー。保持期間が終了すると、送信先リージョンのコピーは自動的に登録解除されます。
      + AMIコピーの暗号化ステータス。ソース AMI が暗号化されている場合、または暗号化がデフォルトで有効化されている場合には、コピーされた AMI も常に暗号化されます。ソース AMI が暗号化されておらず、暗号化がデフォルトで無効になっている場合は、オプションで暗号化を有効にできます。KMS キー を指定しない場合、AMI は、各送信先リージョンにおける EBS 暗号化用のデフォルト KMS キー を使用して暗号化されます。送信先リージョンで KMS キーを指定する場合、選択した IAM ロールには KMS キーへのアクセス権が必要です。
      + AMIコピーの非推奨ルール。非推奨期間が終了すると、AMI コピーは自動的に非推奨になります。非推奨期間は、コピーの保存期間以下である必要があり、また10 年を超えることはできません。
      + ソース AMI からすべてのタグをコピーするか、タグをコピーしないかです。
**注記**  
リージョンごとの、AMI の同時コピー数を超えないようにします。

   1. 新たにスケジュールを追加するには、画面の上部にある [**他のスケジュールを追加する**] をクリックします。追加スケジュールごとに、このトピックの説明にならってフィールドを設定します。

   1. 必要なスケジュールを追加したら、[**ポリシーをレビュー**] をクリックします。

1. ポリシーの概要を確認した後、[**ポリシーを作成**] をクリックします。
**注記**  
`Role with name AWSDataLifecycleManagerDefaultRoleForAMIManagement already exists` エラーが発生した場合、詳細については「[Amazon Data Lifecycle Manager の問題のトラブルシューティング](dlm-troubleshooting.md)」を参照してください。

------
#### [ Command line ]

AMI ライフサイクルポリシーを作成するには、[create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html) コマンドを使用します。`PolicyType` で、`IMAGE_MANAGEMENT` を指定する。

**注記**  
構文を簡略化するために、次の例では、ポリシーの詳細を含む JSON ファイル、`policyDetails.json` を使用しています。

**例 1: 年齢ベースの保持と AMI の非推奨**  
この例では、ターゲットインスタンスを再起動せずに、値が `production` で `purpose` のタグキーを持つすべてのインスタンスの AMI を作成する AMI ライフサイクルポリシーを作成します。ポリシーには、毎日`01:00` UTC時 に AMI を作成するスケジュールが 1 つ含まれます。ポリシーは AMI を`2`日間保持し、そして`1` 日後に非推奨にします。また、作成した AMI に対し、ソースインスタンスからタグもコピーされます。

```
aws dlm create-lifecycle-policy \
    --description "My AMI policy" \
    --state ENABLED \
    --execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRoleForAMIManagement \
    --policy-details file://policyDetails.json
```

次は、`policyDetails.json` ファイルの例です。

```
{
    "PolicyType": "IMAGE_MANAGEMENT",
    "ResourceTypes": [
        "INSTANCE"
    ],
    "TargetTags": [{
        "Key": "purpose",
        "Value": "production"
    }],
    "Schedules": [{
            "Name": "DailyAMIs",
            "TagsToAdd": [{
                "Key": "type",
                "Value": "myDailyAMI"
            }],
            "CreateRule": {
                "Interval": 24,
                "IntervalUnit": "HOURS",
                "Times": [
                    "01:00"
                ]
            },
            RetainRule":{
                "Interval" : 2,
                "IntervalUnit" : "DAYS"
            },
            DeprecateRule": {
                "Interval" : 1,
                "IntervalUnit" : "DAYS"
            },
            "CopyTags": true
        }
    ],
    "Parameters" : {
        "NoReboot":true
    }
}
```

リクエストが成功すると、コマンドは新しく作成されたポリシーの ID を返します。以下は出力の例です。

```
{
   "PolicyId": "policy-9876543210abcdef0"
}
```

**例 2: クロスリージョンコピーを使用した、カウントベースの保持と AMI の非推奨**  
この例では、ターゲットインスタンスを再起動し、`production` の値の `purpose` タグキーを持つすべてのインスタンスの AMI を作成し、 AMI ライフサイクルポリシーを作成します。このポリシーには、`17:30` UTC 時に始まる `6` 時間ごとにAMIを作成するスケジュールが1 つ含まれます。ポリシーは `3` AMI を保持し、`2` つの最も古い AMIを自動的に非推奨にします。また、AMIを `us-east-1` にコピーし、`2` つの AMI コピーを保持し、最も古い AMI を自動的に非推奨にするクロスリージョンコピールールもあります。

```
aws dlm create-lifecycle-policy \
    --description "My AMI policy" \
    --state ENABLED \
    --execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRoleForAMIManagement \
    --policy-details file://policyDetails.json
```

次は、`policyDetails.json` ファイルの例です。

```
{
    "PolicyType": "IMAGE_MANAGEMENT",
    "ResourceTypes" : [
        "INSTANCE"
    ],
    "TargetTags": [{
        "Key":"purpose", 
        "Value":"production"
    }],
    "Parameters" : {
          "NoReboot": true
    },
    "Schedules" : [{
        "Name" : "Schedule1",
        "CopyTags": true,
        "CreateRule" : {
            "Interval": 6,
            "IntervalUnit": "HOURS",
            "Times" : ["17:30"]
        },
        "RetainRule":{
            "Count" : 3
        },
        "DeprecateRule":{
            "Count" : 2
        },
        "CrossRegionCopyRules": [{
            "TargetRegion": "us-east-1",
            "Encrypted": true,
            "RetainRule":{
                "IntervalUnit": "DAYS",
                "Interval": 2
            },
            "DeprecateRule":{
                "IntervalUnit": "DAYS",
                "Interval": 1
            },
            "CopyTags": true
        }]
    }]
}
```

------

## AMI ライフサイクルポリシーに関する考慮事項
<a name="ami-considerations"></a>

AMI ライフサイクルポリシーを作成する場合の**一般的な考慮事項**は次のとおりです。
+ AMI ライフサイクルポリシーは、ポリシーと同じリージョンにあるインスタンスのみを対象としています。
+ 最初の AMI 作成のオペレーションは、指定された開始時刻から 1 時間以内に開始されます。後続の AMI 作成オペレーションは、それらがスケジュールされた時刻から 1 時間以内に開始されます。
+ Amazon Data Lifecycle Manager が AMI を登録解除すると、バッキングスナップショットが自動的に削除されます。
+ ターゲットリソースタグでは大文字と小文字が区別されます。
+ ポリシーによってターゲットにされたインスタンスからターゲットタグを削除した場合、以降、Amazon Data Lifecycle Manager では、標準階層に存在する AMI の管理は行いません。不要になった場合は手動で削除する必要があります。
+ インスタンスをバックアップするために複数のポリシーを作成できます。例えば、インスタンスに 2 つのタグがあり、タグ *A* が 12 時間ごとに AMI を作成するポリシー *A* のターゲットであり、タグ *B* が 24 時間ごとに AMI を作成するポリシー *B* のターゲットである場合、Amazon Data Lifecycle Manager は両方のポリシーのスケジュールに従って AMI を作成します。または、複数のスケジュールを持つ単一のポリシーを作成することで、同じ結果を得ることができます。例えば、タグ *A* のみをターゲットとするポリシーを 1 つ作成し、スケジュールを 2 つ指定できます (1 つは 12 時間ごと、1 つは 24 時間ごと)。
+ ポリシーの作成後にターゲットインスタンスにアタッチされた新しいボリュームは、次回のポリシー実行時に自動的にバックアップに含まれます。ポリシー実行時にインスタンスにアタッチされたすべてのボリュームが含まれます。
+ AMI を 1 つだけ作成するように設定されたカスタム cron ベースのスケジュールでポリシーを作成した場合、保持のしきい値に達しても、その AMI はポリシーによって自動的に登録解除されることはありません。AMI が不要になった場合は、手動で登録解除する必要があります。
+ 保持期間が作成頻度よりも短い経過日ベースのポリシーを作成した場合、Amazon Data Lifecycle Manager は次の AMI が作成されるまで常に最新の AMI を保持します。例えば、経過日ベースのポリシーで保存期間が 7 日間の AMI が毎月 1 つ作成される場合、Amazon Data Lifecycle Manager は、保持期間が 7 日間であっても、各 AMI を 1 か月間保持します。
+ カウントベースのポリシーの場合、Amazon Data Lifecycle Manager は常に、保持ポリシーに従って最も古い AMI の登録解除を試みる前に、作成頻度に従って AMI を作成します。
+ AMI を正常に登録解除し、関連するバッキングスナップショットを削除するには、数時間かかることがあります。以前に作成した AMI が正常に登録解除される前に Amazon Data Lifecycle Manager が次の AMI を作成した場合、一時的に保持数を超える数の AMI を保持する可能性があります。

**ポリシーによってターゲットにされたインスタンスを終了する**場合の考慮事項は次のとおりです。
+ カウントベースの保持スケジュールが設定されたポリシーによってターゲットにされたインスタンスを終了すると、以前に終了したインスタンスから作成された AMI は、ポリシーで管理されなくなります。これらの以前に作成された AMI は、不要になったら手動で登録解除する必要があります。
+ 経過時間ベースの保持スケジュールが設定されたポリシーで作成されたインスタンスを終了すると、ポリシーは定義されたスケジュールに従って、すでに作成された、最後の 1 つ前の AMI まで AMI を登録解除し続けます。最後の AMI が不要になった場合は、手動で削除する必要があります。

AMI ポリシーと **AMI の非推奨**に関する考慮事項は次のとおりです。
+ カウントベースの保持を行っているスケジュールで AMI 非推奨カウントを増やすと、そのスケジュールによって作成されたすべての AMI (既存および新規) に変更が適用されます。
+ 年齢ベースの保持でスケジュールの AMI の非推奨期間を長くした場合、その変更は新しい AMI にのみ適用されます。既存の AMIは影響を受けません。
+ スケジュールからAMIの非推奨ルールを削除しても、Amazon Data Lifecycle Manager は、そのスケジュールで以前に非推奨となっていたAMIの非推奨をキャンセルしません。
+ スケジュールの AMIの非推奨カウントや期間を減らしても、Amazon Data Lifecycle Manager は、そのスケジュールによって以前に非推奨とされたAMIの非推奨をキャンセルしません。
+ AMI ポリシーで作成された AMI を手動で非推奨にしても、Amazon Data Lifecycle Manager は非推奨を上書きしません。
+ AMI ポリシーで以前に非推奨とされたAMI の非推奨を手動でキャンセルしても、Amazon Data Lifecycle Manager はキャンセルを上書きしません。
+ AMI が複数の競合するスケジュールで作成され、1 つ以上のスケジュールに AMI の非推奨ルールがない場合、Amazon Data Lifecycle Manager はその AMI を非推奨としません。
+ AMI が複数の競合するスケジュールで作成され、それらのすべてのスケジュールに AMI の非推奨ルールがある場合、Amazon Data Lifecycle Manager は、非推奨に移行する日が最も遅くなる非推奨ルールを使用します。

次の考慮事項は、AMI ポリシーおよび[ごみ箱](recycle-bin.md)に適用されます。
+ Amazon Data Lifecycle Manager がポリシーの保持しきい値に達したときに AMI の登録を解除してごみ箱に移動した時にその AMI をごみ箱から手動で復元する場合、AMI が不要になった際には手動で AMI の登録を解除する必要があります。Amazon Data Lifecycle Manager は、AMI を管理しなくなります。
+ ポリシーによって作成された AMI を手動で登録解除し、ポリシーの保持しきい値に達したときにその AMI がごみ箱にある場合、Amazon Data Lifecycle Manager はスナップショットを登録解除しません。Amazon Data Lifecycle Manager は、AMI がごみ箱に保存されている間は、スナップショットを管理しません。

  ポリシーの保持しきい値に達する前に AMI がごみ箱から復元された場合、Amazon Data Lifecycle Manager は、ポリシーの保持しきい値に達したときに AMI を削除します。

  ポリシーの保持しきい値に達した後に AMI がごみ箱から復元された場合、Amazon Data Lifecycle Manager はその AMI を削除しません。不要になった場合は、手動で削除する必要があります。

以下は、**エラー**状態にある AMI ポリシーに関する考慮事項です。
+ 期間ベースの保持スケジュールを持つポリシーの場合、ポリシーが `error` 状態の間に有効期限を迎える AMI は無期限に保持されます。これらの AMI は手動で登録解除する必要があります。ポリシーを再度有効にすると、Amazon Data Lifecycle Manager は保持期間が終了した時に AMI の登録解除を再開します。
+ カウントベースの保持スケジュールが設定されているポリシーの場合、ポリシーが `error` 状態の間は AMI の作成と登録解除が停止されます。ポリシーを再度有効にすると、Amazon Data Lifecycle Manager は AMI の作成を再開し、保持しきい値に達した時に AMI の登録解除を再開します。

AMI ポリシーと **[AMI の無効化](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/disable-an-ami.html)**に関する考慮事項は次のとおりです。
+ Amazon Data Lifecycle Manager が作成した AMI を無効化し、保持しきい値に達したときにその AMI が無効になっている場合、Amazon Data Lifecycle Manager は AMIを登録解除し、関連付けられたスナップショットを削除します。
+ Amazon Data Lifecycle Manager が作成した AMI を無効にし、関連付けられたスナップショットを手動でアーカイブし、保持しきい値に達したときにそれらのスナップショットがアーカイブされた場合、Amazon Data Lifecycle Manager はそれらのスナップショットを削除せず、管理もできなくなります。

AMI ポリシーと **[AMI 登録解除保護](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/deregister-ami.html#ami-deregistration-protection)**には、以下の考慮事項が適用されます。
+ Amazon Data Lifecycle Manager に作成された AMI の登録解除保護を手動で実行し、それでも AMI 保持しきい値に達して有効化されると、Amazon Data Lifecycle Manager はその AMI を管理しなくなります。不要になった場合は、AMI の登録を手動で解除して、基となるスナップショットを削除する必要があります。

## その他のリソース
<a name="ami-additional-resources"></a>

詳細については、[「Amazon Data Lifecycle Manager ストレージを使用した Amazon EBS スナップショットと AMI 管理の自動化](https://aws.amazon.com/blogs/storage/automating-amazon-ebs-snapshot-and-ami-management-using-amazon-dlm/) AWS 」ブログを参照してください。

# Data Lifecycle Manager を使用してクロスアカウントのスナップショットコピーを自動化
<a name="event-policy"></a>

クロスアカウントのスナップショットのコピーを自動化すると、Amazon EBS スナップショットを分離アカウントの特定のリージョンにコピーし、暗号化キーを使用してそれらのスナップショットを暗号化できます。これにより、アカウントが侵害された場合にデータの損失から保護することができます。

アカウント間でスナップショットのコピーを自動化するには、次の 2 つのアカウントが使用されます。
+ **ソースアカウント** — ソースアカウントは 、スナップショットを作成してターゲットアカウントと共有するアカウントです。このアカウントでは、設定された間隔でスナップショットを作成し、他の AWS アカウントと共有する EBS スナップショットポリシーを作成する必要があります。
+ **ターゲットアカウント**— ターゲットアカウントは 、スナップショットを共有する共有先アカウントを持つアカウントで、共有スナップショットのコピーを作成するアカウントです。このアカウントでは、指定した 1 つ以上のソースアカウントによって共有されるスナップショットを自動的にコピーするクロスアカウントコピーイベントポリシーを作成する必要があります。

**注記**  
ソースアカウントの EBS スナップショットポリシーとターゲットアカウントのクロスアカウントコピーイベントポリシーの両方を同じ AWS リージョンに作成する必要があります。これにより、ターゲットアカウントは必要に応じてスナップショットを異なる送信先リージョンにコピーできるようになります。

**Topics**
+ [クロスアカウントスナップショットコピーポリシーの作成](#create-cac-policy)
+ [スナップショット説明フィルターの指定](#snapshot-descr-filters)
+ [クロスアカウントスナップショットコピーポリシーに関する考慮事項](#event-policy-considerations)
+ [その他のリソース](#event-additional-resources)

## クロスアカウントスナップショットコピーポリシーの作成
<a name="create-cac-policy"></a>

アカウント間でスナップショットをコピーするためにソースアカウントとターゲットアカウントを準備するには、次の手順を実行します。

**Topics**

### 手順 1: EBS スナップショットポリシーを作成する (*ソースアカウント*)
<a name="create-snapshot-policy"></a>

ソースアカウントで EBS スナップショットポリシーを作成します。これにより、スナップショットを作成し、必要なターゲットアカウントと共有します。

ポリシーを作成するときは、クロスアカウント共有を有効にし、スナップショットを共有するターゲット AWS アカウントを指定します。このアカウントは、スナップショットを共有するアカウントです。暗号化されたスナップショットを共有する場合は、選択したターゲットアカウントに、ソースボリュームの暗号化に使用された KMS キー を使用するためのアクセス権限を付与する必要があります。詳細については、「[ステップ 2: カスタマーマネージド型キー (*ソースアカウント*) を共有する](#share-cmk)」を参照してください。

**注記**  
このポリシーは、ステップ 3 でターゲットアカウントのクロスアカウントコピーイベントポリシーを作成するリージョンと同じ AWS リージョンに作成します。クロスアカウントスナップショット共有が正しく機能するには、両方のポリシーが同じリージョンにある必要があります。
共有できるのは、暗号化されていないスナップショットまたはカスタマーマネージド型キーを使用して暗号化されたスナップショットだけです。デフォルトの EBS 暗号化 KMS キー で暗号化されたスナップショットを共有することはできません。暗号化されたスナップショットを共有する場合は、ソースボリュームの暗号化に使用された KMS キー も、ターゲットアカウントと共有する必要があります。詳細については、「AWS Key Management Service デベロッパーガイド**」の「[他のアカウントのユーザーに KMS キーの使用を許可する](https://docs.aws.amazon.com//kms/latest/developerguide/key-policy-modifying-external-accounts.html)」を参照してください。

EBS スナップショットポリシーを作成する方法については、[EBS スナップショット用の Amazon Data Lifecycle Manager カスタムポリシーを作成](snapshot-ami-policy.md)を参照してください。

EBS スナップショットポリシーを作成するには、次のいずれかの方法を使用します。

### ステップ 2: カスタマーマネージド型キー (*ソースアカウント*) を共有する
<a name="share-cmk"></a>

暗号化されたスナップショットを共有する場合は、IAM ロールと (前のステップで選択した) ターゲットの AWS アカウントに、ソースボリュームの暗号化に使用されたカスタマーマネージド型キーを使用するためのアクセス権限を付与する必要があります。

**注記**  
この手順は、暗号化されたスナップショットを共有する場合にのみ実行してください。暗号化されていないスナップショットを共有する場合は、この手順をスキップします。

------
#### [ Console ]

****

1. [https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms) で AWS KMS コンソールを開きます。

1. を変更するには AWS リージョン、ページの右上隅にあるリージョンセレクターを使用します。

1. ナビゲーションペインで、[**カスタマーマネージド型キー**] を選択してから、ターゲットアカウントと共有する必要がある KMS キーを選択します。

   KMS キー の ARN を記録しておきます。これは後で必要になります。

1. [**キーポリシー**] タブで、[**キーユーザー**] セクションまで下にスクロールします。[**追加**] を選択し、前のステップで選択した IAM ロールの名前を入力してから、[**追加**] をクリックします。

1. **[キーポリシー]** タブで、**[その他の AWS アカウント]** セクションまで下にスクロールします。**他の AWS アカウントを追加**を選択し、前のステップでスナップショットを共有するために選択したすべてのターゲット AWS アカウントを追加します。

1. **[Save changes]** (変更の保存) をクリックします。

------
#### [ Command line ]

KMS キー に現在アタッチされているキーポリシーを取得するには、[get-key-policy](https://docs.aws.amazon.com/cli/latest/reference/kms/get-key-policy.html) コマンドを使用します。

例えば、次のコマンドは、`9d5e2b3d-e410-4a27-a958-19e220d83a1e` の ID を持つ KMS キー のキーポリシーを取得し、`snapshotKey.json` という名前のファイルに書き込みます。

```
$ aws kms get-key-policy \
    --policy-name default \
    --key-id 9d5e2b3d-e410-4a27-a958-19e220d83a1e \
    --query Policy \
    --output text > snapshotKey.json
```

任意のテキストエディタを使用してキーポリシーを開きます。スナップショットポリシーの作成時に指定した IAM ロールの ARN と、KMS キー を共有するターゲットアカウントの ARN を追加します。

例えば、次のポリシーでは、デフォルトの IAM ロールの ARN と、ターゲットアカウント `222222222222.` 用のルートアカウントの ARN を追加しました。

**ヒント**  
最小権限のプリンシパルに従うには、`kms:CreateGrant` へのフルアクセスを許可しないでください。代わりに、次の例に示すように、 AWS サービスによってユーザーに代わって権限が作成された場合にのみ、 `kms:GrantIsForAWSResource`条件キーを使用して KMS キーに対する権限の作成をユーザーに許可します。

```
{
    "Sid" : "Allow use of the key",
    "Effect" : "Allow",
    "Principal" : {
        "AWS" : [
            "arn:aws:iam::111111111111:role/service-role/AWSDataLifecycleManagerDefaultRole",
            "arn:aws:iam::222222222222:root"
        ]
    },
    "Action" : [ 
        "kms:Encrypt", 
        "kms:Decrypt", 
        "kms:ReEncrypt*", 
        "kms:GenerateDataKey*", 
        "kms:DescribeKey" 
    ],
    "Resource" : "*"
}, 
{
    "Sid" : "Allow attachment of persistent resources",
    "Effect" : "Allow",
    "Principal" : {
        "AWS" : [
            "arn:aws:iam::111111111111:role/service-role/AWSDataLifecycleManagerDefaultRole",
            "arn:aws:iam::222222222222:root"
        ]
    },
    "Action" : [ 
        "kms:CreateGrant", 
        "kms:ListGrants", 
        "kms:RevokeGrant"
    ],
    "Resource" : "*",
    "Condition" : {
        "Bool" : {
          "kms:GrantIsForAWSResource" : "true"
        }
    }
}
```

ファイルを保存して閉じます。次に、[put-key-policy](https://docs.aws.amazon.com/cli/latest/reference/kms/put-key-policy.html) コマンドを使用して、更新されたキーポリシーを KMS キー にアタッチします。



```
$ aws kms put-key-policy \
    --policy-name default \
    --key-id 9d5e2b3d-e410-4a27-a958-19e220d83a1e \
    --policy file://snapshotKey.json
```

------

### 手順 3: クロスアカウントコピーイベントポリシーの作成 (*ターゲットアカウント*)
<a name="cac-policy"></a>

ターゲットアカウントで、必要なソースアカウントで共有されるスナップショットを自動的にコピーするクロスアカウントコピーイベントポリシーを作成する必要があります。

このポリシーは、指定されたソースアカウントの 1 つがスナップショットを共有する場合にのみ、ターゲットアカウントで実行されます。

**注記**  
このポリシーは、ステップ 1 で作成したソースアカウントの EBS スナップショットポリシーと同じ AWS リージョンに作成します。クロスアカウントスナップショット共有が正しく機能するには、両方のポリシーが同じリージョンにある必要があります。その後、必要に応じて異なる送信先リージョンにスナップショットをコピーするようにこのポリシーを設定できます。

クロスアカウントコピーイベントポリシーを作成するには、次のいずれかの方法を使用します。

------
#### [ Console ]

1. Amazon EC2 コンソール ([https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)) を開きます。

1. ナビゲーションペインで、[**Elastic Block Store**]、[**ライフサイクルマネージャー**]、[**ライフサイクルポリシーの作成**] の順に選択します。

1. [**ポリシータイプの選択**] 画面で、[**クロスアカウントコピーのイベントポリシー**] を選択した上で、[**次へ**] をクリックします。

1. [**ポリシーの説明**] に、ポリシーの簡単な説明を入力します。

1. [**ポリシータグ**] に、ライフサイクルポリシーに適用されるタグを追加します。これらのタグは、ポリシーを識別および分類するために使用することができます。

1. [**イベントの設定**] セクションで、ポリシーを実行するスナップショット共有イベントを定義します。以下の操作を実行します。

   1. **共有アカウント**では、共有スナップショットをコピーするソース AWS アカウントを指定します。**アカウントの追加** を選択し、12 桁の AWS アカウント ID を入力し、**追加** を選択します。

   1. [**説明でフィルタリング**] に、正規表現を使用して必要なスナップショットの説明を入力します。指定したソースアカウントによって共有され、指定したフィルターに一致する説明を持つスナップショットのみが、ポリシーによってコピーされます。詳細については、を参照してください[スナップショット説明フィルターの指定](#snapshot-descr-filters)

1. [**IAM ロール**] で、スナップショットのコピーアクションを実行するアクセス許可を持つ IAM ロールを選択します。Amazon Data Lifecycle Manager から提供されるデフォルトのロールを使用するには、[**デフォルトロール**] を選択します。以前に作成したカスタム IAM ロールを使用する場合には、[**別のロールを選択**] をクリックした上で、使用するロールを選択します。

   暗号化されたスナップショットをコピーする場合は、ソースボリュームの暗号化に使用する暗号化 KMS キー を使用するためのアクセス権限を選択した IAM ロールに付与する必要があります。同様に、別の KMS キー を使用して送信先リージョンのスナップショットを暗号化する場合は、送信先 KMS キー を使用するためのアクセス権限を IAM ロールに付与する必要があります。詳細については、を参照してください[ステップ 4: IAM ロールに必要な KMS キー の使用を許可する (*ターゲットアカウント*)](#target_iam-role)

1. [**コピーアクション**] セクションで、アクティブ化された際にポリシーが実行する、スナップショットのコピーアクションを定義します。ポリシーは、スナップショットを最大 3 つのリージョンにコピーできます。送信先となるリージョンごとに、個別のコピールールを指定する必要があります。追加したルールごとに以下を実行します。

   1. [**名前**] に、コピーアクションのわかりやすい名前を入力します。

   1. **[Target Region]** (ターゲットリージョン) で、スナップショッのをコピー先リージョンを選択します。

   1. [**有効期限**] では、作成したスナップショットのコピーを、ターゲットリージョンに保持する期間を指定します。

   1. スナップショットのコピーを暗号化するには、[**暗号化**] で、[**暗号化の有効化**] を選択します。ソーススナップショットが暗号化されている場合、またはアカウントで暗号化がデフォルトで有効になっている場合は、ここで暗号化を有効しなくても、スナップショットのコピーは常に暗号化されます。ソーススナップショットが暗号化されておらず、アカウントで暗号化がデフォルトで有効になっていない場合は、暗号化を有効または無効にすることができます。暗号化を有効にし、KMS キー を指定しない場合、スナップショットは、各送信先リージョンでデフォルトの暗号化 KMS キー を使用して暗号化されます。送信先のリージョンの KMS キー を指定する場合は、KMS キー へのアクセスが必要です。

1. さらに、スナップショットのコピーアクションを追加するには、[**新しいリージョンを追加**] をクリックします。

1. [**Policy status after creation (作成後のポリシーの状態)**] では、[**Enable policy (ポリシーの有効化)**] を選択すると、次のスケジュールした時刻にポリシーが実行されます。ポリシーが実行されないようにするには、[**Disable policy (ポリシーの無効化)**] を選択します。ここでポリシーを有効にしない場合、作成後に手動で有効にするまで、スナップショットのコピーは開始されません。

1. [**Create policy**] (ポリシーの作成) を選択します。

------
#### [ Command line ]

ポリシーを作成するには、[create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html) コマンドを使用します。クロスアカウントコピーイベントポリシーを作成するには、`PolicyType` で、`EVENT_BASED_POLICY` を指定します。

例えば、次のコマンドは、ターゲットアカウント `222222222222` にクロスアカウントコピーイベントポリシーを作成します。ポリシーは、ソースアカウント `111111111111` によって共有されるスナップショットをコピーします。ポリシーは、スナップショットを `sa-east-1` と `eu-west-2` にコピーします。`sa-east-1` にコピーされたスナップショットは暗号化されず、3 日間保持されます。`eu-west-2` にコピーされたスナップショットは KMS キー `8af79514-350d-4c52-bac8-8985e84171c7` を使用して暗号化され、1 か月間保持されます。このポリシーは、デフォルトの IAM ロールを使用します。

```
$ aws dlm create-lifecycle-policy \
    --description "Copy policy" \
    --state ENABLED \
    --execution-role-arn arn:aws:iam::222222222222:role/service-role/AWSDataLifecycleManagerDefaultRole \
    --policy-details file://policyDetails.json
```

以下は、`policyDetails.json` ファイルの内容を示しています。

```
{
    "PolicyType" : "EVENT_BASED_POLICY",
    "EventSource" : {
        "Type" : "MANAGED_CWE",
        "Parameters": {
            "EventType" : "shareSnapshot",
            "SnapshotOwner": ["111111111111"]
        }
    },
    "Actions" : [{
        "Name" :"Copy Snapshot to Sao Paulo and London",
        "CrossRegionCopy" : [{
            "Target" : "sa-east-1",
             "EncryptionConfiguration" : {
                 "Encrypted" : false
             },
             "RetainRule" : {
             "Interval" : 3,
            "IntervalUnit" : "DAYS"
            }
        },
        {
            "Target" : "eu-west-2",
            "EncryptionConfiguration" : {
                 "Encrypted" : true,
                 "CmkArn" : "arn:aws:kms:eu-west-2:222222222222:key/8af79514-350d-4c52-bac8-8985e84171c7"
            },
            "RetainRule" : {
                "Interval" : 1,
                "IntervalUnit" : "MONTHS"
            }
        }]
    }]
}
```

リクエストが成功すると、コマンドは新しく作成されたポリシーの ID を返します。以下は出力の例です。

```
{
    "PolicyId": "policy-9876543210abcdef0"
}
```

------

### ステップ 4: IAM ロールに必要な KMS キー の使用を許可する (*ターゲットアカウント*)
<a name="target_iam-role"></a>

暗号化されたスナップショットをコピーする場合は、(前の手順で選択した) IAM ロールに、ソースボリュームの暗号化に使用された カスタマーマネージド型キー を使用するためのアクセス権限を付与する必要があります。

**注記**  
暗号化されたスナップショットをコピーする場合のみ、この手順を実行してください。暗号化されていないスナップショットをコピーする場合は、この手順をスキップします。

以下のいずれかの方法を使用して、必要なポリシーを IAM ロールに追加します。

------
#### [ Console ]

****

1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。

1. ナビゲーションペインで、[**ロール**] を選択します。前の手順でクロスアカウントコピーイベントポリシーを作成したときに選択した IAM ロールを検索して選択します。デフォルトのロールを使用することを選択した場合、ロールの名前は **AWSDataLifecycleManagerDefaultRole** になります。

1. [**インラインポリシーの追加**] を選択し、次に [**JSON**] タブを選択します

1. 既存のポリシーを次のように置き換え、ステップ 2 でソースボリュームの暗号化に使用され、ソースアカウントによって共有された KMS キーの ARN を指定します。
**注記**  
複数のソースアカウントからコピーする場合は、各ソースアカウントから対応する KMS キー ARN を指定する必要があります。

   次の例では、ポリシーは、ソースアカウント `111111111111` で共有された KMS キー `1234abcd-12ab-34cd-56ef-1234567890ab` とターゲットアカウント `222222222222` に存在する KMS キー `4567dcba-23ab-34cd-56ef-0987654321yz` を使用するためのアクセス権限を IAM ロールに付与します。
**ヒント**  
最小権限のプリンシパルに従うには、`kms:CreateGrant` へのフルアクセスを許可しないでください。代わりに、次の例に示すように、 AWS サービスによってユーザーに代わって権限が作成された場合にのみ、 `kms:GrantIsForAWSResource`条件キーを使用して KMS キーに対する権限の作成をユーザーに許可します。

------
#### [ JSON ]

****  

   ```
    {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Action": [
                   "kms:RevokeGrant",
                   "kms:CreateGrant",
                   "kms:ListGrants"
               ],
               "Resource": [
                   "arn:aws:kms:us-east-1:111111111111:key/1234abcd-12ab-34cd-56ef-1234567890ab",
                   "arn:aws:kms:us-east-1:222222222222:key/4567dcba-23ab-34cd-56ef-0987654321yz"		
               ],
               "Condition": {
                   "Bool": {
                       "kms:GrantIsForAWSResource": "true"
                   }
               }
           },
           {
               "Effect": "Allow",
               "Action": [
                   "kms:Encrypt",
                   "kms:Decrypt",
                   "kms:ReEncrypt*",
                   "kms:GenerateDataKey*",
                   "kms:DescribeKey"
               ],
               "Resource": [
                   "arn:aws:kms:us-east-1:111111111111:key/1234abcd-12ab-34cd-56ef-1234567890ab",
                   "arn:aws:kms:us-east-1:222222222222:key/4567dcba-23ab-34cd-56ef-0987654321yz"
               ]
           }
       ]
   }
   ```

------

1. **[Review policy]** (ポリシーの確認) を選択します。

1. [**名前**] にポリシーのわかりやすい名前を入力し、[**ポリシーの作成**] を選択します。

------
#### [ Command line ]

お好みのテキストエディタを使用して、`policyDetails.json` という名前の新しい JSON ファイルを作成します。以下のポリシーを追加し、ステップ 2 でソースボリュームの暗号化に使用され、ソースアカウントによって共有された KMS キーの ARN を指定します。

**注記**  
複数のソースアカウントからコピーする場合は、各ソースアカウントから対応する KMS キー ARN を指定する必要があります。

次の例では、ポリシーは、ソースアカウント `111111111111` で共有された KMS キー `1234abcd-12ab-34cd-56ef-1234567890ab` とターゲットアカウント `222222222222` に存在する KMS キー `4567dcba-23ab-34cd-56ef-0987654321yz` を使用するためのアクセス権限を IAM ロールに付与します。

**ヒント**  
最小権限のプリンシパルに従うには、`kms:CreateGrant` へのフルアクセスを許可しないでください。代わりに、次の例に示すように、 AWS サービスによってユーザーに代わって権限が作成された場合にのみ、 `kms:GrantIsForAWSResource`条件キーを使用して KMS キーに対する権限の作成をユーザーに許可します。

------
#### [ JSON ]

****  

```
 {
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kms:RevokeGrant",
                "kms:CreateGrant",
                "kms:ListGrants"
            ],
            "Resource": [
                "arn:aws:kms:us-east-1:111111111111:key/1234abcd-12ab-34cd-56ef-1234567890ab",
                "arn:aws:kms:us-east-1:222222222222:key/4567dcba-23ab-34cd-56ef-0987654321yz"		
            ],
            "Condition": {
                "Bool": {
                    "kms:GrantIsForAWSResource": "true"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "kms:Encrypt",
                "kms:Decrypt",
                "kms:ReEncrypt*",
                "kms:GenerateDataKey*",
                "kms:DescribeKey"
            ],
            "Resource": [
                "arn:aws:kms:us-east-1:111111111111:key/1234abcd-12ab-34cd-56ef-1234567890ab",
                "arn:aws:kms:us-east-1:222222222222:key/4567dcba-23ab-34cd-56ef-0987654321yz"
            ]
        }
    ]
}
```

------

ファイルを保存して閉じます。次に、[put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html) コマンドを使用して、IAM ロールにポリシーを追加します。

例

```
$ aws iam put-role-policy \
    --role-name AWSDataLifecycleManagerDefaultRole \
    --policy-name CopyPolicy \
    --policy-document file://AdminPolicy.json
```

------

## スナップショット説明フィルターの指定
<a name="snapshot-descr-filters"></a>

ターゲットアカウントでスナップショットコピーポリシーを作成する場合は、スナップショットの説明フィルターを指定する必要があります。スナップショット説明フィルターにより、ポリシーによってコピーされるスナップショットを制御できる追加のフィルターレベルを指定できます。つまり、スナップショットは、指定したソースアカウントのいずれかによって共有され、指定したフィルターに一致するスナップショットの説明がある場合にのみ、ポリシーによりコピーされます。つまり、スナップショットが指定されたコースアカウントのいずれかによって共有されているのに、指定したフィルターに一致する説明がない場合、そのスナップショットはポリシーによってコピーされません。

スナップショットフィルターの説明は、正規表現を使用して指定する必要があります。コンソールとコマンドラインを使用してクロスアカウントコピーイベントポリシーを作成する場合、このフィールドは必須です。使用できる正規表現の例を次に示します。
+ `.*`— このフィルターは、すべてのスナップショットの説明に一致します。この式を使用すると、ポリシーは、指定したソースアカウントの 1 つが共有しているすべてのスナップショットをコピーします。
+ `Created for policy: policy-0123456789abcdef0.*`— このフィルターは、`policy-0123456789abcdef0` の ID を持ったポリシーによって作成されたスナップショットにのみ一致します。このような式を使用すると、ポリシーは、指定したソースアカウントのいずれかによってアカウントと共有され、指定された ID を持つポリシーによって作成されたスナップショットのみをコピーします。
+ `.*production.*`— このフィルターは、説明のいずれかの場所に `production` の単語が含まれているスナップショットに一致します。この式を使用すると、ポリシーは、指定したソースアカウントのいずれかで共有され、説明に指定されたテキストを含むすべてのスナップショットをコピーします。

## クロスアカウントスナップショットコピーポリシーに関する考慮事項
<a name="event-policy-considerations"></a>

以下はアカウント間のコピーイベントポリシーの考慮事項です。
+ ソースアカウントの EBS スナップショットポリシーとターゲットアカウントのクロスアカウントコピーイベントポリシーは、同じ AWS リージョンで作成する必要があります。スナップショットが共有されると、ターゲットアカウントポリシーは、コピーアクションで指定された異なる送信先リージョンにスナップショットをコピーできます。
+ コピーできるのは、暗号化されていないスナップショットまたは カスタマーマネージド型キー を使用して暗号化されたスナップショットだけです。
+ Amazon Data Lifecycle Manager の外部で共有されるスナップショットをコピーするクロスアカウントコピーイベントポリシーを作成できます。
+ ターゲットアカウントのスナップショットを暗号化する場合、クロスアカウントコピーイベントポリシー用に選択された IAM ロールには、必要な KMS キー を使用するためのアクセス権限が必要です。

## その他のリソース
<a name="event-additional-resources"></a>

詳細については、[AWS 「アカウントストレージ間で暗号化された Amazon EBS スナップショットのコピーの自動化](https://aws.amazon.com/blogs/storage/automating-copying-encrypted-amazon-ebs-snapshots-across-aws-accounts/) AWS 」ブログを参照してください。

# Amazon Data Lifecycle Manager デフォルトポリシーの変更
<a name="modify"></a>

Amazon Data Lifecycle Manager ポリシーを変更するときは、次の点に注意してください。
+ ターゲットタグを削除して AMI またはスナップショットポリシーを変更すると、それらのタグを持つボリュームまたはインスタンスはポリシーで管理されなくなります。
+ スケジュール名を変更すると、古いスケジュール名で作成されたスナップショットまたは AMI はポリシーで管理されなくなります。
+ 経過時間ベースの保持スケジュールを、新たな期間を使用するスケジュールに修正すると、新たな期間は、変更後に作成された新たなスナップショットまたは AMI にのみ適用されます。新たなスケジュールは、変更前に作成されたスナップショットまたは AMI の保持スケジュールに影響を及ぼすことはありません。
+ 作成後、ポリシーの保持スケジュールをカウントベースから経過時間ベースに変更することはできません。この変更を行うには、新たなポリシーを作成する必要があります。
+ 期間ベースの保持スケジュールを持つポリシーを無効にすると、ポリシーが無効になっている間に有効期限が切れるように設定されたスナップショットまたは AMI は無期限に保持されます。スナップショットを削除するか、AMI を手動で登録解除する必要があります。ポリシーを再度有効にすると、Amazon Data Lifecycle Manager は保持期間の終了時にスナップショットの削除または AMI の登録解除を再開します。
+ カウントベースの保持スケジュールを持つポリシーを無効にすると、ポリシーはスナップショットまたは AMI の作成と削除を停止します。ポリシーを再度有効にすると、Amazon Data Lifecycle Manager はスナップショットと AMI の作成を再開し、保持しきい値に達するとスナップショットまたは AMI の削除を再開します。
+ スナップショットアーカイブを有効にしたポリシーを含むポリシーを無効にした時点で、アーカイブ層に残されているスナップショットに対しては、Amazon Data Lifecycle Manager による管理が行われなくなります。不要になったスナップショットは、手動で削除する必要があります。
+ カウントベースのスケジュールでスナップショットのアーカイブを有効にした場合、このアーカイブルールは、以後スケジュールに従って作成およびアーカイブされるすべての新しいスナップショットに適用されます。また、このスケジュールによって以前に作成およびアーカイブされた既存のスナップショットにも適用されます。
+ 期間ベースのスケジュールに対しスナップショットのアーカイブを有効にした場合、アーカイブルールは、有効化した時点以降に作成された新しいスナップショットにのみ適用されます。スナップショットのアーカイブを有効にする前に作成された既存のスナップショットは、それらのスナップショットが最初に作成およびアーカイブされた時点で設定されていたスケジュールに従って、引き続きそれぞれのストレージ階層から削除されます。
+ カウントベースのスケジュールでスナップショットのアーカイブを無効にすると、スケジュールはただちにスナップショットのアーカイブを停止します。スケジュールによって以前にアーカイブされたスナップショットはアーカイブ階層に残り、Amazon Data Lifecycle Manager によって削除されることはありません。
+ 期間ベースのスケジュールにおいてスナップショットのアーカイブを無効にすると、ポリシーで作成されアーカイブが予定されているスナップショットは、スケジュールされた (`aws:dlm:expirationTime` システムタグが示す) アーカイブの日時に完全に削除されます。
+ スケジュールにおいてスナップショットのアーカイブを無効にした場合、スケジュールは、その時点でスナップショットのアーカイブを停止します。スケジュールによって以前にアーカイブされたスナップショットはアーカイブ階層に残り、Amazon Data Lifecycle Manager によって削除されることはありません。
+ カウントベースのスケジュールにおいてアーカイブ保持数を変更した場合、この新しい保存数は、以前にスケジュールによってアーカイブされた既存のスナップショットの数も含みます。
+ 期間ベースのスケジュールにおいてアーカイブの保持期間を変更した場合は、この変更を行った時点後にアーカイブされたスナップショットに対してのみ、新しい保持期間が適用されます。

次のいずれかの手順に従ってライフサイクルポリシーを変更します。

------
#### [ Console ]

**ライフサイクルポリシーを変更するには**

1. Amazon EC2 コンソール ([https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)) を開きます。

1. ナビゲーションペインで [**Elastic Block Store**]、[**ライフサイクルマネージャー**] の順に選択します。

1. リストからライフサイクルポリシーを選択します。

1. **[アクション]**、**[ライフサイクルポリシーの変更]** の順に選択します。

1. 必要に応じてポリシー設定を修正します。具体例を挙げると、スケジュールを修正する、タグを追加もしくは削除する、またはポリシーを有効化もしくは無効化することができます。

1. **[ポリシーの変更]** を選択します。

------
#### [ Command line ]

ライフサイクルポリシーに関する情報を変更するには、[update-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/update-lifecycle-policy.html) コマンドを使用します。構文を簡略化するために、この例では、ポリシーの詳細を含む JSON ファイル、`policyDetailsUpdated.json` を参照しています。

```
aws dlm update-lifecycle-policy \
    --state DISABLED \
    --execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole" \
    --policy-details file://policyDetailsUpdated.json
```

次は、`policyDetailsUpdated.json` ファイルの例です。

```
{
   "ResourceTypes":[
      "VOLUME"
   ],
   "TargetTags":[
      {
         "Key": "costcenter",
         "Value": "120"
      }
   ],
   "Schedules":[
      {
         "Name": "DailySnapshots",
         "TagsToAdd": [
            {
               "Key": "type",
               "Value": "myDailySnapshot"
            }
         ],
         "CreateRule": {
            "Interval": 12,
            "IntervalUnit": "HOURS",
            "Times": [
               "15:00"
            ]
         },
         "RetainRule": {
            "Count" :5
         },
         "CopyTags": false 
      }
   ]
}
```

更新されたポリシーを表示するには、`get-lifecycle-policy` コマンドを使用します。状態、タグの値、スナップショットの間隔、およびスナップショットの開始時刻が変更されたことがわかります。

------

# Amazon Data Lifecycle Manager のポリシーを削除
<a name="delete"></a>

Amazon Data Lifecycle Manager ポリシーを削除するときは、次の点に注意してください。
+ ポリシーを削除した場合でも、そのポリシーによって作成されたスナップショットまたは AMI は自動的に削除されません。これらのスナップショットや AMI が不要になった場合は、手動で削除する必要があります。
+ スナップショットのアーカイブが有効になっているポリシーを削除すると、その時点でアーカイブ層にあったスナップショットには、Amazon Data Lifecycle Manager による管理が行われなくなります。不要になったスナップショットは、手動で削除する必要があります。
+ アーカイブが有効化された期間ベースのスケジュールを含むポリシーを削除すると、そのポリシーによって作成されアーカイブが予定されていたスナップショットは、スケジュールされた (`aws:dlm:expirationtime` システムタグで示されている) アーカイブの日時に完全に削除されます。

次のいずれかの手順に従ってライフサイクルポリシーを削除します。

------
#### [ Console ]

**ライフサイクルポリシーを削除するには**

1. Amazon EC2 コンソール ([https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)) を開きます。

1. ナビゲーションペインで [**Elastic Block Store**]、[**ライフサイクルマネージャー**] の順に選択します。

1. リストからライフサイクルポリシーを選択します。

1. **[アクション]**、**[ライフサイクルポリシーの削除]** の順に選択します。

1. 確認を求めるメッセージが表示されたら、**[ポリシーの削除]** を選択します。

------
#### [ Command line ]

ライフサイクルポリシーを削除し、ポリシーで指定されたターゲットタグを解放して再利用できるようにするには、[delete-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/delete-lifecycle-policy.html) コマンドを使用します。

**注記**  
Amazon Data Lifecycle Manager によって作成されたスナップショットだけを削除できます。

```
aws dlm delete-lifecycle-policy --policy-id policy-0123456789abcdef0
```

------

[Amazon Data Lifecycle Manager API リファレンス](https://docs.aws.amazon.com/dlm/latest/APIReference/)には、Amazon Data Lifecycle Manager クエリ API の各アクションとデータ型の説明と構文があります。

または、いずれかの AWS SDKs を使用して、使用しているプログラミング言語またはプラットフォームに合わせて API にアクセスすることもできます。詳細については、[AWS SDK](https://aws.amazon.com/developer/tools/) を参照してください。

# IAM を使用して Amazon Data Lifecycle Manager へのアクセスを制御
<a name="dlm-prerequisites"></a>

Amazon Data Lifecycle Manager へのアクセスには、認証情報が必要です。それらの資格情報には、インスタンス、ボリューム、スナップショット、AMIなどの AWS リソースにアクセスするためのアクセス許可が必要です。

Amazon Data Lifecycle Manager を使用するには、次の IAM 許可が必要です。

**注記**  
`ec2:DescribeAvailabilityZones`、`ec2:DescribeRegions`、`kms:ListAliases`、および `kms:DescribeKey` 許可は、コンソールユーザーにのみ必要です。コンソールへのアクセスが不要な場合は、許可を削除できます。
*AWSDataLifecycleManagerDefaultRole* ロールの ARN 形式は、コンソールを使用して作成されたか、 AWS CLIを使用して作成されたかによって異なります。コンソールを使用してロールが作成された場合、ARN 形式は `arn:aws:iam::account_id:role/service-role/AWSDataLifecycleManagerDefaultRole` です。ロールが を使用して作成された場合 AWS CLI、ARN 形式は です`arn:aws:iam::account_id:role/AWSDataLifecycleManagerDefaultRole`。

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "dlm:*",
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": "iam:PassRole",
            "Resource": [
                "arn:aws:iam::111122223333:role/AWSDataLifecycleManagerDefaultRole",
                "arn:aws:iam::111122223333:role/AWSDataLifecycleManagerDefaultRoleForAMIManagement",
                "arn:aws:iam::111122223333:role/service-role/AWSDataLifecycleManagerDefaultRole",
                "arn:aws:iam::111122223333:role/service-role/AWSDataLifecycleManagerDefaultRoleForAMIManagement"
            ]
        },
        {
            "Effect": "Allow",
            "Action": "iam:ListRoles",
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeAvailabilityZones",
                "ec2:DescribeRegions",
                "kms:ListAliases",
                "kms:DescribeKey"
            ],
            "Resource": "*"
        }
    ]
}
```

------

**暗号化のアクセス許可**

Amazon Data Lifecycle Manager および暗号化されたリソースを操作する場合は、次の点を考慮してください。
+ ソースボリュームが暗号化されている場合は、Amazon Data Lifecycle Manager デフォルトのロール (**AWSDataLifecycleManagerDefaultRole** および **AWSDataLifecycleManagerDefaultRoleForAMIManagement**) に、ボリュームの暗号化に使用する KMS キー を使うアクセス権限があることを確認してください。
+ 暗号化されていないスナップショット、または暗号化されていないスナップショットによってバックアップされた AMI に対する**クロスリージョンコピー**を有効にし、送信先リージョンで暗号化を有効にする場合は、デフォルトのロールに、送信先リージョンで暗号化を実行するのに必要な KMS キー を使用するためのアクセス権限があることを確認してください。
+ 暗号化されたスナップショット、または暗号化されたスナップショットによってバックアップされた AMI に対して**クロスリージョンコピー**を有効にする場合は 、デフォルトのロールに、送信元および送信先の両方の KMS キー を使用するためのアクセス権限があることを確認してください。
+ 暗号化されたスナップショットのスナップショットアーカイブを有効にする場合は、Amazon Data Lifecycle Manager デフォルトのロール (**AWSDataLifecycleManagerDefaultRole**) に、スナップショショットの暗号化に使用する KMS キーを使う許可があることを確認してください。

詳細については、*AWS Key Management Service デベロッパーガイド*の「[他のアカウントのユーザーに KMS キーの使用を許可する](https://docs.aws.amazon.com//kms/latest/developerguide/key-policy-modifying-external-accounts.html)」を参照してください。

詳細については、「*AWS Identity and Access Management ユーザーガイド*」の「[IAM ユーザーのアクセス許可を変更する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html)」を参照してください。

# AWS Amazon Data Lifecycle Manager の マネージドポリシー
<a name="managed-policies"></a>

 AWS 管理ポリシーは、 によって作成および管理されるスタンドアロンポリシーです AWS。 AWS 管理ポリシーは、多くの一般的なユースケースにアクセス許可を付与するように設計されています。 AWS 管理ポリシーを使用すると、ポリシーを自分で記述する必要があったよりも、ユーザー、グループ、ロールに適切なアクセス許可を割り当てることが効率的になります。

ただし、 AWS 管理ポリシーで定義されているアクセス許可を変更することはできません。 AWS は、 AWS 管理ポリシーで定義されているアクセス許可を更新することがあります。行われた更新は、ポリシーがアタッチされているすべてのプリンシパルエンティティ (ユーザー、グループ、ロール) に影響します。

Amazon Data Lifecycle Manager は、一般的なユースケース用の AWS マネージドポリシーを提供します。これらのポリシーでは、より効率的に適切なアクセス許可を定義し、リソースへのアクセスを制御できます。Amazon Data Lifecycle Manager が提供する AWS マネージドポリシーは、Amazon Data Lifecycle Manager に渡すロールにアタッチされるように設計されています。

**Topics**
+ [AWSDataLifecycleManagerServiceRole](#AWSDataLifecycleManagerServiceRole)
+ [AWSDataLifecycleManagerServiceRoleForAMIManagement](#AWSDataLifecycleManagerServiceRoleForAMIManagement)
+ [AWSDataLifecycleManagerSSMFullAccess](#AWSDataLifecycleManagerSSMFullAccess)
+ [AWS マネージドポリシーの更新](#policy-update)

## AWSDataLifecycleManagerServiceRole
<a name="AWSDataLifecycleManagerServiceRole"></a>

**AWSDataLifecycleManagerServiceRole** ポリシーは、Amazon Data Lifecycle Manager に適切なアクセス許可を付与し、Amazon EBSスナップショット ポリシーおよびクロスアカウントコピーイベントポリシーを作成、管理します。

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:CreateSnapshot",
                "ec2:CreateSnapshots",
                "ec2:DeleteSnapshot",
                "ec2:DescribeInstances",
                "ec2:DescribeVolumes",
                "ec2:DescribeSnapshots",
                "ec2:EnableFastSnapshotRestores",
                "ec2:DescribeFastSnapshotRestores",
                "ec2:DisableFastSnapshotRestores",
                "ec2:CopySnapshot",
                "ec2:ModifySnapshotAttribute",
                "ec2:DescribeSnapshotAttribute",
                "ec2:ModifySnapshotTier",
                "ec2:DescribeSnapshotTierStatus",
                "ec2:DescribeAvailabilityZones"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:CreateTags"
            ],
            "Resource": "arn:aws:ec2:*::snapshot/*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "events:PutRule",
                "events:DeleteRule",
                "events:DescribeRule",
                "events:EnableRule",
                "events:DisableRule",
                "events:ListTargetsByRule",
                "events:PutTargets",
                "events:RemoveTargets"
            ],
            "Resource": "arn:aws:events:*:*:rule/AwsDataLifecycleRule.managed-cwe.*"
        }
    ]
}
```

------

## AWSDataLifecycleManagerServiceRoleForAMIManagement
<a name="AWSDataLifecycleManagerServiceRoleForAMIManagement"></a>

**[AWSDataLifecycleManagerServiceRoleForAMIManagement]** ポリシーは、Amazon Data Lifecycle Manager に適切なアクセス権限を付与し、Amazon EBS-backed AMI ポリシーを作成および管理します。

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ec2:CreateTags",
            "Resource": [
                "arn:aws:ec2:*::snapshot/*",
                "arn:aws:ec2:*::image/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeImages",
                "ec2:DescribeInstances",
                "ec2:DescribeImageAttribute",
                "ec2:DescribeVolumes",
                "ec2:DescribeSnapshots"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": "ec2:DeleteSnapshot",
            "Resource": "arn:aws:ec2:*::snapshot/*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:ResetImageAttribute",
                "ec2:DeregisterImage",
                "ec2:CreateImage",
                "ec2:CopyImage",
                "ec2:ModifyImageAttribute"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:EnableImageDeprecation",
                "ec2:DisableImageDeprecation"
            ],
            "Resource": "arn:aws:ec2:*::image/*"
        }
    ]
}
```

------

## AWSDataLifecycleManagerSSMFullAccess
<a name="AWSDataLifecycleManagerSSMFullAccess"></a>

すべての Amazon EC2 インスタンスで事前スクリプトと事後スクリプトを実行するために必要な Systems Manager アクションを実行する権限を Amazon Data Lifecycle Manager に付与します。

**重要**  
このポリシーでは、事前スクリプトと事後スクリプトを使用するときに、`aws:ResourceTag` 条件キーを使って特定の SSM ドキュメントへのアクセスを制限します。Amazon Data Lifecycle Manager が SSM ドキュメントにアクセスできるようにするには、SSM ドキュメントに `DLMScriptsAccess:true` のタグが付けられていることを確認する必要があります。

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowSSMReadOnlyAccess",
            "Effect": "Allow",
            "Action": [
                "ssm:GetCommandInvocation",
                "ssm:ListCommands",
                "ssm:DescribeInstanceInformation"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AllowTaggedSSMDocumentsOnly",
            "Effect": "Allow",
            "Action": [
                "ssm:SendCommand",
                "ssm:DescribeDocument",
                "ssm:GetDocument"
            ],
            "Resource": [
                "arn:aws:ssm:*:*:document/*"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/DLMScriptsAccess": "true"
                }
            }
        },
        {
            "Sid": "AllowSpecificAWSOwnedSSMDocuments",
            "Effect": "Allow",
            "Action": [
                "ssm:SendCommand",
                "ssm:DescribeDocument",
                "ssm:GetDocument"
            ],
            "Resource": [
                "arn:aws:ssm:*:*:document/AWSEC2-CreateVssSnapshot",
                "arn:aws:ssm:*:*:document/AWSSystemsManagerSAP-CreateDLMSnapshotForSAPHANA"
            ]
        },
        {
            "Sid": "AllowAllEC2Instances",
            "Effect": "Allow",
            "Action": [
                "ssm:SendCommand"
            ],
            "Resource": [
                "arn:aws:ec2:*:*:instance/*"
            ]
        }
    ]
}
```

------

## AWS マネージドポリシーの更新
<a name="policy-update"></a>

AWS サービスは、 AWS 管理ポリシーを維持および更新します。 AWS 管理ポリシーのアクセス許可は変更できません。サービスは、新機能をサポートするために、 AWS 管理ポリシーに追加のアクセス許可を追加することがあります。この種類の更新はポリシーがアタッチされている、すべてのアイデンティティ (ユーザー、グループおよびロール) に影響を与えます。サービスは、新機能が起動されたとき、または新しいオペレーションが利用可能になったときに、 AWS マネージドポリシーを更新する可能性が最も高いです。サービスは AWS マネージドポリシーからアクセス許可を削除しないため、ポリシーの更新によって既存のアクセス許可が損なわれることはありません。

次の表は、このサービスがこれらの変更の追跡を開始してからの Amazon Data Lifecycle Manager の AWS マネージドポリシーの更新に関する詳細を示しています。このページへの変更に関する自動通知を受けるには、[Amazon EBS ユーザーガイドのドキュメント履歴](doc-history.md) の RSS フィードを購読してください。


| 変更 | 説明 | 日付 | 
| --- | --- | --- | 
| AWSDataLifecycleManagerServiceRole — ポリシーのアクセス許可を更新しました。 | ローカルゾーンに関する情報を取得するアクセス許可をスナップショットポリシーに付与する ec2:DescribeAvailabilityZones アクションを、Amazon Data Lifecycle Manager に追加しました。 | 2024 年 12 月 16 日 | 
| AWSDataLifecycleManagerSSMFullAccess – ポリシーのアクセス許可を更新しました。 | AWSSystemsManagerSAP-CreateDLMSnapshotForSAPHANA SSM ドキュメントを使用した SAP HANA で、アプリケーション整合性のあるスナップショットをサポートするようにポリシーを更新しました。 | 2023 年 11 月 17 日 | 
| AWSDataLifecycleManagerSSMFullAccess — 新しい AWS 管理ポリシーを追加しました。 | Amazon Data Lifecycle Manager に AWSDataLifecycleManagerSSMFullAccess AWS 管理ポリシーが追加されました。 | 2023 年 11 月 7 日 | 
| AWSDataLifecycleManagerServiceRole – スナップショットのアーカイブをサポートするための、アクセス許可を追加しました。 | Amazon Data Lifecycle Manager に ec2:ModifySnapshotTier および ec2:DescribeSnapshotTierStatus アクションが追加され、スナップショットのアーカイブおよびスナップショットのアーカイブステータスの確認に必要なアクセス許可をスナップショットポリシーに付与できるようになりました。 | 2022 年 9 月 30 日 | 
| [AWSDataLifecycleManagerServiceRoleForAMIManagement]— AMI の非推奨をサポートする権限を追加しました。 | Amazon Data Lifecycle Manager は、ec2:EnableImageDeprecationおよびec2:DisableImageDeprecationアクションを使用して、AMI の非推奨を有効または無効にするアクセス権限を EBS-backed AMI ポリシーに付与します。 | 2021 年 8 月 23 日 | 
| Amazon Data Lifecycle Manager が変更追跡を開始しました | Amazon Data Lifecycle Manager は、 AWS マネージドポリシーの変更の追跡を開始しました。 | 2021 年 8 月 23 日 | 

# Amazon Data Lifecycle Manager 用の IAM サービスロール
<a name="service-role"></a>

 AWS Identity and Access Management (IAM) ロールは、 AWS アイデンティティができることとできないことを決定するアクセス許可ポリシーを持つアイデンティティであるという点で、ユーザーと似ています AWS。ただし、ユーザーは 1 人の特定の人に一意に関連付けられますが、ロールはそれを必要とする任意の人が引き受けるようになっています。サービスロールは、ユーザーに代わってアクションを実行するために AWS サービスが引き受けるロールです。お客様に代わってバックアップ操作を実行するサービスとして、Amazon Data Lifecycle Managerでは、お客様に代わってポリシー操作を実行するときに、想定するロールを渡す必要があります。IAM ロールの詳細については、*IAM ユーザーガイド*の[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)を参照してください。

Amazon Data Lifecycle Manager に渡すロールには、Amazon Data Lifecycle Manager がポリシー操作に関連するアクション (スナップショットと AMI の作成、スナップショットと AMI のコピー、スナップショットの削除、AMI の登録解除など) を実行できるようにするアクセス権限を持つ IAM ポリシーが必要です。Amazon Data Lifecycle Manager のポリシータイプごとに異なるアクセス権限が必要です。ロールには、Amazon Data Lifecycle Manager が信頼されたエンティティとして登録されている必要があります。これにより、Amazon Data Lifecycle Manager はロールを引き受けることができます。

**Topics**
+ [Amazon Data Lifecycle Manager のデフォルトのサービスロール](#default-service-roles)
+ [Amazon Data Lifecycle Manager のカスタムサービスロール](#custom-role)

## Amazon Data Lifecycle Manager のデフォルトのサービスロール
<a name="default-service-roles"></a>

Amazon Data Lifecycle Manager は、以下のデフォルトのサービスロールを使用します：
+ **AWSDataLifecycleManagerDefaultRole** — スナップショットを管理するためのデフォルトのロール。`dlm.amazonaws.com`サービスのみを信頼してロールを引き受け、Amazon Data Lifecycle Manager は、お客様に代わってスナップショットおよびクロスアカウントのスナップショットコピーポリシーで必要なアクションを実行できます。このロールは ` AWSDataLifecycleManagerServiceRole` AWS マネージドポリシーを使用します。
**注記**  
ロールの ARN 形式は、コンソールを使用して作成されたか、 AWS CLIを使用して作成されたかによって異なります。コンソールを使用してロールが作成された場合、ARN 形式は `arn:aws:iam::account_id:role/service-role/AWSDataLifecycleManagerDefaultRole` です。ロールが を使用して作成された場合 AWS CLI、ARN 形式は です`arn:aws:iam::account_id:role/AWSDataLifecycleManagerDefaultRole`。
+ **AWSDataLifecycleManagerDefaultRoleForAMIManagement**— AMI を管理するためのデフォルトロール。`dlm.amazonaws.com`サービスのみを信頼してロールを引き受けます。これにより、Amazon Data Lifecycle Manager が、お客様に代わってEBS-backed AMI ポリシーで必要なアクションを実行できるようになります。このロールは `AWSDataLifecycleManagerServiceRoleForAMIManagement` AWS マネージドポリシーを使用します。

Amazon Data Lifecycle Manager コンソールを使用している場合、Amazon Data Lifecycle Managerは、スナップショットまたはクロスアカウントのスナップショットコピーポリシーを最初に作成したときに、**AWSDataLifecycleManagerDefaultRole** サービスロールを自動的に作成します。同時にEBS-backed AMIポリシーを最初に作成したときに、**AWSDataLifecycleManagerDefaultRoleForAMIManagement** サービスロールを自動的に作成します。

コンソールを使用していない場合は、サービスロールを手動で作成するには、[デフォルトロールの作成](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-default-role.html)コマンドを実行します。この場合`--resource-type`を指定して`snapshot` AWSDatalifeCycleManagerDefaultRole を作成するか、または`image`AWSDatalifeCycleManagerDefaultRoleForAMIManagementを作成します。

```
$ aws dlm create-default-role --resource-type snapshot|image
```

デフォルトのサービスロールを削除したのち、再度作成する必要がある場合は、同じ手順でアカウントにロールを再作成できます。

## Amazon Data Lifecycle Manager のカスタムサービスロール
<a name="custom-role"></a>

デフォルトのサービスロールを使用する代わりに、必要なアクセス許可を持つカスタム IAM ロールを作成し、ライフサイクルポリシーの作成時に、そのロールを選択することもできます。

**カスタム IAM ロールを作成するには**

1. 次のアクセス許可でロールを作成します。
   + スナップショットライフサイクルポリシーを管理するためのアクセス許可

------
#### [ JSON ]

****  

     ```
     {
         "Version":"2012-10-17",		 	 	 
         "Statement": [
             {
                 "Effect": "Allow",
                 "Action": [
                     "ec2:CreateSnapshot",
                     "ec2:CreateSnapshots",
                     "ec2:DeleteSnapshot",
                     "ec2:DescribeInstances",
                     "ec2:DescribeVolumes",
                     "ec2:DescribeSnapshots",
                     "ec2:EnableFastSnapshotRestores",
                     "ec2:DescribeFastSnapshotRestores",
                     "ec2:DisableFastSnapshotRestores",
                     "ec2:CopySnapshot",
                     "ec2:ModifySnapshotAttribute",
                     "ec2:DescribeSnapshotAttribute",
                     "ec2:ModifySnapshotTier",
                     "ec2:DescribeSnapshotTierStatus",
                     "ec2:DescribeAvailabilityZones"
                 ],
                 "Resource": "*"
             },
             {
                 "Effect": "Allow",
                 "Action": [
                     "ec2:CreateTags"
                 ],
                 "Resource": "arn:aws:ec2:*::snapshot/*"
             },
             {
                 "Effect": "Allow",
                 "Action": [
                     "events:PutRule",
                     "events:DeleteRule",
                     "events:DescribeRule",
                     "events:EnableRule",
                     "events:DisableRule",
                     "events:ListTargetsByRule",
                     "events:PutTargets",
                     "events:RemoveTargets"
                 ],
                 "Resource": "arn:aws:events:*:*:rule/AwsDataLifecycleRule.managed-cwe.*"
             },
             {
                 "Effect": "Allow",
                 "Action": [
                     "ssm:GetCommandInvocation",
                     "ssm:ListCommands",
                     "ssm:DescribeInstanceInformation"
                 ],
                 "Resource": "*"
             },
             {
                 "Effect": "Allow",
                 "Action": [
                     "ssm:SendCommand",
                     "ssm:DescribeDocument",
                     "ssm:GetDocument"
                 ],
                 "Resource": [
                     "arn:aws:ssm:*:*:document/*"
                 ],
                 "Condition": {
                     "StringEquals": {
                         "aws:ResourceTag/DLMScriptsAccess": "true"
                     }
                 }
             },
             {
                 "Effect": "Allow",
                 "Action": [
                     "ssm:SendCommand",
                     "ssm:DescribeDocument",
                     "ssm:GetDocument"
                 ],
                 "Resource": [
                     "arn:aws:ssm:*::document/*"
                 ]
             },
             {
                 "Effect": "Allow",
                 "Action": [
                     "ssm:SendCommand"
                 ],
                 "Resource": [
                     "arn:aws:ec2:*:*:instance/*"
                 ],
                 "Condition": {
                     "StringNotLike": {
                         "aws:ResourceTag/DLMScriptsAccess": "false"
                     }
                 }
             }
         ]
     }
     ```

------
   + AMI ライフサイクルポリシーを管理するためのアクセス許可

------
#### [ JSON ]

****  

     ```
     {
         "Version":"2012-10-17",		 	 	 
         "Statement": [
             {
                 "Effect": "Allow",
                 "Action": "ec2:CreateTags",
                 "Resource": [
                     "arn:aws:ec2:*::snapshot/*",
                     "arn:aws:ec2:*::image/*"
                 ]
             },
             {
                 "Effect": "Allow",
                 "Action": [
                     "ec2:DescribeImages",
                     "ec2:DescribeInstances",
                     "ec2:DescribeImageAttribute",
                     "ec2:DescribeVolumes",
                     "ec2:DescribeSnapshots"
                 ],
                 "Resource": "*"
             },
             {
                 "Effect": "Allow",
                 "Action": "ec2:DeleteSnapshot",
                 "Resource": "arn:aws:ec2:*::snapshot/*"
             },
             {
                 "Effect": "Allow",
                 "Action": [
                     "ec2:ResetImageAttribute",
                     "ec2:DeregisterImage",
                     "ec2:CreateImage",
                     "ec2:CopyImage",
                     "ec2:ModifyImageAttribute"
                 ],
                 "Resource": "*"
             },
             {
                 "Effect": "Allow",
                 "Action": [
                     "ec2:EnableImageDeprecation",
                     "ec2:DisableImageDeprecation"
                 ],
                 "Resource": "arn:aws:ec2:*::image/*"
             }
         ]
     }
     ```

------

   詳細については、*IAM ユーザーガイド* の[ロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html)を参照してください。

1. ロールに信頼関係を追加します。

   1. IAM コンソールで、[**ロール**] を選択します。

   1. 作成したロールを選択し、**信頼関係**を選択します。

   1. [**信頼関係の編集**] を選択して、次のポリシーを追加し、[**信頼ポリシーの更新**] を選択します。

------
#### [ JSON ]

****  

      ```
      {
      	"Version":"2012-10-17",		 	 	 
      	"Statement": [{
      		"Effect": "Allow",
      		"Principal": {
      			"Service": "dlm.amazonaws.com"
      		},
      		"Action": "sts:AssumeRole"
      	}]
      }
      ```

------

      [Confused Deputy Problem (混乱した使節の問題)](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) から自分を守るために、`aws:SourceAccount` および `aws:SourceArn` の条件キーを使用することをお勧めします。例えば、前述の信頼ポリシーに次の条件ブロックを追加できます。`aws:SourceAccount` は、ライフサイクルポリシーの所有者であり、`aws:SourceArn` は、ライフサイクルポリシーの ARN です。ライフサイクルポリシー ID が不明である場合は、ARN のその部分にワイルドカード (`*`) を選択することができ、ライフサイクルポリシーを作成後に信頼ポリシーを更新します。

      ```
      "Condition": {
          "StringEquals": {
              "aws:SourceAccount": "account_id"
          },
          "ArnLike": {
              "aws:SourceArn": "arn:partition:dlm:region:account_id:policy/policy_id"
          }
      }
      ```

# Amazon Data Lifecycle Manager のポリシーをモニタリング
<a name="dlm-monitor-lifecycle"></a>

次の機能を使用して、スナップショットと AMI のライフサイクルをモニタリングできます。

**Topics**
+ [コンソールと AWS CLI](#monitor-console-cli)
+ [AWS CloudTrail](#monitor-lifecycle-cloudtrail)
+ [EventBridge を使用した Data Lifecycle Manager ポリシーのモニタリング](monitor-cloudwatch-events.md)
+ [CloudWatch を使用して、Data Lifecycle Manager のポリシーをモニタリング](monitor-dlm-cw-metrics.md)

## コンソールと AWS CLI
<a name="monitor-console-cli"></a>

ライフサイクルポリシーは、Amazon EC2 コンソールまたは AWS CLIを使用して表示できます。ポリシーによって作成された各スナップショットと AMI には、タイムスタンプとポリシー関連のタグがあります。タグを使用してスナップショットと AMI をフィルタリングして、意図したとおりにバックアップが作成されていることを確認できます。

## AWS CloudTrail
<a name="monitor-lifecycle-cloudtrail"></a>

を使用すると AWS CloudTrail、ユーザーアクティビティと API の使用状況を追跡して、内部ポリシーと規制標準への準拠を示すことができます。詳細については、「[AWS CloudTrail ユーザーガイド](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/)」を参照してください。

# EventBridge を使用した Data Lifecycle Manager ポリシーのモニタリング
<a name="monitor-cloudwatch-events"></a>

Amazon EBS と Amazon Data Lifecycle Manager は、ライフサイクルポリシーアクションに関するイベントを発行します。 AWS Lambda および Amazon CloudWatch Events を使用して、プログラムでイベント通知を処理できます。イベントは、ベストエフォートベースで出力されます。詳細については、[Amazon EventBridge ユーザーガイド](https://docs.aws.amazon.com/eventbridge/latest/userguide/)を参照してください。

利用できるイベントは次のとおりです。

**注記**  
AMI ライフサイクルポリシーアクションでは、イベントは発生しません。
+ `createSnapshot` – `CreateSnapshot` アクションが成功または失敗したときに発生する Amazon EBS イベント。詳細については、「[Amazon EBS 用 Amazon EventBridge イベント](ebs-cloud-watch-events.md)」を参照してください。
+ `DLM Policy State Change` – ライフサイクルポリシーがエラー状態になったときに発生する Amazon Data Lifecycle Manager イベント。このイベントには、エラーを引き起こした原因の説明が含まれています。

  次に、IAM ロールによって付与されたアクセス権限が不十分な場合のイベントの例を示します。

  ```
  {
      "version": "0",
      "id": "01234567-0123-0123-0123-0123456789ab",
      "detail-type": "DLM Policy State Change",
      source": "aws.dlm",
      "account": "123456789012",
      "time": "2018-05-25T13:12:22Z",
      "region": "us-east-1",
      "resources": [
          "arn:aws:dlm:us-east-1:123456789012:policy/policy-0123456789abcdef"
      ],
      "detail": {
          "state": "ERROR",
          "cause": "Role provided does not have sufficient permissions",
          "policy_id": "arn:aws:dlm:us-east-1:123456789012:policy/policy-0123456789abcdef"
      }
  }
  ```

  制限を超えた場合のイベントの例を次に示します。

  ```
  {
      "version": "0",
      "id": "01234567-0123-0123-0123-0123456789ab",
      "detail-type": "DLM Policy State Change",
      "source": "aws.dlm",
      "account": "123456789012",
      "time": "2018-05-25T13:12:22Z",
      "region": "us-east-1",
      "resources": [
          "arn:aws:dlm:us-east-1:123456789012:policy/policy-0123456789abcdef"
      ],
      "detail":{
          "state": "ERROR",
          "cause": "Maximum allowed active snapshot limit exceeded",
          "policy_id": "arn:aws:dlm:us-east-1:123456789012:policy/policy-0123456789abcdef"
      }
  }
  ```
+ `DLM Pre Post Script Notification` – 事前スクリプトまたは事後スクリプトが開始、成功、または失敗したときに発生するイベント。

  VSS バックアップが成功した場合のイベントの例を次に示します。

  ```
  {
      "version": "0",
      "id": "12345678-1234-1234-1234-123456789012",
      "detail-type": "DLM Pre Post Script Notification",
      "source": "aws.dlm",
      "account": "123456789012",
      "time": "2023-10-27T22:04:52Z",
      "region": "us-east-1",
      "resources": ["arn:aws:dlm:us-east-1:123456789012:policy/policy-01234567890abcdef"],
      "detail": {
          "script_stage": "",
          "result": "success",
          "cause": "",
          "policy_id": "arn:aws:dlm:us-east-1:123456789012:policy/policy-01234567890abcdef",
          "execution_handler": "AWS_VSS_BACKUP",
          "source": "arn:aws:ec2:us-east-1:123456789012:instance/i-01234567890abcdef",
          "resource_type": "EBS_SNAPSHOT",
          "resources": [{
              "status": "pending",
              "resource_id": "arn:aws:ec2:us-east-1::snapshot/snap-01234567890abcdef",
              "source": "arn:aws:ec2:us-east-1:123456789012:volume/vol-01234567890abcdef"
          }],
          "request_id": "a1b2c3d4-a1b2-a1b2-a1b2-a1b2c3d4e5f6",
          "start_time": "2023-10-27T22:03:29.370Z",
          "end_time": "2023-10-27T22:04:51.370Z",
          "timeout_time": ""
      }
  }
  ```

# CloudWatch を使用して、Data Lifecycle Manager のポリシーをモニタリング
<a name="monitor-dlm-cw-metrics"></a>

Amazon Data Lifecycle Manager のライフサイクルポリシーは、CloudWatch を使ってモニタリングすることができます。CloudWatch は、raw データを収集し、読み取り可能なほぼリアルタイムのメトリクスに加工することができます。これらのメトリクスを使用して、ポリシーによって作成、削除、コピーされた Amazon EBS スナップショットと EBS Backed AMI の数を正確に把握できます。また、特定のしきい値を監視するアラームを設定し、これらのしきい値に達したときに通知を送信したりアクションを実行したりできます。

メトリクスは 15 か月間保持されるため、履歴情報にアクセスして長期間にわたるライフサイクルポリシーのパフォーマンスをより的確に把握できます。

Amazon CloudWatch の詳細については、[Amazon CloudWatch ユーザーガイド](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/)を参照してください。

**Topics**
+ [サポートされるメトリクス](#metrics)
+ [ポリシーの CloudWatch メトリクスを表示する](#view-metrics)
+ [グラフメトリクス](#graph-metrics)
+ [ポリシーの CloudWatch アラームを作成する](#create-alarm)
+ [ユースケースの例](#use-cases)
+ [失敗したアクションを報告するポリシーの管理](#manage)

## サポートされるメトリクス
<a name="metrics"></a>

`AWS/EBS` 名前空間には、Amazon Data Lifecycle Manager の以下のメトリクスが含まれます。メトリクスは、ポリシータイプによって異なります。

すべてのメトリクスは、`DLMPolicyId` ディメンションで測定できます。最も有用な統計データは `sum` と `average`、そして測定単位は `count` です。

タブを選択すると、そのポリシータイプでサポートされているメトリクスが表示されます。

------
#### [ EBS snapshot policies ]


| メトリクス | 説明 | 
| --- | --- | 
|  `ResourcesTargeted`  |  スナップショットまたは EBS-backed AMI ポリシーで指定されたタグがターゲットとするリソースの数。  | 
|  `SnapshotsCreateStarted`  |  スナップショットポリシーによって開始されたスナップショット作成アクションの数。後続の再試行が複数ある場合でも、各アクションは 1 回だけ記録されます。 スナップショット作成アクションが失敗すると、Amazon Data Lifecycle Manager は `SnapshotsCreateFailed` メトリクスを送信します。  | 
|  `SnapshotsCreateCompleted`  |  スナップショットポリシーにより作成されたスナップショットの数。これには、スケジュールされた時刻から 60 分以内に成功した再試行が含まれます。  | 
|  `SnapshotsCreateFailed`  |  スナップショットポリシーにより作成できなかったスナップショットの数。これには、スケジュールされた時刻から 60 分以内に失敗した再試行が含まれます。  | 
|  `SnapshotsSharedCompleted`  |  スナップショットポリシーによってアカウント間で共有されたスナップショットの数。  | 
|  `SnapshotsDeleteCompleted`  |  スナップショットポリシーまたは EBS-backed AMI ポリシーにより削除されたスナップショットの数。このメトリクスは、ポリシーによって作成されたスナップショットにのみ適用されます。このポリシーは、ポリシーによって作成されたクロスリージョンスナップショットコピーには適用されません。 このメトリクスには、EBS-backed AMI ポリシーが AMI の登録を解除したときに削除されるスナップショットが含まれます。  | 
|  `SnapshotsDeleteFailed`  |  スナップショットポリシーまたは EBS-backed AMI ポリシーにより削除できなかったスナップショットの数。このメトリクスは、ポリシーによって作成されたスナップショットにのみ適用されます。このポリシーは、ポリシーによって作成されたクロスリージョンスナップショットコピーには適用されません。 このメトリクスには、EBS-backed AMI ポリシーが AMI の登録を解除したときに削除されるスナップショットが含まれます。  | 
|  `SnapshotsCopiedRegionStarted`  |  スナップショットポリシーによって開始されたクロスリージョンスナップショットコピーアクションの数。  | 
|  `SnapshotsCopiedRegionCompleted`  |  スナップショットポリシーによって作成されたクロスリージョンスナップショットコピーの数。これには、スケジュールされた時刻から 24 時間以内に成功した再試行が含まれます。  | 
|  `SnapshotsCopiedRegionFailed`  |  スナップショットポリシーにより作成できなかったクロスリージョンスナップショットコピーの数。これには、スケジュールされた時刻から 24 時間以内に失敗した再試行が含まれます。  | 
|  `SnapshotsCopiedRegionDeleteCompleted`  |  スナップショットポリシーによって削除された、保持ルールで指定されたクロスリージョンスナップショットコピーの数。  | 
|  `SnapshotsCopiedRegionDeleteFailed`  |  スナップショットポリシーにより、保持ルールで指定された削除できなかったクロスリージョンのスナップショットコピーの数。  | 
|  `snapshotsArchiveDeletionFailed`  |  スナップショットポリシーによりアーカイブ層から削除できなかったアーカイブ済みスナップショットの数。  | 
|  `snapshotsArchiveScheduled`  |  スナップショットポリシーによりアーカイブが予定されているスナップショットの数。  | 
|  `snapshotsArchiveCompleted`  |  スナップショットポリシーによりアーカイブが正常に行われたスナップショットの数。  | 
|  `snapshotsArchiveFailed`  |  スナップショットポリシーによりアーカイブできなかったスナップショットの数。  | 
|  `snapshotsArchiveDeletionCompleted`  |  スナップショットポリシーによりアーカイブ層から正常に削除できたアーカイブ済みスナップショットの数。  | 
|  `PreScriptStarted`  |  事前スクリプトが正常に開始されたインスタンスの数。 スクリプトの再試行が有効になっている場合、このメトリクスはポリシー実行ごとに複数回出力される可能性があります。  | 
|  `PreScriptCompleted`  |  事前スクリプトが正常に完了したインスタンスの数。事前スクリプトが指定したタイムアウト期間外に完了した場合でも、メトリクスは出力されます。 スクリプトの再試行が有効になっている場合、このメトリクスはポリシー実行ごとに複数回出力される可能性があります。  | 
|  `PreScriptFailed`  |  事前スクリプトが正常に完了しなかったインスタンスの数。事前スクリプトが指定したタイムアウト期間外に完了した場合でも、メトリクスは出力されます。 スクリプトの再試行が有効になっている場合、このメトリクスはポリシー実行ごとに複数回出力される可能性があります。  | 
|  `PostScriptStarted`  |  ポストスクリプトが正常に開始されたインスタンスの数。 スクリプトの再試行が有効になっている場合、このメトリクスはポリシー実行ごとに複数回出力される可能性があります。  | 
|  PostScriptCompleted  |  ポストスクリプトが正常に完了したインスタンスの数。事後スクリプトが指定したタイムアウト期間外に完了した場合でも、メトリクスは出力されます。 スクリプトの再試行が有効になっている場合、このメトリクスはポリシー実行ごとに複数回出力される可能性があります。  | 
|  PostScriptFailed  |  事後スクリプトが正常に完了しなかったインスタンスの数。事後スクリプトが指定したタイムアウト期間外に完了した場合でも、メトリクスは出力されます。 スクリプトの再試行が有効になっている場合、このメトリクスはポリシー実行ごとに複数回出力される可能性があります。  | 
|  `VSSBackupStarted`  |  VSS バックアップが正常に開始されたインスタンスの数。 スクリプトの再試行が有効になっている場合、このメトリクスはポリシー実行ごとに複数回出力される可能性があります。  | 
|  `VSSBackupCompleted`  |  VSS バックアップが正常に完了したインスタンスの数。VSS バックアップがタイムアウト期間外に完了した場合でも、メトリクスは出力されます。 スクリプトの再試行が有効になっている場合、このメトリクスはポリシー実行ごとに複数回出力される可能性があります。  | 
|  `VSSBackupFailed`  |  VSS バックアップが正常に完了しなかったインスタンスの数。VSS バックアップがタイムアウト期間外に完了した場合でも、メトリクスは出力されます。 スクリプトの再試行が有効になっている場合、このメトリクスはポリシー実行ごとに複数回出力される可能性があります。  | 

------
#### [ EBS-backed AMI policies ]

EBS-backed AMI ポリシーでは、次のメトリクスを使用できます。


| メトリクス | 説明 | 
| --- | --- | 
|  `ResourcesTargeted`  |  スナップショットまたは EBS-backed AMI ポリシーで指定されたタグがターゲットとするリソースの数。  | 
|  `SnapshotsDeleteCompleted`  |  スナップショットポリシーまたは EBS-backed AMI ポリシーにより削除されたスナップショットの数。このメトリクスは、ポリシーによって作成されたスナップショットにのみ適用されます。このポリシーは、ポリシーによって作成されたクロスリージョンスナップショットコピーには適用されません。 このメトリクスには、EBS-backed AMI ポリシーが AMI の登録を解除したときに削除されるスナップショットが含まれます。  | 
|  `SnapshotsDeleteFailed`  |  スナップショットポリシーまたは EBS-backed AMI ポリシーにより削除できなかったスナップショットの数。このメトリクスは、ポリシーによって作成されたスナップショットにのみ適用されます。このポリシーは、ポリシーによって作成されたクロスリージョンスナップショットコピーには適用されません。 このメトリクスには、EBS-backed AMI ポリシーが AMI の登録を解除したときに削除されるスナップショットが含まれます。  | 
|  `SnapshotsCopiedRegionDeleteCompleted`  |  スナップショットポリシーによって削除された、保持ルールで指定されたクロスリージョンスナップショットコピーの数。  | 
|  `SnapshotsCopiedRegionDeleteFailed`  |  スナップショットポリシーにより、保持ルールで指定された削除できなかったクロスリージョンのスナップショットコピーの数。  | 
|  `ImagesCreateStarted`  |  EBS-backed AMI ポリシーによって開始された **CreateImage** アクションの数。  | 
|  `ImagesCreateCompleted`  |  EBS-backed AMI ポリシーによって作成された AMI の数。  | 
|  `ImagesCreateFailed`  |  EBS-backed AMI ポリシーによって作成できなかった AMI の数。  | 
|  `ImagesDeregisterCompleted`  |  EBS-backed AMI ポリシーによって登録解除された AMI の数。  | 
|  `ImagesDeregisterFailed`  |  EBS-backed AMI ポリシーによって登録解除できなかった AMI の数。  | 
|  `ImagesCopiedRegionStarted`  |  EBS-backed AMI ポリシーによって開始されたクロスリージョンコピーアクションの数。  | 
|  `ImagesCopiedRegionCompleted`  |  EBS-Backed AMI ポリシーによって作成されたクロスリージョン AMI コピーの数。  | 
|  `ImagesCopiedRegionFailed`  |  EBS-backed AMI ポリシーによって作成できなかったクロスリージョン AMI コピーの数。  | 
|  `ImagesCopiedRegionDeregisterCompleted`  |  EBS-backed AMI ポリシーによって保持ルールで指定された、登録解除されたクロスリージョン AMI コピーの数。  | 
|  `ImagesCopiedRegionDeregisteredFailed`  |  EBS-backed AMI ポリシーによって登録解除できなかった、保持ルールで指定されたクロスリージョン AMI コピーの数。  | 
|  `EnableImageDeprecationCompleted`  |  EBS-backed AMI ポリシーによって非推奨としてマークされた AMI の数。  | 
|  `EnableImageDeprecationFailed`  |  EBS-backed AMI ポリシーによって非推奨としてマークされなかった AMI の数。  | 
|  `EnableCopiedImageDeprecationCompleted`  |  EBS-Backed AMI ポリシーによって非推奨としてマークされたクロスリージョン AMI コピーの数。  | 
|  `EnableCopiedImageDeprecationFailed`  |  グリッドでポリシーを選択し、Monitoringタブを選びます。EBSでサポートされているAMIポリシーによって非推奨としてマークされなかったクロスリージョンAMIコピーの数。  | 

------
#### [ Cross-account copy event policies ]

クロスアカウントコピーイベントポリシーでは、以下のメトリクスを使用できます。


| メトリクス | 説明 | 
| --- | --- | 
|  `SnapshotsCopiedAccountStarted`  |  クロスアカウントコピーイベントポリシーによって開始された、クロスアカウントスナップショットコピーアクションの数。  | 
|  `SnapshotsCopiedAccountCompleted`  |  クロスアカウントコピーイベントポリシーによって別のアカウントからコピーされたスナップショットの数。これには、スケジュールされた時刻から 24 時間以内に成功した再試行が含まれます。  | 
|  `SnapshotsCopiedAccountFailed`  |  クロスアカウントコピーイベントポリシーによって別のアカウントからコピーできなかったスナップショットの数。これには、スケジュールされた時刻から 24 時間以内に失敗した再試行が含まれます。  | 
|  `SnapshotsCopiedAccountDeleteCompleted`  |  クロスアカウントのコピーイベントポリシーによって、保持ルールで指定された削除されたクロスレジオンスナップショットコピーの数。  | 
|  `SnapshotsCopiedAccountDeleteFailed`  |  クロスアカウントのコピーイベントポリシーによって、保持ルールで指定された削除できなかったクロスレジオンスナップショットコピーの数。  | 

------

## ポリシーの CloudWatch メトリクスを表示する
<a name="view-metrics"></a>

 AWS マネジメントコンソール または コマンドラインツールを使用して、Amazon Data Lifecycle Manager が Amazon CloudWatch に送信するメトリクスを一覧表示できます。

------
#### [ Amazon EC2 console ]

**Amazon EC2 コンソールを使用してメトリクスを表示するには**

1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。

1. ナビゲーションペインで**Lifecycle Manager**を選択します。

1. グリッドでポリシーを選択し、**モニタリング**タブを選びます。

------
#### [ CloudWatch console ]

**Amazon CloudWatch コンソールを使用してメトリクスを表示するには**

1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。

1. ナビゲーションペインで [**メトリクス**] を選択します。

1. [**EBS**] 名前空間を選択し、[**Data Lifecycle Manager metrics**] (Data Lifecycle Manager メトリクス) を選択します。

------
#### [ AWS CLI ]

**Amazon Data Lifecycle Manager で利用可能なメトリクスをすべて表示するには**  
[list-metrics](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/list-metrics.html) コマンドを使用します。

```
$ C:\> aws cloudwatch list-metrics \
    --namespace AWS/EBS
```

**特定のポリシーのすべてのメトリクスを表示するには**  
[list-metrics](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/list-metrics.html) コマンドを使用して、`DLMPolicyId` ディメンションを指定します。

```
$ C:\> aws cloudwatch list-metrics \
    --namespace AWS/EBS \
    --dimensions Name=DLMPolicyId,Value=policy-abcdef01234567890
```

**すべてのポリシーにわたって単一のメトリクスを表示するには**  
[list-metrics](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/list-metrics.html) コマンドを使用して、`--metric-name` オプションを指定します。

```
$ C:\> aws cloudwatch list-metrics \
    --namespace AWS/EBS \
    --metric-name SnapshotsCreateCompleted
```

------

## ポリシーのグラフメトリクス
<a name="graph-metrics"></a>

ポリシーの作成が完了したら、Amazon EC2 コンソールを開いて、**Monitoring** タブにポリシーのモニタリンググラフを表示できます。各グラフは利用可能な Amazon EC2 メトリクスのいずれかに基づいています。

以下のグラフが利用可能です：
+ ターゲットとなるリソース (`ResourcesTargeted`に基づく)
+ スナップショットの作成が開始されました (`SnapshotsCreateStarted`)
+ スナップショットの作成が完了しました (`SnapshotsCreateCompleted`に基づく)
+ スナップショットの作成に失敗しました (`SnapshotsCreateFailed`に基づく)
+ スナップショットの共有が完了しました (`SnapshotsSharedCompleted`に基づく)
+ スナップショットの削除が完了しました (`SnapshotsDeleteCompleted`に基づく)
+ スナップショットの削除に失敗しました (`SnapshotsDeleteFailed`に基づく)
+ スナップショットのクロスリージョンコピーが開始されました (`SnapshotsCopiedRegionStarted`に基づく)
+ スナップショットのクロスリージョンコピーが完了しました (`SnapshotsCopiedRegionCompleted`に基づく)
+ スナップショットのクロスリージョンコピーに失敗しました (`SnapshotsCopiedRegionFailed`に基づく)
+ スナップショットのクロスリージョンコピーの削除が完了しました (`SnapshotsCopiedRegionDeleteCompleted`に基づく)
+ スナップショットのクロスリージョンコピーの削除に失敗しました (`SnapshotsCopiedRegionDeleteFailed`に基づく)
+ スナップショットのクロスアカウントコピーが開始されました (`SnapshotsCopiedAccountStarted`に基づく)
+ スナップショットのクロスアカウントコピーが完了しました (`SnapshotsCopiedAccountCompleted`に基づく)
+ スナップショットのクロスアカウントコピーに失敗しました (`SnapshotsCopiedAccountFailed`に基づく)
+ スナップショットのクロスアカウントコピーの削除が完了しました (`SnapshotsCopiedAccountDeleteCompleted`に基づく)
+ スナップショットのクロスアカウントコピーの削除に失敗しました (`SnapshotsCopiedAccountDeleteFailed`に基づく)
+ AMI の作成が開始されました (`ImagesCreateStarted`に基づく)
+ AMI の作成が完了しました (`ImagesCreateCompleted`に基づく)
+ AMI の作成に失敗しました (`ImagesCreateFailed`に基づく)
+ AMI の登録解除が完了しました (`ImagesDeregisterCompleted`に基づく)
+ AMI の登録解除に失敗しました (`ImagesDeregisterFailed`に基づく)
+ AMI のクロスリージョンコピーを開始 (`ImagesCopiedRegionStarted`に基づく)
+ AMI のクロスリージョンコピーが完了しました (`ImagesCopiedRegionCompleted`に基づく)
+ AMI のクロスリージョンコピーに失敗しました (`ImagesCopiedRegionFailed`に基づく)
+ AMI のクロスリージョンコピーの登録解除が完了しました (`ImagesCopiedRegionDeregisterCompleted`に基づく)
+ AMI のクロスリージョンコピーの登録解除に失敗しました (`ImagesCopiedRegionDeregisteredFailed`に基づく)
+ AMI の有効化の廃止が完了しました (`EnableImageDeprecationCompleted`に基づく)
+ AMI の有効化の廃止に失敗しました (`EnableImageDeprecationFailed`に基づく)
+ AMI クロスリージョンコピーの有効化の廃止が完了しました (`EnableCopiedImageDeprecationCompleted`に基づく)
+ AMI クロスリージョンコピーの有効化の廃止に失敗しました (`EnableCopiedImageDeprecationFailed`に基づく)

## ポリシーの CloudWatch アラームを作成する
<a name="create-alarm"></a>

ポリシーの CloudWatch メトリクスをモニタリングする CloudWatch アラームを作成できます。CloudWatch は、指定したしきい値にメトリクスが到達すると、自動的に通知を送信します。CloudWatch アラームを作成するには、CloudWatch コンソールを使用します。

CloudWatch コンソールを使用してアラームを作成する方法について詳細は、*Amazon CloudWatch ユーザーガイド*の次のトピックを参照してください。
+ [静的しきい値に基づいて CloudWatch アラームを作成する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)
+ [異常検出に基づいて CloudWatch アラームを作成する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Anomaly_Detection_Alarm.html)

## ユースケースの例
<a name="use-cases"></a>

ユースケースの例を次に示します。

**Topics**
+ [例 1: ResourcesTargeted メトリクス](#case1)
+ [例 2: SnapshotDeleteFailed メトリクス](#case2)
+ [例 3: SnapshotsCopiedRegionFailed メトリクス](#case3)

### 例 1: ResourcesTargeted メトリクス
<a name="case1"></a>

`ResourcesTargeted` メトリクスを使って、特定のポリシーが実行されるたびに対象となるリソースの総数をモニタリングすることができます。これにより、ターゲットリソースの数が予想されるしきい値を下回ったり上回ったりしたときにアラームをトリガーできます。

例えば、日時ポリシーで `50` 個以下のボリュームのバックアップを作成することを想定している場合、`1` 時間の間に `ResourcesTargeted` の `sum` が `50` より大きくなったときにメールで通知するアラームを作成することができます。これにより、誤ってタグ付けされたボリュームからスナップショットが予期せず作成されないようにすることができます。

以下のコマンドを使用して、このアラームを作成できます。

```
$ C:\> aws cloudwatch put-metric-alarm \
    --alarm-name resource-targeted-monitor \
    --alarm-description "Alarm when policy targets more than 50 resources" \
    --metric-name ResourcesTargeted \
    --namespace AWS/EBS \
    --statistic Sum \
    --period 3600 \
    --threshold 50 \
    --comparison-operator GreaterThanThreshold \
    --dimensions "Name=DLMPolicyId,Value=policy_id" \
    --evaluation-periods 1 \
    --alarm-actions sns_topic_arn
```

### 例 2: SnapshotDeleteFailed メトリクス
<a name="case2"></a>

この `SnapshotDeleteFailed` メトリクスを使用して、ポリシーのスナップショット保持ルールに従ってスナップショットを削除する際の失敗をモニタリングできます。

例えば、12 時間ごとにスナップショットを自動的に削除するポリシーを作成した場合、`1` 時間の間に `SnapshotDeletionFailed` の `sum` が `0` より大きくなったときにエンジニアリングチームに通知するアラームを作成することができます。これにより、不適切なスナップショットの保持を調査し、不要なスナップショットによってストレージコストが増加しないようにすることができます。

以下のコマンドを使用して、このアラームを作成できます。

```
$ C:\> aws cloudwatch put-metric-alarm \
    --alarm-name snapshot-deletion-failed-monitor \
    --alarm-description "Alarm when snapshot deletions fail" \
    --metric-name SnapshotsDeleteFailed \
    --namespace AWS/EBS \
    --statistic Sum \
    --period 3600 \
    --threshold 0 \
    --comparison-operator GreaterThanThreshold \
    --dimensions "Name=DLMPolicyId,Value=policy_id" \
    --evaluation-periods 1 \
    --alarm-actions sns_topic_arn
```

### 例 3: SnapshotsCopiedRegionFailed メトリクス
<a name="case3"></a>

`SnapshotsCopiedRegionFailed` メトリクスを使用して、ポリシーが他のリージョンへのスナップショットのコピーに失敗した場合を特定します。

例えば、ポリシーによりリージョン間でスナップショットを毎日コピーしている場合、`1` 時間の間に `SnapshotCrossRegionCopyFailed` の `sum` が `0` より大きくなったときにエンジニアリングチームに SMS を送信するアラームを作成することができます。これは、系統内の後続のスナップショットがポリシーによって正常にコピーされたかどうかを検証する場合に便利です。

以下のコマンドを使用して、このアラームを作成できます。

```
$ C:\> aws cloudwatch put-metric-alarm \
    --alarm-name snapshot-copy-region-failed-monitor \
    --alarm-description "Alarm when snapshot copy fails" \
    --metric-name SnapshotsCopiedRegionFailed \
    --namespace AWS/EBS \
    --statistic Sum \
    --period 3600 \
    --threshold 0 \
    --comparison-operator GreaterThanThreshold \
    --dimensions "Name=DLMPolicyId,Value=policy_id" \
    --evaluation-periods 1 \
    --alarm-actions sns_topic_arn
```

## 失敗したアクションを報告するポリシーの管理
<a name="manage"></a>

ポリシーの 1 つが、失敗したアクションメトリクスについて予期しないゼロ以外の値を報告した場合の対処方法の詳細については、「[What do I do if Amazon Data Lifecycle Manager reports failed actions in Amazon CloudWatch metrics?](https://repost.aws/knowledge-center/cloudwatch-metrics-dlm)」の記事を参照してください。

# Amazon Data Lifecycle Manager 用のサービスエンドポイント
<a name="dlm-service-endpoints"></a>

*エンドポイント*は、 AWS ウェブサービスのエントリポイントとして機能する URL です。Amazon Data Lifecycle Manager は、次のエンドポイントタイプをサポートします。
+ IPv4 エンドポイント
+ IPv4 と IPv6 の両方をサポートするデュアルスタックのエンドポイント
+ FIPS エンドポイント

リクエストを行うと、使用するエンドポイントとリージョンを指定できます。エンドポイントを指定しない場合、デフォルトで IPv4 エンドポイントが使用されます。別のエンドポイントタイプを使用するには、リクエストで指定する必要があります。これを行う方法の例については、「[エンドポイントの指定](#dlm-endpoint-examples)」を参照してください。

Amazon Data Lifecycle Manager については、「*Amazon Web Services 全般のリファレンス*」の「[Amazon Data Lifecycle Manager endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/dlm.html)」を参照してください。

**Topics**
+ [IPv4 エンドポイント](#dlm-ipv4)
+ [デュアルスタック (IPv4 および IPv6) エンドポイント](#dlm-ipv6)
+ [FIPS エンドポイント](#dlm-fips)
+ [エンドポイントの指定](#dlm-endpoint-examples)

## IPv4 エンドポイント
<a name="dlm-ipv4"></a>

IPv4 エンドポイントは IPv4 トラフィックのみをサポートします。IPv4 エンドポイントは、全リージョンで利用できます。

リージョンをエンドポイント名の一部として指定する必要があります。エンドポイント名には、次の命名規則が使用されます。
+ dlm.*region*.amazonaws.com

例えば、米国東部 (バージニア北部) リージョンの IPv4 エンドポイントは `dlm.us-east-1.amazonaws.com` です。

## デュアルスタック (IPv4 および IPv6) エンドポイント
<a name="dlm-ipv6"></a>

デュアルスタックエンドポイントは、IPv4 と IPv6 トラフィックの両方をサポートします。デュアルスタックエンドポイントは、すべてのリージョンで利用できます。

IPv6 を使用するには、デュアルスタックエンドポイントを使用する必要があります。デュアルスタックエンドポイントにリクエストを行うと、エンドポイント URL は、ネットワークとクライアントが使用するプロトコルに応じて IPv6 または IPv4 アドレスに解決されます。

リージョンをエンドポイント名の一部として指定する必要があります。デュアルスタックエンドポイント名には、次の命名規則が使用されます。
+ `dlm.region.api.aws`

例えば、米国東部 (バージニア北部) リージョンのデュアルスタックエンドポイントは `dlm.us-east-1.api.aws` です。

## FIPS エンドポイント
<a name="dlm-fips"></a>

Amazon Data Lifecycle Manager は、次のリージョンの FIPS 検証済みデュアルスタック (IPv4 および IPv6) エンドポイントを提供します。
+ `us-east-1` — 米国東部 (バージニア北部)
+ `us-east-2` — 米国東部 (オハイオ)
+ `us-west-1` — 米国西部 (北カリフォルニア)
+ `us-west-2` — 米国西部 (オレゴン)
+ `ca-central-1` — カナダ (中部)
+ `ca-west-1` — カナダ西部 (カルガリー)

FIPS デュアルスタックエンドポイントは、命名規則 を使用します`dlm-fips.region.api.aws`。例えば、米国東部 (バージニア北部) リージョンの FIPS デュアルスタックのエンドポイントは `dlm-fips.us-east-1.api.aws` です。

## エンドポイントの指定
<a name="dlm-endpoint-examples"></a>

次の例は、 AWS CLIを使用して `US East (N. Virginia)` リージョンのエンドポイントを指定する方法を示しています。
+ **デュアルスタック**

  ```
  aws dlm create-default-role \
  --resource-type snapshot \
  --endpoint-url https://dlm.us-east-2.api.aws
  ```
+ **IPv4**

  ```
  aws dlm create-default-role \
  --resource-type snapshot \
  --endpoint-url https://dlm.us-east-2.amazonaws.com
  ```

# VPC と Amazon EBS 間にプライベート接続を作成する
<a name="dlm-vpc-endpoints"></a>

[AWS PrivateLink](https://aws.amazon.com/privatelink/) を利用した *インターフェイス VPC エンドポイント*を作成することで、VPC と Amazon EBS 間にプライベート接続を確立できます。インターネットゲートウェイ、NAT デバイス、VPN 接続、または AWS Direct Connect 接続を使用せずに、VPC 内にあるかのように Amazon EBS にアクセスできます。VPC のインスタンスは、パブリック IP アドレスがなくても Amazon EBS と通信できます。

インターフェイスエンドポイントに対して有効にする各サブネットにエンドポイントネットワークインターフェイスを作成します。

詳細については、「 *AWS PrivateLink ガイド*」の[「Access AWS のサービス through AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html)」を参照してください。

**注記**  
Amazon Data Lifecycle Manager は、すべての商用および AWS GovCloud (US) リージョンの IPv4 インターフェイス VPC エンドポイントと、商用リージョンの IPv6 インターフェイス VPC エンドポイントのみをサポートします。

## Amazon EBS の VPC エンドポイントに関する考慮事項
<a name="dlm-vpc-endpoint-considerations"></a>

Amazon EBS のインターフェイス VPC エンドポイントを設定する前に、「*AWS PrivateLink ガイド*」の「[Access an AWS service using an interface VPC endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#considerations-interface-endpoints)」を確認してください。

デフォルトで、エンドポイント経由での Amazon EBS への完全なアクセスが許可されます。VPC エンドポイントポリシーを使用してインターフェイスエンドポイントへのアクセスを制御できます。VPC エンドポイントに Amazon EBS へのアクセスをコントロールするエンドポイントポリシーをアタッチできます。このポリシーでは、以下の情報を指定します。
+ アクションを実行できる**プリンシパル**。
+ 実行可能な**アクション**。
+ アクションを実行できる**リソース**。

詳細については、*Amazon VPC ユーザーガイド*の[VPC エンドポイントによるサービスのアクセスコントロール](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html)を参照してください。

Amazon EBS のエンドポイントポリシーの例を次に示します。このポリシーは、エンドポイントにアタッチされると、Amazon Data Lifecycle Manager ポリシーに関する概要情報を取得するアクセス許可をすべてのユーザーに付与します。

```
{
  "Statement": [{
    "Action": "dlm:GetLifecyclePolicies",
    "Effect": "Allow",
    "Principal": "*",
    "Resource": "*"
  }]
}
```

## Amazon EBS 用のインターフェイス VPC エンドポイントを作成する
<a name="dlm-vpc-endpoint-create"></a>

Amazon EBS 用の VPC エンドポイントは、Amazon VPC コンソールまたは AWS Command Line Interface (AWS CLI) で作成できます。詳細については、「*AWS PrivateLink ガイド*」の「[Create a VPC endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws)」を参照してください。

Amazon EBS 用の VPC エンドポイントを作成するには、次のサービス名を使用します。
+ `com.amazonaws.region.dlm`

エンドポイントのプライベート DNS を有効にすると、リージョンのデフォルト DNS 名 (`dlm.us-east-1.amazonaws.com` など) を使用して、Amazon EBS への API リクエストを実行できます。

# Amazon Data Lifecycle Manager の問題のトラブルシューティング
<a name="dlm-troubleshooting"></a>

以下のドキュメントは、発生する可能性のある問題のトラブルシューティングに役立ちます。

**Topics**
+ [エラー: `Role with name already exists`](#dlm-role-arn-issue)

## エラー: `Role with name already exists`
<a name="dlm-role-arn-issue"></a>

**説明**  
コンソールを使用してポリシーを作成しようとしたときに、`Role with name AWSDataLifecycleManagerDefaultRole already exists` または `Role with name AWSDataLifecycleManagerDefaultRoleForAMIManagement already exists` エラーが発生します。

**原因**  
デフォルトロールの ARN 形式は、コンソールまたは AWS CLIのどちらを使用して作成されたかによって異なります。ARN は異なりますが、ロールは同じロール名を使用するため、コンソールと AWS CLIでロール名の競合が発生します。

**ソリューション**  
この問題を解決するには、次の操作を行います:

1. (*事前スクリプトと事後スクリプトに対してのみ有効なスナップショットポリシーの場合*) **AWSDataLifecycleManagerSSMFullAccess** AWS 管理ポリシーを **AWSDataLifecycleManagerDefaultRole** IAM ロールに手動でアタッチします。詳細については、「[IAM アイデンティティのアクセス許可の追加](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console)」を参照してください。

1. Amazon Data Lifecycle Manager ポリシーを作成するときは、**[IAM ロール]** で **[別のロールを選択]** を選択し、**[AWSDataLifecycleManagerDefaultRole]** (スナップショットポリシー用) または **[AWSDataLifecycleManagerDefaultRoleForAMIManagement]** (AMI ポリシー用) のいずれかを選択します。

1. 引き続き、通常どおりポリシーを作成します。