Amazon GuardDuty の料金とコスト最適化（FinOps）：課金モデルを分解し、ムダを削り、請求を予測する

「GuardDuty って、全部の保護プランを ON にすると、いくらかかるんですか？」——AWS のセキュリティ予算を相談される場で、脅威検知そのものよりお金の質問が出てくることは珍しくありません。そして多くの場合、その不安の正体は「料金体系が分解されていないから、請求の内訳が読めない」ことにあります。

GuardDuty の料金は、実は驚くほど機械的です。課金は「有効化した機能 × その機能が監視した量」の積に分解でき、各単位（100万イベント・GB・vCPU時間）と単価さえ押さえれば、請求書を見る前に概算が出せます。逆に言えば、ここを分解せずに「とりあえず全部 ON」にすると、検知価値の薄い対象にまで従量課金を払い続けることになります。

この記事は、GuardDuty を本番品質で導入したうえで、その費用を FinOps の作法で設計・予測・最適化するための実装ガイドです。脅威検知そのものの設計（保護プラン選定・組織一括有効化・EventBridge 自動対応）は姉妹記事のGuardDuty 本番設計ガイドに譲り、本記事はコスト軸に全振りします。課金モデルをコンポーネント単位で分解し、支配的なドライバーを特定し、実使用量を可視化し、トライアルから請求を予測し、効くムダ取りと効かないムダ取りを切り分けます。題材として、私がマルチアカウント AWS 上のサーバーレス決済プラットフォームで IAM・可観測性・DR を横断実装し、複数アカウントのコスト配分と請求予測を運用に載せてきた経験も交えます。

この記事のルール：料金体系・課金単位・トライアル仕様は AWS 公式ドキュメント／料金ページ（2026年6月時点） に基づきます。価格は改定され、リージョンによって異なります。本文中の金額は US East（バージニア北部）の参考値（2026年6月時点・リージョン/改定で変動）であり、保証された現在価格ではありません——本番投入前に必ず公式料金ページと AWS Pricing Calculator で最新の自リージョンの値を確認してください。そしてもう一つ——GuardDuty は多層防御の一層です。コスト最適化はセキュリティの網羅性とのトレードオフであり、「安くするために検知の穴を作る」のは本末転倒です。本記事は「価値の薄い監視を削り、価値の高い監視は残す」ことを目指します。

0. メンタルモデル：GuardDuty のコストは「有効化したもの × 監視量」

最適化を始める前に、GuardDuty の課金を一行で固定します。これがすべての判断の土台です。

GuardDuty のコスト ＝ Σ（有効化した各機能 × その機能が解析・監視した量 × リージョン単価）。 finding の件数でも、検知された脅威の数でもなく、「解析したデータの量」に対する従量課金である。

ここから、FinOps として効く3つの帰結が出ます。

1. コストは「監視のスイッチ」ではなく「監視の量」に比例する。 S3 Protection を ON にした瞬間に課金が始まるのではなく、S3 データイベントを解析した分だけ課金されます。だから「有効化したか」ではなく「どれだけ流れているか」を見ないと、請求は読めません。これが後述の Usage ページと get-usage-statistics を見るべき理由です。
2. 課金は finding ではなく「データソースの解析」に対して発生する。 ここが最大の誤解ポイントです。finding を抑制（Suppression Rule）してもコストは1円も下がりません。なぜなら課金されているのは「データソースを解析する行為」であって、「finding を生成・表示する行為」ではないからです（7章で詳説）。
3. 支配的なドライバーは少数。 9つの課金コンポーネントがあっても、たいていの請求は Runtime Monitoring（vCPU時間）・CloudTrail 管理イベント量・VPC Flow Logs/DNS のバイト数 の上位2〜3個で説明できます。FinOps は「全部を均等に削る」のではなく「ドライバーを特定して、そこを叩く」のが筋です（2章のドライバー表）。

この3点を押さえると、GuardDuty のコスト最適化は 「①課金モデルを分解する → ②実使用量を見てドライバーを特定する → ③価値対コストの低い監視だけ削る → ④請求を予測・監視する」 という FinOps の標準サイクルに落ちます。順に作ります。

