Amazon GuardDutyとは｜AWSの脅威検出の仕組みと運用・料金

Amazon GuardDutyとは｜ログ分析型の脅威検出サービス

GuardDutyは、AWS環境のデータソースとログを継続的にモニタリングして、疑わしいアクティビティを検出するサービスです。悪意のあるIPアドレスやドメインのリスト、ファイルハッシュ、機械学習モデルといった脅威インテリジェンスを使って判定します。利用者側でログ収集基盤を組む必要はありません。

ここが、SIEMを自前で構築する場合との最大の違いです。ログの集約先を決め、パーサを書き、相関ルールを育てる——その一連の作業が不要になります。

できること・できないことを先に押さえておくと、以降の判断が速くなります。

有効化と同時に取り込まれる3つの基盤データソース

GuardDutyをAWSアカウントで有効にすると、以下の基盤データソースの取り込みが自動的に始まります。追加の設定は要りません。

注意したいのは、これらのログをGuardDutyが分析するために、利用者がCloudTrailの証跡やVPCフローログを別途「有効化」する必要はない点です。GuardDutyはAWS側で独立してこれらを取得します。自分で作成したCloudTrail証跡やフローログの料金とは別勘定になります。

CSPM・WAF・SIEMとの役割の違い

守備範囲が重なって見えるサービスが多いので、先に整理しておきます。

クラウドの設定不備対策そのものはCSPMとは｜クラウド設定不備対策の実務と案件単価・必要スキルで詳しく扱っています。ログ集約とSIEMの基本はSplunkとは｜ログ分析とSIEMの基本・フリーランス案件単価を解説、アプリ層の防御はWAFとは｜仕組み・種類とファイアウォールとの違い・運用のコツを参照してください。

実務では、この4つは競合しません。GuardDutyが検出し、SIEMが文脈を補い、CSPMが再発の温床を潰す、という組み合わせになります。ゼロトラストとは｜境界型との違い・主要技術・案件動向を解説で整理されている考え方とも接続する領域です。

ミニFAQ：GuardDutyを入れればSIEMは不要ですか

不要にはなりません。GuardDutyは検出に特化しており、ログの長期保管や、AWS以外のシステムを含めた横断調査はカバーしません。監査要件でログ保管期間が決まっている場合は、別途S3やSIEMへの集約が必要です。

GuardDutyが検出できる脅威と保護プラン

GuardDutyの検出範囲は、有効化しただけで動く「基本の脅威検出」と、個別に有効化する「保護プラン」の二階建てになっています。

基本の脅威検出でわかること

AWS公式ドキュメントでは、GuardDutyが検出できる脅威シナリオとして次のようなものが挙げられています。

• 漏洩したAWS認証情報の不正利用

• EC2インスタンスやコンテナワークロードでの不正なクリプトマイニング

• データの持ち出しや破壊によるランサムウェアイベント

• EC2インスタンスやコンテナワークロード上のマルウェアの存在

• EKSクラスター、ECS、Fargateタスクでの不正な挙動

出典はAmazon GuardDuty とは（AWS公式ドキュメント）です。

保護プランと有効化の判断

保護プランは、基盤データソース以外のログやイベントを追加で監視する仕組みです。2026年11月時点でAWS公式ドキュメントに掲載されている保護プランは次のとおりです。構成は随時追加・改称されるため、採用前に公式ドキュメントで最新の一覧を確認してください。

ここで重要なのが、初めてGuardDutyを有効化したアカウントでは、Runtime Monitoringを除く保護プランが自動で有効になり、30日間の無料トライアルの対象になるという挙動です（2026年11月時点の公式ドキュメント記載）。既存利用者のアカウントでは、あとから追加された保護プランは自動では有効になりません。この非対称さが、コスト見積もりを狂わせる原因になります。有効化の挙動はサービス側の変更を受けるため、実際に何がオンになっているかはGuardDutyコンソールの保護プラン画面で確認してください。

なお Malware Protection for S3 だけは、GuardDuty本体を有効にしなくても単独で使えます（Malware Protection for S3（AWS公式ドキュメント））。

