今後使うのか、使うのかもわからないフルバックアップの AMI を理由あって半永久的に残す必要がある場面はありませんでしょうか。
AMI を S3 へ保存できるならいっそのこと S3 Glaicer Deep Archive で AMI を塩漬けにしても問題ないのか気になったので確認しました。
せっかく試すなら最安価を目指して北米リージョンの S3 Glaicer Deep Archive を利用します。
確認結果
S3 Glacier Deep Archive に保存した AMI を復元して EC2 インスタンスとして起動できました。
- S3 へ保存した AMI のオブジェクトを S3 Glaicer Deep Archive にできる
- S3 Glacier Deep Archive から AMI のオブジェクトを AMI へ戻せる
- AMI に戻した AMI から EC2 インスタンスの起動できる
可能な限り安いところに保存してみる
フルバックアップの AMI として通常保存しておくよりも 98% OFF で利用できる北米リージョンの S3 Glaicer Deep Archive を採用します。
- 容量単価（東京リージョン、2023/07/18時点）
- AMI（EBSスナップショット）
- スタンダード: $0.05/GB/月
- S3
- Standard: $0.025/GB
- 50% OFF
- Glacier Deep Archive: $0.002/GB
- 96% OFF
- Glacier Deep Archive: $0.00099/GB（バージニア北部）
- 98% OFF
- Standard: $0.025/GB
- AMI（EBSスナップショット）
仮に AMI の容量が 2 TB あった場合、長期保存を前提として東京リージョンで AMI のまま保持すると $100/月かかります。 北米リージョンの S3 Glaicer Deep Archive を利用すると $1.98/月で済む計算です。
保存までの流れ
東京の AMI を東京の S3 へコピー
aws ec2 create-store-image-taskコマンドで AMI を S3 へ保存します。
- 対象とする AMI ID:
ami-013dd3f5c1a8888b9 - 保存先の S3 バケット:
ami-archives-tokyo
create-store-image-task — AWS CLI 2.13.1 Command Reference
aws ec2 create-store-image-task \
--image-id ami-013dd3f5c1a8888b9 \
--bucket ami-archives-tokyo実行結果
{
"ObjectKey": "ami-013dd3f5c1a8888b9.bin"
}aws ec2 describe-store-image-tasksコマンドで AMI から S3 への保存の進捗状況を確認します。
describe-store-image-tasks — AWS CLI 2.13.1 Command Reference
aws ec2 describe-store-image-tasks実行結果
{
"StoreImageTaskResults": [
{
"AmiId": "ami-013dd3f5c1a8888b9",
"TaskStartTime": "2023-07-18T02:01:12.394000+00:00",
"Bucket": "ami-archives-tokyo",
"S3objectKey": "ami-013dd3f5c1a8888b9.bin",
"ProgressPercentage": 100,
"StoreTaskState": "Completed",
"StoreTaskFailureReason": ""
}
]
}S3 バケットを確認します。aws ec2 create-store-image-taskコマンドの実行結果で表示されたObjectKeyの値の名前で AMI が保存されました。
AMI は S3 へ移動ではなくコピーという扱いですAMI は削除されずオリジナルの AMI はいつもの AMI の画面に残ります。目的次第ではありますが S3 へ保存後は AMI は削除しないと AMI 保存料は発生し続けますね。
EC2 の EBS が圧縮されてスナップショットになった容量を確認する手段は用意されていませんが、AMI を S3 へ保存することで間接的に容量を確認できることを知りました。
補足
東京リージョンにある AMI を北米リージョンにある S3 バケットへ保存を試みて失敗した記録です。
AWS CLI を実行する環境のAWS_DEFAULT_REGION=ap-northeast-1となっている場合
An error occurred (InvalidRequest) when calling the CreateStoreImageTask operation: The bucket is in this region: us-east-1. Please use this region to retry the request (Service: Amazon S3; Status Code: 301; Error Code: PermanentRedirect; Request ID: WTDSDXWKDJY1EZTR; S3 Extended Request ID: ZT5WUAqccIQ4UzigmsRYXpDLAShH9aj5aGCrRCJ/LwgObYsfQwGJ9PT/G/IetmBl/V9fNTB7WYg=; Proxy: null)AWS CLI を実行する環境のAWS_DEFAULT_REGION=us-east-1となっている場合
An error occurred (InvalidAMIID.NotFound) when calling the CreateStoreImageTask operation: The image id '[ami-013dd3f5c1a8888b9]' does not exist以上の結果から東京リージョンにある AMI を東京リージョンにある S3 バケットへ一度保存してから、北米リージョンの S3 バケットへ移動することとしました。
東京の S3 から北米の S3 へ移動
マネージメントコンソールから操作します。
北米リージョンに作成した S3 バケットを送信先と指定しました。
移動が完了しました。移動が完了するまでブラウザのタブを閉じることができませんでした。移動するオブジェクトのサイズ次第ではありますが、AWS CLI で操作する方が望ましい操作でした。
北米リージョンの S3 バケットで AMI のオブジェクトが保存されていることを確認できました。
北米リージョンの S3 で塩漬けにする
ストレージクラスをスタンダードから Glacier Deep Archive へ変更します。
Glacier Deep Archive を選択しました。
ストレージクラスが Glacier Deep Archive となりました。
以上の手順で AMI のフルバックアップを安価に長期保存することに成功しました。
次は塩漬けにした AMI を EC2 インスタンスに戻せるか確認します。
AMI を S3 に保存したときの管理について
S3 に保存した AMI のオブジェクトのメタデータを確認すると、AMI の名前と、説明欄がそのままメタデータとして記録されていました。通常の AMI の確認画面でも確認したい情報は S3 に AMI を移しても引き継がれていました。これはありがたいですね。
AMI を解凍して復元してみる
引き続きマネージメントコンソールで操作できる作業はマネージメントコンソールから実施します。本来であれば 3 年は寝かせてから試したいところなのですが時間の都合、5分程度の浅漬け状態の AMI を Glaicer Deep Archive から取り出します。
標準取り出しで復元して放置します。
通常12時間以内で復元できます。ですので待つだけです。
一晩放置して翌日確認したら復元に成功していました。
Glaicer Deep Archive から復元したオブジェクトは S3 間の移動操作ができませんでした。
ダウンロード・アップロード
マネージメントコンソールからの移動操作はできませんでした。AWS CLI で一度ローカル PC に北米リージョンにある復元したオブジェクトをダウンロードし、東京リージョンの S3 へアップロードし直します。
ローカル PC までダウンロードすると AWS からのインターネットアウト代（データ転送料金）が発生します。AMI の容量次第では S3 VPC エンドポイント経由の EC2 インスタンスで作業するなど作業環境は考えた方が良いです。
# 北米リージョンの S3 からダウンロード
$ aws s3 cp s3://ami-archives-northern-virginia/ami-013dd3f5c1a8888b9.bin .
download: s3://ami-archives-northern-virginia/ami-013dd3f5c1a8888b9.bin to ./ami-013dd3f5c1a8888b9.bin
# 東京リージョンの S3 へアップロード
$ aws s3 mv ./ami-013dd3f5c1a8888b9.bin s3://ami-archives-tokyo
move: ./ami-013dd3f5c1a8888b9.bin to s3://ami-archives-tokyo/ami-013dd3f5c1a8888b9.binaws ec2 create-restore-image-taskコマンドで東京リージョンの S3 に保存してある AMI を本来の AMI の居場所へ戻します。
aws ec2 create-restore-image-task \
--object-key ami-013dd3f5c1a8888b9.bin \
--bucket ami-archives-tokyo \
--name PClusterManager-backup-s3-restore実行結果
{
"ImageId": "ami-0c258e9b0bdb177de"
}新しい AMI ID で登録されていました。
この AMI からインスタンスを起動してみます。
補足
S3 から AMI へ戻すときのエラー例です。--nameで指定する AMI 名がすでに存在している AMI 名と重複していると以下のエラーになります。
aws ec2 create-restore-image-task \
--object-key ami-013dd3f5c1a8888b9.bin \
--bucket ami-archives-tokyo \
--name PClusterManager-backupオリジナルの AMI と同じ AMI 名を指定して失敗しました。
エラーメッセージ
An error occurred (InvalidAMIName.Duplicate) when calling the CreateRestoreImageTask operation: The AMI name is taken. Specify a different AMI name.PClusterManager-backupEC2 へログイン
セッションマネージャーで接続可能な IAM ロールを付与して EC2 インスタンスを起動させました。
今回テストに利用にした AMI は昔 ParallelCluster の作業端末として使っていたインスタンスでした。当時利用していた ParallelCluster のコマンドのバージョンを確認できました。
> pcluster version
{
"version": "3.1.4"
}古いファイルも確認できました。Glacier Deep Archive から復元した AMI でも問題なく起動できました。
> ll
total 0
drwxr-xr-x 3 ec2-user ec2-user 78 Oct 21 2021 aws
drwxr-xr-x 9 ec2-user ec2-user 106 Jun 2 2022 parallelcluster-configs
drwxrwxr-x 8 ec2-user ec2-user 72 May 28 2022 pclusterVersionおわりに
EC2 として起動するまでに最大12時間弱は見ておく必要がありますが、いつ使うかわからないけど長期保存しないといけない事情があるときの方法として利用できるのではないでしょうか。マネージメントコンソールから試して問題ないことが確認できたので、まともに検討するなら AWS CLI か SDK で作業した方が良い作業という感想です。
本検証は研究のために使用した実行環境（ソフトウェアのバージョンなど）をまるっと一式、10 年間保存しておくための安価な保存方法の検証でした。解析結果のデータは別個で S3 へ保存してしまえば良いのですが、あとあと論文執筆時に、当時利用したアプリケーションのバージョン（実行環境）をもしかしたら確認するかもとなると AMI を安価に保存できた方が望ましいことでしょう。
研究データも含む AMI なら法規制対応でオブジェクトロックと合わせて検討したいところです。
個人的には AMI を S3 へ保存することで AMI（スナップショット）の容量を知ることができたのが発見でした。
21
