EC2(EBS)はオンラインではDisk容量は増やせない - ヌキのやる気のないエンジニアブログ

っぽい。管理コンソールからいろいろ見てみたけどなさそう。
これ調べた理由はEBSボリュームのsnapshotを自動で取るようにしたけど、実際それを使ってどうやって戻すんだろうかという手順知らないからちゃんと確認しただけ。

EBSについてはこちらの資料がわかりやすいと思います

※AWS歴1ヶ月ちょいの人が書いてるので間違えがあったらツッコミお願いします

1. 対象のインスタンスを確認する

ここで確認するのは「ルートデバイスタイプ」が「ebs」になっていること。
ebsタイプじゃないインスタンスはインスタンスタイプで容量が決まってるので変更できません。
あともう一つ、アベイラビリティゾーン(今後AZと略します)の確認。
今回は「ap-northeast-1a」である。
なんでAZを確認するかは後述します。

2. ボリュームから対象のEBSを選択してSnapshotを取得する

EC2の管理コンソールからボリュームをクリックするとEBSボリュームが表示されます。
Nameタグは空なのでわかりづらいですが、どのインスタンスにアタッチされているかは「アタッチ済み情報」を見るとEC2インスタンスのNameタグの名前が表示されているので、対象のEBSボリュームをクリックして選択します。
そしたら上の方にある「アクション」をクリックして「スナップショットの作成」をクリックします。

そしたら「Name」と「説明」の入力欄が出るのでわかりやすく入力してください。

「作成」をクリックするとSnapshotが作成が始まります

3. Snapshotから作成したSnapshotの確認

2で作成したSnapshotができていることをここで確認します。容量が大きいと時間かかるかも。8GBだと結構一瞬で終わります。

今度はSnapshotからボリュームを作成します。
EC2管理コンソールのスナップショットから対象のものを選びます。
2でSnapshotを作成するときにNameを指定したものを見ればわかりますが、Snapshotのボリュームの項目を見るとEBSボリュームIDが書かれているのでそこでも確認できます。同じEBSボリュームIDのものが複数ある場合は「開始」の項目を見ていつ作られたものかで確認してください。
SnapshotはS3上にあるためそのままEBSとしては利用ができません。ちなみにS3の管理コンソールを見てもEBSのSnapshotは見えないのでご注意ください。S3を使ってるのでSnapshotを取り過ぎるとそれだけお金もかかるので注意です( ･`ω･´)
対象のスナップショットをクリックして選択したら上の「アクション」から「ボリュームの作成」をクリックします。

ここでボリュームのタイプ、サイズ、AZが選択できます。
タイプは変更する必要なければ今までのものと同じものを選択し、サイズは容量を増やす場合は希望の容量を記載します。ちなみにSnapshot取得時の容量よりも少なくすることはできないので要注意です。
AZの選択は要注意です。1で容量を変更するEC2インスタンスのAZを確認したのはここで必要だからです。
今回は「ap-northeast-1a」が対象のAZだったためこのAZを選択します。
異なるAZのEBSをEC2インスタンスはアタッチすることができないため、同じAZを選択する必要があります。

「作成」を押すとEBSボリュームが作成されます。

ここでは作成されたボリュームIDは確認しておきましょう。EBSボリューム数が少なければわかりやすいですが、アタッチされてないものが多いと行方不明になります。
(ボリュームのNameタグの入力項目くらい作って欲しいものです)

4. 作成したEBSボリュームをEC2にアタッチして容量を増やす

3で作成したEBSボリュームを確認します。

ここで見るべきは「状態」です。「In-use」の場合はEC2インスタンスにアタッチ済みになります。「available」の場合はどのEC2インスタンスからもアタッチされていないので利用可能です。
今8GBのボリュームがアタッチされていて、30GBのボリュームはアタッチされていないものになります。
このままではEC2に割り当てるボリュームを付け替えられないので、まずは対象のEC2インスタンスを停止します。

インスタンスから対象のEC2インスタンスを選択して「アクション」から「インスタンスの状態」→「停止」を選択します。
OS自体がシャットダウンされるので、サービス影響があるEC2インスタンスの場合はメンテナンス等に振るか、ELBから外して影響ないようにします。
EC2インスタンスを停止したら今度は、今までアタッチしていたEBSボリュームをデタッチ(外す)します。

外れない場合は「強制デタッチ」してもいいかも。でも「デタッチ」でエラーになる場合はEC2インスタンスがちゃんと停止されてない可能性があるのでちゃんと確認します。
デタッチをするとEC2インスタンスの「ルートデバイス」の項目と「ブロックデバイス」が「-」になります。
インスタンスの管理画面で確認するとこんな感じです。

デタッチができたら、今度は容量を増やしたEBSボリュームをアタッチします。
対象のボリュームを選択して上の「アクション」から「ボリュームのアタッチ」を選択します。

どのインスタンスにアタッチするかの項目とデバイスのPATHを入力するように求められます。
インスタンスはNameタグのものを入力するとサジェストされるのでインスタンスIDを覚える必要はありません。インスタンスにNameタグがついてない場合はインスタンスIDを確認して入力してください。
デバイスPATHは1で確認したものを入力します。今回は「/dev/sda1」でした。
「アタッチ」をクリックするとインスタンスにこのボリュームがアタッチされます。

アタッチするとボリュームの「状態」の項目が「In-use」に変わってるはずです。

5. アタッチしなおしたものになっているか確認する

EC2インスタンスのルートデバイスをクリックするとボリュームIDが表示されるので、新しいボリュームIDになっているのを確認します。

あとはインスタンスを起動してあげたら容量が変わっています。
ﾜｰｲヽ(ﾟ∀ﾟ)ﾒ(ﾟ∀ﾟ)ﾒ(ﾟ∀ﾟ)ﾉﾜｰｲ

まとめ

Snapshotを作成した後のファイル等は移行できないので、完全にインスタンスをサービスアウト(ファイル等更新されないようにする)してから本作業をすることをおすすめします。
更新されても捨てれるようなものだったらいいですが。
インスタンスを停止している状態からでも本作業は可能ですので、EBSを付け替える前にインスタンスを停止しておいた方がいいかも。差異がなくなるので。
容量を増やすのは割と簡単なので本番環境だからといって最初からガツンと容量を当てるのではなく、スモールスタートで容量を決めて後から必要になったら容量を増やす運用にするとコスト削減ができるのではないかと思います。

定期的にEBSのバックアップを取っている場合は3の作業から実施すればバックアップから復旧させることが可能ですので、手順としては同じになります。

追記

AMIがLVMを使っている場合上記手順だけではボリュームが増えませんでした。

下記スクリプトを作ってrootユーザで実行したらボリュームが増えました。
再起動(reboot)がかかるので気をつけてください。

 #!/bin/sh
DEVICE=/dev/xvda

RCLOCAL=/etc/rc.d/rc.local
# modify partition table

fdisk ${DEVICE} <> ${RCLOCAL}

echo -n 'lvresize -l +100%FREE /dev/VolGroup/lv_root && ' >> ${RCLOCAL}

echo -n 'resize2fs /dev/VolGroup/lv_root && ' >> ${RCLOCAL}

echo -n 'sed -i -e '\''$d'\'' /etc/rc.d/rc.local ' >> ${RCLOCAL}
reboot

ハマったのは

echo -n 'pvresize /dev/xvda1 && ' >> ${RCLOCAL}

の部分が配られてるスクリプトだとxvda2だったので適用されず、手動でxvda1に変更したら反映されました。