Amazon GuardDuty徹底解説：AWSの脅威検知を“運用で効く形”にする設計術（GCP Event Threat Detection／Microsoft Defender for Cloud比較）
はじめに：GuardDutyは「入れる」より「運用の筋道」を作るほど強くなります
Amazon GuardDuty（以下、GuardDuty）は、AWS環境における不正・不審な挙動を検知するための脅威検知サービスです。GuardDutyは、CloudTrailイベント、VPCフローログ、DNSログなどのデータソースを分析して、疑わしい活動を検知すると公式ドキュメントに整理されています。
ここで大切なのは、GuardDutyは「アラートを出す箱」ではなく、“どの通知をどう扱うか”まで含めて設計するほど価値が出るサービスだという点です。検知が増えるほど、見る人が疲れてしまい、結局放置される──これはセキュリティ運用で起きがちな失敗です。
この記事では、GuardDutyを中心に、
- 何を見て、何を後回しにし、何を自動化するか
- 誤検知とノイズをどう抑えるか
- 料金の増え方をどう見積もるか
- マルチクラウド（GCP／Azure）では何が対応するか
を、実務で迷いにくい形にまとめますね。
比較対象として、GCP側はSecurity Command Centerの「Event Threat Detection」が、Cloud Loggingのログストリームを監視して脅威をほぼリアルタイムで検出する仕組みとして説明されています。
Azure側は「Microsoft Defender for Cloud」が、クラウドのセキュリティ体制管理と脅威保護を提供するサービスとして整理されています。
この記事が役に立つ方（具体的に）
まず、AWS上でプロダクトを運用していて「ログイン試行が増えた」「謎のスキャンが来る」「外部連携が増えて不正アクセスが怖い」と感じているバックエンド／SREのみなさまです。GuardDutyは、典型的な侵害の兆候を“見つけやすい形”で上げてくれるので、調査の初動が速くなります（ただし、運用設計がないとノイズに埋もれます）。
次に、情シス／セキュリティ担当として「脅威検知を入れていること」を監査・顧客要件として説明したい方です。GuardDutyは検知結果（Findings）が体系的に整理され、Finding typesが更新されることも公式に案内されています。
そして、GCP／Azureも併用していて、同じ“脅威検知の考え方”をクラウド横断で揃えたいアーキテクトの方です。GCPはEvent Threat DetectionがSCC Premiumで提供される組み込み検知として整理され、AzureはDefender for Cloudがマルチクラウド／ハイブリッドを含む保護として説明されています。
1. Amazon GuardDutyとは：何を材料に、どんな形で“疑わしさ”を出すのか
GuardDutyは、AWS環境で不正や予期しない活動を検出する目的で、複数の基盤データソースを分析するサービスとして説明されています。代表的な基盤データソースとして、CloudTrailイベントログ、CloudTrail管理イベント、S3のCloudTrailデータイベント、VPCフローログ、DNSログなどが挙げられています。
GuardDutyが出す結果は「Finding（検出結果）」です。Findingは、不審または悪意のある活動の兆候を検知したときに生成される通知だと説明されています。
ここが運用上の中心になります。つまり、GuardDuty導入は「Findingをどの粒度で、誰が、どの速度で処理するか」を決めることとセットです。
2. “設計の芯”は3つ：対象範囲、優先順位、処理フロー
2-1. 対象範囲：最初から全リージョン全アカウントで良い？
GuardDutyはリージョン単位で有効化される運用が基本になりやすく、マルチリージョンや複数アカウントだと、どこまでを一度に対象にするかで運用負荷が変わります。現場的には、まず「本番」「対外公開がある」「個人情報や決済がある」領域を優先し、ノイズの傾向を掴んでから広げるのが安定しやすいです。
2-2. 優先順位：全部を“重大”として扱わない
Finding typesは非常に多く、更新も入ります。公式ドキュメントでもFinding typesと更新の扱いが整理されています。
だからこそ、運用で最初に決めたいのは次のような優先度ルールです。
- すぐ対応（例：認証情報の悪用が疑わしい、権限昇格が疑わしい）
- 早めに調査（例：内部探索、異常な通信）
- 監視継続（例：ノイズが多いが傾向は見たい）
- 当面対象外（例：開発環境の既知の挙動）
この“扱いの分類”がないと、通知の山に負けてしまいます。
2-3. 処理フロー：検知→一次切り分け→二次調査→是正
GuardDutyは検知そのものがゴールではありません。運用のゴールは、
- 侵害が起きているなら止める
- 誤検知なら例外や運用ルールでノイズを減らす
- どちらでもないなら監視基準を改善する
ことです。これを実現するために、後述の「一次調査のテンプレ」と「自動化できる分岐」を用意しておくのがコツです。
3. サンプル：Finding対応の“現場で使える”一次調査テンプレ
ここでは、GuardDutyを導入した直後でも使える、一次調査の型を例として置きます。細部はチームや環境に合わせて調整してくださいね。
3-1. サンプル手順（10分でやる一次切り分け）
- Findingのタイプと対象リソースを確認する
- どのFinding typeか（分類）
- どのアカウント・リージョンか
- どの主体（ユーザー／ロール／インスタンス／アクセスキー等）に紐づくか
Finding typeが体系的に整理されているので、まずは分類で“重さ”を判断しやすいです。
- “いつから、どれくらいの頻度で”発生しているかを見る
- 瞬間的なスパイクか
- 継続的か
継続的なら自動化ボットや探索の可能性が高く、スパイクなら誤設定や一時的なイベントの可能性もあります。
- 影響が大きい可能性だけ、即時の安全策を先に打つ
- 該当のアクセスキーを一時停止／無効化
- 該当の主体の権限を一時的に絞る
- 外部公開の入口で明確に悪性が濃いIPを遮断（ただし巻き込み注意）
※この“止血”は組織の権限と手順が必要なので、あらかじめ誰ができるか決めておくのが大切です。
- 二次調査に回す条件を決めて、チケット化する
- 侵害の可能性が否定できない
- 再発している
- 重要資産に関係する
こういった条件を満たすものだけ、深掘りします。
このテンプレの狙いは、全件を深掘りしないことです。深掘りはコストが高いので、「やる価値が高いもの」をふるいにかける役割を一次対応に持たせます。
4. ノイズを減らす設計：誤検知は“運用改善の材料”として扱う
GuardDutyに限らず、脅威検知は必ずノイズが出ます。大切なのは、ノイズを放置せずに「なぜ出るか」を整理して運用に落とすことです。
4-1. 典型的なノイズ源
- 正規のセキュリティスキャン（脆弱性診断、ペネトレーションテスト）
- 社内の監視やジョブが発生させる一見不審なアクセス
- 開発環境の雑多な挙動
このようなものは「ノイズとして消す」のではなく、「いつ、誰が、何のために発生させるか」を明文化し、作業時刻や送信元などで切り分けしやすい形にします。結果として、誤検知の扱いが属人化しづらくなります。
4-2. Finding typesは変化する前提で見る
Finding typesは更新され、追加や変更があり得ることが示されています。
つまり、「去年の運用ルールが今年も最適」とは限りません。月次で「新しいタイプが増えていないか」「ノイズが増えた理由は何か」を棚卸しするだけでも、運用の疲弊を防ぎやすくなります。
5. 料金の考え方：GuardDutyは“分析量”に比例して増えます
GuardDutyの料金は、分析対象のログやイベント量に基づく形で提示されます。公式の料金ページでは、たとえばS3データイベント分析が「月あたりのイベント数（百万単位）」で段階課金される例が示されています。
実務的には、次の順で見積もると読みやすいです。
- どの分析を有効化するか（基盤データソース中心か、追加の分析を入れるか）
- どの環境がどれくらいのイベント量か（本番と開発は差が大きいことが多いです）
- 大量ログが出る領域（例：データイベント相当）がコストを押し上げないかを先に見る
「GuardDutyを入れたら高い」ではなく、「どのログ量に対してどの分析を走らせるか」を設計できる、と捉えると、コストも説明しやすくなります。
6. GCPとの比較：Event Threat Detectionは“Cloud Loggingのストリーム監視”が中心
GCP側では、Security Command Center（SCC）Premiumの組み込みサービスとしてEvent Threat Detectionが、組織またはプロジェクトを継続監視して脅威を近リアルタイムに検出する仕組みとして説明されています。
また、日本語ページでも「Cloud Loggingのロギングストリームをモニタリングし、脅威をほぼリアルタイムで検出する」と明記されています。
このため比較の軸としては、次が分かりやすいです。
- AWS GuardDuty：AWS内の基盤データソース（CloudTrail相当、VPC Flow Logs、DNS）を中心に検知
- GCP Event Threat Detection：Cloud Loggingストリームを監視して検知
どちらも「ログを材料に検知する」点は同じですが、GCPでは“Loggingを中心に据える”設計がより前面に出る印象があります。運用としては、ログの整備（どの監査ログを有効化し、保持し、どこまで分析するか）が品質を左右します。
7. Azureとの比較：Defender for Cloudは“体制管理＋脅威保護”を包括的に扱う
Microsoft Defender for Cloudは、Azure、ハイブリッド、マルチクラウドのリソースを保護するためのセキュリティサービスとして紹介されています。
この説明から読み取れる実務的な違いは、Azure側が「脅威検知」単体よりも「姿勢管理（CSPM）＋脅威保護」を包括的に扱う方向に寄っている点です。
GuardDutyは“脅威検知（検出結果）”の中核として使いやすい一方、Azure側ではDefender for Cloudの中で、リソース種別ごとの保護（Servers/Containers/Storage等）や、監視・推奨事項も含めた運用に統合されやすいです。
つまり、比較の仕方としては、
- AWS：GuardDutyを中心に検知 → ほかの統合サービスや運用で処理フローを作る
- Azure：Defender for Cloudの枠内で、検知と体制管理をまとめて運用する
という「運用の束ね方」の差が出やすいです。
8. 失敗しない導入チェックリスト：最初の2週間で決めたいこと
最後に、GuardDuty導入で後から効いてくる“決めごと”を、チームで使える形にまとめます。
- 対象範囲（どのアカウント／どのリージョン／どの環境）
- 優先度ルール（Finding typeをどう分類し、誰がどれを何分以内に見るか）
- 一次調査テンプレ（10分で切り分けできる項目を固定化）
- ノイズの扱い（正規スキャンや監視をどう記録し、どこまで例外にするか）
- 自動化の境界（“止血”まで自動にするのか、“通知とチケット化”までにするのか）
- コストの見積もり方法（どの分析が、どのログ量に比例するか）
- 月次棚卸し（新しいFinding type、ノイズ増、運用負荷の変化をレビューする）
この7つが決まると、GuardDutyは「入れたけど見ない」から抜け出しやすくなります。
まとめ：GuardDutyは“検知の正しさ”より“運用の継続性”で価値が決まります
Amazon GuardDutyは、CloudTrailイベント、VPCフローログ、DNSログなどのデータソースを分析して不審な活動を検出し、Findingとして通知する脅威検知サービスです。
ただし、検知サービスは「全部を深掘りしない」設計が重要です。一次対応テンプレでふるいにかけ、優先度ルールで対応を揃え、ノイズは運用改善の材料として扱う。この循環が作れるほど、GuardDutyは“役に立つアラート”へ育ちます。
GCPではSCC PremiumのEvent Threat DetectionがCloud Loggingストリームを監視して脅威を検出する仕組みとして整理され、AzureではDefender for Cloudがマルチクラウドも含む保護を提供するサービスとして説明されています。
マルチクラウドでも共通なのは、「検知→分類→調査→是正→改善」の運用ループを作ることです。まずは小さく、でも運用のルールは丁寧に。そう始めるのが、いちばん失敗しにくいと思います。