2023.10.13 2023.11.24

Data Lifecycle ManagerでAMIを管理してみよう

akira

Contents

はじめに
DLMでどんな事ができるのか
1. 機能概要
2. AWS Backupとの使い分け
実際にAMIを取得、管理してみる
まとめ

はじめに

週３回のジム通いが楽しくなってきたakiraです。

AWSを運用する上で、EC2のAMI取得とその管理は欠かすことのできない運用項目の１つであると思います。
本ブログでは運用を楽にするサービスの１つとしてData Lifecycle Manager（以下DLM）をご紹介いたします。また、類似のサービスとしてAWS Backupがありますので、使い分けのポイントも合わせてご紹介できればと思います。

DLMでどんな事ができるのか

DLMの機能概要の紹介とAWS Backupとの使い分けについて簡単にご紹介させていただきます。

機能概要

EBSスナップショット・EBS-backed AMIの管理

大きな機能として、EBSスナップショットとEBS-backed AMIの管理があります。
作成のみではなくライフサイクル管理までできるということがポイントになるかと思います。
コンソール/CLIを経由して取得の頻度やライフサイクルを指定するのみで自動的に取得から削除するまでを管理することが出来ます。

注意点として、EBSスナップショットの作成/EBS-backed AMIの取得のどちらも、指定された時刻ちょうどに実行されるわけではありません。
指定された開始時刻から 1 時間以内に開始され、後続のオペレーションがあればそれらのスケジュールされた時刻を基準として 1 時間以内に開始されます。

その他にも制約事項が記載されていますので、要件等に応じて下記を参照の上ご利用ください。

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

もう一つの機能として、クロスアカウントでのスナップショットコピー自動化があります。

こちらの機能を用いると、EC2のスナップショットを取得するだけではなく取得したスナップショットを他のアカウントにコピーするまでを自動化することが出来ます。
KMSを利用することでセキュアにコピーすることが出来るため、アカウントレベルでの侵害に備えたデータのバックアップとして活用することが出来ます。

その他の手順等については下記を参照の上ご利用ください。

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

AWS Backupとの使い分け

AWS BackupではEC2のみならず、様々なリソースのバックアップを取得することが可能です。
また、リソースにもよりますがリージョンをまたいでのバックアップ作成が可能であることも大きな特徴になります。

どう使い分けるのが良いか

気になるポイントとしてはDLMとAWS Backupの使い分けになると思います。
参考として公式ドキュメントには以下の記載があります。

EBS スナップショットの作成、復元、削除を自動化したい場合、Amazon Data Lifecycle Manager を使用してください。EBS ボリュームを含む、ご使用中の AWS のサービス周辺のバックアップを 1 か所で管理しモニタリングしたい場合、AWS Backup をご使用ください。
https://aws.amazon.com/jp/backup/faqs/

記載事項からバックアップ機能としての比較だけで判断するのではなく、その他にどのようなリソースを利用しているのか、どのようなワークロードを実行しているのかを考慮して総合的に判断するのが良いと思われます。

実際にAMIを取得、管理してみる

今ブログでは3台のEC2を作成し、DLMでAMI取得とLifecycle管理を実際にやってみたいと思います。

下準備

AMI取得のターゲットとなるEC2の作成

今回使用するEC2には区別のために以下の表のとおり、複数のタグを付与しました。

タグ	EC2 1号機	EC2 2号機	EC2 3号機
Name	backup_test	prd_backup_test2	prd_backup_test3
env	dev	prd	prd
workload	development	analytics	visualization

各EC2に付与したタグ

今回はDLMの検証のため、EC2の作成手順は省略しております。

DLMの設定

今回はタグを利用して2パターンのDLMを設定していきます

パターン1：Nameタグで1つのEC2を対象にする

まずは標準的なパターンとしてName = backup_test をターゲットにして設定してみます。

AWSコンソールから[ライフサイクルマネージャー]→[EBS-backed AMIポリシー]を選択→[次のステップ]

ターゲットをName=backup_testのタグがついているリソースに指定します。（EC2 1号機が対象になる想定です）
その他、ロールはデフォルトを使用し、他の項目も初期値のままで[次へ]を押下します。

毎時、AMIを取得し、7日後に期限切れになるように設定してみます。

その他、問題がなければ[ポリシーを作成]を実行します。これであとは待つだけになります。

パターン2：envタグで2つのEC2を対象にする

続いて少し実用的なパターンとしてenv = prd をターゲットにして設定してみます。本番環境のフラグが付与されているEC2を一括でAMI取得するイメージです。

設定方法は先程とほぼ同様で、以下のようにタグを指定してあげるだけで問題ありません。

スケジュールは先程同様毎時取得ですがCron式を用いて記載してみました。
また、保持タイプも日数ではなく個数で管理するように設定してみています。

結果の確認

設定から少しの間放置して、各パターンでどの様に取得されているか確認していきます。

パターン1：想定通りに毎時取得されていることがわかります。保持期間が7日なので確認時点では取得されたAMIはすべて保持されていました。

パターン2：こちらも想定通りに毎時取得、かつ2つのEC2のAMIが取得されていました。
保持設定数は2に設定していましたが、ちょうど取得直後であったようで3つずつ表示されていました。

AMI を正常に登録解除し、関連するバッキングスナップショットを削除するには、数時間かかることがあります。以前に作成した AMI が正常に登録解除される前に Amazon Data Lifecycle Manager が次の AMI を作成した場合、一時的に保持数を超える数の AMI を保持する可能性があります。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ami-policy.html#ami-considerations

追加の検証

上記の検証から、パターン1について、保持期間が少し長すぎると感じました。そこで、以下のようにスケジュールを変更してみたいと思います。

確認したいこととしては、スケジュールを変更したときに変更前のスケジュールで取得されたAMIにどのような影響があるかになります。

しばらく経過すると以下のような結果になりました。

実はこれは想定通りの挙動で、公式ドキュメントにも以下のような記載があります。

経過時間ベースの保持スケジュールを、新たな期間を使用するスケジュールに修正すると、新たな期間は、変更後に作成された新たなスナップショットまたは AMI にのみ適用されます。新たなスケジュールは、変更前に作成されたスナップショットまたは AMI の保持スケジュールに影響を及ぼすことはありません。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/view-modify-delete.html#modify

本検証からスケジュール変更時には旧AMIを手動で削除する必要があるとわかりました。
他にも制約事項が記載されていますので、合わせてご確認いただければと思います。