AMI ライフサイクルポリシーを作成する AMI ライフサイクルポリシーに関する考慮事項その他のリソース

AMI ライフサイクルの自動化

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

トピック

AMI ライフサイクルポリシーを作成する
AMI ライフサイクルポリシーに関する考慮事項
その他のリソース

AMI ライフサイクルポリシーを作成する

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

New console

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

Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。
ナビゲーションペインで、[Elastic Block Store]、[ライフサイクルマネージャー]、[ライフサイクルポリシーの作成] の順に選択します。
[ポリシータイプの選択] 画面で、[EBS-backed AMI ポリシー] を選択した後、[次] をクリックします。
[Target resources] (ターゲットのリソース) セクションの [Target resource tags] (ターゲットリソースタグ) で、バックアップするボリュームまたはインスタンスを識別するリソースタグを選択します。ポリシーでは、特定のタグキーと値のペアを持つリソースのみがバックアップされます。
[説明] にポリシーの簡単な説明を入力します。
[IAM ロール] で、AMI とスナップショットを管理しインスタンスを記述するためのアクセス許可を持つ、IAM ロールを選択します。Amazon Data Lifecycle Manager から提供されるデフォルトのロールを使用するには、[デフォルトロール] を選択します。以前に作成したカスタム IAM ロールを使用するには、[別のロールを選択] をクリックした上で、使用するロールを選択します。
[ポリシータグ] に、ライフサイクルポリシーに適用されるタグを追加します。これらのタグは、ポリシーを識別および分類するために使用することができます。
[作成後のポリシーの状態] で、[ポリシーの有効化] を選択すると、次にスケジュールした時刻でポリシーが実行されます。ポリシーが実行されないようにするには、[ポリシーの無効化] を選択します。ここでポリシーを有効にしない場合、作成後に手動で有効にするまで AMI の作成は開始されません。
[インスタンスの再起動] セクションに、AMI の作成前にインスタンスを再起動するかどうかが表示されています。ターゲットのインスタンスが再起動されないようにするには、[いいえ] を選択します。[いいえ] を選択することで、データの整合性に問題が発生する場合があります。AMI の作成前にインスタンスを再起動するには、[はい] を選択します。これを選択すると、データの整合性が保証されます。ただし、複数のターゲットインスタンスが同時に再起動する可能性があります。
[Next] を選択します。
[スケジュールの設定] 画面で、ポリシースケジュールを設定します。1 つのポリシーには、最大 4 つのスケジュールを含めることができます。スケジュール 1 は必須です。スケジュール 2、3、および 4 はオプションです。追加したポリシースケジュールごとに、以下の操作を行います。
1. [スケジュールの詳細] セクションで、次の操作を行います。
  1. [スケジュール名] で、スケジュールの分かりやすい名前を指定します。
  2. [頻度]とそれに関連するフィールドで、ポリシーの実行間隔を設定します。ポリシーの実行は、日次、週次、月次、年次のいずれかのスケジュールで設定できます。または、[カスタム cron 式] をクリックし、最長 1 年の間隔を指定します。詳細については、Amazon CloudWatch Events ユーザーガイドの「Cron 式」を参照してください。
  3. [開始時刻] では、ポリシー実行の開始予定時刻を指定します。初回のポリシー実行は、スケジュールした時刻から 1 時間以内に開始されます。時刻は、hh:mm UTC 形式で入力する必要があります。
  4. [保持タイプ] で、スケジュールで作成された AMI の保持ポリシーを指定します。AMI は、総数または期間に基づいて保持できます。
    
    カウントベースの保持の場合、指定できる範囲は 1～1000 です。このカウントが最大数に達すると、新しい AMI が作成される時点で、最も古いスナップショットの登録が解除されます。
    
    保存期間に基づく保持の場合、指定できる範囲は 1 日～100 年です。各 AMI の保存期間が終了すると、その AMI は削除されます。
    
    注記
    すべてのスケジュールは、同じ保持タイプである必要があります。保持タイプを指定できるのは、スケジュール 1 のみです。スケジュール 2、3、4 は、スケジュール 1 から保持タイプを継承します。各スケジュールには、独自の保持回数または期間を設定できます。