EKS前提の環境で検討する場合は、Kubernetesとは？仕組み・Dockerとの違い・フリーランス案件の単価をエンジニア視点で解説もあわせて確認しておくと、ランタイムモニタリングの負荷感が掴みやすくなります。

Extended Threat Detection（拡張脅威検出）

単体では脅威に見えない複数のイベントが、疑わしい順序で観測されたとき、GuardDutyはそれを「攻撃シーケンス」として識別します。これがExtended Threat Detectionです。

この機能は、GuardDutyを有効にしたアカウントで追加コストなしに自動で有効になります。ユースケース別の保護プランを有効にする必要はありません。ただしS3リソースに影響する多段攻撃を捉えるには、S3 Protectionの有効化がAWSから推奨されています。

後述する抑制ルールと相互作用するため、ここは覚えておいてください。

検出結果（Findings）の読み方

検出結果が出たときに最初にやることは、タイプ名と重大度を見て「いま動くべきか」を決めることです。

検出結果タイプの命名規則

GuardDutyの検出結果タイプは、決まったフォーマットで命名されています。

ThreatPurpose:ResourceTypeAffected/ThreatFamilyName.DetectionMechanism!Artifact

分解すると次のようになります。

• ThreatPurpose — 脅威の目的、攻撃の種類、または攻撃段階

• ResourceTypeAffected — 標的になったAWSリソースの種類

• ThreatFamilyName — 検出している脅威・不正活動の内容

• DetectionMechanism — 検出方法。.Custom は独自の脅威リスト由来、.Reputation はドメイン評価スコアモデル由来

• Artifact — 悪用に使われた具体的なリソース（任意項目。付かない場合もある）

たとえば Recon:EC2/PortProbeUnprotectedPort なら、「偵察目的（Recon）で、EC2インスタンス（ResourceTypeAffected）の保護されていないポートが探索されている」と、名前だけで読み取れます。アラートの一覧を眺める段階で当たりを付けられるので、この規則は覚えておく価値があります。

ThreatPurposeの主な値

ThreatPurposeの一部はMITRE ATT&CKのタクティクスに対応しています。実務で頻出するものを抜粋します。

Policy や Pentest のように、「攻撃とは限らないが見逃したくない」区分があるのが特徴です。社内の脆弱性診断が Pentest として上がってくるのは、仕様どおりの動きです。

重大度4区分と初動の目安

重大度は1.0〜10.0の数値で、4段階に区分されます。数値が大きいほどリスクが高いことを示します。

詳細はGuardDuty の検出結果の重大度（AWS公式ドキュメント）を確認してください。

現場では、この表をそのままエスカレーション基準に落とし込むのが最短です。重大・高は即時連絡、中は当日中の一次調査、低は週次レビューでまとめて確認、といった具合に。判断基準を文書化しておくと、夜間や休日の当番でも迷いません。

ミニFAQ：重大度「中」が大量に出て手が回りません

中は「通常と違う」止まりの判定なので、環境の個性がそのまま出ます。同じタイプが繰り返し出て、かつ毎回「許可された活動」と結論が出ているなら、次章の抑制ルールの対象です。ただし抑制は「繰り返し誤検知だと確認できたもの」に限って、事後的に作るのが原則です。

有効化から通知までの設定手順

GuardDutyの有効化自体はコンソールから数分で完了します。手間がかかるのは、その後の通知導線です。

有効化（リージョン単位）

GuardDutyはリージョン単位のサービスです。使っていないリージョンも含めて有効化するかどうかは、方針を先に決めておきます。未使用リージョンで不審なAPI呼び出しが起きるケースは珍しくないため、全リージョン有効化を選ぶ組織もあります。

EventBridge経由で通知を飛ばす

検出結果に変化があると、GuardDutyはイベントを作成します。これをAmazon EventBridgeとは｜仕組み・料金と他サービスの使い分けで受けて、SNSやチャットツール、チケットシステムへ流すのが定番の構成です。

ここで重大度によるフィルタを噛ませておかないと、低重大度の通知でチャンネルが埋まります。最初から全部流す設計にしないことが、アラート疲れを防ぐ第一歩になります。

