経緯
クローズサブネット（インターネット接続性なし）で、セッションマネージャの接続を検証したくて、インターフェイスエンドポイントを作った。
クローズサブネットからはセッションマネージャで接続できるようになったのだが、
同じVPC内のパブリックサブネットにあるインスタンスに、セッションマネージャで接続できなくなった。（元々接続できていたのに）
パブリックサブネットには、インターフェイスエンドポイントはアタッチしていないし、NW的には何も変わっていないはずなのに…と思っていたのだが。。
結論
同一VPC内はすべてインターフェイスエンドポイントを見に行く1。
パブリックサブネットにはアタッチしてないから、変わらないものと誤認していた。
そして、エンドポイントのセキュリティグループで許可してなかったので接続できなくなった。
インターフェイスエンドポイントを使用すると起こる事であって、SSMに限ったことではない。
調査したこと
- 対象インスタンスにSSH接続
- SSM Agentのログを調べると、インターフェイスエンドポイントに接続しにいって失敗している模様。
journalctl -u amazon-ssm-agent | less
amazon-ssm-agent[2391]: caused by: Post https://ssm.ap-northeast-1.amazonaws.com/: dial tcp 172.30.4.52:443: i/o timeout
amazon-ssm-agent[2391]: 2019-12-09 08:02:05 INFO [HealthCheck] increasing error count by 1
amazon-ssm-agent[2391]: 2019-12-09 08:02:05 ERROR [HealthCheck] error when calling AWS APIs. error details - RequestError: send request failed
amazon-ssm-agent[2391]: caused by: Post https://ssm.ap-northeast-1.amazonaws.com/: dial tcp 172.30.4.52:443: i/o timeout
amazon-ssm-agent[2391]: 2019-12-09 08:02:05 INFO [HealthCheck] increasing error count by 1
なぜか
エンドポイントの「プライベートDNS名」を有効化すると、デフォルトのDNS 名には、インターフェイスエンドポイントのIPが紐付けられる。
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpce-interface.html#vpce-private-dns
DNSはVPC毎2なので、サブネットに関わらず、インターフェイスエンドポイントを見に行く。
余談
- DNSがVPC毎2なのは知っていたので、考えてみれば分かる事ではある。
- しかし、インターフェイスエンドポイントのドキュメントには、「インターフェイスエンドポイントを使用する VPC 内のサブネットを選択します」と書かれていて、実態と記述の印象が異なる。
- これは社内の検証環境なので全然影響は無いのだが、既存通信に影響が出て結構危ない。
感覚的には、影響範囲はサブネットであるように感じたが、実際はVPC全体である。 - ちなみに、プライベートDNS名を有効化した上で、サブネットをどこも選択しないと、
デフォルトDNS名で名前解決したとき、IPが返ってこなくなるのでどこからも接続できなくなる。
$ nslookup ssm.ap-northeast-1.amazonaws.com
Server: 172.30.0.2
Address: 172.30.0.2#53
Non-authoritative answer:
*** Can't find ssm.ap-northeast-1.amazonaws.com: No answer
- 少なくとも、ドキュメントの「使用するサブネット」を選択しますという表現は良くないと思う。
また、サブネットはAZ毎に1つしか選べないので、そこでも違和感がある。 - マルチAZなら2つのAZに設定しよう。
- 「仕組みを考えれば理解はできるけど、誤解を招きませんか？」とサポートに言ってみたら、フィードバックして頂けるとのこと。