--- title: "Amazon GuardDutyの料金：東京リージョンの実額とMalware Protectionの追加課金を検証" url: "https://www.issoh.co.jp/tech/details/17313/" published: 2026-09-04 updated: 2026-10-17 categories: ["セキュリティ"] publisher: "株式会社一創" --- # Amazon GuardDutyの料金：東京リージョンの実額とMalware Protectionの追加課金を検証 GuardDutyの料金を調べると「ログ量に応じた従量課金です」で終わる解説が並びます。見積もりを作る側が知りたいのは、東京リージョンで1GBいくらなのか、保護プランを足すと月額がどれだけ動くのか、という数字のほうでしょう。この記事では AWS Price List API の ap-northeast-1 オファーから取り出した実額をもとに、課金単位ごとの単価、Malware Protectionで請求が跳ねる仕組み、使用量をCLIで測る手順、3構成の月額試算を整理しました。単価はリージョンと時点で変わるため、記載は2026年8月31日公開のオファーファイル基準です。 ## まとめ：GuardDutyの料金は基本2項目で決まり保護プランごとに上乗せされる GuardDutyの請求は、まず基本の脅威検出2項目で土台が決まります。CloudTrail管理イベントの件数と、VPCフローログ・DNSログのデータ量です。東京リージョンでは前者が100万件4.72USD、後者が初回500GBまで1GB 1.18USDでした。EC2が10台程度なら月額100USDに届きません。 額が動くのは保護プランを足したときです。ランタイムモニタリングは1vCPUあたり月2.00USDでvCPU数に比例し、Malware Protection for S3はスキャンしたデータ量とスキャンリクエスト数の両方で課金されます。後者はアップロードの多いバケットで基本料金を上回ることがあり、月額が倍近くまで動く要因になっていました。 判断の順序は単純です。まず有効化して30日間の無料トライアルで実使用量を測り、`get-usage-statistics` で機能ごとの内訳を確認してから、保護プランを1つずつ足す。この順序なら請求書を見て驚く事態は避けられます。GuardDutyそのものの役割はAmazon GuardDutyとはで整理しました。 ## 東京リージョンの実額単価を課金単位ごとに並べて請求の内訳を把握する AWSの[GuardDuty料金ページ](https://aws.amazon.com/jp/guardduty/pricing/)は保護プランごとにタブが分かれ、全体を一覧しづらい構成です。単価は [AWS Price List API の東京リージョン向けオファーファイル](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonGuardDuty/current/ap-northeast-1/index.json)にJSONで公開されているので、そこから抜き出して1枚に並べました。 ### 基本の脅威検出はCloudTrail管理イベントとログ量の2軸で決まる 基本の脅威検出は無効化できない土台の部分で、CloudTrail管理イベントとVPCフローログ・DNSログを分析します。CloudTrail管理イベントは1件あたり0.00000472USD、つまり100万件で4.72USDでした。階層割引がなく件数に正比例します。監査ログ側は[AWS CloudTrailとは](/tech/details/17649/)で扱いました。 誤解しやすいのが、CloudTrailやVPCフローログ側で設定したフィルタリングはGuardDutyの処理対象に影響しない、という仕様です。[公式ユーザーガイドの使用状況モニタリングの章](https://docs.aws.amazon.com/ja%5Fjp/guardduty/latest/ug/monitoring%5Fcosts.html)に明記されています。証跡を絞ってもGuardDuty側の分析量は減りません。サービス内部で独立にイベントを取得しているためです。 | 課金対象 | 東京リージョンの単価 | | ----------------- | -------------------- | | CloudTrail管理イベント | 100万件あたり4.72USD | | VPCフローログ・DNSログ | 1GB 1.18USD（初回500GB） | | S3データイベント | 100万件あたり1.04USD | | EKS監査ログ | 100万件あたり2.48USD | | ランタイムモニタリング | 1vCPU 月2.00USD | | RDS Protection | 1vCPU 月1.33USD | | Lambda Protection | 1GB 1.18USD | | EC2マルウェアスキャン | 1GB 0.05USD | | S3マルウェアスキャン | 1GB 0.1185USD | | AI Protection | 1GB 1.18USD | ### VPCフローログとDNSログに効く4段階のボリュームディスカウント ログ量側には階層があり、量が増えるほど1GBあたりの単価が下がります。東京リージョンでは初回500GBまでが1.18USD、以降0.59USD・0.29USD・0.17USDと下がり、最上位は最初の階層の7分の1以下でした。 | 月間データ量 | 1GBあたりの単価 | | --------------- | --------- | | 初回500GBまで | 1.18USD | | 500GB超2,500GBまで | 0.59USD | | 2,500GB超1万GBまで | 0.29USD | | 1万GB超 | 0.17USD | この階層はLambda ProtectionのネットワークログとAI Protectionのデータイベントにも同じ数字が適用されていました。3系統のログ課金が同一の単価表を共有している形です。組織で複数アカウントを運用しているなら、委任管理者の使用状況ページで実効単価を確認してから見積もりを固めてください。 ### 保護プランごとの上乗せ単価とvCPU単位で課金される3つのプラン vCPU単位の課金になるのはランタイムモニタリングとRDS Protectionです。ランタイムモニタリングはEC2・EKS・Fargateのいずれも同一単価で、500vCPUまでが月2.00USD、500超5,000までが1.00USD、5,000超が0.33USDという3段階でした。RDS Protectionはプロビジョンドが1vCPU月1.33USD、AuroraのACU単位が1ACU月0.33USDです。稼働しているだけで積み上がる反面、vCPU数は事前に数えられるので試算の精度は高く出せます。 ## Malware Protectionの追加課金が発生する条件をスキャン対象別に切り分ける 請求額の予想が外れる原因のほとんどはMalware Protectionです。[公式ユーザーガイドのMalware Protectionの章](https://docs.aws.amazon.com/ja%5Fjp/guardduty/latest/ug/malware-protection.html)のとおり、EC2向けとS3向けで別に課金され、さらに実行型とオンデマンドで単価が分かれています。 ### EC2のマルウェアスキャンはEBSボリューム容量で課金される Malware Protection for EC2の実行型スキャンは、GuardDutyがEC2やコンテナで疑わしい挙動を検出したときに、対象インスタンスのEBSボリュームのスナップショットを取ってスキャンします。東京リージョンの単価はスキャンしたEBSボリューム1GBあたり0.05USDでした。 見積もりを外すのは、スキャン対象がボリュームの割り当てサイズではなく実データ量である点を読み違えたときです。500GBのボリュームに20GBしか入っていなければ課金対象は小さく収まります。反面、検出のたびにスキャンが走るため検出件数が多い環境では回数が効いてきました。深掘りには[Amazon Detectiveとは](https://www.issoh.co.jp/tech/details/15896/)で扱った調査基盤を併用してください。 ### S3のマルウェアスキャンはデータ量とリクエスト数で二重に課金される Malware Protection for S3は課金軸が2本あります。スキャンしたデータ量が1GBあたり0.1185USD、スキャンリクエストが1,000件あたり0.282USDです。前者だけで試算すると、小さいファイルを大量にアップロードするバケットで大きく外します。 たとえば平均2.5MBのファイルを月200万個アップロードするバケットなら、データ量は約5,000GBで592.50USD、リクエストは200万件で564USD、合計1,156.50USDになります。リクエスト側がデータ量側とほぼ同額です。ユーザー投稿を受けるバケットでは、この二重課金を前提に対象バケットを絞り込む設計が要ります。 ### オンデマンドスキャンとAWS Backupスキャンは別単価になる 手動で走らせるオンデマンドスキャンは、EBSボリューム由来が1GB 0.05USD、スナップショットやAMI由来が1GB 0.083USDでした。AWS Backupのリカバリポイントスキャンも0.083USDです。同じ「マルウェアスキャン」でも対象がボリュームかスナップショットかで単価が1.66倍違います。しかもオンデマンドスキャンは無料トライアルの対象外で、初日から課金が始まりました。 ## 無料トライアルの適用範囲を保護プランごとに読み分けて試算に使う GuardDutyには初回有効化から30日間の無料トライアルが付きます。[公式ユーザーガイドの料金の章](https://docs.aws.amazon.com/ja%5Fjp/guardduty/latest/ug/guardduty-pricing.html)では、対象・対象外がプランごとに整理されていました。 ### 30日間の無料トライアルの対象になる保護プランと対象外になる2つ トライアル対象は、基本の脅威検出、S3 Protection、EKS Protection、ランタイムモニタリング、RDS Protection、Lambda Protection、AI Protection、Malware Protection for EC2の実行型スキャンです。対象外は前述のオンデマンドスキャンとMalware Protection for S3の2つで、後者には別枠の無料利用枠があります。 実務で効くのは、既存アカウントが後から新しい保護プランを有効化したとき、そのプランに独自の30日間トライアルが付く仕様です。数年動かしている環境でも、AI Protectionを新たに入れる際は実使用量を無料で測れます。段階導入と相性の良い設計でした。 ### リージョン単位とアカウント単位で無料トライアルが再度始まる条件 トライアルはリージョンごと、かつアカウントごとに提供されます。東京リージョンで使い切っていても、大阪リージョンで初めて有効化すれば新たに30日間が始まりました。Organizations配下でメンバーアカウントを追加した場合も同様です。まず1アカウント1リージョンで測り、単位あたりの使用量を横展開する進め方が取れます。アカウント基盤の考え方は[AWS IAM Identity Centerとは](https://www.issoh.co.jp/tech/details/15900/)で整理しました。 ## 自社環境の請求額をCLIとCloudWatchメトリクスで先に実測する手順 見積もりの精度を上げる近道は、料金表から逆算せずに自分の環境の使用量を先に測ることです。GuardDutyには使用量を機能別に返すAPIとCloudWatchメトリクスの両方があります。 ### get-usage-statisticsで機能別の使用額をCLIから取得する まず検出器IDを取り、機能別の使用額をUSDで集計します。[AWS CLIリファレンスのget-usage-statistics](https://docs.aws.amazon.com/cli/latest/reference/guardduty/get-usage-statistics.html)にあるとおり、必須パラメータは検出器ID・集計タイプ・集計条件の3つです。 ``` # 東京リージョンの検出器IDを取得する aws guardduty list-detectors --region ap-northeast-1 # 機能別の使用額をUSDで集計する（直近30日分が返る） aws guardduty get-usage-statistics \ --region ap-northeast-1 \ --detector-id YOUR_DETECTOR_ID \ --usage-statistic-type SUM_BY_FEATURES \ --usage-criteria '{"Features":["CLOUD_TRAIL","FLOW_LOGS","DNS_LOGS","S3_DATA_EVENTS","EKS_AUDIT_LOGS","EBS_MALWARE_PROTECTION","EC2_RUNTIME_MONITORING","AI_PROTECTION"]}' \ --unit USD # 組織で機能別に使用額の多いアカウントを並べる aws guardduty get-usage-statistics \ --region ap-northeast-1 \ --detector-id YOUR_DETECTOR_ID \ --usage-statistic-type TOP_ACCOUNTS_BY_FEATURE \ --usage-criteria '{"Features":["FLOW_LOGS","EBS_MALWARE_PROTECTION"]}' \ --unit USD ``` 集計タイプは6種類あり、内訳確認なら SUM\_BY\_FEATURES、犯人捜しなら TOP\_RESOURCES が使いやすい形でした。返るのは直近30日分で、有効化直後は30日に満たない実績しか含まれません。コンソールの推定コストは30日へ引き延ばした月次見積もりなので、両者は一致しない前提で読んでください。 ### CloudWatchのGuardDuty名前空間で使用量を有効化前に読む GuardDutyは名前空間 AWS/GuardDuty に時間単位のメトリクスを発行します。AnalyzedCount（CloudTrail管理イベント）、AnalyzedBytes（VPC・DNSログ）、MonitoredVcpuHours、MonitoredAcuHours、ScannedBytes が24時間以内に公開されました。バイト単位のメトリクスは1GB＝1,073,741,824バイトで割ってから単価を掛けてください。1,000,000,000で割ると7%ほど過小に見積もることになります。 ### Cost Explorerで使用タイプ別に請求実績を分解して確認する トライアル終了後の実請求は、使用タイプ別に分解すると原因が一目で分かります。東京リージョンの使用タイプ名は APN1- で始まり、APN1-PaidEventsAnalyzed-Bytes がVPC・DNSログ、APN1-PaidEC2vCPUMonitored がランタイムモニタリングに対応します。 ``` aws ce get-cost-and-usage \ --time-period Start=2026-08-01,End=2026-09-01 \ --granularity MONTHLY \ --metrics UnblendedCost \ --group-by Type=DIMENSION,Key=USAGE_TYPE \ --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon GuardDuty"]}}' ``` この出力の使用タイプ名を先ほどの単価表と突き合わせれば、どの課金軸が膨らんだかが金額で特定できます。設定変更の履歴側は[AWS Configとは](https://www.issoh.co.jp/tech/details/15616/)で扱った記録と突き合わせると、いつの変更が請求を動かしたかまで追えます。 ## 3つの構成で月額を試算して請求が跳ねる原因を金額ベースで切り分ける 単価表だけでは規模感がつかめないので、3つの構成で月額を試算しました。いずれも東京リージョン・1アカウント・2026年8月31日時点の単価による計算です。 ### 小規模構成と本番EKS構成で月額がどこまで開くかを金額で試算する 小規模構成として、EC2 10台、CloudTrail管理イベント300万件、VPC・DNSログ60GBを置きます。CloudTrailが3×4.72で14.16USD、ログが60×1.18で70.80USD、合計84.96USDでした。 本番EKS構成はこうなります。CloudTrail管理イベント2,000万件で94.40USD、VPC・DNSログ800GBは階層をまたいで500×1.18＋300×0.59＝767USD、EKS監査ログ5,000万件で124USD、ランタイム200vCPUで400USD。合計1,385.40USDと、小規模構成の16倍を超えました。 ### マルウェアスキャンを足した瞬間に月額が倍近くまで増える具体例 3つ目は本番EKS構成にMalware Protectionを足した形です。EC2側の実行型スキャンがEBS 2,000GBで100USD、S3側が前述の5,000GB・200万リクエストで1,156.50USD。基本部分の1,385.40USDに1,256.50USDが上乗せされ、合計2,641.90USDになりました。月額はほぼ倍です。 この増分のうちS3スキャンだけで全体の44%近くを占めていました。スイッチひとつで入るのに、請求への影響は基本の脅威検出より大きくなります。全バケットへ一律に掛けず、外部から書き込みを受けるバケットに限定する運用が現実的でした。 ### 請求額が急に跳ねたときに使用タイプ名から原因を切り分ける手順 請求が跳ねたときは、増えた使用タイプを1つに特定してから対処します。PaidEventsAnalyzed-Bytes ならログ量の増加、PaidEC2vCPUMonitored ならインスタンスの落とし忘れ、MalwareProtectionS3ScanRequest ならアップロード件数の急増が原因でした。 ログ量が原因の場合、削減の余地は限られます。前述のとおりCloudTrail側のフィルタは効きません。手を打てるのはトラフィックそのものか、有効にするリージョンの絞り込みです。一方でvCPU課金とスキャン課金は対象リソースの棚卸しで直接減らせます。[AWS Security Hubとは](https://www.issoh.co.jp/tech/details/15890/)で扱った集約層と組み合わせると、どのリソースが検出結果を量産しているかを追えます。 ## AI Protectionの追加でGuardDutyの請求構造がどう変わるかを確認する 2026年に入って課金軸が1本増えました。生成AIワークロードを対象にするAI Protectionです。既存の料金解説の多くはこの軸を含まないまま書かれています。 ### AI Protectionは2026年7月に一般提供が始まった保護プラン AWSの[What’s Newの告知](https://aws.amazon.com/jp/about-aws/whats-new/2026/07/amazon-guardduty-ai-protection-aws/)によれば、Amazon GuardDuty AI Protectionは2026年7月14日に一般提供が始まりました。設定手順と検出内容は[公式ユーザーガイドのAI Protectionの章](https://docs.aws.amazon.com/ja%5Fjp/guardduty/latest/ug/gdu-ai-protection.html)にまとまっています。Amazon BedrockやSageMakerを使う環境で、通常と異なる呼び出しパターンや資源の大量消費を検出する位置づけです。 API側でも実体を確認できます。GetUsageStatistics の Features に AI\_PROTECTION が加わっているため、前掲のCLIでそのまま使用額を取り出せます。導入の判断材料を先に数字で持てる状態です。 ### AIデータイベントの単価は基本のログ課金とそろえた階層になる 東京リージョンのオファーファイルでは、AIデータイベントの分析が初回500GBまで1GB 1.18USD、以降0.59USD・0.29USD・0.17USDと並んでいました。VPCフローログ・DNSログと同じ階層です。 注意したいのは、この階層がログ課金とは別枠で積算される点です。VPC・DNSログで既に0.29USDの階層へ入っていても、AIデータイベントは自分の量で判定されて1.18USDから始まります。生成AIを使い始めたばかりの環境では、少量でも最上位の単価が適用される計算です。 ## GuardDutyを有効化する条件と保護プランを見送る場面を金額で線引きする ここからは受託開発の現場で見積もりを作ってきた立場からの判断です。数字を並べただけでは決められない部分を、条件付きで言い切ります。 ### 受託開発の現場でGuardDutyを有効化すると判断する条件 基本の脅威検出は、AWSアカウントを本番運用しているなら有効化する側に倒して差し支えありません。理由は3つです。第1に、小規模構成の試算が示すとおり月額100USDを下回る環境が多いこと。第2に、エージェントもログ基盤も不要で導入工数がほぼゼロで済むこと。第3に、30日間の無料トライアルで実額を確認してから決められることです。 保護プランのうち先に足すべきはS3 ProtectionとEKS Protectionでした。どちらも既定で有効になり、単価が土台部分より小さく収まります。ランタイムモニタリングはvCPU数が読めるので試算しやすく、コンテナ本番環境では投資に見合う場面が多いと判断しました。構成込みの試算が必要なら[インフラ構築（AWS・Google Cloud・Azure）](https://www.issoh.co.jp/service/system/aws/)の窓口へどうぞ。 有効化したあとに検出結果を見逃さない通知の組み方は、[GuardDuty EventBridge連携の実装：検出結果とCloudTrailの操作をSNS・Slackへ通知する](https://www.issoh.co.jp/tech/details/18451/)で重大度の絞り込みから解説しています。 ### 保護プランを段階的に足すか見送るかを月額の増分で線引きする基準 見送りを勧めるのは次の場面です。第1に、Malware Protection for S3を全バケット一括で掛ける設計。リクエスト課金がデータ量課金と並ぶ規模になり、外部書き込みを受けないバケットに掛ける費用対効果は見合いません。第2に、検出結果を誰も見ない体制。GuardDutyは検出するだけで遮断はしないため、トリアージ担当が居なければ請求だけが増えます。遮断側は[AWS Shieldとは](https://www.issoh.co.jp/tech/details/15892/)、脆弱性側は[Amazon Inspectorとは](https://www.issoh.co.jp/tech/details/15894/)が担当する領域です。 第3に、開発・検証専用アカウントでのランタイムモニタリング。vCPUが立ち上がっている限り課金され、対処しない環境ではコストが積み上がるだけです。ここは本番アカウントに絞って構いません。逆に個人情報や決済データを扱う本番環境なら、月額が倍になってもMalware Protectionを入れる側に倒します。責任分界の考え方は[クラウドセキュリティとは](https://www.issoh.co.jp/column/details/13266/)で整理しました。 ## よくある質問 ### GuardDutyを有効化しただけで料金は発生しますか？ 30日間の無料トライアル期間中は発生しません。終了後は、分析対象のCloudTrail管理イベントやVPCフローログが存在する限り課金されます。CloudTrail側の課金がどこから発生するかは[CloudTrailの証跡設計と料金実額をまとめた記事](https://www.issoh.co.jp/tech/details/17649/)で整理しました。リソースを動かしていないアカウントなら分析量がほぼゼロで、請求も小さく収まります。 ### 無料トライアル中の推定コストは実際の請求と一致しますか？ 一致しない場合があります。コンソールの推定コストは、観測した使用量を30日間へ引き延ばした月次見積もりです。有効化直後は数日分の実績しかないため、その期間のトラフィックが平常時と違えば見積もりも外れます。月末のバッチなど負荷の山を含む期間で測ってください。 ### Runtime Monitoringを入れるとVPCフローログの料金は二重になりますか？ 二重にはなりません。公式ユーザーガイドには、エージェントがランタイムイベントを送信している間その分のVPCフローログ処理料金は発生しないと記載されています。エージェントを入れた範囲はログ課金がランタイム課金へ置き換わります。 ### Malware Protection for S3の課金を抑える方法はありますか？ 対象バケットを限定するのが最も効きます。スキャンはバケット単位で有効化するため、外部からのアップロードを受けるバケットに絞れば、データ量とリクエスト数を同時に減らせます。小さいファイルを大量に置く用途のバケットはリクエスト課金が効きやすいので、対象から外す判断も有効でした。 ### 組織全体のGuardDuty料金はどこで確認できますか？ 委任管理者アカウントのGuardDutyコンソールで、メンバーを含む使用状況とアカウント別の内訳が確認できます。CLIでは集計タイプに TOP\_ACCOUNTS\_BY\_FEATURE を指定すると使用額の大きいアカウントが並びます。 ## 関連記事 - Amazon GuardDutyとは？AWS環境の脅威検出サービスの基本的な概要と特徴を初心者向けに解説：前提になる定義と検出内容。 - [Amazon Detectiveとは？behavior graphの仕組み・料金とGuardDutyとの使い分けを実装者目線で解説](https://www.issoh.co.jp/tech/details/15896/)：検出結果を深掘りする調査基盤。 - [AWS Security Hubとは？CSPMとの違い・料金と導入判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15890/)：検出結果を集約する層の料金モデル。 - [Amazon Inspectorとは？対応スキャンと料金・Classic終了後の導入判断](https://www.issoh.co.jp/tech/details/15894/)：脆弱性側の検出を担う同クラスタのサービス。 - [AWS Configとは？設定変更の記録・ルール評価・料金の考え方と導入判断を実装者目線で解説【2026年時点】](https://www.issoh.co.jp/tech/details/15616/)：設定変更と請求変動の突き合わせ。 --- 出典: [Amazon GuardDutyの料金：東京リージョンの実額とMalware Protectionの追加課金を検証]()（株式会社一創）