環境
以下の条件に当てはまる環境で、よく発生する問題です。
- 多数のEC2を構築・運用している
- Systems Manager(SSM)を使用できるように各種セットアップ済みである
- Systems ManagerのランコマンドやPatch Manager等を利用している
多数のEC2でSystems Managerを利用すると
正しく構成していれば、各EC2のSystems Managerエージェント（SSMエージェント）はSystems Managerサービスと通信できます。
通常は、何ら問題ないです。
しかしながら何らかの原因で、一部のEC2でSSMの通信ができないケースが出てきます。
（原因は本当に色々あって、IAMの設定不備、VPCルーティング設定不備、セキュリティグループ設定不備、SSMエージェントが落ちている、SSMエージェントのバージョンが古い、169.254.169.xxx の通信など、、多岐にわたります）
多数のEC2を運用していると、SSMの通信できないEC2の原因を調べるよりも、どのEC2が通信できててどのEC2が通信できてないかをそもそも見つけにくい 状況だったりします。
SSMの通信NGをなぜ見つけにくいのか
マネージメントコンソールで、Systems Managerのマネージドインスタンスを見ると、対象EC2のリストが確認できます。
ただし表示されるのはSSMエージェントと通信が確立できたEC2であり、全く通信できていないEC2はリストに表示されません。
また、EC2を停止するとリストからも消えてしまいます。
API/CLIで通信できないEC2一覧の取得
そこで２つのコマンドを使います。
コマンド１つ目
aws ec2 describe-instance-status
APIの場合は、
ec2:DescribeInstanceStatus
を実行すると、稼働している(runningステータス)のEC2一覧が取得できます。
そしてコマンド２つ目
aws ssm describe-instance-information
APIの場合は、
ssm:DescribeInstanceInformation
を実行すると、SSMエージェントの通信OKなEC2一覧が取得できます。
欲しいのはrunningのEC2にもかかわらずSSMの通信NGの一覧です。
それを得るには、コマンド１つ目のEC2一覧 から コマンド２つ目のEC2一覧を引いたもの を抽出すればよいです。
インスタンスIDで突き合せられます。
インスタンスIDじゃ分からないよ！という場合はさらにタグなどを取得します。
https://qiita.com/t-fujiwara/items/835cccbef7ec6d199251
なお、停止しているEC2は調べようがありません。まずは開始させましょう。