注)
この記事はGemini3に大まかな内容を任せたものになります
はじめに
開発環境での話
セキュリティ向上のため、EC2（Linux）へのSSHポート（22）を全閉鎖し、接続を AWS Systems Manager Session Manager（以下SSM） に一本化しました。
「これで鍵管理も不要、セキュアな環境が完成した」と思っていましたが、ある日ログの肥大化によりディスク使用率が100% に到達。
その結果、「ディスクがいっぱいだとSSMエージェントが正常に動作せず、ログインできない」 という閉め出し状態に陥りました。
最終的に、緊急対応としてセキュリティグループを一時解放して秘密鍵でアクセスという手段を取らざるを得ませんでした。
その反省から、「EC2シリアルコンソール」 をバックアップ手段として導入した経緯をまとめます。
環境・運用
- OS: Amazon Linux 2 (または Amazon Linux 2023 / Ubuntu 等)
-
運用:
- セキュリティグループ（SG）のInbound 22番ポートは削除（0.0.0.0/0 からの許可なし）
- 日常の運用や調査はSSMセッションマネージャーのみを使用
事件発生：Disk Usage 100%
ある日、稼働しているアプリケーションの不具合によりログが爆発的に出力され、ルートボリュームの容量を使い切ってしまいました。
SSMが繋がらない
障害対応のため、いつも通りAWSマネジメントコンソールから「接続」ボタン（SSM）を押しました。
しかし、接続エラーが返ってくるだけ
↑見たことある人はあるだろうポップアップ
なぜ繋がらないのか
SSMエージェント（amazon-ssm-agent）自体も、動作時にログ出力や一時ファイルの作成を行います。
ディスク容量が完全に0バイト（100%使用）の状態ではエージェント自体が正常に動作できず、セッションを確立することができませんでした。
「ログを消したいのに、ログインできないから消せない」 というデッドロック状態です。
緊急対応
SSMが使えない以上、コンソールからは対応不可
復旧を最優先するため、泣く泣く以下の対応
- EC2のセキュリティグループに「MyIPからのSSH（22）」を許可するルールを追加
- （SSM運用で鍵を使っていない場合は）EC2を停止し、ボリュームをデタッチして別インスタンスから削除等の外科手術が必要ですが、今回は念のため残していた鍵でSSH接続
- SSH経由で肥大化したログファイルを削除し、空き容量を確保
- SSM接続の回復を確認
「SSM一本化でセキュアな環境」を目指していたのに、トラブル時に結局ポートを開けることになってしまう。
そもそも、ログローテートしとけっていう話
恒久対策：EC2シリアルコンソール
ディスク枯渇やネットワーク設定ミスでSSMが死んだ場合でも、OSが生きていれば物理コンソールのように接続できる 手段として、EC2シリアルコンソールと接続用ユーザー を導入しました。
EC2シリアルコンソールとは
↑これ
導入手順
今回、以下の設定を追加しました。
1. AWSアカウントレベルでの有効化
AWSコンソールの「EC2」→「EC2シリアルコンソール」の設定から、「許可」にチェック。
左下の設定から有効化しましょう
2. 非常用ユーザーの作成
シリアルコンソール接続時は、IAM認証ではなくOS内部のユーザー認証（ユーザー名とパスワード） を求められます。
SSM運用だとパスワード設定をしていない（鍵認証のみ、あるいはユーザーを作らない）ことが多いですが、ここを通すために非常用ユーザーを作成しました。
興味本位でシリアルコンソール接続押してもパスワード通らず 
ってなった人はいると思います。
私もそうです
実際に使ったコマンド
useradd -m -s /bin/bash [新規作成ユーザー]
passwd -d [新規作成ユーザー]
echo "[新規作成ユーザー] ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/90-[新規作成ユーザー]
chmod 440 /etc/sudoers.d/90-[新規作成ユーザー]
このコマンドだとパスワード無しで実行できる上にrootへsudo suできるから危険
となるかもしれませんが、
権限セットでシリアルコンソール利用可能なユーザーを管理者レベルに制限しています。
- 実際の対応
EC2シリアルコンソールで接続後 df -h 確認すると/dev/nvme0n1p1が100%になっています。
この状態だとSSM接続はエラーポップアップで失敗します。
temp_fill_fileというのが今回事前用意していたバカデカファイルで、削除
ということで無事にSSM救出成功です
まとめ
- SSM接続はディスク容量ゼロに対して脆弱である
- エージェントが動くためのリソースがないと接続できません
- セキュリティグループを閉じている場合、SSMが死ぬと「詰みかねない」
- 「EC2シリアルコンソール」は最後の砦
- 有効化し、ログイン可能なユーザーを用意しておくことで、ネットワークやディスク障害時でもブラウザからログイン可能です
こんな運用もできたよということで紹介でした