2. [タグ付け] セクションで、以下を実行します。
  1. ソースインスタンスからスケジュールにより作成された AMI に対し、すべてのユーザー定義タグをコピーするには、[ソースからタグをコピー] を選択します。
  2. デフォルトで、スケジュールによって作成された AMI には、ソースインスタンスの ID を使用して自動的にタグ付けが行われます。この自動タグ付けが行われないようにするには、[可変タグ] から、instance-id:$(instance-id) タイルを削除します
  3. 他のタグを指定し、このスケジュールによって作成された AMI に割り当てるには、[タグを追加] をクリックします。
3. 使用しなくなった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を非推奨にするようにスケジュールを設定できます。
4. スケジュールによって作成された AMI を別のリージョンにコピーするには、[クロスリージョンのコピー] セクションで、[クロスリージョンコピーを有効化する] を選択します。AMI は、アカウント内で最大 3 つの異なるリージョンにコピーできます。コピー先となるリージョンごとに、個別のクロスリージョンコピーのためのルールを指定する必要があります。
  
  コピー先リージョンごとに、以下を指定できます：
  - AMIコピーの保持ポリシー。保持期間が終了すると、コピー先リージョンのコピーは自動的に登録解除されます。
  - AMIコピーの暗号化ステータス。ソース AMI が暗号化されている場合、または暗号化がデフォルトで有効化されている場合には、コピーされた AMI も常に暗号化されます。ソース AMI が暗号化されておらず、暗号化がデフォルトで無効になっている場合は、オプションで暗号化を有効にできます。KMS キーを指定しない場合、AMI は、各送信先リージョンにおける EBS 暗号化用のデフォルト KMS キーを使用して暗号化されます。送信先リージョンで KMS キーを指定する場合、選択した IAM ロールには KMS キーへのアクセス権が必要です。
  - AMIコピーの非推奨ルール。非推奨期間が終了すると、AMI コピーは自動的に非推奨になります。非推奨期間は、コピーの保存期間以下である必要があり、また10 年を超えることはできません。
  - ソース AMI からすべてのタグをコピーするか、タグをコピーしないかです。
  注記
  リージョンごとの、AMI の同時コピー数を超えないようにします。
5. 新たにスケジュールを追加するには、画面の上部にある [他のスケジュールを追加する] をクリックします。追加スケジュールごとに、このトピックの説明にならってフィールドを設定します。
6. 必要なスケジュールを追加したら、[ポリシーをレビュー] をクリックします。
ポリシーの概要を確認した後、[ポリシーを作成] をクリックします。

Console

AMI ライフサイクルポリシーを作成するには

Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。
ナビゲーションペインで、[Elastic Block Store]、[ライフサイクルマネージャー]、[ライフサイクルポリシーの作成] の順に選択します。
必要に応じて、ポリシーに次の情報を入力します。
- 説明— ポリシーの説明。
- ポリシータイプ— 作成するポリシーのタイプ。[EBS-backed AMI ポリシー] を選択します。
- これらのタグを持つターゲット— バックアップするインスタンスを識別するリソースタグ。ポリシーでは、特定のタグキーと値のペアを持つインスタンスのみがバックアップされます。
- ポリシータグ— ライフサイクルポリシーに適用されるタグ。
[IAM ロール] で、イメージを管理するためのアクセス許可を持つ IAM ロールを選択します。お客様は、AWS が提供するデフォルトのロールを使用することも、カスタム IAM ロールを作成することもできます。
ポリシースケジュールを追加します。スケジュール 1 は必須です。スケジュール 2、3、および 4 はオプションです。追加したポリシースケジュールごとに、次の情報を指定します。
- スケジュール名— スケジュールの名称。
- 頻度— ポリシーの実行間隔。ポリシーの実行は、日次、週次、月次、年次のいずれかのスケジュールで設定できます。または、[カスタム cron 式] をクリックし、最長 1 年の間隔を指定します。詳細については、Amazon CloudWatch Events ユーザーガイドの「Cron 式」を参照してください。
- 開始時刻: hh:mm UTC— ポリシー実行の開始予定時刻。初回のポリシー実行は、予定時刻から 1 時間以内に開始されます。
- 保持タイプ— AMI は、総数または期間に基づいて保持できます。カウントベースの保持の場合、指定できる範囲は 1～1000 です。このカウントが最大数に達すると、新しい AMI が作成される時点で、最も古い AMI が削除されます。保存期間に基づく保持の場合、保存時間の範囲は 1～100 年です。各 AMI の保存期間が終了すると、その AMI は削除されます。保存期間は、この間隔以上でなければなりません。
  
  注記
  すべてのスケジュールは、同じ保持タイプである必要があります。保持タイプを指定できるのは、スケジュール 1 のみです。スケジュール 2、3、4 は、スケジュール 1 から保持タイプを継承します。各スケジュールには、独自の保持回数または期間を設定できます。