1. 課金モデルを分解する：コンポーネントと単位

GuardDuty の料金は機能（保護プラン）ごとに独立しており、それぞれ固有の課金単位を持ちます。まず単位だけを正確に押さえます（単価は2章で参考値を付けます）。

ここで FinOps 的に重要な構造が3つあります。

• 単位がバラバラ（イベント数・GB・vCPU・ACU・オブジェクト数）。だから「どの機能が高いか」を金額に正規化しないと比較できません。get-usage-statistics は使用量をドル換算（推定）で返してくれるので、これが効きます（4章）。
• 多くが「量で逓減（tiered）」。VPC Flow Logs・S3 データイベント・EKS 監査ログ・Runtime Monitoring は、量が増えるほど単価が下がる階段になっています。つまり「大規模なら GB/イベント単価は下がる」が、「小規模でも最初のティアの単価は高い」。小さく始める環境ほど、単価の体感は割高になります。
• 基盤データソースに『追加費用ゼロ』の領域はない——ただしExtended Threat Detection（ETD）は完全無償です（後述）。基盤検知（CloudTrail/VPC Flow Logs/DNS の解析）は従量課金ですが、その上に乗る相関エンジン（ETD）には課金されません。「弱いシグナルを束ねて Critical の攻撃シーケンスにする」という最も価値の高いレイヤーがタダ、という事実は、最適化の方針に直結します（後述）。

誤解されやすい無料の境界：「GuardDuty を有効化したら CloudTrail や VPC Flow Logs の保存料も別途かかるのでは？」——かかりません。GuardDuty は基盤データソースを「独立した複製ストリーム」として直接消費し、あなたが CloudTrail 証跡を作る・VPC Flow Logs を有効化する・それらを S3 に保存する必要はありません。GuardDuty 側の解析料だけが課金対象です。詳しくは本番設計ガイドのメンタルモデルを参照してください。

2. コストドライバーを順位づける：何が請求を支配するか

9コンポーネントを均等に見ても FinOps にはなりません。**「典型的にどれが請求を支配するか」**を順位づけ、注力先を決めます。以下は US East（バージニア北部）の参考単価（2026年6月時点・リージョン/改定で変動。要確認） を添えたドライバー表です。

参考価格の扱い（再掲・重要）：上表は US East（バージニア北部）の 2026年6月時点の参考値です。東京（ap-northeast-1）をはじめ他リージョンでは異なり、価格は改定されます。Malware Protection for S3 の $0.09/GB は「2025年2月1日発効」と料金ページに明記がある通り、改定が現実に起きる領域です。本番の見積りは必ず公式料金ページと Pricing Calculator で自リージョン・最新を確認してください。

実務的な結論はシンプルです。請求の8割は上位3つ（Runtime Monitoring / CloudTrail 管理イベント / VPC Flow Logs）で説明できることがほとんど。だから FinOps では、まずこの3つの実使用量を見ることから始めます。次章でその見方を作ります。

3. 実使用量を「見る」：Usage ページと CloudWatch メトリクス

最適化の前提は計測です。GuardDuty は使用量を見る経路を複数用意しています。

3.1 console の Usage ページ

GuardDuty コンソールには Usage（使用量）ページがあり、データソース／機能ごとの推定使用コストが表示されます。新規有効化したリージョンの30日無料トライアル中は、ここで「本番量ならいくらになるか」の推定月額を、各データソース別に確認できます。最初にやるべきはこのページを開くこと——「どの機能が金額を食っているか」が一目で分かります。

3.2 CloudWatch 使用量メトリクス（アラートと履歴の土台）

GuardDuty は使用量を CloudWatch の AWS/GuardDuty 名前空間に時間単位でパブリッシュします（反映は24時間以内）。これがコスト監視ダッシュボードとアラームの土台になります。主なメトリクスは：

組織の場合、これらは委任管理者アカウントに集約されてパブリッシュされます（組織全体の合算。ディメンションは DataSource）。スタンドアロンアカウントは AccountId, DataSource ディメンション付きで自アカウントに出ます。

