はじめに
Systems Managerには、Session Managerと言う機能があります。
この機能を利用することでEC2インスタンスへアクセスする際に公開鍵暗号方式を用いたSSHを行わずアクセスする事が出来ます。
また、VPCエンドポイント経由で外部に公開されていないプライベートサブネット上のインスタンスにもアクセス出来ます。
プライベートサブネット上に配置したEC2インスタンスへのセッションが失敗するのは、よく散見されるケースで公式ドキュメントやクラスメソッド様の記事にも記載があります。
Troubleshooting Session Manager
セッションマネージャーのハマりどころをパターンごとに整理してみる(鈴木 純様)
ですので、セッションマネージャー周りのトラブルはIAMロールやセキュリティグループ、VPCエンドポイント辺りの設定値を見直すと問題はすぐに解消すると思います。
そう・・・そう思っていたのですが、それとは違う、変な事象にぶつかり解決に時間を要した時の話です。
起きたこと
社内の検証環境においてVPCエンドポイント経由でSession Managerへ接続した際にプロンプトを中々返さない。
以下の通り、よくある構成でSession Managerを利用していました。
この時、Session Managerが起動はするのですが、黒い画面が表示されたままになり、約2、3分経ってようやくプロンプトを返します。
黒い画面までは表示されているので、ポート回りかな？と思って確認しても間違っていませんでした。現に繋がっていますしね。
原因を探るべくVPC内部のDNSサーバで変なキャッシュが残っていたりするのか、
インスタンスのスペックが低いと時間を要するのか等色々と調べていました。
しかしながら、その様な情報も見つけることが出来ませんでした。
原因
セッションアクティビティのログ記録が有効化になっていた。
Session ManagerではSystems Managerコンソールにおけるセッション情報やアクティビティログをCloudWatch LogsやS3にストリーミングする機能を持っています。
検証環境ではS3バケットのロギングが有効になっており、エンドポイント先となるバケットが存在しなかった事が原因になります。
ログ記録の設定はユーザ単位では無くアカウント、リージョン単位の設定となりますので、他の方がログ記録を有効にしていると、知らないうちにセッションログが指定されたロググループやS3バケットに格納されていく仕様となっております。
エージェントに対して共通の設定を行う事が出来ますので、決して悪い事では無いのですが、今回のケースは偶々その仕様にぶつかってしまったことになります。
この機能は、AWS Systems Manager→Session Manager→Preferences(設定)から設定する事が出来ます。
調査した事
ノード内でSSM Agentのログが記録されているので、中身を見てみました。
SSM Agentのログは以下の場所で確認できます。
| OS | パス |
|---|---|
| Linux | /var/log/amazon/ssm |
| WIndows Server | %PROGRAMDATA%\Amazon\SSM\Logs\ |
ログを見る限りですが、プロンプトを返す前にエンドポイントにHTTPリクエストを送っています。
HTTPリクエスト先であるエンドポイントが見当たらないと何度かリトライ処理を行っているようです。
ログ抜粋(Amazon Linuxで確認)
2022-04-20 04:52:51 ERROR [ssm-session-worker] [ここにユーザ名がはいる] [DataBackend] [pluginName=Standard_Stream] HTTP HEAD request failed: url=`ログのエンドポイント(https:://XXXXXが入る)`, error=Head "`ログのエンドポイント(https:://XXXXXが入る)`": dial tcp XX.XXX.XXX.XX:443: i/o timeout
リトライ処理も失敗した後にようやくプロンプトを返しているようです。
このロギング設定をDisabledにした後、プロンプトがすぐに帰ってくることを確認しました。
確認は出来ていませんが、CloudWatch LogsやS3バケット向けのポリシーをEC2にアタッチしているロールに設定出来ていないと同じようなリトライ処理が走るのではないかと思っています。
VPCエンドポイントのハンズオン記事で、ロールにAmazonSSMManagedInstanceCoreを付与する事は書いていても、LogsやS3に関する事はあまり書かれていないです。
ロギング機能はOptionalですので当然と言えばそうなのですが、知らないうちにハマってしまいそうだなと思い、自戒を込めて書いておきます。
上記の状態でロギング機能を有効にしたまま解決できる方法が見つかれば、その際は新しい記事にでも起こそうと思います。(ニーズがあるかはさておき)
まとめ
ユーザによってAWSアカウントを分割している組織だとあまり出会う事はないかもしれませんが、共通の検証環境を使っているような組織だと起きるかもしれませんね。
検証環境ならまだしも、お客様の環境上で同じような事を起こすとよろしくないので、TIPS程度に見て頂ければ嬉しいです。
また何かあれば書きます。ではでは。
追記(20220421)
トラブルシューティングのリンクに以下の記載がありました。
検証でロギング機能を有効にして、一時的に作成したロググループやバケットがあれば、要注意でございます。
Solution D: The log group or Amazon S3 bucket you specified in your session preferences has been deleted. To resolve this issue, update your session preferences with a valid log group or S3 bucket.
参考資料
Troubleshooting Session Manager