自由気ままに書いちゃおう

好きなことをつらつらと・・・

AWS SessionManager(セッションマネージャ)のトラブルシューティング

下記の記事でセッションマネージャを利用したポートフォワーディングについて記載してますが、その際に設定したVPCエンドポイント(VPC Endpoints)で想定外のことが起こったので、備忘を兼ね記載しようと思います。

↓過去の記事↓

AWS SessionManager(セッションマネージャ)でポートフォワーディング1 - 自由気ままに書いちゃおう

AWS SessionManager(セッションマネージャ)でポートフォワーディング2 - 自由気ままに書いちゃおう

■何が起こったのか


上記「過去の記事」ではプライベートサブネットのみを用意していたため、パブリックサブネットも新たに用意し、セッションマネージャの機能を確かめようとしました。
(ただ単にセッションマネージャでコンソール表示させたかっただけなのですが・・・)

何故かパブリックサブネットに配置したEC2(WindowsServer/RHEL/AmazonLinux2)でセッションマネージャ機能が利用できなくなりました。
本来なら、セッションマネージャのリストにEC2が表示されるはずが、プライベートサブネットのEC2のみしか表示されない状態に。。。

AmazonLinux2の/var/log/amazon/ssm/amazon-ssm-agent.logには、以下ログが出力されておりました。

2020-05-01 22:04:50 INFO Got signal:terminated value:0xbb8330
2020-05-01 22:04:50 INFO Stopping agent
2020-05-01 22:07:00 INFO Entering SSM Agent hibernate - RequestError: send request failed
caused by: Post https://ssm.ap-northeast-1.amazonaws.com/: dial tcp 172.30.1.18:443: i/o timeout

■原因


VPC Endpointsの動作仕様を勘違いしていました。。。
VPC Endpointsを作成したAWSサービス(今回の場合は、セッションマネージャ用のEndpoints)を利用する際、パブリックサブネットだろうがプライベートサブネットだろうが、そんなことは関係なしにVPC Endpointsを通して特定のAWSサービスにアクセスします。
※パブリックサブネットのルートテーブルのデフォルトゲートウェイがInternetGatewayを向いていても関係なしにEndpointsを経由してセッションマネージャに到達します・・・。

図解するとこんな感じです。
灰色線が誤った認識のものです。
正しくは黄色線の方です。

f:id:guri2o1667:20200501225845p:plain


つまり、Endpoints用のセキュリティグループで接続元の情報を制限していたため、(今回の場合は、プライベートサブネットのEC2からの通信のみを許可していました)
正常にセッションマネージャとパブリックセグメント上のEC2が通信することができず、セッションマネージャのリストに表示されなかったということです。

Endpoints用のセキュリティグループの設定を見直したところ、問題なくセッションマネージャのリストに表示され、コンソール接続もできるようになりました。

■補足


AmazonLinux2で出力されたエラーメッセージの中でIPアドレス(172.30.1.18:443)が出てきましたがこれは、「com.amazonaws.ap-northeast-1.ssm」サービスを作成した際に一緒に作成されたEndpoints用のNICのIPアドレスです。

f:id:guri2o1667:20200501232037p:plain

 

f:id:guri2o1667:20200501232205p:plain




■原因の深堀り


原因は上記の通りなのですが、そもそもVPC Endpoints作成時にプライベートサブネットを指定して作成しているわけで、まさかパブリックサブネットにも影響があるとは思ってもおらず。。。
というわけで、VPCEndpointsをもう少し詳細にみていこうと思いますが、長くなったので次回以降にやりたいと思います。

以上です。