はじめに
AWS上で構築していたGNS3サーバ（UbuntuOS）の2台目が必要になったので、AMIを取得して複製したところ、インスタンスのステータスチェックが失敗しました。
これまでに1,2回しか出会ったことがない事象、たまたまかな？と思いEC2を停止起動したり、AMIを取得しなおして再作成してもダメでした。
色々調べた結果、起動に失敗するEC2のEBSを正常なEC2に紐づけて、/var/log/messages を確認してみることにしました（AWSコンソール上で見ることができるシステムログは確認済み）
目次
1.EC2からEBSをデタッチする
EC2にアタッチされているEBSボリュームをそれぞれデタッチします。
2.問題のあるEBSを正常なEC2にアタッチ
...しようと思っていましたが、AZが異なるためそのままではアタッチできないことが判明...
仕方がないので、一度EBSボリュームからスナップショットを作成して、さらにそのスナップショットからボリュームを再作成する際に別AZを指定することで、解決しました。
ちょっと遠回りしましたが何とかアタッチできたので、EC2を起動しました。
なお、ボリュームをアタッチする際はデバイスを/dev/sda1に変更しないとEC2が認識してくれません（ルートデバイス名はEC2のストレージタブにて確認）
3.EC2にSSHログインする
EC2が問題なく起動してくれたので、SSHでログインします。
鍵が一致しないと警告が出てしまいましたが、鍵の上書きはせずに続行をクリック。
なお、鍵を上書きしなかったせいなのかは分かりませんが、ユーザ名/パスワードではSSHもRDPも失敗したため、pem鍵を使用してログインしました。
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にアタッチして、起動すると...
やはり失敗しました。今回悪いのはEBSではなくEC2（もしくはAMI）みたいです。
ただ、AMI取り直しも、AMIからEC2作成も何度か試していて毎回失敗するので、もしかしたら別の要因があるかもしれません（進展あれば適宜更新）
さいごに
EBSボリュームを別AZに存在するEC2にアタッチする場合、一旦スナップショットを作成して回避する、などは今後も使えそうだなと思いました。
参考文献
本記事はこちらの文献を参考に執筆しました。この場を借りてお礼申し上げます。