【AWS】EC2に紐づくEBSボリュームを差し替える

## はじめに
AWS上で構築していたGNS3サーバ（UbuntuOS）の2台目が必要になったので、AMIを取得して複製したところ、インスタンスのステータスチェックが失敗しました。
<img width="800" alt="20201128_EC2のボリューム差し替え_01.PNG" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/873566/56f319ce-e27f-0852-7f88-4f1522a83f89.png">
これまでに1,2回しか出会ったことがない事象、たまたまかな？と思いEC2を停止起動したり、AMIを取得しなおして再作成してもダメでした。
色々調べた結果、起動に失敗するEC2のEBSを正常なEC2に紐づけて、/var/log/messages を確認してみることにしました（AWSコンソール上で見ることができるシステムログは確認済み）


## 目次
1. [EC2からEBSをデタッチする](#Chapter1)
1. [問題のあるEBSを正常なEC2にアタッチする](#Chapter2)
1. [EC2にログインし原因調査](#Chapter3)
1. [システムログを確認する](#Chapter4)
1. [さいごに](#finally)
1. [参考文献](#reference)


<a id="#Chapter1"></a>
## 1.EC2からEBSをデタッチする
EC2にアタッチされているEBSボリュームをそれぞれデタッチします。
<img width="500" alt="20201128_EC2のボリューム差し替え_02.PNG" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/873566/1de875e6-a2e8-f2fe-706f-159d6a28dedf.png">



<a id="#Chapter2"></a>
## 2.問題のあるEBSを正常なEC2にアタッチ
...しようと思っていましたが、AZが異なるためそのままではアタッチできないことが判明...
仕方がないので、一度EBSボリュームからスナップショットを作成して、さらにそのスナップショットからボリュームを再作成する際に別AZを指定することで、解決しました。
<img width="800" alt="20201128_EC2のボリューム差し替え_04.PNG" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/873566/52a0a140-d536-d592-5ce2-a102146ff7db.png">
<img width="500" alt="20201128_EC2のボリューム差し替え_07.PNG" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/873566/3a322360-09b5-e73b-eeab-160f08e73a23.png">

ちょっと遠回りしましたが何とかアタッチできたので、EC2を起動しました。
なお、ボリュームをアタッチする際はデバイスを`/dev/sda1`に変更しないとEC2が認識してくれません（ルートデバイス名はEC2のストレージタブにて確認）
<img width="800" alt="20201128_EC2のボリューム差し替え_09.PNG" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/873566/7825889b-bc9f-726d-c406-e0137397f3e6.png">



<a id="#Chapter3"></a>
## 3.EC2にSSHログインする
EC2が問題なく起動してくれたので、SSHでログインします。
鍵が一致しないと警告が出てしまいましたが、鍵の上書きはせずに続行をクリック。
<img width="300" alt="20201128_EC2のボリューム差し替え_10.PNG" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/873566/82b747d0-85f7-c80f-22e5-e859a423891b.png">
なお、鍵を上書きしなかったせいなのかは分かりませんが、ユーザ名/パスワードではSSHもRDPも失敗したため、pem鍵を使用してログインしました。


<a id="#Chapter4"></a>
## 4.ログを確認する
「あれ、/var/log/messagesがない...？」と思って調べたら、Ubuntuは/var/log/syslog を見るらしい。勉強になります。

参考：[見るべきログを知っておく (/var/log/ 配下のファイル紹介)]
(https://mekou.com/linux-magazine/%E8%A6%8B%E3%82%8B%E3%81%B9%E3%81%8D%E3%83%AD%E3%82%B0%E3%82%92%E7%9F%A5%E3%81%A3%E3%81%A6%E3%81%8A%E3%81%8F-var-log-%E9%85%8D%E4%B8%8B%E3%81%AE%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E7%B4%B9/)

ログの場所も把握して、いざ/var/log/syslogを確認したのですが...
原因がさっぱりわかりません。amazon-ssm-agentの起動に関してERRORが出ていることは確認できましたが、あまり関係無さそう。


ただ、ここにきて「問題のあると思われるEBS」を正常なEC2にアタッチして無事起動できているということは、問題があるのはEBSではなくEC2の方では？ということに気づきました。
てことで元々正常なEC2にアタッチされていたEBS（からスナップショットを作成⇒別AZにてボリューム作成したもの）を疑惑の出たEC2にアタッチして、起動すると...
<img width="800" alt="20201128_EC2のボリューム差し替え_11.PNG" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/873566/8635eb58-b213-b3fc-2460-2e1784ecd883.png">

やはり失敗しました。今回悪いのはEBSではなくEC2（もしくはAMI）みたいです。
ただ、AMI取り直しも、AMIからEC2作成も何度か試していて毎回失敗するので、もしかしたら別の要因があるかもしれません（進展あれば適宜更新）

<a id="#finally"></a>
## さいごに
EBSボリュームを別AZに存在するEC2にアタッチする場合、一旦スナップショットを作成して回避する、などは今後も使えそうだなと思いました。

<a id="#reference"></a>
## 参考文献
本記事はこちらの文献を参考に執筆しました。この場を借りてお礼申し上げます。

- [見るべきログを知っておく (/var/log/ 配下のファイル紹介)](https://mekou.com/linux-magazine/%E8%A6%8B%E3%82%8B%E3%81%B9%E3%81%8D%E3%83%AD%E3%82%B0%E3%82%92%E7%9F%A5%E3%81%A3%E3%81%A6%E3%81%8A%E3%81%8F-var-log-%E9%85%8D%E4%B8%8B%E3%81%AE%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E7%B4%B9/)