- ソースからタグをコピー—ソースインスタンスのすべてのユーザー定義タグを、スケジュールにより作成された AMI にコピーするかどうかを選択します。
- 動的タグ— ソースインスタンスの ID を使用しながら、AMI に自動的にタグ付けするように選択できます。
- 追加のタグ— このスケジュールによって作成された AMI に割り当てる追加のタグを指定します。
- クロスリージョンコピーを有効化— AMI は最大 3 つの異なるリージョンにコピーできます。
  
  リージョンごとに、異なる保持ポリシーを選択できます。また、すべてのタグをコピーするか、いずれのタグもコピーしないかを選択できます。ソース AMI が暗号化されている場合、または暗号化がデフォルトで有効化されている場合には、コピーされた AMI も暗号化されます。AMI が暗号化されていない場合には、暗号化を有効化できます。KMS キーを指定しない場合、AMI は、各送信先リージョンにおける EBS 暗号化用のデフォルト KMS キーを使用して暗号化されます。送信先リージョンで KMS キーを指定する場合、選択した IAM ロールには KMS キーへのアクセス権が必要です。
  
  リージョンごとの、AMI の同時コピー数を超えないようにします。
AMI の作成前にインスタンスを再起動するかどうかを指定します。ターゲットインスタンスが再起動されないようにするには、[ポリシー実行時にインスタンスを再起動] で [いいえ] を選択します。このオプションを選択すると、データの整合性に問題が発生する場合があります。AMI の作成前にインスタンスを再起動するには、[ポリシー実行時にインスタンスを再起動] で [はい] を選択します。これを選択すると、データの整合性は保証されますが、複数のターゲットインスタンスが同時に再起動する可能性があります。
[Policy status after creation (作成後のポリシーの状態)] では、[Enable policy (ポリシーの有効化)] を選択すると、次のスケジュールした時刻にポリシーが実行されます。ポリシーが実行されないようにするには、[Disable policy (ポリシーの無効化)] を選択します。
[Create Policy (ポリシーの作成)] を選択します。

Command line

AMI ライフサイクルポリシーを作成するには、create-lifecycle-policy コマンドを使用します。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 ライフサイクルポリシーに関する考慮事項

AMI ライフサイクルポリシーを作成する場合の考慮事項は次のとおりです。

最初の AMI 作成のオペレーションは、指定された開始時刻から 1 時間以内に開始されます。後続の AMI 作成オペレーションは、それらがスケジュールされた時刻から 1 時間以内に開始されます。
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 が不要になった場合は、手動で登録解除する必要があります。

ポリシーのターゲットとなるインスタンスの終了には次の考慮事項が適用されます:

カウントベースの保持スケジュールが設定されたポリシーによってターゲットにされたインスタンスを終了すると、以前に終了したインスタンスから作成された 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 は、非推奨に移行する日が最も遅くなる非推奨ルールを使用します。

その他のリソース

詳細については、AWS ストレージブログ記事「Automating Amazon EBS snapshot and AMI management using Amazon Data Lifecycle Manager」(Amazon Data Lifecycle Manager を使用して Amazon EBS スナップショットと AMI 管理を自動化する) を参照してください。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

スナップショットのライフサイクルの自動化

クロスアカウントのスナップショットコピーの自動化