FinOps の実装ポイント：MonitoredVcpuHours と AnalyzedBytes を CloudWatch ダッシュボードに並べておくと、「先週から Runtime の vCPU 時間が跳ねた＝コストが跳ねる」を請求書を待たずに先取りできます。バイト系メトリクスを金額に直すには 1 GB = 1,073,741,824 bytes で換算します（Pricing Calculator も同じ換算）。

4. 使用量を分解する：get-usage-statistics（bash）

Usage ページが「見る」なら、aws guardduty get-usage-statistics は「機械的に分解して比較・自動化する」ための API です。使用量を推定ドル換算で、データソース別／機能別／アカウント別／リソース別に返します。FinOps レポートやアラートの自動化に向きます。

# 前提: 委任管理者(または対象アカウント)の detector-id を取得しておく。
DETECTOR_ID=$(aws guardduty list-detectors --query 'DetectorIds[0]' --output text)

# ① データソース別の使用量を集計する（どの基盤データソースが高いか）。
#    DataSources の有効値: FLOW_LOGS | CLOUD_TRAIL | DNS_LOGS | S3_LOGS
#                          | KUBERNETES_AUDIT_LOGS | EC2_MALWARE_SCAN
aws guardduty get-usage-statistics \
  --detector-id "$DETECTOR_ID" \
  --usage-statistic-type SUM_BY_DATA_SOURCE \
  --usage-criteria 'DataSources=CLOUD_TRAIL,FLOW_LOGS,DNS_LOGS,S3_LOGS'

# ② 機能(保護プラン)別の使用量を集計する（Runtime Monitoring 等の新しい機能を含む）。
#    注意: 列挙値は SUM_BY_FEATURES（複数形）。SUM_BY_FEATURE ではないので注意。
#    Features の有効値(抜粋): FLOW_LOGS | CLOUD_TRAIL | DNS_LOGS | S3_DATA_EVENTS
#      | EKS_AUDIT_LOGS | EBS_MALWARE_PROTECTION | RDS_LOGIN_EVENTS
#      | LAMBDA_NETWORK_LOGS | EKS_RUNTIME_MONITORING | EC2_RUNTIME_MONITORING
#      | FARGATE_RUNTIME_MONITORING | RDS_DBI_PROTECTION_PROVISIONED
#      | RDS_DBI_PROTECTION_SERVERLESS
aws guardduty get-usage-statistics \
  --detector-id "$DETECTOR_ID" \
  --usage-statistic-type SUM_BY_FEATURES \
  --usage-criteria 'Features=EC2_RUNTIME_MONITORING,EKS_RUNTIME_MONITORING,FARGATE_RUNTIME_MONITORING'

# ③ アカウント別の使用量（委任管理者が「どのメンバーアカウントが高いか」を出す）。
#    組織のコスト配分(showback/chargeback)に直結する分解軸。
aws guardduty get-usage-statistics \
  --detector-id "$DETECTOR_ID" \
  --usage-statistic-type SUM_BY_ACCOUNT \
  --usage-criteria 'AccountIds=123456789012,210987654321'

# ④ コスト上位リソースを出す（どの EC2/リソースが Runtime コストを牽引しているか）。
#    "犯人探し"に有効。usage-criteria が不要なら空オブジェクトを渡す。
aws guardduty get-usage-statistics \
  --detector-id "$DETECTOR_ID" \
  --usage-statistic-type TOP_RESOURCES \
  --usage-criteria '{}' \
  --output json

--usage-statistic-type の有効値は SUM_BY_ACCOUNT / SUM_BY_DATA_SOURCE / SUM_BY_RESOURCE / TOP_RESOURCES / SUM_BY_FEATURES / TOP_ACCOUNTS_BY_FEATURE です。

委任管理者のレバレッジ：組織の GuardDuty 委任管理者は、SUM_BY_ACCOUNT でメンバーアカウント別の使用量を、TOP_ACCOUNTS_BY_FEATURE で「どの機能を、どのアカウントが牽引しているか」を一発で出せます。コストの説明責任を「アカウント＝チーム」に紐づけられるので、showback/chargeback の土台になります。組織でのアカウント分離と委任管理者の設計はマルチアカウント統制ガイドを参照してください。決済プラットフォームのように本番/ステージング/監査でアカウントを割っている環境では、このアカウント別分解がそのままコスト配分になります。

