最初に
今回は、AWSのSession Manager で EC2 インスタンスに接続できなくなり、対応に追われた経験を備忘録として記録しておきたいと思います。もし同じような状況に直面された方がいらっしゃれば、この記事が少しでも参考になれば幸いです。
突如として現れた接続エラー
先日、いつものように Session Manager を使って EC2 インスタンスに接続しようとしたところ、添付画像のように見慣れないエラーメッセージが表示されました。
エラー画面
エラーの原因として考えられたこと：ディスク容量の不足
このエラーの原因を調査する中で、最も可能性が高いと判断したのが、EC2 インスタンスのディスク容量が上限に達していたことでした。
Session Manager での接続失敗については、AWS 公式のナレッジセンターでも「Plugin with name Standard_Stream not found. または Your session has been terminated for the following reasons: The target instance ID could not be found. というエラーメッセージが表示されて Amazon EC2 インスタンスに接続できないのはなぜですか?」という記事で、ディスク容量の不足が原因の一つとして挙げられています。
Amazon EC2 インスタンスに接続できないのはなぜですか?
心当たりのある出来事がありました。先日、データベースのダンプを取得するスクリプトの動作確認を行っており、30分おきにスクリプトを実行するように設定していました。しかし、業務終了後にこのスクリプトの停止を忘れてしまい、翌日まで実行し続けてしまっていたのです。
データベースのダンプはそれなりの容量を消費するため、短時間で頻繁に実行し続けた結果、ディスク容量が枯渇してしまったのではないか、と推測しました。ディスク容量が100%になると、OS の正常な動作にも影響が出ることがあり、Session Manager などの接続ツールも機能しなくなることがあります。
公式
解決に向けた試行錯誤
Session Manager で接続できないとなると、他にインスタンスにアクセスする方法を探す必要があります。いくつか試みましたが、それぞれ課題がありました。
試み1：EC2 シリアルコンソール → 利用不可
まず最初に EC2 シリアルコンソールを試しました。これは OS が起動しない場合や SSH キーを紛失した場合など、緊急時に役立つ機能です。しかし、添付画像のように、以下のメッセージが表示されました。
EC2シリアルコンソールではサポートされていません
「このインスタンスタイプは、EC2 シリアルコンソールではサポートされていません。」
「EC2 シリアルコンソールを使用してインスタンスのシリアルポートに接続するには、インスタンスが AWS Nitro System 上に構築されたインスタンスタイプを使用する必要があります。インスタンスタイプは、サポートされている仮想化インスタンスタイプまたはベアメタルインスタンスタイプに変更できます。」
【うまくいかなかった原因】
使用していた EC2 インスタンスのタイプが、EC2 シリアルコンソールをサポートする「AWS Nitro System」上に構築されたものではなかったため、利用できませんでした。全てのインスタンスタイプでシリアルコンソールが利用できるわけではない、ということを改めて認識しました。
試み2：ボリュームの変更（ディスク容量の増量） → 接続が必要
次に、ディスク容量が問題であれば、ボリュームサイズを増やせば良いと考え、添付画像のように EBS ボリュームのサイズ変更を行いました。
ディスク容量の増量
【うまくいかなかった原因】
EBS ボリュームのサイズ自体は変更できますが、インスタンス内のファイルシステムにその変更を反映させるには、インスタンスにログインしてファイルシステムを拡張するコマンド（例：resize2fs や xfs_growfs）を実行する必要があります。
しかし、Session Manager や SSH でインスタンスに接続できないため、このファイルシステムの拡張操作を行うことができませんでした。結果として、ボリュームを増やしてもインスタンス上ではディスク容量が不足した状態のままでした。
試み3：SSH での接続 → キーペアなし
最後の手段として、SSH での接続を試みました。
キーペアなしで接続できず
【うまくいかなかった原因】
インスタンス作成時に SSH キーペアを用意しておらず（または管理できていなかったため）、必要な秘密鍵がない状態でした。セキュリティの観点から、キーペアがない状態での SSH 接続は許可されません。
最終的な対応：新しいインスタンスの作成
様々な手段を試みましたが、既存のインスタンスにアクセスして問題を解決することが困難だと判断しました。
まとめと学んだこと
最終的には、新しい EC2 インスタンスをゼロから作成することになりました。今回の経験を踏まえ、同様の事態を避けるために以下の点に注意して構築を進めました。
今回のトラブルは、AWS 運用における基本的ながらも重要な教訓となりました。
ディスク容量の監視は不可欠: 想定外のスクリプト動作やログ増加などにより、いつの間にかディスク容量が不足する可能性があります。
緊急時のアクセス手段を確保すること: Session Manager が使えない場合に備え、SSH キーペアの適切な管理や、シリアルコンソールが利用可能なインスタンスタイプかどうかの確認が重要です。
EBS ボリューム拡張時のファイルシステム拡張: ボリュームサイズを増やしただけでは、OS から認識されない場合があることを再確認しました。
もし皆さんも Session Manager で接続できない事態に直面したら、まずはディスク容量の状況を疑ってみてください。そして、私のようにアクセス手段を失うことがないよう、事前の準備と対策をしっかり行っておくことをお勧めします。
Discussion