カスタマーサクセス部 佐竹です。
本日は表題の通り、コスト最適化のために有効な「Amazon EBS Snapshots Archive」と「Recycle Bin」を組み合わせて AMI と紐づく EBS Snapshot をアーカイブする方法について記載します。
サービスとサービスを組み合わせる利用方法のため、少し理解が難しいかもしれませんが丁寧に解説していきます。
- はじめに
- Snapshots Archive の運用上の課題
- 「ごみ箱 (Recycle Bin)」が AMI の削除に対応
- AMI だけを「ごみ箱」に入れ制約を回避する
- コストに関する補足事項
- 動作確認
- まとめ
はじめに
Amazon EBS Snapshots Archive は、 EBS Snapshot を S3 Glacier と同様のアーカイブ層に移動させることにより Snapshot の費用を圧縮し、コスト削減が可能な機能としてリリースされました。
詳しくは以下にある弊社ブログ記事を参考ください。
Snapshots Archive の運用上の課題
Amazon EBS Snapshots Archive はコスト削減の視点から、長期間保存する EC2 インスタンスのバックアップとして利用したいという要望が多い機能です。
ただし、1点運用上の課題(問題点)があります。それは「AMI と紐づけされている EBS Snapshot はアーカイブできない」という仕様です。
実際に、AMI と紐づけがある EBS Snapshot をアーカイブしようとすると、上記エラー Failed to archive snapshot. snap-0e53ece8baf6d1aaf: The snapshot snap-0e53ece8baf6d1aaf is currently in use by ami-004d3faccbebfb2b0
が発生してしまいます。
このため、AMI と 紐づいている EBS Snapshot には Archive 機能が利用できません。これは、以下の公式ドキュメントにも記載がある制限事項です。
- Amazon EBS-backed AMI に関連付けられているスナップショットは、アーカイブできません。
この制約を回避するために、Snapshot と紐づけ状態にある AMI を削除(Deregister )してしまうと、Windows や RHEL を利用している場合に EC2 インスタンスのバックアップとして利用できなくなってしまいます。つまり、EC2 インスタンスを作成(Launch)できなくなってしまうわけです。
データボリューム(Dドライブ以降のドライブ)のみを保存したいという「AMI なしにそれ単体で運用している EBS Snapshot」に対しては Archive を利用可能ですが、お客様は EBS Snapshot を EC2 インスタンスのバックアップ AMI と共にセットで利用されている場合が大半です。
このような状況から「Amazon EBS Snapshots Archive」は実際問題として使えない、という結論になってしまっているのが現状です。
「ごみ箱 (Recycle Bin)」が AMI の削除に対応
しかし、以下の機能アップデートにより、その懸念点を払拭することが可能となりました。その機能アップデートとは「ごみ箱」が AMI の削除にも対応したことです。
上記ブログで詳細に解説しております通りですが、「ごみ箱」機能を有効化することで、EBS Snapshot だけではなく、AMI も「ごみ箱」に入るようになりました。
これにより、AMI と EBS Snapshot をセットで「ごみ箱」へ移動させることが可能となりました。そのため、誤って削除した AMI や Snapshot を期限内であれば元通り復活させることができるようになっています。
今回はこの機能を利用していきます。
AMI だけを「ごみ箱」に入れ制約を回避する
「ごみ箱」が AMI の削除に対応したため、AMI を論理的に削除可能となりました。
このため、AMI を「ごみ箱」に入れ論理的に削除することで、AMI と 紐づいている EBS Snapshot には Archive 機能が利用できない という制約を回避することが可能となります。
具体的な利用手順としては以下の通りです。
AMI を保持したまま EBS Snapshot をアーカイブする手順
- 「ごみ箱」機能を有効に設定する
- 紐づく AMI を削除する (AMI は「ごみ箱」へと移動する)
- EBS Snapshots Archive で、対象の Snapshot をアーカイブする
アーカイブした EBS Snapshot を AMI として再利用する手順
- EBS Snapshots Archive から、対象の Snapshot を Restore しスタンダード階層へ戻す
- AMI を「ごみ箱」から Recover する
動作確認を行ったところ、AMI として再利用する場合はこれらの手順はどちらが先でも問題ありませんでした。
注意事項及び制約
- AMI を論理的に削除する前に EBS Snapshot をアーカイブすることはできません
- 「ごみ箱」の最低保存期間は1日、最大保存期間は365日ですため、保存期間を越えた AMI は完全に削除されてしまう点に注意してください
- EBS Snapshot のサイズによっては、アーカイブされた Snapshot をアーカイブ階層からスタンダード階層に復元するのに最大72時間かかる場合があります
注意事項を踏まえた改善手順
上記手順の問題は、「ごみ箱」に移動させた AMI が最長1年(365日)で全て消えてしまうという点です。これを払拭するには以下の改善手順が有効と考えられます。
- 「ごみ箱」機能を有効に設定する
- 紐づく AMI を削除する (AMI は「ごみ箱」へと移動する)
- EBS Snapshots Archive で、対象の Snapshot をアーカイブする
- AMI を「ごみ箱」から Recover する
このように「AMI の Recover を早期に行う」手順とすることで、AMI を保持したまま Snapshot だけをアーカイブすることが可能となります。
改善手順の注意事項及び制約
- AMI を「ごみ箱」から Recover した後、Snapshot をアーカイブ階層から復元せずに AMI を構築に使用した場合、EC2 インスタンスはエラーなく作成されますが即時 Terminate されてしまいます
このような動作になる理由は、Root ドライブ(Cドライブ)が存在しない EC2 インスタンスが作成されるためです。
このため、本運用を行う中で AMI を構築等に利用される場合には、紐づく Snapshot がアーカイブされているかどうか予め確認の上 AMI を利用されることを推奨します。
コストに関する補足事項
EBS Snapshots Archive の最小保存期間は90日です。
90日間より前にアーカイブされたスナップショットを削除または永続的に復元すると、アーカイブ階層の残りの日数に対して請求されます。例えば、40日で永続的に復元した場合は、50日分の費用が請求されることになります。
そのため、本手順でアーカイブされた EBS Snapshot の Restore においては、復元タイプの「永続(permanent)」と「一時(temporary)」のうち「一時(temporary)」を利用されるほうがコストの観点からは最適です。
動作確認
マネジメントコンソールから上記手順を画面キャプチャと共に改めてご紹介します。
今回の検証に利用する AMI は ami-0198a349835f077ed
です。これに紐づく Snapshot として snap-0a7a91128d2020b5f
を1つのみ保持しています。
作成されたばかりの AMI に紐づく Snapshot は、Storage tier = Standard に所属します。今回は AMI を保持したまま、Snapshot をアーカイブしていきます。以下、手順通りに続けます。
1.「ごみ箱」機能を有効に設定する
先のブログでご紹介した内容と重複することと、以前の検証記事で「ごみ箱」機能は既に設定済となりますため、本ブログ内では割愛させて頂きます。
「ごみ箱」に移動するには、同コンソール画面の右上からジャンプする方法が便利です。
既存の設定を修正し、AMI が「ごみ箱」に入るようにするためには「Retention settings」で「Apply to all resources」を押下すると簡単に設定が可能です。AMI と EBS Snapshot で別のルールを取り決めたい場合は、既存の設定を修正するのではなく、新しく別のルールを作成ください。
2. 紐づく AMI を削除する
「ごみ箱」が有効化されている状態で、AMI を削除(Deregister)します。
成功すると以下の通りの表示がされ、AMI が一覧から消えます。
この状態で「ごみ箱」を見に行きます。
「ごみ箱」内で削除した AMI が確認できました。
3. EBS Snapshots Archive で対象の Snapshot をアーカイブする
先の手順で AMI は論理的に削除されましたので、EBS Snapshot がアーカイブ可能となりました。実際にアーカイブしていきます。
「Archive Snapshot」を押下し、対象の Snapshot をアーカイブします。
アーカイブが完了するには少々時間がかかります。進捗状況は「Tiering status」と「Tier change progress」で状況が把握できます。
参考までですが、アーカイブティアへの移動の開始と終了は以下の通りでした。容量は 30 GiB です。
- 開始:Wed Jun 08 2022 17:03:50 GMT+0900 (日本標準時)
- 終了:Wed Jun 08 2022 17:28:43 GMT+0900 (日本標準時)
アーカイブにかかった時間は、およそ25分でした。
「Archival completed」となれば完了です。
4. AMI を「ごみ箱」から Recover する
現在は以下の状況になっています。
- AMI:ごみ箱
- EBS Snapshot:アーカイブ
このままだと、時間経過で AMI が完全削除されてしまうため「ごみ箱」から取り出します。
ami-0198a349835f077ed
を検索し、「Recover resources」を押下します。
成功すると、AMI が「ごみ箱」の一覧から消えます。次いで、EC2 のコンソールから確認します。
AMI が EC2 のコンソールから確認できました。元通り戻ってきています。これで、AMI は残存したままに EBS Snapshot だけをアーカイブすることができました。
Snapshot がアーカイブされている AMI でインスタンスを構築した場合
先に記載した通り、EBS Snapshot がアーカイブされている AMI で EC2 インスタンスを構築した場合は、EC2 インスタンスはエラーなく作成されますが即時 Terminate されてしまいます。
このように一見成功しているように見えるのですが・・・
この通り、インスタンスを確認すると「Terminated」となっています。注意してください。
5. アーカイブされた Snapshot をスタンダード階層へ戻す
AMI を正常に動作させるには、AMI に紐づく Snapshot をスタンダード階層に戻す必要があります。
snap-0a7a91128d2020b5f
を選択し、メニューから「Restore snapshot from archive」を押下します。先に記載しました通り、コスト最適化の観点から、Restore は「Temporary」で実施します。
成功すると、再度待ち時間が発生します。
参考までですが、スタンダードティアへの移動の開始と終了は以下の通りでした。容量は同様に 30 GiB です。
- 開始:Wed Jun 08 2022 17:57:03 GMT+0900 (日本標準時)
- 終了:Thu Jun 08 2022 23:57:33 GMT+0900 (日本標準時)
アーカイブするのは25分でしたが、リストアは6時間くらいかかっています。
なお、スタンダードティアへの一時的なリストアは終了時間がコンソールから閲覧できません。
ただし Temporary restore expires on
が Thu Jun 09 2022 23:57:33 GMT+0900 (日本標準時)
となっており、かつ今回は「1日」の設定でリストアしたため、移動完了は Temporary restore expires on
マイナス1日となりますので、終了時間を Thu Jun 08 2022 23:57:33 GMT+0900 (日本標準時)
と記載しております。
正常に AMI が利用可能か EC2 インスタンスを作成し確認する
一時的に Snapshot をリストアした AMI で EC2 インスタンスの構築を試みます。
Snapshot がリストアされていれば、AMI は問題なく利用できますため上画像の通りインスタンスを正常に構築することができています。
これで本オペレーション全体の動作確認は完了です。
まとめ
本ブログでは、Amazon EBS Snapshots Archive と Recycle Bin を組み合わせて AMI と紐づく Snapshot をアーカイブする方法について記載しました。
手順としては以下の通りです。
- 「ごみ箱」機能を有効に設定する
- 紐づく AMI を削除する (AMI は「ごみ箱」へと移動する)
- EBS Snapshots Archive で、対象の Snapshot をアーカイブする
- AMI を「ごみ箱」から Recover する
- AMI を構築に利用する場合は、アーカイブされた EBS Snapshot を Restore しスタンダード階層へ戻す ※オプション
本手順の通り実行することで、AMI を残したまま EBS Snapshot をアーカイブすることが可能です。
オペレーションの実現性
ただ、正直なところ運用上煩雑な手順が必要であることから、この手順をバックアップオペレーションの一部として運用することは「可能だとしても避けたほうが良いのでは」とも感じます。
費用対効果次第ですが、AMI を長期間保存する必要があり、75% のディスカウントが追加の(煩雑な)オペレーションコストを上回るのであれば導入を検討されても良いでしょう。
また、これらの動作が意図されたものかどうか AWS サポートに確認したとろ、「ごみ箱」の機能は「あくまで誤って削除されたリソースを復元することを可能にする機能として利用することを推奨」と回答がありました。
よって、本操作を運用として行われたい場合は、ここまで記載した情報を踏まえた上で、十分な検証期間を設けたのちに実行頂ければと考えております。
AWS への今後の期待
最後にですが、「AMI と共に EBS Snapshot をアーカイブしたい」というエンドユーザ様からのご意見により、今後 AWS が同様の動作を一般的な機能として提供する可能性があります。
私も可能であれば、記載した複雑な操作なしに「AMI と共に EBS Snapshot をアーカイブしたい」と思います。今後アップデートがあり、煩雑な操作が不要となることを期待しながら、本ブログを終えたいと存じます。
では、またお会いしましょう。
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 AWS Ambassadors/2023-2024 Japan AWS Top Engineers/2020-2024 All Certifications Engineers。AWSのコスト削減、最適化を得意としています。