環境

以下の条件に当てはまる環境で、よく発生する問題です。

多数の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は調べようがありません。まずは開始させましょう。