Security Hub・Detectiveとの連携

AWS Security Hub CSPM と組み合わせると、複数サービスの検出結果を集約して優先順位付けできます。Amazon Detective は、検出結果の根本原因調査を支援するサービスで、ログデータを自動収集して可視化します。

ISMSやSOC 2のようなフレームワーク対応を並行して進めている現場では、ISMS・SOC2取得支援案件｜フリーランスの実装・証跡業務と単価で触れられている証跡の要求とも絡んできます。「検出していること」だけでなく「検出後の運用手順が定義されていること」を求められるためです。

マルチアカウント運用（AWS Organizations）

アカウントが1つで済む案件は、現場ではむしろ少数派です。

委任管理者と自動有効化

複数アカウント環境の管理方法は、AWS Organizations を使う方式（AWS推奨）と、従来の招待方式の2つがあります。Organizations方式では、管理アカウントがGuardDutyの委任管理者を指定し、委任管理者が組織全体の検出結果を一元的に扱います。

新規アカウントを組織に追加したときに自動でGuardDutyを有効化する設定を入れておかないと、気づかないうちに監視対象から漏れたアカウントが生まれます。棚卸しのタイミングで必ず確認したい項目です。

抑制ルールを作れるのは管理者だけ

マルチアカウント環境では、抑制ルールを作成できるのはGuardDuty管理者（委任管理者）のみです。メンバーアカウント側の担当者が「自分のアカウントの誤検知を自分で畳む」ことはできません。

これは運用設計に直接響きます。誤検知の抑制申請を受け付ける窓口と、承認のルールを決めておかないと、管理者にリクエストが溜まり続けます。

誤検知とアラート疲れへの対処｜抑制ルールの実務

GuardDuty運用でいちばん時間を取られるのが、ここです。

抑制された検出結果はどう扱われるか

抑制ルールは、条件に一致する新しい検出結果を自動的にアーカイブする仕組みです。挙動を正確に押さえておきます。

• 抑制された検出結果は、AWS Security Hub CSPM・Amazon S3・Amazon Detective・Amazon EventBridge のいずれにも送信されません。SIEMやチケットシステム側のノイズが消えます

• Malware Protection for EC2 を有効にしている場合、抑制された検出結果はマルウェアスキャンを起動しません

• GuardDutyは抑制ルールに一致する検出結果も生成し続けますが、自動的に「アーカイブ済み」としてマークします

• アーカイブされた検出結果はGuardDuty内に90日間保存され、その期間中はコンソールの Archived から閲覧できます

つまり「消える」のではなく「通知経路から外れる」のが抑制です。あとから見返せる点は、監査対応でも効いてきます。詳細はGuardDuty の抑制ルール（AWS公式ドキュメント）にまとまっています。

定番の誤検知4パターンと抑制条件

AWSが公式に「抑制ルールのよくあるユースケース」として挙げている検出結果タイプを、環境の特徴とセットで整理しました。自分の案件に当てはまるものがないか確認してみてください。

コンテナ環境では、もうひとつ定番があります。Kubernetesクラスターは coredns のようなDNSサーバーをPodとして動かすため、Podからの1回の名前解決に対してGuardDutyが2つのDNSイベント（Pod側とサーバーPod側）を取得し、DNS系の検出結果が重複することがあります。この場合は実行ファイルのパスやSHA-256をフィルタ条件に使います。

もうひとつ、Dockerソケットへのアクセスを検出する PrivilegeEscalation:Runtime/DockerSocketAccessed も、正当な理由でソケットにアクセスするコンテナがある環境では繰り返し上がります。

広すぎる抑制はExtended Threat Detectionを壊す

ここは見落とされやすい論点です。

抑制ルールでアーカイブされた検出結果は、Extended Threat Detectionが攻撃シーケンスを相関分析する際のシグナルとして使われません。たとえば「EKSクラスター関連の検出結果をすべて抑制する」という雑なルールを作ると、コンテナを侵害して特権トークンを取得し機密リソースへアクセスする、という多段攻撃をGuardDutyが検出できなくなります。

AWSが示している原則はシンプルです。