5. トライアルから本番請求を予測する（30日無料トライアル）

GuardDuty は 新規有効化したアカウント×リージョンごとに30日間の無料トライアルを提供します。トライアルの対象は、基盤検知（Foundational Threat Detection）に加え、S3 / EKS / Runtime Monitoring / RDS / Lambda の各保護プラン、および GuardDuty 起点の Malware Protection for EC2 スキャンです。

このトライアルは「タダで使える期間」である以上に、**FinOps 的には『本番量での請求を、課金される前に観測できる期間』**として価値があります。手順はこうです。

1. 本番に近い負荷の状態でトライアルを回す。 トライアル中の使用量は GuardDuty の Usage メトリクス／console に蓄積されます。「最小構成で有効化して、トライアル後に本番投入」だと予測がズレるので、できるだけ本番相当の量で観測します。
2. 観測した使用量を AWS Pricing Calculator に入れる。 Pricing Calculator で Amazon GuardDuty を選び、自リージョンを指定し、CloudWatch/Usage で観測した各機能の使用量（vCPU時間・イベント数・GB）を入力すると、トライアル後の月額が出ます。バイト系メトリクスは GB へ換算してから入力します。
3. トライアル終了後は AWS Billing で実額を確認する。 予測と実額の差をレビューし、外れていればドライバー（多くは Runtime の vCPU 時間）を見直します。

トライアルの落とし穴：トライアルはリージョン単位です。「全リージョンで有効化する」ことを公式は推奨しますが（グローバルサービスイベントの監視のため）、各リージョンのトライアルは独立しています。Security Hub の有効化/無効化はトライアルを延長・再付与しません——既にトライアルを使い切ったアカウントに新しいトライアルは付きません。

5.1 手計算で「桁」を掴む：ワークシート（参考値・要確認）

Pricing Calculator が正式な見積りですが、桁感を手で掴んでおくと、Calculator の出力やトライアルの推定が「妥当か」を即座に検算できます。以下は US East 参考単価（2026年6月時点・リージョン/改定で変動。あくまで桁感の例） で組んだワークシートです。自分の数字に置き換えて使ってください。

検算のコツ：MonitoredVcpuHours は「vCPU・時間」なので、月合計を 720（時間/月の概数）で割れば「平均 vCPU・月」になります。上の例だと「合計 28,800 vCPU時間 ÷ 720 ≈ 40 vCPU」です。VPC Flow Logs が支配的に見えたら、6.3 の二重課金免除（Runtime を入れた EC2 ぶんは無料化）を効かせる前後で再計算してください——免除を入れると VPC Flow Logs の AnalyzedBytes 自体が減るので、上の式の GB が小さくなります。なおこの概算は「最初のティア単価」で雑に掛けたもので、量が逓減ティアに入ると実額はこれより下がります。必ず Pricing Calculator で確定させてください。

6. 効くコスト最適化：価値の薄い監視だけを削る

ここからが実務の核心です。**「セキュリティの穴を作らずにコストを下げる」**戦術を、効く順に挙げます。

6.1 資産がある所だけ保護プランを足す（YAGNI）

最大のムダは「監視対象が存在しないのに保護プランを有効化している」状態です。EKS を運用していないアカウントで EKS Protection を ON にしても、検知は1件も出ず、監査ログ解析の課金だけが乗りかねません。原則は本番設計ガイドと同じ——S3 Protection は機密データを扱うほぼ全アカウントでデフォルト ON、EKS/RDS/Lambda は該当資産のあるアカウントだけ、Runtime Monitoring は本番の重要ワークロードに限定。これは「セキュリティ予算の配分問題」そのものです。

6.2 Runtime Monitoring を重要ワークロードに絞る（最大のレバー）

Runtime Monitoring は保護 vCPU 数 × 稼働時間で課金され、上位ティアでも他機能と比べて単価が高く、最大のコストドライバーになりがちです。全コンテナ・全 EC2 に一律展開すると一気に膨らみます。「ランタイムの侵害が起きたら事業に致命的なワークロード」だけに絞るのが定石です。GuardDuty にエージェント配置を自動管理させつつ、監視対象をタグやクラスタ単位でスコープします。vCPU 課金の構造と EKS/ECS-Fargate/EC2 でのエージェント設計はRuntime Monitoring 実装ガイドで詳説しています。

