下記の記事でセッションマネージャを利用したポートフォワーディングについて記載してますが、その際に設定したVPCエンドポイント（VPC Endpoints）で想定外のことが起こったので、備忘を兼ね記載しようと思います。
↓過去の記事↓
AWS SessionManager(セッションマネージャ）でポートフォワーディング１ - 自由気ままに書いちゃおう
AWS SessionManager(セッションマネージャ）でポートフォワーディング２ - 自由気ままに書いちゃおう
■何が起こったのか
上記「過去の記事」ではプライベートサブネットのみを用意していたため、パブリックサブネットも新たに用意し、セッションマネージャの機能を確かめようとしました。
（ただ単にセッションマネージャでコンソール表示させたかっただけなのですが・・・）
何故かパブリックサブネットに配置した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を経由してセッションマネージャに到達します・・・。
図解するとこんな感じです。
灰色線が誤った認識のものです。
正しくは黄色線の方です。
つまり、Endpoints用のセキュリティグループで接続元の情報を制限していたため、（今回の場合は、プライベートサブネットのEC2からの通信のみを許可していました）
正常にセッションマネージャとパブリックセグメント上のEC2が通信することができず、セッションマネージャのリストに表示されなかったということです。
Endpoints用のセキュリティグループの設定を見直したところ、問題なくセッションマネージャのリストに表示され、コンソール接続もできるようになりました。
■補足
AmazonLinux2で出力されたエラーメッセージの中でIPアドレス（172.30.1.18:443）が出てきましたがこれは、「com.amazonaws.ap-northeast-1.ssm」サービスを作成した際に一緒に作成されたEndpoints用のNICのIPアドレスです。
■原因の深堀り
原因は上記の通りなのですが、そもそもVPC Endpoints作成時にプライベートサブネットを指定して作成しているわけで、まさかパブリックサブネットにも影響があるとは思ってもおらず。。。
というわけで、VPCEndpointsをもう少し詳細にみていこうと思いますが、長くなったので次回以降にやりたいと思います。
以上です。