1. 抑制ルールは、既知の信頼できる活動からのアラートを減らす目的で使い続けてよい

2. ただし、検出結果を出したくない特定の挙動に絞り込んでおく

3. 抑制ルールは事前にではなく、自環境で繰り返し誤検知だと確認できたものに対して事後的に作る

「とりあえずこのタイプは全部切る」が最も危ない運用になります。

フリーランス案件でのGuardDuty｜求められる役割

GuardDutyが案件要件に単独で書かれることは、あまりありません。登場の仕方はだいたい3パターンに分かれます。

案件でのGuardDutyの登場パターン

1. クラウドインフラ案件の運用項目のひとつ — EC2・S3・RDSといった基盤構築に付随して、監視・セキュリティの設定項目として出てくる形です。構築フェーズの終盤に一式まとめて求められます

2. セキュリティ運用（SOC・監視）案件の検知ソースのひとつ — Security HubやSIEMへの集約前提で、検出結果のトリアージ手順やエスカレーションフローの設計を任されるケースです

3. ガバナンス・監査対応案件での整備項目 — マルチアカウント全体への展開、委任管理者の設計、証跡としての検出結果の扱いを整える仕事です

1に近いほどインフラ寄り、3に近いほどガバナンス寄りの役割になります。クラウド案件の参入順序｜AWS・Azure・GCPどれから取るかの判断軸で整理されているように、まずAWSの基盤運用で実績を作ってから2・3へ広げる順序が現実的です。

評価されやすいスキルの組み合わせ

GuardDutyの有効化そのものはボタン操作に近く、それだけでは評価されません。実務で効くのは次の組み合わせです。

• 検出結果タイプと重大度を踏まえたトリアージ基準を、運用ドキュメントに落とせること

• EventBridgeやSNSを使った通知フローをIaCで再現可能にできること

• マルチアカウント構成（Organizations・委任管理者）を踏まえて展開設計ができること

• 誤検知を抑制ルールで畳む際に、Extended Threat Detectionへの影響まで説明できること

• 請求を見て、どの保護プランがコストを押し上げているか切り分けられること

最後の項目は意外と差がつきます。セキュリティ機能のコスト説明ができる人は、そう多くありません。

AWS全般の知識を体系立てて示したい場合はAWS認定資格一覧【2026年最新】全12種の難易度・受験料とおすすめ取得順、脅威動向の押さえ方は情報セキュリティ10大脅威2026｜組織編の全順位とエンジニアの対策が参考になります。

単価はGuardDuty単体ではなく職種レイヤーで決まる

単価レンジは「GuardDutyができるか」ではなく、AWS運用エンジニアとして入るのか、セキュリティエンジニアとして入るのかで決まります。レンジの実数は、職種別にまとめたAWSエンジニア フリーランスの単価相場｜経験・案件レイヤー別に解説とセキュリティエンジニアのフリーランス単価相場｜案件動向とスキル別レンジを確認してください。単価を体系的に上げる考え方はフリーランスエンジニアの単価相場と単価の上げ方で整理しています。

自分がいまどのレンジを狙えるか把握しておきたい方は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。案件を具体的に見る場合はセキュリティエンジニアの案件一覧から、監視・運用の要件が自分の経験と合うかを確認するのが早いです。条件の優先順位の付け方は案件の選び方｜フリーランスエンジニアが単価・稼働・スキルで決める優先順位にまとめています。

料金体系とコストが膨らむポイント

結論として、GuardDutyの費用は「リージョン」「有効にした保護プラン」「分析されたログ量」の3つで決まります。初期費用や月額固定費はなく、全額が従量課金です。したがって同じ構成でも環境ごとに金額は変わるため、実額は対象リージョンを指定したうえで公式の料金ページと料金計算ツールで見積もってください。

課金単位の一覧

単価はリージョンによって異なります。金額はAmazon GuardDuty の料金（AWS公式）と料金計算ツールで、対象リージョンを指定して確認してください。

コストが読みにくくなる3つの要因

• 初回有効化で保護プランが自動オンになる — ランタイムモニタリング以外は自動で有効化され、30日間の無料トライアルに含まれます。トライアル中は請求が出ないため、31日目に初めて実額が見えます