6.3 VPC Flow Logs の二重課金免除を活かす（見落とされがち）

これは知っているかどうかで請求が変わるポイントです。Runtime Monitoring のセキュリティエージェントが EC2 インスタンス上で稼働し、GuardDuty がそのインスタンスのランタイムイベントを受け取っている間、GuardDuty はその EC2 インスタンスの VPC Flow Logs 解析を課金しません（二重課金の回避）。

公式の表現どおり、エージェントがランタイムイベントデータを実際に送っている限りこの免除が効き、エージェントが送信を止めると VPC Flow Logs 課金に戻ります。CloudWatch の使用量メトリクスでも、Runtime Monitoring を有効化すると VPC Flow Logs の使用量が減るのが観測できます。

設計への含意：「Runtime Monitoring は高い」は半分正しいですが、Runtime を入れた EC2 では VPC Flow Logs 解析がタダになるぶん、ネットワークが活発な EC2 ほど相殺が効きます。Runtime のコスト評価は「vCPU 課金の増分」だけでなく「VPC Flow Logs 課金の減分」も合わせて見るのが正確です。

6.4 Malware Protection for S3 の無料枠と単独利用

Malware Protection for S3 には 月 1,000 リクエスト＋1GB の無料枠があり、また GuardDuty 本体を有効化せず単独で使えます。「アップロードされたファイルだけスキャンしたい」用途なら、基盤検知のコストを払わずに最小構成で導入できます。

6.5 ETD は無償——「タダで効く最強レイヤー」を活かす

Extended Threat Detection（ETD）には追加費用がありません。弱いシグナルを24時間窓で相関し、多段攻撃を1つの AttackSequence:*（必ず Critical）finding に束ねる、最も価値の高いレイヤーが無償です。つまりコスト最適化で ETD を削る理由は一切ありません。むしろ「ETD の相関を広げるために S3 Protection を入れる」という、安価な機能で無償の相関価値を最大化する設計が筋です。

6.6 効かないムダ取り（次章で詳説）

一方で、「効きそうで効かない」最適化があります。代表が Suppression Rule（抑制ルール） と Trusted IP リスト。これらはノイズを減らしますがコストは下げません。理由は重要なので独立した章で扱います。

7. コストを下げない施策：抑制ルールの誤解（最重要）

FinOps 上、最も多い誤解がこれです。

Suppression Rule（抑制ルール）は finding を「アーカイブ」するだけで、GuardDuty のコストを下げない。

なぜか。0章の帰結②に戻ります——課金されているのは「データソースを解析する行為」であって、「finding を生成・表示する行為」ではないからです。抑制ルールがするのは「条件に一致した finding を自動でアーカイブし、ダッシュボードと通知から外す」ことだけ。解析そのものは止まらないので、課金も止まりません。「ノイズが多くて請求も高いから、抑制でまとめて消そう」——これはコスト最適化にはならないのです。

同様に：

• Trusted IP リスト：載せた IP からのトラフィックは finding を生成しなくなりますが、そのトラフィックの解析（VPC Flow Logs 等）は行われ、課金されます。ノイズは減りますが、コストは下がりません。
• 脅威リスト（Threat list）：自前の悪性 IP/ドメインで finding を増やす側の道具で、コスト削減の文脈には関係しません。

つまり、抑制ルール・Trusted IP リストは「運用ノイズを減らすための道具」であって「コストを減らすための道具」ではありません。混同すると、「抑制したのに請求が下がらない」と悩むことになります。コストを下げたいなら、解析するデータ量そのものを減らす（＝6章：監視対象を絞る・資産のない保護プランを切る）しかありません。

