AWS Well-Architected Tool のLensを活用してワークロードをレビューしよう
doiken
デロイト トーマツ ウェブサービス株式会社（DWS）公式ブログ
Data Lifecycle ManagerでAMIを管理してみよう
akira
はじめに
週３回のジム通いが楽しくなってきた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 |
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を手動で削除する必要があるとわかりました。
他にも制約事項が記載されていますので、合わせてご確認いただければと思います。
まとめ
タグを用いてLifecycle管理ができるのはとても便利に思います。
一方で、管理の方法を誤ると思わぬコストの増加にも繋がるため慎重に管理する必要があると思いました。
このブログがAMIを管理されている誰かのお役に立てれば幸いです。
AUTHOR