• VPCフローログとDNSログがGB課金 — 通信量に比例するので、トラフィックの多い環境では基盤データソースだけで無視できない額になります

• ランタイムモニタリングはvCPU課金 — コンテナのスケール設計がそのままコストに跳ね返ります。オートスケールで台数が増える環境では見積もりの幅が大きくなります

無料トライアル中は、コンソールの使用量（Usage）画面で「トライアルが終わったらいくらになるか」の推定が見られます。31日目を待たずに、ここで確認しておくのが実務上の鉄則です。

ミニFAQ：使っていないリージョンでも課金されますか

有効化しているリージョンで分析対象のログ・イベントが発生していなければ、その分の課金は発生しません。ただし未使用のつもりのリージョンでもCloudTrail管理イベントはゼロにならないことがあるため、請求を一度確認しておくと安心です。

導入・運用チェックリスト

参画初期に確認しておきたい項目をまとめました。既存環境の引き継ぎでも、新規構築でも使えます。

有効化の設計

• ☐

  対象リージョンの方針は決まっているか（全リージョンか、利用リージョンのみか）

• ☐

  AWS Organizations の委任管理者は誰か。招待方式が残っていないか

• ☐

  新規アカウントの自動有効化は設定されているか

• ☐

  有効化されている保護プランと、その選定理由が説明できるか

検出後の運用

• ☐

  重大度ごとのエスカレーション基準が文書化されているか

• ☐

  EventBridgeの通知が重大度でフィルタされているか

• ☐

  検出結果の一次調査を誰がどの時間帯に担うか決まっているか

• ☐

  Security Hub・Detective・SIEMへの連携経路が重複していないか

抑制ルール

• ☐

  既存の抑制ルールの作成理由が記録されているか

• ☐

  検出結果タイプ全体を切るような広すぎるルールがないか

• ☐

  抑制申請の受付と承認のフローが決まっているか

• ☐

  Extended Threat Detectionへの影響を検討した形跡があるか

コスト

• ☐

  使用量（Usage）画面でプラン別の内訳を確認したか

• ☐

  無料トライアルの終了日を把握しているか

• ☐

  コストを押し上げている保護プランと、それが必要な理由を説明できるか

まとめ

GuardDutyは数分で有効化できますが、価値が出るのは検出結果を捌く運用を設計してからです。有効化はスタート地点にすぎません。

• 基盤データソース（CloudTrail管理イベント・VPCフローログ・DNSログ）は有効化と同時に自動で取り込まれる

• 保護プランは初回有効化時にRuntime Monitoring以外が自動でオンになり、30日の無料トライアルの対象になる（2026年11月時点）

• 重大度は1.0〜10.0の4区分。重大（9.0〜10.0）と高（7.0〜8.9）を即時対応の線引きにするのが実務的

• 抑制ルールはSecurity Hub・S3・Detective・EventBridgeへの送信を止める。アーカイブは90日間参照できる

• 抑制範囲を広げすぎるとExtended Threat Detectionの相関分析が機能しなくなる。特定の挙動に絞り、事後的に作る

• マルチアカウント環境で抑制ルールを作れるのは委任管理者のみ。申請と承認のフローを先に決めておく

次の一歩としては、参画している環境で使用量（Usage）画面を開き、どの保護プランが有効になっていて、どこにコストがかかっているかを確認してみてください。そこから運用の穴が見えてきます。

なお本記事の仕様・保護プラン構成・課金単位は2026年11月時点でAWS公式ドキュメントに記載されている内容をもとにしています。AWSのサービス仕様は随時更新されるため、実際の設定や費用の判断にあたっては最新の公式ドキュメントと、所属組織のセキュリティポリシー・社内の有識者の確認を優先してください。

参照した一次情報

• Amazon GuardDuty とは（AWS公式ドキュメント）

• GuardDuty の検出結果の重大度（AWS公式ドキュメント）

• GuardDuty finding format（AWS公式ドキュメント）

• Suppression rules in GuardDuty（AWS公式ドキュメント）

• Amazon GuardDuty の料金（AWS公式）