抑制とコストの正しい使い分け：抑制ルールはコストではなくノイズと、ETD の相関品質のために使います。注意点として、ETD はアーカイブ済み finding を相関の対象にしません。「単体ではノイズに見える弱いシグナルを抑制で消すと、本来束ねるはずだった攻撃シーケンス（Critical）まで見えなくなる」可能性があります。抑制は「無害と確信できるノイズ」に限り、コスト削減の手段として使わない——この二点が要点です（詳細は本番設計ガイドの誤検知チューニング章）。

8. 請求を予測し、監視する：Budgets と Cost Anomaly Detection

最適化したあとは「逸脱を早く知る」仕組みを残します。GuardDuty のコストが跳ねる典型は「Runtime Monitoring を新しいクラスタに広げた」「CloudTrail を大量に叩くバッチを足した」——いずれも有効化や負荷の変化です。これを請求書の月末ではなく発生時点で捕まえます。

8.1 サービス単位の AWS Budgets アラート（Terraform）

GuardDuty のコストだけを切り出して予算アラートを張ります。cost_filter の Service ディメンションを Amazon GuardDuty に絞るのがポイントです。

# ============================================================
# 目的: GuardDuty のコストだけを監視し、跳ねたら即通知する。
#   - Service フィルタで GuardDuty に限定（全体予算に埋もれさせない）
#   - 80%(実績) で気づき、100%(予測) で月中に警告
# 注意: limit_amount は自リージョン・自構成の想定額に置き換えること。
#       金額は USD。参考値ではなく、5章で予測した実額ベースで設定する。
# ============================================================
resource "aws_budgets_budget" "guardduty_monthly" {
  name         = "guardduty-monthly-cost"
  budget_type  = "COST"
  limit_amount = "300" # USD/月。← 5章のトライアル予測に基づき各自設定
  limit_unit   = "USD"
  time_unit    = "MONTHLY"

  # GuardDuty のコストだけに絞る。これがサービス単位監視の肝。
  cost_filter {
    name   = "Service"
    values = ["Amazon GuardDuty"]
  }

  # 実績80%で通知（まだ余裕があるうちに気づく）。
  notification {
    comparison_operator       = "GREATER_THAN"
    threshold                 = 80
    threshold_type            = "PERCENTAGE"
    notification_type         = "ACTUAL"
    subscriber_sns_topic_arns = [aws_sns_topic.cost_alert.arn]
  }

  # 予測100%で通知（月末に超過見込みなら月中でも警告）。
  # 「有効化を広げた直後」の跳ねを月初に捕まえるための予測アラート。
  notification {
    comparison_operator       = "GREATER_THAN"
    threshold                 = 100
    threshold_type            = "PERCENTAGE"
    notification_type         = "FORECASTED"
    subscriber_sns_topic_arns = [aws_sns_topic.cost_alert.arn]
  }
}

8.2 Cost Anomaly Detection（異常な跳ねを自動検知）

予算アラートは「閾値」を超えたら鳴りますが、閾値を決めにくい初期や、想定内でも急変したケースには AWS Cost Anomaly Detection が効きます。GuardDuty を含むサービス単位のモニターを作り、過去パターンから外れた支出を機械学習で検知して通知します。「Runtime を広げた」「CloudTrail が急増した」といった構造変化を、閾値設定なしで拾えるのが利点です。Budgets（既知の上限の番人）と Cost Anomaly Detection（未知の急変の番人）は併用が定石です。

FinOps の運用設計：①トライアルで予測（5章）→ ②Budgets で上限を張る（8.1）→ ③Cost Anomaly Detection で急変を拾う（8.2）→ ④跳ねたら get-usage-statistics（4章）でドライバー（多くは Runtime の vCPU 時間）を特定 → ⑤6章の戦術で削る。この閉ループを Terraform で宣言しておけば、人が見張らなくてもコストが構造的に管理されます。これは私がスタートアップの AWS コスト最適化で繰り返してきた「下がり続ける仕組みをコードで残す」考え方そのものです。

9. まとめ：GuardDuty コスト最適化チートシート

迷ったときの早見表です。

