この記事は個人ブログと同じ内容です
はじめに
プライベートサブネットにあるEC2インスタンスに、VPCエンドポイント経由でAWS Systems Manager（SSM）を使って接続する際、かなり苦戦したので、その対処法についてこの記事でまとめます。
SSMで接続できないときのエラーメッセージ
SSMでEC2に接続できない場合、接続画面に以下のようなエラーメッセージが表示されることがあります。
SSM Agent がオンラインになっていません SSM エージェントは Systems Manager エンドポイントに接続して自身をサービスに登録できませんでした。
私もAWS初心者で、最初は何が問題なのか全くわかりませんでした。原因は複数あるかもしれないので、以下の項目を一つずつ確認していきましょう。
確認すべき項目
- AmazonSSMManagedInstanceCoreポリシーがアタッチされたIAMロールを持つEC2インスタンス
- SSM エージェントがインストールされていること
- 以下の4つのインターフェース型のVPCエンドポイントが設定されていること
com.amazonaws.region.ec2com.amazonaws.region.ec2messagescom.amazonaws.region.ssmcom.amazonaws.region.ssmmessages
- VPCエンドポイントへのTCP 443ポートの通信が許可されていること
特にネットワーク周りの設定がわかりにくいので、ここを確認するための具体的な方法を紹介します。
対処法1: VPC Reachability Analyzerを使う
VPC Reachability Analyzerは、VPC内のリソース間で接続テストを行うことができるツールです。 これを使うことで、EC2とVPCエンドポイントが通信できているか確認できます。また、通信が失敗している場合、どこで失敗しているかがわかるので非常に便利です。
送信元にEC2インスタンスを指定し、宛先にVPCエンドポイントのENI（Elastic Network Interface）を指定してテストを実施します。失敗した場合、どこで失敗したのかが一目でわかります。
ただし、返りの通信（EC2からVPCエンドポイントへの応答）は確認できない点と、1回の分析に0.1ドルかかるため、無駄な分析をしないように注意してください。
対処法2: VPCフローログを見る
VPCフローログは、VPCのENI間のIPトラフィックに関する情報をキャプチャする機能です。 これを使うことで、EC2とVPCエンドポイントが通信できているかを確認できます。 ただし、VPC Reachability Analyzerとは異なり、セキュリティグループ（SG）やネットワークACL（NACL）のどちらが原因なのかは判別できないため、少し面倒です。 また、ログの内容はわかりにくいことが多いです。
まず、VPCの設定画面でフローログを作成します。すると、CloudWatchにロググループが作成されるので、その中からEC2とVPCエンドポイントのENIに関連するログを確認します。
フローログの見方
AWS公式ドキュメントのフローログの例が参考になります。 https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/flow-logs-records-examples.html.
例えば、以下のログでは、IPアドレス 172.31.16.139 からプライベートIPアドレス 172.31.16.21 へのSSHトラフィック（宛先ポート22、TCPプロトコル）が許可されていることがわかります。
2 123456789010 eni-1235b8ca123456789 172.31.16.139 172.31.16.21 20641 22 6 20 4249 1418530010 1418530070 ACCEPT OK
実際にどんなログがあればいいのか
EC2のENIのフローログでは、EC2のIPアドレスからVPCエンドポイントのIPアドレスへのTCP 443通信が行われていることを確認します。
2 123456789010 {EC2またはVPCエンドポイントのENI} {EC2のIP} {VPCエンドポイントのIP} 20641 {443} 6 20 4249 1418530010 1418530070 {ACCEPT OK}
また、VPCエンドポイントのIPアドレスからEC2のIPアドレスへの443通信の返りも確認できれば問題ありません。
2 123456789010 {EC2またはVPCエンドポイントのENI} {VPCエンドポイントのIP} {EC2のIP} {443} 12345 6 20 4249 1418530010 1418530070 {ACCEPT OK}
対処法3: 他の方法でEC2に接続する
EC2に直接アクセスすることで、SSMエージェントがオンラインであるかどうかや、VPCエンドポイントとの疎通状況を確認できます。 他の方法で接続する場合、Instance Connectを利用するのがおすすめです。EC2のサブネットに作成すれば、セキュリティグループの設定し、VPCエンドポイントを作り、IAMポリシーを付与するだけで、接続できるため、手間が省けます。
SSMエージェントがオンラインであるか確認
https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/ssm-agent-status-and-restart.html
SSMエージェントがオンラインかどうかは、以下のコマンドで確認できます（Amazon Linux 2023の場合）。
sudo systemctl status amazon-ssm-agent
成功すると次のような表示がされます。失敗している場合は、SSMエージェントのインストールや起動を行いましょう。
VPCエンドポイントとの疎通確認
以下のコマンドでVPCエンドポイントとの疎通を確認できます。 ただし、どこで失敗したかの詳細まではわかりません。
curl -v https://VPCエンドポイントのDNS
レスポンスに以下のようなメッセージが含まれていれば、成功です。
* Connected to {VPCエンドポイントのDNS} (IPアドレス) port 443
対処法4: NACLとSGを全開放する
これは最終手段です。すべてのNACLとSGで0.0.0.0/0からのアクセスを許可します。
これで接続が成功すれば、ネットワーク設定に問題があったと考えられます。失敗する場合は、IAMロールやSSMエージェントのインストール状態など、ネットワーク以外の原因と考えられ、原因の切り分けができます。
接続が成功した場合は、NACLやSGのルールを一つずつセキュアな設定に戻していきましょう。
最後に
セッションマネージャーでEC2に接続できないときの対処法を説明しました。VPC Reachability Analyzerは、原因を迅速に特定できるため非常に便利です。VPCフローログも使えますが、内容がわかりにくく初心者には少し難しいかもしれません。少しずつ慣れていきましょう。
