本記事はBeeX Advent Calendar 2025の2日目の記事です。
目次
はじめに
最近では「セキュリティ」が重要なテーマの一つですよね。
AWSにはセキュリティ強化サービスが複数ありますが、脅威検知を自動化できるAmazon GuardDutyは導入しているケースが多いサービスです。
今回、とある案件対応でGuardDuty(ランタイムモニタリング)を有効化した際にハマったポイントがあったため、備忘録として対処法をまとめます。
前提
GuardDuty周りのキーワード
- Amazon GuardDuty:脅威を検知するマネージドサービス
- ランタイムモニタリング:OS内部の挙動を監視して脅威検知する機能
- ランタイムカバレッジ:Runtime Monitoring の対象リソースが「監視できているか(イベントを送れているか)」を示す状態。問題があるとUnhealthyになる
- ランタイム統計:カバレジなどの集計表示
GuardDutyの仕組み
仕組み①:エージェント導入(自動 or 手動)
-
自動エージェント設定(推奨):GuardDuty が Systems Manager(SSM)を使って、エージェント導入・更新を管理する方式
-
手動インストール:自分でエージェントを導入して管理する方式。
仕組み②:ランタイムのテレメトリ送信
エージェントが集めたランタイムイベント(挙動データ)を GuardDuty に送信できることで、Runtime Coverage がHealthy(正常) として扱われる。
概要(発生した事象)
GuardDuty の有効化設定の際に発生した事象は以下です。
原因と対処手順
原因(ありがちなパターン)
Runtime Monitoring は「エージェントがテレメトリ送信できること」が前提なので、どれかが欠けるとEC2 が認識されません。
自動エージェント設定の場合のチェック観点は以下です。
- EC2がSSM管理になっていない(SSM Agent未導入/未起動/IAMロール不足 など)
- SSM の通信ができない(プライベートサブネットで外に出られない or 必要な経路がないなど)
- OSが非対応(Runtime Monitoringは対応OSが限られる)
- VPCのDNS設定が無効で、GuardDutyのVPCE作成に失敗する
※エージェントは入っていても、GuardDuty 側の自動エージェント設定の状態により反映が遅れることがある
対処方法
私の環境では以下の順で切り分けしました。
-
EC2がSSMでオンラインになっているか
⇒ OK -
対象EC2にIAM ロール(
AmazonSSMManagedInstanceCoreなど)が付与されているか
⇒ OK -
GuardDutyのエージェントがインストールされ起動しているか
⇒ OK(自動エージェント設定を有効化) -
プライベートサブネットの場合、VPC エンドポイントなどの通信経路があるか
⇒ NG
エラーメッセージ「VPC Endpoint Creation Failed」からもVPCエンドポイント周りが怪しいと気づけました。
ハマったポイント
VPC エンドポイントを作成するには、VPC 設定で DNS を有効化(DNSホスト名 / DNS解決)する必要があるため、有効化しました。
が、1日経ってもEC2が認識されない 状況が続きました...
そこで検証環境で挙動確認したところ、ポイントは以下と判明(念のため仕様についてAWSサポートにも確認)
VPCエンドポイント作成のトリガーは自動エージェント有効化タイミング
私の環境では、すでに自動エージェントが有効化されていたため、
- 自動エージェントを一度 無効化
- VPC の DNS を 有効化
- 自動エージェントを 再度有効化
という流れにしたところ無事解決!
結果、以下のとおり EC2 が認識されるようになり、VPCE も作成されていました。

備忘録(設定時の注意点まとめ)
- Runtime Monitoringは、対応OS/カーネルなどの前提がある(Linux系でも対象外があり得る)
- インスタンスタイプ(特に古い世代)は対象外になり得る
参考
まとめ
GuardDuty は使用することの多い脅威検知サービスですが、特にRuntime Monitoring(Coverage)は前提条件が多く、落とし穴が多いので事前確認が必要です。
設定時はまず前提を満たしているかをチェックすると、ハマりを減らせます。
この記事が一助になればうれしいです。