• 課金の本質：GuardDuty のコストは 「有効化した機能 × 監視量 × リージョン単価」 の従量課金。finding 件数ではなく『解析したデータ量』に課金される。
• 支配的ドライバー：請求の大半は Runtime Monitoring（vCPU時間）／CloudTrail 管理イベント量／VPC Flow Logs・DNS のバイト数 の上位2〜3個で説明できる。ここを見て、ここを叩く。
• 実使用量の可視化：まず console の Usage ページ。自動化・分解は aws guardduty get-usage-statistics（SUM_BY_DATA_SOURCE / SUM_BY_FEATURES（複数形）/ SUM_BY_ACCOUNT / TOP_RESOURCES / TOP_ACCOUNTS_BY_FEATURE）。CloudWatch AWS/GuardDuty で履歴とアラート。
• 請求予測：30日無料トライアル（リージョン×アカウント単位）中の使用量を AWS Pricing Calculator に入れて、課金される前に月額を予測。委任管理者はメンバーアカウント別の想定コストまで見える。
• 効くムダ取り：①資産がある所だけ保護プランを足す（YAGNI） ②Runtime Monitoring は重要ワークロードに絞る（最大のレバー）③EC2 で Runtime エージェントが動く分は VPC Flow Logs 解析が二重課金されない免除を活かす ④Malware Protection for S3 は無料枠＋単独利用 ⑤ETD は無償——削らず活かす。
• 効かないムダ取り（誤解注意）：Suppression Rule は finding をアーカイブするだけでコストを下げない。Trusted IP リストもノイズは減らすがコストは下げない（課金対象は解析量であって finding ではない）。コストを下げるには解析量そのものを減らすしかない。
• 監視：Service フィルタで GuardDuty に絞った AWS Budgets（既知の上限）＋ Cost Anomaly Detection（未知の急変）。跳ねたら get-usage-statistics でドライバーを特定して削る、の閉ループ。
• 価格の鉄則：本文の金額は US East 参考・2026年6月時点・リージョン/改定で変動。保証値ではない。本番見積りは必ず公式料金ページと Pricing Calculator で自リージョン・最新を確認。

GuardDuty のコストは「ブラックボックスな請求書」ではなく、分解すれば予測でき、ドライバーを叩けば下げられる機械的な構造です。最大のレバレッジは「全部を削る」ことではなく、価値の薄い監視だけを外し、ETD という無償の相関価値を最大化することにあります。

私はマルチアカウントのサーバーレス決済プラットフォームで、実際の金銭・カーボンクレジット・地域通貨を扱う基盤の IAM・可観測性・DR を横断実装し、複数アカウントのコスト配分と請求予測をコードの構造で運用に載せてきました。GuardDuty のコスト設計も同じ思想です——①トライアルで請求を予測し、②使用量を get-usage-statistics で分解し、③価値対コストの低い監視だけを削り、④Budgets と Cost Anomaly Detection で逸脱を発生時点で捕まえる。「とりあえず全部 ON」でも「不安だから最小限」でもない、根拠のある配分を設計します。

「自社の GuardDuty にいくらかかるのか、どこにムダがあり、どう請求を予測・監視するか」——課金モデルの分解から使用量の可視化、保護プランの取捨選択、Terraform での Budgets/Cost Anomaly Detection 実装まで、一人 × 生成AI（Claude Code）で速く・安全に伴走できます。 「全部 ON にしたら高そうで踏み切れない」という段階からでも、お気軽にご相談ください。

参考（公式ドキュメント）

• Amazon GuardDuty pricing — 全コンポーネントの従量課金・ティア・リージョン別単価・30日無料トライアル（価格は改定・要確認）
• Monitoring GuardDuty usage and estimating costs — CloudWatch 使用量メトリクス・VPC Flow Logs 二重課金免除・トライアルからの予測・Pricing Calculator 手順
• GuardDuty foundational data sources — 「独立した複製ストリーム」・基盤データソースに追加保存コストがない点・委任管理者のメンバー別想定コスト・DNS は AWS リゾルバ利用時のみ
• get-usage-statistics（AWS CLI リファレンス） — --usage-statistic-type の有効値・--usage-criteria（DataSources/Features/AccountIds）
• Suppression rules — 抑制ルールは finding をアーカイブする機能（コスト削減機能ではない点・ETD との相互作用）
• AWS Pricing Calculator — 観測使用量からの月額見積り