今回はバックアップとして取得「AMI」を任意S3バケットに圧縮保存（ストア）する方法について記載します。（コスト優先でAPI叩く手間があるためニッチな内容かもしれません）
AMIの保存先ってバックエンド上は最初からS3でしょ？何が言いたいの？
そうだけど、「AWSが管理するS3域」であって任意バケットではない。また、スナップショットの保存コストはS3標準クラスの2倍かかる。
うまく活用すればAMIを低コストなオブジェクトとして任意S3に保存可能です。
※2023年9月追記：2022年は対象EC2は1000GB以下でしたが、いつの間にか5000GB以下までサポートされてました！これはさらなる月額コスト削減のチャンス到来です。
以下、目次となります。
始めに
本記事で紹介するストア操作（CreateStoreImageTask）を行うと、任意のS3バケットに「圧縮コピー」されます。結果的に保存コストを平均「1/10」程度にすることが可能です。
本記事では保存エリアを次のように呼ぶことにします。
- S3(基本)：EC2サービスより確認できる圧縮前のAMI
- S3(圧縮)：S3サービスより確認できる圧縮済のAMIオブジェクト
・・・他に良い表現は無かったんだろうか。
利用ケースの1つとして考えられるのは、
使う機会は無いが長期保存しておきたいAMIがある。
だから低コストで保存しておきたい。
です。
Amazon マシンイメージ (AMI) は、ソフトウェア構成 (オペレーティングシステム、アプリケーションサーバー、アプリケーションなど) を記録したテンプレートです。
AMI作成は、対象EC2の「イメージ作成」より可能です。AMIは「ソフトウェア」＋「スナップショット」で構成されます。
Amazon マシンイメージ (AMI) を Amazon S3 バケットに保存し、AMI を別の S3 バケットにコピーして、S3 バケットから復元できます。対象APIはCreateStoreImageTask、DescribeStoreImageTasks、CreateRestoreImageTaskです。
2021年12月時点、本操作はAWSマネジメントコンソール上からは実施出来ません。よってCLI等でAPIを叩く必要があります。本記事ではCloudShellからAWS CLIを利用します。
なお、同じような機能として2021年末に発表された「Amazon EBS Snapshot Archive」がありますが、こちらはAMIに関連付いたスナップショットは未対応です。
使い方
前提条件
- CloudShellが使えること。
※今回はCloudShellでCLIを叩くため。 - 同一リージョンにS3バケットが既に存在すること。（なければ作ります）。
- 操作者の権限（ポリシー）として、対象のEC2及び済S3バケットに対し、一通りの権限を持っていること。→ 権限の詳細（具体的なポリシー）は公式サイトにあります。
API（コマンド）一覧
現時点では「3つ」あります。
| 操作 | AWS コマンド名 | 補足 |
|---|---|---|
| ストア操作：S3(基本)⇒S3(圧縮) | create-store-image-task | |
| ストア状況確認 | describe-store-image-tasks | |
| リストア操作：S3(圧縮)→S3(基本) | create-restore-image-task |
ストア操作：S3(基本)→S3(圧縮)
必須引数として「AMIID」「S3バケット名」を指定します。
aws ec2 create-store-image-task \
--image-id ami-1234567890abcdef0 \
--bucket myamibucketコマンドが正常終了すると「ObjectKey」（S3バケット内のオブジェクト名）が返ります。ObjectKeyは「元々のAMIID.bin」になります。
ストア状況は別のコマンドより確認します。基本的には100GB程度であれば10分以内に完了します。
ストア状況確認
必須引数は特にありません。直近1カ月の実施状況を確認可能です。
aws ec2 describe-store-image-tasks
リストア操作：S3(圧縮)→S3(基本)
必須引数として「オブジェクト名」「S3バケット名」を指定します。
aws ec2 create-restore-image-task \
--object-key ami-1234567890abcdef0.bin \
--bucket myamibucket \こちらについてもコマンドはすぐに終わりますが、利用可能になるまでは数分かかります。（詳細はEC2サービス＠AMIメニューのステータスより確認可能。）
制限事項
AWS公式サイトからの抜粋です（2023年9月時点）
- これらの API を使用して保存できるのは、EBS-backed AMI だけです。
- 準仮想化 (PV) AMI はサポートされていません。
- 保存可能な AMI の上限サイズ (圧縮前) は、5,000 GB です。
- 保存イメージリクエストのクォータ: 進行中の 600 GB の保存作業 (スナップショットデータ)。
- 復元イメージリクエストのクォータ: 進行中の 300 GB の復元作業 (スナップショットデータ)。
- 保存タスク中は、スナップショットを削除してはならず、保存を実行する IAM プリンシパルにはスナップショットへのアクセス権が必要です。それ以外の場合は、保存プロセスが失敗します。
- 同じ S3 バケットに AMI の複数のコピーを作成することはできません。
- S3 バケットに保存されている AMI は、元の AMI ID では復元できません。AMI エイリアシングを使用すると、これを軽減できます。
- 現在、保存 API と復元 API は、AWS Command Line Interface、AWS SDK、および Amazon EC2 API を使用する場合にのみサポートされます。Amazon EC2 コンソールを使用して AMI を保存および復元することはできません。
将来改善される可能性はありますが、現状は1TBの制限があります。・・・できれば巨大なAMIはコスト削減という観点でS3バケットに逃がしてあげたい。（けど圧縮プロセスとか大変なんだろうなぁと想像）
→ サポートに要望上げたのが届いたのかな！なんと、S3単一ファイルの上限値と同じ「5000GB」になってました！
コスト
ここでは1カ月（30日）の保存コストを比較します。AMIをS3にストアすると圧縮がかかりますが、圧縮率は私の経験を踏まえて「1/5」とします。
| 保存エリア | AMI容量 | 保存コスト($/月) |
|---|---|---|
| S3(基本) | 500GB | 500 * 0.05 = 25 |
| S3(圧縮) | 100GB | 100 * 0.025 = 2.5 |
このように「1/10」の保存コストになります。またS3のストレージクラスを「標準」→「Glaciar」等に変えてあげれば、さらにコストカット可能です。
※利用することによる特別なコスト（ストア専用コストやリストア専用コスト）はかかりません。また、リージョン内の転送となるため、転送コストも発生しません。
補足（タグ等）
- AMIをストアすると元々のタグはS3上では隠蔽されます。
- リストアすると元々のタグが復元されます。
- ストア後に付与したタグはリストア時に取り除かれます。
- AMIをストアするとAMIのnameやdescriptionはバケットオブジェクトのメタデータとして付与されます。ami nameはリストア時のオプションですが、未指定の場合はメタデータを元に復元されます。
- 自分の管理上のS3に単一ファイルとして存在するので、ローカルPCにダウンロードも可能です。
→ ・・・本当はそこからOVA形式に変換とか出来たら楽しそうですけど、もちろん出来ませんね。
補足（ストア/リストア先の削除）
例えば、S3バケットにストアした後、EC2メニューより確認可能なAMI（スナップショット含め）は削除してOKです。リストアした場合も同様です。
ただし注意する点があります。
- ストア実行後、ストア状況が100％になる前にAMIを削除すると、失敗します。
- リストア実行後も同様で、AMIステータスが「利用可能」前にオブジェクトを削除すると、失敗します。
ガードかかることを期待しちゃだめなんだね。
まとめ
AMIのS3に対するストア（リストア含む）に関してご紹介しました。消すに消せないAMIをS3に移動させることで大きくコストカット可能です。操作も簡単な為お勧めです。
将来的には、自動でこういった仕組みが利用できるようになるかもしれませんね。
最後までご覧いただき、ありがとうございました。
コメント