はじめに
以前の記事で紹介した「SSM Agentの実行スクリプトを削除する方法」の設定をAnsibleで行った際、失敗してEC2インスタンスにログインできなくなったため、そうならないようにするための注意点・回避方法を紹介したいと思います。
Session ManagerによるEC2インスタンスログイン
Session Managerを使ってEC2インスタンスに接続を行うと、セキュリティグループでSSHアクセスを許可しなくても接続できるため、SSHによる接続は行わずにSession Managerで接続を行うようにしている方も多いかと思います。
私が作業を行ったシステムでもSSHは許可されておらず、Session Manager経由でしか接続できない環境でした。
ちなみにSession Managerでログインする場合、EC2インスタンス側でSession Managerで接続できるようにIAMロールの設定やssm-agentのサービスを起動（最近はデフォルトで有効）しておけば以下コマンドを入力するか、マネジメントコンソール上から接続できます。
aws ssm start-session --target [インスタンスID]
回避策
同じようなことが起こらないようにするために考えた2つの回避策を紹介します。
作業前にSession Managerにログインしておく
ssm-agentのサービスを再起動しても、元々Session Managerで接続しているコネクションは切断されないため、ssm-agentの設定変更作業を行う前に、何かあったときのために別のコネクションを維持しておけば復旧できます。
当然ログアウトしてしまったり、何も操作せず長い時間放置してタイムアウトで切れてしまうと接続できないため、注意しましょう。
EC2シリアルコンソール機能を使ってログインする
いくつか条件や事前準備は必要ですが、対象のEC2インスタンスがNitroインスタンスタイプの場合はEC2シリアルコンソールを使えばssm-agentのサービスが停止してしまっている場合でも接続できます。
EC2シリアルコンソールについて詳しくは前回の記事に書かれています。
今回のようなssm-agentの設定変更時だけではなく、他の不具合で接続できなくなった場合でも対処できる可能性があるので、Nitroインスタンスを使用しているようであればいざというときのために設定しておくと良いと思います。
おわりに
今回は許可されている他インスタンスから接続を行うことで無理やり対処しましたが、作業に対する注意力が足りなかったと反省しております。
繰り返さないよう意識を高めることも必要ですが、問題が発生した場合の回避策や事前の防止策を学ぶことで改善することも必要だと改めて感じました。