【入門】AWS GuardDutyの仕組み・使い方・検知内容まとめ

概要

ブログを見ていただきありがとうございます。
AWSの脅威検知サービス「GuardDuty」について、基本的な仕組み・検知内容・運用方法を初学者向けにまとめました。
有効化の手順からサンプル検知のテスト方法、実運用の対応フローまでを網羅的に紹介します。

GuardDutyをこれまで使用したことがなく、どのように動作するサービスなのか理解するところから調査を始めました。
本記事が、同じようにGuardDutyを調べている方の参考になれば幸いです。

GuardDutyとは

GuardDutyは、AWS上のログ（CloudTrail / VPC Flow Logs / DNS など）を分析し、
攻撃や不審な挙動を検知するサービスです。

検知に特化したサービス（IDS）であり、攻撃の遮断は行いません。
防御が必要な場合は、WAF・セキュリティグループ・Lambdaによる自動対応などと組み合わせて運用します。

利用方法

GuardDutyの検知ルールについて

GuardDutyでは、ユーザーが自分でルールを作る必要はなく、AWSが提供する マネージドルール に基づき、以下のログデータを常時分析しています。

データソース	検知される脅威例
VPC Flow Logs	不審なIPとの通信（C2通信・ブルートフォース）
CloudTrail Logs	IAMユーザーの不審な操作、設定改ざん
DNS Logs	マルウェアやブラックホールドメインとの通信
EKS Audit Logs	不審なKubernetes API操作（例: 匿名アクセス）

これらのログを GuardDuty が統合的に分析し、脅威を検出します。

CloudTrail / VPC Flow Logs / DNS Logs / EKS Logs
         ↓
   GuardDuty（脅威検知）
         ↓
 Security Hub / SNS 通知

検知ルールは AWS のセキュリティ研究チームが随時更新しており、新しい脅威（CVE・マルウェアなど）にも自動で対応されます。
そのため、利用者側でルールを追加したり更新したりする必要はありません。

GuardDutyの料金（参考）

GuardDutyの料金は使用量ベースで、解析するログ量に応じて課金されます。
主に以下の3つが課金対象です。

対象ログ	料金の考え方	備考
CloudTrail イベントログ	約 $4.00 / 100万イベント	管理イベントの解析量に応じて課金
VPC Flow Logs	約 $1.00 / 1GB	ネットワークトラフィック量に比例
DNS クエリログ	約 $0.70 / 100万クエリ	不審ドメイン検出に使用

※ 料金はリージョンにより変動
※ 初回30日間は無料トライアル で試すことができます
詳細：https://aws.amazon.com/jp/guardduty/pricing/

GuardDutyを有効化する手順

GuardDutyの有効化は非常に簡単で、数クリックで開始できます。

1. AWSコンソールで 「GuardDuty」 を開く
2. 「Get started」または「有効化」をクリック
3. 有効化したいリージョンを確認して「Enable GuardDuty」を実行

これで GuardDuty が有効となり、CloudTrail / VPC Flow Logs / DNS Logs の解析が開始されます。

テスト用サンプル検出を実行（任意）

GuardDutyには、AWS公式が用意している サンプル検出（Sample Findings） 機能があります。
実際に不正アクセスを行わずに、GuardDutyの動作や通知フローをテストすることができます。

以下の AWS CLI を実行します。

aws guardduty create-sample-findings

（※ 古いCLIの場合、--detector-id が必要なケースがあります）

コマンド実行後、GuardDutyコンソールの「検出結果」に
複数のサンプル（SSHブルートフォース、C2通信など）が生成されます。

これらはすべてサンプルデータなので実害はありません。
以下はサンプル検出が出力された画面例です。

「検出結果」の一覧では、以下の情報を確認できます。

• 検知タイプ（例：UnauthorizedAccess:EC2/SSHBruteForce）
• 重要度（Severity）
• 影響範囲（リソースID）
• 発生時間
• 推奨アクション

通知設定（SNSやSlack連携）をしている場合は、このサンプル検出を使って 通知フローが正常に動くか を確認できます。

実際の検知内容に基づく対応フロー

前述のとおり、GuardDutyは「検知専用」のサービスです。
そのため、GuardDutyの検知結果をもとに、通知 → 分析 → 対応 → 再発防止
という一連のインシデント対応フローを構築して運用することが重要です。

以下は GuardDuty を利用した標準的な対応フローです。

検知 → 分析 → 対応 → 防御ルール化 の流れ

フェーズ	実施内容	主なサービス
① 検知	GuardDutyが不審な挙動を検出（例：SSHブルートフォース）	GuardDuty
② 通知	SNSまたはSecurity Hub経由で通知（メールやSlack連携）	EventBridge / SNS / Security Hub
③ 分析	CloudTrailやVPC Flow Logsで詳細を確認し、影響範囲を特定	CloudTrail / VPC Flow Logs
④ 対応	一時的な遮断（SG変更、IAM無効化、EC2隔離）	Lambda（自動化）/ コンソール操作
⑤ 再発防止	対応内容をルール化して防御強化	AWS WAF / IAMポリシー / Config ルール / SCP など

GuardDutyと他セキュリティサービスの連携イメージ

GuardDutyは単体で防御を行うサービスではないため、
通知・自動対応・防御強化を行うためには他サービスとの連携が重要になります。

以下は GuardDuty を中心とした標準的な連携イメージです。

        ┌──────────────────┐
        │     GuardDuty    │
        │  （検知・分析）   │
        └───────┬──────────┘
                │ Findings
                ▼
