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

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

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

トピック

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

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

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

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. AMI のタグ付けを設定します。
  
  [タグ付け] セクションで、以下を実行します。
  1. ソースインスタンスからスケジュールにより作成された AMI に対し、すべてのユーザー定義タグをコピーするには、[ソースからタグをコピー] を選択します。
  2. デフォルトで、スケジュールによって作成された AMI には、ソースインスタンスの ID を使用して自動的にタグ付けが行われます。この自動タグ付けが行われないようにするには、[可変タグ] から、instance-id:$(instance-id) タイルを削除します
  3. 他のタグを指定し、このスケジュールによって作成された AMI に割り当てるには、[タグを追加] をクリックします。
  表示を増やす表示を減らす
3. 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を非推奨にするようにスケジュールを設定できます。
  
  表示を増やす表示を減らす
4. クロスリージョンでのコピーを設定します。
  
  スケジュールによって作成された AMI を別のリージョンにコピーするには、[クロスリージョンのコピー] セクションで、[クロスリージョンコピーを有効化する] を選択します。AMI は、アカウント内で最大 3 つの異なるリージョンにコピーできます。コピー先となるリージョンごとに、個別のクロスリージョンコピーのためのルールを指定する必要があります。
  
  コピー先リージョンごとに、以下を指定できます：
  AMIコピーの保持ポリシー。保持期間が終了すると、コピー先リージョンのコピーは自動的に登録解除されます。
  
  AMIコピーの暗号化ステータス。ソース AMI が暗号化されている場合、または暗号化がデフォルトで有効化されている場合には、コピーされた AMI も常に暗号化されます。ソース AMI が暗号化されておらず、暗号化がデフォルトで無効になっている場合は、オプションで暗号化を有効にできます。KMS キーを指定しない場合、AMI は、各送信先リージョンにおける EBS 暗号化用のデフォルト KMS キーを使用して暗号化されます。送信先リージョンで KMS キーを指定する場合、選択した IAM ロールには KMS キーへのアクセス権が必要です。
  
  AMIコピーの非推奨ルール。非推奨期間が終了すると、AMI コピーは自動的に非推奨になります。非推奨期間は、コピーの保存期間以下である必要があり、また10 年を超えることはできません。
  
  ソース AMI からすべてのタグをコピーするか、タグをコピーしないかです。
  注記
  リージョンごとの、AMI の同時コピー数を超えないようにします。
  表示を増やす表示を減らす
5. 新たにスケジュールを追加するには、画面の上部にある [他のスケジュールを追加する] をクリックします。追加スケジュールごとに、このトピックの説明にならってフィールドを設定します。
6. 必要なスケジュールを追加したら、[ポリシーをレビュー] をクリックします。
ポリシーの概要を確認した後、[ポリシーを作成] をクリックします。

注記
Role with name AWSDataLifecycleManagerDefaultRoleForAMIManagement already exists エラーが発生した場合、詳細については「トラブルシューティング」を参照してください。

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 ライフサイクルポリシーは、ポリシーと同じリージョンにあるインスタンスのみを対象としています。
最初の 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 ポリシーおよび「ごみ箱」に適用されます。

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の無効化に関する考慮事項は次のとおりです。

Amazon Data Lifecycle Manager が作成した AMI を無効化し、保持しきい値に達したときにその AMI が無効になっている場合、Amazon Data Lifecycle Manager は AMIを登録解除し、関連付けられたスナップショットを削除します。
Amazon Data Lifecycle Manager が作成した 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 を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

事前スクリプトと事後スクリプトの実行をモニタリング

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