目次
AMI作成の手動とData Lifecycle Manager(DLM)の違いのまとめ
| 作成方法 | スケジュール | 保持/削除 | |
|---|---|---|---|
| 手動でAMI作成 | その都度、対象のインスタンスを選んで実行 |
自前で実装（Cron・EventBridge + Lambda 等） | 手動運用 |
| DLMでAMI作成 | ポリシーを一度作れば、スケジュール・自動作成・命名・タグ・保持・削除まで自動化 対象：タグやリソース指定で幅広く対象化できる |
ポリシーに周期/開始時刻を設定するだけ | 自動で AMIの登録解除とスナップショットの削除。 |
DLM は AMI/スナップショットの自動作成・保持・削除を目的としたサービスです。
DLMのNoReboot パラメータの既定はtrue（=再起動しない）です。（必要に応じて再起動に切り替え可）
Automate backups with Amazon Data Lifecycle Manager
https://docs.aws.amazon.com/ebs/latest/userguide/snapshot-lifecycle.html?utm_source=chatgpt.com
Modify Amazon Data Lifecycle Manager policies(DLM)
https://docs.aws.amazon.com/ebs/latest/userguide/modify.html?utm_source=chatgpt.com
手動でAMI作成
一時的な検証・単発のバックアップのときに使用します。
または自前で定期バックアップのサイクルを作ることも可能です。
DLMでAMI作成
定期バックアップを作成できます。（例：毎日/毎6時間で AMI を作る）
世代管理を作成できます。（直近3世代だけ残すなど）
→年齢（Age）ベース or 個数（Count）ベース
横展開ができます。（タグで一括対象化／クロスリージョン自動コピー）
再起動可否も設定できます。（NoReboot の既定は 「再起動なし」。整合性重視なら「再起動あり」に）
AMI取得失敗
AMI取得を失敗する場合はあります。
その回の AMI は作られず、既存 AMI は即時には消えません。
検知は CloudWatch メトリクスと EventBridge で可能です。
AMI取得失敗の例
・IAMロール不足／誤設定（DLM のサービスロールが無い／信頼関係や権限不足）
・KMS キー権限の不足（暗号化 AMI／クロスリージョンコピー時のキー使用権限が無い等）
・対象外や条件未充足（タグ不一致、デフォルトポリシーは “作成から24時間未満のリソースは対象外” など）
・クォータ超過（AMI 総数などのリージョンクォータに抵触）
・スケジュール猶予内に開始されず“遅延”に見える（開始は指定時刻の1時間以内が仕様）
DLMでAMI取得失敗し、そのままの状態で、次のAMI取得のタイミングがきたとき
原因が解消済み & ポリシーENABLEDなら、次回スケジュールで自動再トライされます。
ポリシーが error/disabledなら、個数（Count）ベースは新規作成も止まるため、原因修正→ポリシー有効化が必要です。
https://docs.aws.amazon.com/ebs/latest/userguide/ami-policy.html
関連の記事