CloudWatch Agentでメトリクスを収集できずハマった話

はじめに

はじめまして。スカイアーチHRソリューションズの肱黒です。初投稿です。

株式会社ギークフィードのアドベントカレンダーに参加させていただきました！

この記事はギークフィード Advent Calendar 2023の4日目の記事です！

本記事では、CloudWatchのカスタムメトリクスの検証を行っていた際にハマった話を書きます。

発生した事象

やりたかったことは、上記の構成のようにパブリックサブネットに構築したEC2からCloudWatchのメトリクスを送信することでした。しかし、なかなかCloudWatchのコンソール画面にメトリクスが表示されず、CloudWatchエージェントのログを確認したところ、エラーが出力されていました。

$ tail -f /var/log/amazon/amazon-cloudwatch-agent/amazon-cloudwatch-agent.log
2023-12-03T15:11:25Z E! cloudwatch: WriteToCloudWatch failure, err:  RequestError: send request failed
caused by: Post "https://monitoring.ap-northeast-1.amazonaws.com/": dial tcp 10.0.3.69:443: i/o timeout
2023-12-03T15:12:24Z E! cloudwatch: code: RequestError, message: send request failed, original error: Post "https://monitoring.ap-northeast-1.amazonaws.com/": dial tcp 10.0.3.69:443: i/o timeout

ログの内容から10.0.3.69にhttpsで疎通できず、タイムアウトしていることがわかったのですが、パブリックのサービスエンドポイントと通信するはずなのに、なぜプライベートサブネット範囲のアドレスが出てくるのか理解出来ませんでした。

その後、手当たり次第に設定変更を行い、VPCエンドポイントを再作成したところ、メトリクスがCloudWatchのコンソール画面に表示されました。

原因

前日に検証用として作成していたVPCエンドポイントが残っていて、それにアタッチしていたセキュリティグループに対象EC2からのアクセス許可がなかったことが原因でした。

当初はRoute53 Resolver(旧Amazon Provided DNS)へエンドポイントの名前解決を行い、グローバルIPが返ってくるような認識でしたが誤りでした。

公式ドキュメントによると名前空間が重複するパブリックホストゾーンとプライベートホストゾーンがある場合、プライベートホストゾーンの名前が一致するかどうかを評価し、一致しなかったときにリクエストをパブリックDNSリゾルバーに転送するそうです。

まとめると、当時の環境はパブリックホストゾーンとプライベートホストゾーンで「monitoring.ap-northeast-1.amazonaws.com」の名前空間が重複した状態になっており、EC2からのDNS問い合わせはRoute53 ResolverでENIのIPに解決されたが、EC2からの通信はSGで許可されていなかったためエンドポイントと疎通できない状況だったようです。

余談

記事を書くにあたって当時の状況を再現しました。そこで色々と調べたのですが、VPC Endpointをサブネットに関連付けなかったために通信ができないというハマりポイントもあるようでした。実際に試してみると下記のエラーが出力されていました。

$ tail -f /var/log/amazon/amazon-cloudwatch-agent/amazon-cloudwatch-agent.log
2023-12-03T17:47:24Z E! cloudwatch: code: RequestError, message: send request failed, original error: Post "https://monitoring.ap-northeast-1.amazonaws.com/": dial tcp: lookup monitoring.ap-northeast-1.amazonaws.com on 10.0.0.2:53: no such host

10.0.0.2のIPアドレスはVPC内のRoute53 Resolverのアドレスなので、プライベートホストゾーンで名前解決しようとするもENIがないため具体的なIPに解決できない状況のようです。

また、マネジメントコンソール上でもVPCエンドポイントとサブネットの関連付けを外した後にENIが削除されていることを確認できました。

おわりに

今回の件はCloudWatchに限った話ではなく、VPC Endpoint全般で発生する話みたいです。あらためて、NW周りは曖昧な理解でいると危険だなと感じました。Route53まわりはこちらのBlackBeltなどで理解を深めておきたいと思います！

今月はAmazon Connect関連でも記事を書く予定です！

この記事が少しでも参考になれば幸いです。