コラム
はじめに
通常、AWSアカウント上で構築したシステムが不要になった場合は、アカウントを閉鎖すれば利用料は発生しません。アクティブな一部のリソースについては解約後も引き続き利用料が発生する可能性がありますが、ここでは論点がずれるため詳細な説明はしないことにします。
気になる方は「AWS アカウントを解約するにはどうすればよいですか?」をご確認ください。
私がS3を使用したAMIの保存と復元を試した理由は、いつか再開される可能性のある案件で使用しているAWSアカウントの利用料を最低限に収めるためです。
EC2やRDSなどのデータは残しておき、案件が再開された場合にシステムを復元できるようにしておく必要がありました。インフラ環境のリソースそのものについてはCloudFormationテンプレートとして保持しておくことでシステムは復元できます。
しかし、EC2やRDSについてはAMIやスナップショットという形で保持していたものの、それでも毎月数百ドル程度は発生していたため、さらにコストを削減するための方法を模索しました。
AMIやRDSスナップショットのS3での保存
AMI(とEBSスナップショット)やRDSスナップショットをS3にエクスポートし、任意のタイミングでリストアできるかどうか調べてみました。
AMIのエクスポート
AMIのエクスポートとリストアには以下のAPIを利用できます。
※本記事では順に保存API、ステータス確認API、復元APIと呼びます。
-
CreateStoreImageTask
– AMI を S3 バケットに保存する。 -
DescribeStoreImageTasks
– AMI 保存タスクの進行状況を示す。 -
CreateRestoreImageTask
– S3 バケットから AMI を復元する。
これらのAPIはAWS Command Line Interface、AWS SDK、および Amazon EC2 API での使用のみサポートされており、マネジメントコンソールではサポートされていません。(2022/10/31時点)
AMIのエクスポートに関するAPIの詳細な仕様について気になる方は「S3 を使用して AMI を保存および復元する」をご確認いただければと思います。
RDSスナップショットのエクスポート
RDSスナップショットのエクスポートは、「Amazon RDS Snapshot Export」という機能を使えば実現できます。
S3に保存する際に、スナップショットのデータは Apache Parquet 形式で圧縮保存されるため、維持コストを削減できると考えました。
しかし、この機能にはリストアがサポートされておらず、今回の用途には適していないため、RDSスナップショットはエクスポートせずに保持することとなりました。
「Amazon RDS Snapshot Export」の用途は、データを低コストで維持することではなく、S3にエクスポートしたデータをAmazon Athena や Amazon Redshift Spectrum などのツールを使用して分析することとなっているようです。
AMIのエクスポートの流れ
ここからは実際にS3を使用してAMIをエクスポートしてみます。本記事ではAWS CLIを使って流れを記載します。
AMIエクスポートの準備
早速S3へのエクスポートを試したいところですが、まずはAWSアカウントに存在するAMIを必要最低限の数に整理しましょう。
日次でAMIを取得し、一定期間保持するようなバックアップ設計をしているシステムの場合は、最新の一つのみ残しておけば問題ありません。調査用やテスト用に作成したAMIなど、不要なAMIが意外と存在します。
次に、エクスポートオブジェクトを保管するためのS3バケットを作成します。
バケット名はシステムで使用するものではなく、AMIの保管用であることが分かる名称で作成してください。
AMIエクスポート
AMIの整理とS3バケットの準備ができたら、エクスポートの作業に入ります。
エクスポートには保存API「CreateStoreImageTask」を利用します。
【コマンド文法】
$ aws --profile <使用するProfile> --region <リージョン> ec2 create-store-image-task --bucket <エクスポート先のS3バケット名> --image-id <AMI ID>
<使用するprofile>や<リージョン>は必要があれば指定してください。<エクスポート先のS3バケット名>は先ほど作成したAMI保管用のS3バケット名を指定します。また、<AMI ID>はエクスポート対象のAMI IDを指定します。
実行結果は以下の通りです。
【サンプル】
$ aws ec2 create-store-image-task --bucket XX-ami-backup-yyyymmdd --image-id ami-XXXXXXXXXXXXXXXXX { "ObjectKey": "ami-XXXXXXXXXXXXXXXXX" }
上記のコマンドだけでは、エクスポート処理が正常に終了したかどうか分かりません。並行して複数の処理を実行することができるため、各処理の実行ステータスを確認する必要があります。
タスクの進捗状況の確認にはステータス確認API「DescribeStoreImageTasks」を利用します。
【コマンド文法】
$ aws --profile <使用するProfile> --region <リージョン> ec2 describe-store-image-tasks --max-items <表示する履歴の数>
<表示する履歴の数>を指定しない場合は、過去31日間に処理されたすべての保存API実行履歴のリストが表示されます。最新のタスクのみ確認する場合は1を指定しましょう。
実行結果は以下の通りです。
【サンプル】
$ aws ec2 describe-store-image-tasks --max-items 1 { "StoreImageTaskResults": [ { "AmiId": "ami-XXXXXXXXXXXXXXXXX", "TaskStartTime": "2022-10-27T05:23:05.316000+00:00", "Bucket": "ami-backup-yyyymmdd", "S3objectKey": "ami-XXXXXXXXXXXXXXXXX.bin", "ProgressPercentage": 100, "StoreTaskState": "Completed", "StoreTaskFailureReason": "" } ], "NextToken": "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ" }
処理が失敗する主な原因には
- 保存する AMI の (圧縮前の) サイズが1 TBを超えている。
- 計 600 GBを超えるスナップショットデータ保存作業が進行中である。
等があります。制約事項については第二章で示した公式ドキュメントをご確認ください。
ここでの注意点として、エクスポートするAMIの「AMI名とAMI IDのマッピング表」を作成しておいたほうが良いということです。
エクスポートの作業後はAMIを削除すると思いますが、S3バケットにエクスポートされたオブジェクトからは元のAMIの名称は分かりません。リストア作業時に困ることになるので、AMI IDから役割が分かるようにしておきましょう。
S3でのエクスポート結果確認
ステータス確認APIだけでなく、実際にS3バケットにオブジェクトが作成されているかどうかも確認します。
エクスポート先のS3バケットには「.bin」オブジェクトが作成されています。
オブジェクトの名称は、エクスポートしたAMIの「<AMI ID>.bin」で指定されるようです。
AMIとEBSスナップショットの削除
S3バケットへのエクスポート処理が完了したAMIやEBSスナップショットは削除して問題ありません。
リストアする際にEBSスナップショットも含めて新規作成されます。
ここまでの流れで、Amazon S3を使用したAMIの保存(エクスポート)については一通り説明しました。
S3バケットに.binオブジェクトの状態でしばらく保管することになりますが、システムを復活させるその時のために、AMIの復元(リストア)についても確認しておきます。
AMIのリストア
リストアには復元API「CreateRestoreImageTask」を利用します。
【コマンド文法】
$ aws --profile <使用するProfile> --region <リージョン> ec2 create-restore-image-task --bucket <リストア元のS3バケット名> --object-key <オブジェクト名> --name "<新規AMI名>"
<リストア元のS3バケット名>はエクスポート用に作成したAMI保管用のS3バケット名を指定します。また、<オブジェクト名>はリストア対象のAMIの「<AMI ID>.bin」を指定します。
<新規AMI名>は、基本的にはエクスポート実行時に作成したマッピング表に記載した元々のAMI名で良いです。
実行結果は以下の通りです。
【サンプル】
$ aws ec2 create-restore-image-task --bucket ami-backup-yyyymmdd --object-key ami-XXXXXXXXXXXXXXXXX.bin --name "demo" { "ImageId": "ami-XXXXXXXXXXXXXXXXX" }
。
ただし、公式ドキュメントの制約事項には「S3 バケットに保存されている AMI は、元の AMI ID では復元できません。」とあります。リストアまでの期間が長いとIDが他のAMIに割り当てられてしまって、「確実には元の AMI ID では復元できません。」ということなのかもしれません。
また、スナップショットに紐づくボリュームIDは忘れているようで、「vol-ffffffff」と表示されていました。
。
AMIのエクスポート処理の失敗
公式ドキュメントの制約事項に注意してエクスポート/リストア処理を行えば、基本的に処理のエラーが発生することはありません。
しかし、私が試した際には公式ドキュメントに記載のない理由でエラーが発生しましたので備忘録として記載しておきます。
今回の作業では多くのAMIのエクスポート処理を実行しましたが、何度実行してもエラーが発生するAMIがいくつかありました。もちろんデータのサイズやAMI仮想化タイプなどは、制約事項に則っていることを確認しています。
エクスポートに失敗したAMIについて眺めてみると、それらの共通点は「GPUインスタンスのAMIであること」でした。5種類のGPUインスタンスのAMIでエクスポート処理を試しましたが、全てエラーとなってしまいました。
上記のAMIについては、仕方がないのでAMIとEBSスナップショットの状態で保持しています。
こちらは公式ドキュメントや他の方のブログ等には記載がなかったため、もし原因に心当たりのある方はご教示いただけると助かります。
まとめ
今回紹介させていただいたケースでの「S3を使用したAMIの保存」の利用は少ないかもしれませんが、システムが稼働していても、少しでも安くデータを保持したいという場合にも利用できます。
EC2でコンピューティングリソースとして残す場合と比べてAMIやEBSスナップショットで保管しておくと維持コストはそもそも安くなりますが、データ量が増えてくると少しづつコストが気になってきます。
コスト削減について検討する際に、選択肢の一つとしてご活用いただけますと幸いです。
今回は以上です。
-
PICK UP
ピックアップ
-
ピックアップコンテンツがありません
-
RANKING
人気の記事
-
-
1
ハイブリッドクラウドを知る
ハイブリッドクラウドを知る
2021/09/27
-
2
【ECS/Fargate】複数のターゲットグループ…
【ECS/Fargate】複数のターゲットグループを登録したサービスのBlue/…
2022/04/28
-
3
Lambdaのマルチアカウントデプロイ 設計編
Lambdaのマルチアカウントデプロイ 設計編
2021/03/01
-
4
AWS Lake Formationで行およびセル…
AWS Lake Formationで行およびセルレベルのきめ細かなアクセス制御…
2021/12/13
-
5
Azure ADテナントとVPN Gatewayを…
Azure ADテナントとVPN Gatewayを利用してP2S VPN接続を行…
2021/08/04
-
-
ARCHIVE
アーカイブ
-
- July 2024 (1)
- January 2024 (1)
- December 2023 (2)
- June 2023 (2)
- May 2023 (1)
- April 2023 (1)
- March 2023 (2)
- February 2023 (2)
- January 2023 (1)
- December 2022 (2)
- October 2022 (2)
- September 2022 (2)