AWS EC2 に ssh で接続できなくなった（hosts.allowが失敗した）２
今の状況はかなりまずい。
会社が引っ越して hosts.allow に書いたIPアドレスでアクセスすることができない。
さらに、
①EC2 Instance Connect も使えない。
②セッションマネージャー も使えない。
③SSH クライアント も使えない。
④EC2 シリアルコンソール も使えない。
という、絶望的な状況なのです。
どうもボリュームを他のインスタンスにつけて、hosts.allowファイルを書き換えるのが答えのようです。
前回は、イメージを作成して完全バックアップを元に作業を進めたが、
このバックアップはバックアップで置いておいて（心に落ち着き）、動いているボリュームをどうにかする方がいいかと考えました。
（１）まず前回作成したイメージ（AMI）を削除した。その際にスナップショットも一緒に削除した。
→イメージを作成した際にスナップショットも作成されというわけですね。
・AMI・・・スナップショット
・インスタンス・・・ボリューム
という理解でいくか
（２）今回はバックアップとして「イメージを作成」し完全バックアップを作成しようと思います。
（３）イメージの作成
・「イメージ名」に「backup」と入力した。
・「終了時に削除」の有効化にチェックをした。
※ここに「イメージの作成プロセス中に、Amazon EC2 は上記の各ボリュームのスナップショットを作成します。」がありましたね。２回目にしてようやく気付く。
「イメージを作成」ボタンを押しました。
（４）「AMI を現在作成中 ami-0b050d7dbe377ce5d インスタンス i-01ed4bb82b5d9ac80 から。インスタンスを削除したり、この AMI に関連する他のアクションを実行したりする前に、AMI のステータスが [利用可能] であることを確認してください。」
とコピー中なので待ちます。
（５）３分後。「保留中」から「利用可能」になりました。
（６）スナップショットはこれのことですね。２週目にしてようやく理解しました。
「AMI-backup」と名前をつけました。
ここまででいえることは、私はただAMIでバックアップを取った。
なにか元のインスタンスで失敗たら、このAMIを使えば元に戻るという理解にしておこう。
（７）修正するインスタンスを停止させた。
（８）「ボリューム」をデタッチした。１回目でデタッチできました。
「使用可能」を確認
（９）「ボリュームのアタッチ」します。インスタンス起動中でもアタッチできました。
正常に動くインスタンスの「/dev/sdf」を選択します（データボリュームの場合は /dev/sd[f-p]）。とありますね。
（１０）ボリュームを調べる。AWSでは「/dev/sdf (attached)」となっているが、実際は「/dev/xvdf」になっていた。↑でも「/dev/xvdf」に変更されることがあるといっていたのはこのことです。
lsblk
（１１）「/dev/xvdf」をマウントする。
sudo mkdir /mnt/mydatasudo mount /dev/xvdf1 /mnt/mydata（１２）ここで、ようやくhosts.allow 書き換えです。
sudo vi /mnt/mydata/etc/hosts.allow（１３）IPの追加が終わったらアンマウント
sudo umount /mnt/mydata
（１３）起動中にデタッチできました。
デタッチするとこんな状態です。
（１４）これを元のインスタンスにアタッチします。
※デバイス名には「/dev/sda」を選択します。
（１５）これでインスタンスを開始しました。
（１６）SSHでアクセスできることを確認できました。
以上