┌─────────────────────────────┐
│  Security Hub（統合ビュー）  │
└───────┬────────┬────────────┘
        │        │
        ▼        ▼
CloudWatch  →  Lambda（自動対応）
        │
        ▼
通知（SNS / ChatOps）

GuardDuty 検出件数の目安と対応優先度の考え方

環境別の検知件数イメージ（1か月あたりの参考値）

GuardDutyの検出件数は、インターネット公開の有無 / IAM利用状況 / アカウント数 / トラフィック量 によって大きく変わります。

以下は AWSドキュメントや一般的な運用傾向から見た「目安」としての参考値です。

規模／環境	特徴	検出件数の目安（1か月あたり）	備考
開発・検証環境（Private Subnet中心）	インターネット公開なし、IAM利用限定的	0～5件程度	ほとんど「低」レベルの通知（スキャン検知など）
ステージング環境（ALB・S3公開あり）	一部外部公開、複数IAMユーザー	5～20件程度	外部スキャンやポートプローブ検知が主
本番環境（ECサイト／API公開）	常時外部通信あり	月10～100件前後	SSHブルートフォース・不正APIコールなど散発的に検知
大規模（数十アカウント統合運用）	Organizations構成	数百件／月もあり得る	自動集約・フィルタリングが必須

※ 上記はあくまで一般的な傾向であり、環境により大きく異なります。
※ 公開されたIPやALBがある場合、外部からの“スキャン系”検知は必ず発生します。

重要度（Severity）の意味と対応方針

GuardDutyでは、検出した脅威に対して 0.0〜8.9 のスコア（Severity） が付与されます。
Severityに応じて優先度をつけて対応することが重要です。

重要度	意味	代表的な検知例	推奨対応
🔴 クリティカル（8〜8.9）	実被害が発生または進行中の可能性が高い	IAM資格情報漏えい、C2通信、マルウェア活動	即時対応必須：キー無効化・EC2隔離・調査開始
🟠 高（4〜7.9）	攻撃試行・不正通信など侵入の兆候	SSHブルートフォース、API悪用、RDP攻撃	優先対応：IP遮断・ログ確認・防御ルール追加
🟡 中（2〜3.9）	潜在的リスク・調査が望ましい	不審ドメインアクセス、設定変更など	内容を確認し、必要に応じて対応
🟢 低（0〜1.9）	情報提供・異常の可能性が低い	スキャン試行、古い認証トークン使用など	基本は監視のみ（ルール改善の参考）

GuardDuty 検出結果タイプ

GuardDutyで検出される脅威は、AWSが定義している Finding Type（検出結果タイプ）
ごとに分類されています。

各 Finding Type の一覧と詳細説明は、AWS公式ドキュメントにまとめられています。

👉 GuardDuty 検出結果タイプ一覧（AWS公式）

具体的な検知内容や推奨アクションも網羅されていますので、
個別の検知内容を深く理解したい場合は上記一覧を参照するのがおすすめです。

対応の基本ポリシー（優先順位づけ）

GuardDuty の検出結果は、Severity（0〜8.9）に応じて
「どの程度の優先度で対応すべきか」を判断します。

以下は、一般的な優先順位づけの例です。

優先度	対応内容	例
高優先度（Critical / High）	即時対応・原因調査	資格情報漏えい、外部通信、ブルートフォース検知
中優先度（Medium）	影響範囲を確認・再発防止策検討	不審ドメインアクセス、匿名EKSアクセス
低優先度（Low）	ログ監視・傾向分析のみ	外部スキャン、古い権限ロール使用など

検知件数が多いときの対処ポイント

GuardDutyは AWS が提供するマネージドルールで動作しているため、
環境によっては過検知が多く発生する場合があります。

検知精度を高め、運用負荷を下げるためには以下のような調整が有効です。

対策	内容	効果
① ノイズフィルタリング	特定のドメイン／IPをホワイトリスト登録	不要な警告を削減
② Security Hub統合	全アカウントの検知を統合しSeverity順に管理	優先度の一元管理
③ EventBridge ルール連携	Critical検知のみ通知（SNS／Slack）	緊急時のみ即時通知
④ 定期レビュー運用	月次で検知傾向を分析しルール最適化	検知精度の維持と負荷軽減

特に本番環境では外部スキャンが頻発するため、
これらの対策を組み合わせることで 「本当に対応が必要な検知」に集中できる運用 が実現できます。

まとめ

Amazon GuardDutyについて、基本的な仕組みから検知内容、運用フローまで簡単にまとめました。

GuardDutyは 有効化するだけですぐに利用できる という手軽さが魅力ですが、
あくまで「検知専用」のサービスであり、防御や修復は行いません。

そのため、実際に重要度の高い検知が発生した際には、

• AWS WAF（Web攻撃の遮断）
• Security Group / NACL（ネットワーク遮断）
• IAM操作（資格情報の無効化）
• Amazon Inspector（脆弱性調査）
• EventBridge + Lambda（自動対応）

といった他のAWSサービスと連携しながら、
「検知 → 通知 → 対応 → 再発防止」の運用フローを整えることが運用フローを整えることが重要です。

この記事が、GuardDutyをこれから学ぶ方や、
脅威検知の第一歩を踏み出す際の参考になれば幸いです。

本記事の内容について、不足や誤りがあれば随時更新していきます。