0
0
テーマ、知りたいこと
AWSBackupやDLMを使って、AMIやボリュームのバックアップができますが、
AMIって、中身はOSとアーキテクチャですよね？
これってそもそも壊れることがあるものなんでしょうか？
もし壊れたりしても、AWSがあらかじめ用意してくれているAMIが
あるわけだし、自分でバックアップとる意味ってあるのでしょうか？
ボリュームだけのバックアップだと、どんな時に困るのでしょうか？
背景、状況
テーマや知りたいことについて、なぜ聞きたいかの背景やどういった状況かを書いてください。
詳しく記入することで、良い回答が得られやすくなります。
回答9件
#1
退会済みユーザー
総合スコア0
投稿2024/04/22 00:05
AMIは自作できるので「いろいろインストール済みのAMI」をバックアップする意味はある。
普通の用途ではAMI作ることはないのでバックアップも不要だけど。
自作AMIが流行ってたのはDocker普及前だし今はもう特殊な事例でしか使われてなさそう。
#2
総合スコア1467
投稿2024/04/22 01:41
もし壊れたりしても、AWSがあらかじめ用意してくれているAMIが
あるわけだし、自分でバックアップとる意味ってあるのでしょうか？
ソースのAMIは削除されたり、無効化されると使えなくなるので、自分でバックアップをとる意味はあるんじゃないでしょうか。
ボリュームだけのバックアップだと、どんな時に困るのでしょうか？
EC2のバックアップについては、AMIとボリュームのバックアップ（スナップショット）という二つの戦略があります。どちらもバックアップとして機能しますが、復元する際に違いがあります。
AMIにはEC2インスタンスの構成要素がふくまれますので、復元時にAMIからEC2インスタンスを作成できます。
一方、スナップショットからの復元したボリュームは、EC2インスタンスにアタッチしないと使えないので、デタッチしたりアタッチしたりする必要があると思います。また、新しいEC2インスタンスに復元する場合は復元したボリュームを使ってAMIを作成するのが推奨されています。（下記URL）
細かいことは承知してませんが、cloud-init が適切に初期化してくれるので、AMIのほうが安全なんじゃないかなって思いますね。
#3
総合スコア7595
投稿2024/04/22 02:15
AMIって、中身はOSとアーキテクチャですよね？
ドキュメントをご参照ください。
1 つまたは複数の Amazon Elastic Block Store (Amazon EBS) スナップショット、または、instance-store-backed AMI、インスタンスのルートボリュームのテンプレート (オペレーティングシステム、アプリケーションサーバー、アプリケーションなど)
AWS アカウントが AMI を使用してインスタンスを起動可能にするための起動許可
インスタンスの起動時にインスタンスにアタッチするボリュームを指定するブロックデバイスマッピング
ということで、OSとアーキテクチャだけではありません。
特にEBS-backedなインスタンスタイプであれば必ずEBSのスナップショットを含んでいます。
AMIやボリュームのバックアップができます
「AMIのバックアップ」はできません。
できるのはEBSのスナップショット取得か、EC2インスタンスのAMI作成です。
もし壊れたりしても、AWSがあらかじめ用意してくれているAMIがあるわけだし、自分でバックアップとる意味ってあるのでしょうか？
AWSが用意しているAMIには、当然のことながら用意されているものしか入っていません。
何かのツールやOSSを入れた状態で立ち上げたいのならAMIの状態で持っておいたほうが立ち上げるまでがスムーズに行えます。
EBSのスナップショットだけだと、スナップショットからAMIを作成するステップが入ります。
ただ、一方でEBSのスナップショットからAMIの作成が可能なため、データ保全が目的ならEBSスナップショットの取得で一応要件は満たせることが多いです。
バックアップの目的次第ですが、取得したものをそのままEC2として復旧させるのならAMIにしてすぐ起動できる状態にしておいたほうが大抵は復旧までの時間が短くなります。
この辺は実際にやってみるとある程度イメージが付きやすいかなと思いますね。
自作AMIが流行ってたのはDocker普及前だし今はもう特殊な事例でしか使われてなさそう。
特殊な事例でもなく、EC2を使うようなケースではよくあるゴールデンイメージパターンとして普通に現在も使われています。
確かにDockerはある程度普及しましたが、全てのユーザーがDockerを使うほどではないですし、EC2を使うケースではEC2の上でわざわざDockerを使わないことが多いです。
それならECSを使えばいいということになるので。
#6
総合スコア1467
投稿2024/04/22 21:54
AMIに何かを入れることはできるのでしょうか？
「AMIに何かをいれる」事はできませんが「何かを入れたEC2インスタンスからカスタムAMIを作る」事はできます。
EC2インスタンスをイメージ化したものがAMIですので、EC2になにかを入れて、インスタンスからAMIを作れば、自分だけのカスタムAMIが作れます。
あとから何か入れるものはすべてEBSに入るため、スナップショットのみ取ればよいかと思っております。いかがでしょうか？
たしかに、あとから入れたものは EBS ボリュームに入ります。先述しましたが、スナップショットもバックアップとして機能しますので、それで十分です。
ただ、バックアップからどのように復元するかも重要な課題です。一般的な復元のシナリオはすくなくとも２つ考えられます。
一つは、既存のインスタンスを、スナップショットの時点まで復元する場合です。この場合は、スナップショットからEBSボリュームを作成して、既存のインスタンスのボリュームを入れ替えることになります。
もう一つは、スナップショットから新しいインスタンスを起動して復元する場合です。インスタンスが停止できなくなった場合等にこの方式をとる必要が出てきます。この場合は、スナップショットからAMIを作成する方法が推奨されています。
このように、EBSスナップショットもAMIはどちらもバックアップとして機能しますが、復元方法が異なるので、復旧時間に差があります。どちらのバックアップ戦略を取るべきかは、ケースバイケースですが、普通に考えてどちらからも復元できる方がいいでしょうね。
#7
ご回答ありがとございます。
復元方法が主に以下の2つであれば、やはりAMIほ別途保持しておく（バックアップしておく）必要はないように
思うのですがその認識でよろしいでしょうか？誤って稼働中のEC2を削除したときに、AMIがあらかじめあったほうがちょっとリストア（別インスタンスとしてリストアすることは認識しております）が楽というだけのように思いました。この認識でよろしいでしょうか？
一つは、既存のインスタンスを、スナップショットの時点まで復元する場合です。この場合は、スナップショットか>らEBSボリュームを作成して、既存のインスタンスのボリュームを入れ替えることになります。
もう一つは、スナップショットから新しいインスタンスを起動して復元する場合です。インスタンスが停止できなく>なった場合等にこの方式をとる必要が出てきます。この場合は、スナップショットからAMIを作成する方法が推奨さ>れています。
#8
総合スコア1467
投稿2024/04/25 00:01
編集2024/04/25 00:03復元方法が主に以下の2つであれば、やはりAMIほ別途保持しておく（バックアップしておく）必要はないように
思うのですがその認識でよろしいでしょうか？
なにを持って必要か？なんですよね。バックアップとリストアをどうやるか、どのくらいの時間で復旧させるか、具体的なオペレーションをどうするか、などで、要不要が決まる感じです。
繰り返しになりますが、AMIもスナップショットもバックアップとして十分に機能しますので、ご質問者がAMIを使わないのであれば、AMIは不要なんだと思います。その認識が正しいかどうかはどのような要件があるか、また、ご質問者の方がどう考えたか、次第ですので、第３者としては、わかりかねるわけです・・・。（あしからず）
たとえば、AutoScaling 構成であれば、バックアップ時にAMIを保持したほうが、復旧が早い気がします。バックアップを他アカウントと共有する場合もAMIのほうが扱いやすいというのがあるでしょう。
また、マルチボリュームのEC2インスタンスをなるべく早く復旧させるには、AMIから立ち上げたほうが早いというケースもあるかもしれません。少なくとも、アタッチするボリュームを間違うというミスはなくなるような気がします。
こういったことを、どう計画して、バックアップの設計を行って、要不要を決めるという感じだと思います。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。