AWSのディスク容量拡張の方法の使い分け

Question

AWSのディスク容量追加に関しての方法を調べていたところ3つの方法が出てきたのですが、使い分けがよくわかりません。

1.ボリュームを新しくアタッチする
2.ルートデバイスボリュームの容量を上げる
3.新しくボリュームを作り、既存ボリュームと入れ替える

※前提としてEBSベースのAMIから起動したインスタンスの場合です。

この3つの違いというか、使い分けがよくわからずに理解できていません。

それと、2に関してですが、ルートデバイスボリュームと他のボリュームの違いもわかっていないかもしれないです。このドキュメント
を見る限りは区別して扱われているようですが、ルートデバイスボリュームとそれ以外のボリュームって何がちがうんでしょうか？

ルートデバイスボリュームは単純にAMIに最初からあるボリュームというだけで、役割自体はあまり変わらないんでしょうか？

3つのディスク容量追加とルートデバイスボリュームの役割について、ご回答いただけたら幸いです。

また、的はずれな発言や足りない情報などあればご指摘ください。

Answer 1

もう少しドキュメントを読みましょう…と言いたいところですが、たしかにドキュメントが分かりづらいのは否めないですね。

ルートデバイスボリュームは、インスタンス作成の際に元となるストレージの事を差しています。

AWSのドキュメントからの引用

インスタンスを起動するときは、ルートデバイスボリュームに格納されているイメージを使用してインスタンスがブートされます。

また、EC2のコンソールでルートデバイスの当たりにカーソルを持っていくとこのような説明が出ます

ブートボリュームを格納するシステムデバイス名 (例: /dev/sda1) 。詳細については、デバイス名を参照してください。

なのでブートボリュームが格納されているストレージデバイスをルートデバイスと呼んでいる、と言えるかなと。
今回はEBS-Backedが前提としていますが、インスタンスストアがあるタイプのインスタンスを立ち上げたらインスタンスストアがルートデバイスになるかと思います。

EBS-Backedであることを前提とした上で上記を踏まえると、１〜３は下記のように説明できます。

1. ルートデバイス以外の別のEBSをアタッチする
2. ルートデバイスとして指定しているEBSの容量を追加する
3. 容量の大きい別のEBSを用意し、今ルートデバイスとして使用しているEBSと入れ替える

3をやるくらいならAMIを取得してインスタンスを作り直し、その際に容量を大きくしたほうが簡単な気がしますが…。

Comments

[copykun_]

ありがとうございます！
とても助かります。

特に挙げた選択肢をより正しい表現に変えていただけたのはわかりやすいです。

ベストアンサーにさせていただきましたが、もう1点質問です。もしよろしければご回答いただければと思います。

この場合
1と2の使いわけってどうなっているんでしょうか？
ルートデバイスボリュームにはブートボリューム以外は入れずに、
たとえばログファイルなど全く別の目的のデータを入れる容量を増やしたいときなどには2ではなく1の手法を選択するという認識でしょうか？

あるいは、ボリュームタイプやタイプごとの料金などを考えた上で決めたり、別のインスタンスにアタッチするケースなども想定して決めたりするという感じでしょうか？
（言い換えれば何も考慮せずにとりあえず容量が増えれば良いのであれば、なんでも良い）

[yu_1985]

1のようにあえてEBSを分けるとするなら、EBSをデタッチして別のインスタンスにアタッチすることで割と簡単にデータを移行できるというメリットがあります。
なので、なにか障害が起こってインスタンスを落とさざるを得なくなったときに変わりのインスタンスを立ち上げてそちらに移し替える、というのがスムーズに行なえます。
2の場合はただサイズを大きくすればいいのでバックアップを取るときも一つのEBSだけ取ればいいので管理上わかりやすくはあります。
簡単とは言ってもいずれもファイルシステムがきちんと増えたボリュームを認識できるようにOS上で操作が必要ですが…。

個人的には、そもそもローカルストレージ上にものを置くのは最低限にして、容量が大きくなるようなものは極力別のところに置くことを推奨します。
用途によっては避けられないことはもちろんありますが…。

[copykun_]

なるほど、とてもわかりやすいです！ありがとうございます！！