top of page

Amazon GuardDutyを使いこなす!追加プロテクション機能の導入メリットとコスト最適化戦略

  • 1 日前
  • 読了時間: 15分

この記事でわかること


  • Amazon GuardDutyの追加プロテクション機能の要点:S3・EKS・RDS・Lambda・Runtime・Malware Protectionなどの各機能が「何を」「どの攻撃から」保護するのか。

  • コスト最適化の具体策:Well-Architected Frameworkの考え方に基づく費用対効果の高い設定と、具体的な計算式。

  • 運用の自動化:Security HubとLambdaを組み合わせた、Slack/Teamsへの通知パイプラインの構築手順。


生成AIやクラウド活用が加速する中で、脅威検知の自動化はこれまで以上に重要になっています。Amazon GuardDutyは、AWS環境を24時間365日自動で監視し、不審な操作や攻撃の兆候を検知するマネージド型の脅威検知サービスです。導入後はAWS側が自動でログを分析するため、専任のセキュリティ担当者がいない組織でも運用できます。


一方、基本データソース(CloudTrail管理イベント・VPCフローログ・DNSクエリログ)の分析だけで運用していると、「追加のプロテクション機能は本当に必要なのか」「コストが跳ね上がるのではないか」という不安に直面しがちです。


本記事では、基本機能を補完する追加プロテクション機能の価値を整理し、コストを賢く管理しながら、検知から通知までを自動化する活用方法を解説します。専門用語には初学者向けの補足を添えていますので、これからGuardDutyを検討する方も読み進められます。


※本記事は2026年5月時点の情報に基づきます。AWSのサービス仕様・料金は随時更新されるため、最新情報は必ずAWS公式ドキュメント・料金ページをご確認ください。



   目次




   はじめに:なぜ基本データソースの分析だけでは不十分なのか


Amazon GuardDutyは、CloudTrail管理イベント・VPCフローログ・DNSクエリログといった基本データソースを継続的に分析し、不審な挙動を検知します。本記事では、この基本データソースの分析(AWS公式の「基礎データソース分析」に相当)を「基本検知」と呼びます。


基本検知は、ネットワークレベルの攻撃やAPIの不正操作を捉えるうえで非常に強力です。しかし近年の攻撃は、データベースの認証突破やコンテナ内のプロセス改ざんなど、より「アプリケーションやリソースの深部」を狙う傾向が強まっています。


AWS Well-Architected Frameworkの「セキュリティ」の柱では、「多層防御」と「検知の自動化」が推奨されています。基本検知を補完する追加プロテクション機能を導入することで、死角をなくし、インシデント対応の初動を早められます。


では、各機能が具体的にどのような脅威を、どのような仕組みで検知するのか、順に見ていきましょう。



   1. GuardDuty 追加プロテクション機能の詳細とメリット


基本検知(管理イベント・VPCフローログ・DNSクエリログ)を利用中の方が拡張できる主な機能は次のとおりです。

機能名

概要・仕組み

守れるもの/

想定する攻撃シナリオ

S3 Protection

CloudTrail S3データプレーンイベント(GetObjectなど)を分析。基本検知(管理イベント)ではS3データプレーンを捉えられないため、有効化しないと検知できない。

バケット内データへの不正アクセスや異常な一括ダウンロード。

例:深夜に外部IPからオブジェクトが大量にGetObjectされる異常ダウンロードを検知。

EKS Protection(監査ログ)

EKS監査ログ(Audit Log)を分析し、Kubernetes APIの操作ログを継続監視する。

Kubernetes APIへの不審な操作や権限昇格。

例:ClusterRoleBinding作成による権限昇格など、侵入後の横移動を検知。

RDS Protection

Amazon Aurora/RDSのログインイベントを分析・プロファイリング。対応エンジンはAurora MySQL・Aurora PostgreSQL・RDS for PostgreSQL・Aurora PostgreSQL Limitless Database(MySQL/MariaDB単体は対象外)。対応バージョンは随時拡張されるため最新は公式ドキュメント参照。

データベースへのブルートフォース攻撃や異常ログイン。

例:自動化ツールによる夜間のブルートフォースを継続分析し、翌朝まで気づかないリスクを排除。

Lambda Protection

Lambda関数の実行で生成されるネットワーク活動(VPCフローログ)を分析。

侵害された関数による外部C2サーバへの通信など。

例:侵害されたLambdaがC2サーバへHTTP接続するケースを検知。(C2=攻撃者が侵害済みホストを遠隔操作する指令サーバ。AWSの「EC2」とは無関係)

Runtime Monitoring

EC2・EKS・ECS(Fargate含む)のOSレベルの挙動をエージェントで分析。EKS Runtime MonitoringはEKS Protection(監査ログ)とは別機能。AWS Fargate上のAmazon EKSクラスターはサポート対象外。

ファイル改ざん、リバースシェル実行など深部の侵害。

例:コンテナ内のリバースシェル実行やファイル改ざんをリアルタイムに検知。

Malware Protection for S3

S3オブジェクトのアップロード時にマルウェアスキャンを実行。GuardDuty本体とは独立して単体利用可能。結果はS3オブジェクトタグとして付与でき、EventBridge/Lambdaと連携した自動隔離フローを構築できる。

アップロードファイルに含まれるマルウェア・ランサムウェア・スパイウェアの検知。

Malware Protection for EC2(EBS)

EC2にアタッチされたEBSボリュームのスナップショットを取得し、マルウェアスキャン。GuardDutyの脅威検知と連動して自動スキャンが開始される(GuardDuty有効化が前提)。

EC2上のEBSボリュームに存在するマルウェア・ランサムウェアの検知。


補足:EKS関連機能の整理


EKSの保護は、独立した2つの機能で構成されます。

  • EKS監査ログモニタリング(EKS Protectionに含まれる):Kubernetes APIの操作ログを分析。

  • EKS Runtime Monitoring(Runtime Monitoringに含まれる):コンテナ内のOSレベルの挙動をエージェントで分析。

それぞれ有効化・課金が独立しているため、導入時は区別して検討してください。



各機能の役割が見えたところで、次は導入コストを左右する課金体系を確認します。



   2. 追加プロテクション機能の課金体系


GuardDutyのコストは、分析・スキャンされたデータ量やイベント数に比例する従量課金制です。主な課金基準は次のとおりです。

機能

課金基準

(東京リージョン・2026年5月時点)

S3 Protection

分析されたS3データイベント数(最初の5億件は $1.04/100万件、次の45億件は $0.52、50億超は $0.26)

Lambda Protection

実行から生成されるVPCフローログのGB量(最初の500GBは $1.18/GB)

EKS Protection(監査ログ)

分析されたEKS監査ログのイベント数(最初の1億件は $2.48/100万件、次の1億件は $1.24、2億超は $0.31)

RDS Protection

vCPU単位($1.33/vCPU/月)。Aurora Serverless v2は $0.33/ACU/月

Runtime Monitoring

vCPU単位(最初の500 vCPUは $1.50、次の4,500 vCPUは $0.75、5,000超は $0.25)。EC2・EKS・ECS(Fargate含む)すべて共通でvCPU単位。月あたりvCPU=アクティブ時間合計×vCPU数÷その月の時間数

Malware Protection for S3

$0.1185/GBスキャン+$0.282/1,000オブジェクト。12か月の無料利用枠あり(月1,000リクエスト+1GB)。S3 APIコストは別途。GuardDuty本体とは独立して課金

Malware Protection for EC2(EBS)

$0.05/GBスキャン(EBSスナップショット料金は別途)。GuardDuty有効化が前提

単価はいずれもAWS公式料金ページの料金例で用いられている東京(アジアパシフィック)リージョンの値です(2026年5月時点。最新の正確な単価は AWS公式料金ページ を参照)。


料金改定の補足:Malware Protection for S3は、2025年2月1日にデータスキャン料金が85%値下げされました(東京リージョンの現行単価は $0.1185/GB。出典:AWS公式料金ページ)。


無料トライアル:ほとんどの機能に30日間の無料トライアルが付属します(Malware Protectionは別の無料利用枠)。トライアル中に実ワークロードでの費用を事前に予測できます。


課金体系を把握したうえで、次はコストを無駄なく抑える具体策を見ていきます。



\AWSの設定でお困りですか?専門エンジニアがサポートします/



   3. コスト抑制のためのベストプラクティス


ここで紹介するのは、AWS Well-Architected Frameworkの「コスト最適化」の柱の考え方を踏まえた一般的な実践例です(AWS公式の定められた手順書ではありません)。自社環境に合わせて取捨選択してください。


  • 使用状況(Usage)タブの監視:機能を有効化した後、どの機能がコストを多く消費しているかを特定する。

  • 特定のバケット・アカウントの除外:機密性の低い開発環境や公開用アセット(画像など)のS3バケットを監視対象から外し、無駄な分析費用を削減する。

  • Runtime Monitoringの選択的有効化:すべてのリソースではなく、外部公開された(Public Facing)リソースなど、リスクの高いワークロードに絞って適用する。

  • 信頼されたIPリストの活用:既知の社内ネットワークからのアクセスに対しFindingsの生成を停止し、不要なアラート(ノイズ)を削減する。ただし分析自体は継続するため、これはGuardDutyの課金額を直接下げる施策ではなく、運用負荷の軽減を目的とする点に注意する。



追加プロテクション機能を導入する際の優先順位 


全機能を一括で有効化すると費用が跳ね上がる可能性があります。下図の参照アーキテクチャ(コスト最適化とセキュリティチェックを両立する構成例)を例に、次の観点で優先度を判断することを推奨します。

優先度

対象と考え方

最優先

S3 Protection。機密データを格納するS3バケット(図のS3 Confidential)への不正アクセス検知を最優先で有効化する。Public Access Blockやライフサイクルポリシー(Glacierへの自動移行)と組み合わせると、保護とコスト削減を両立しやすい。

RDS Protection(重要DBへのブルートフォース・異常ログイン検知)、EKS Protection(Kubernetes APIの不審操作検知)。本番環境の重要リソースから早期に有効化する。

Runtime Monitoring(EC2・EKSのOSレベル侵害検知)。エージェント導入コストを30日トライアルで評価してから判断する。

開発・ステージング環境全般(除外推奨)。また、該当リソースが存在しない機能(例:Lambdaを使っていない環境でのLambda Protection)は対象外とする。


Malware Protectionの位置づけ:機密データを扱うS3バケットには Malware Protection for S3 を、マルウェア感染リスクの高いEC2には Malware Protection for EC2(EBS)を、上記の優先度とは独立して選択的に併用を検討します。


図1:参照アーキテクチャ(コスト最適化&セキュリティチェック)。優先度ラベルと各Checkは下の解説に対応します。
図1:参照アーキテクチャ(コスト最適化&セキュリティチェック)。優先度ラベルと各Checkは下の解説に対応します。

図のCheck 1・2は、NAT Gateway経由通信の削減、ALBのアイドル状態の確認・削除、不要なEIP・未使用IGWの削除といった一般的なインフラコスト削減施策です。これらはGuardDutyの課金とは別物ですが、同じ参照アーキテクチャ上で併せて見直すと全体コストを下げやすいため、参考として示しています。



30日間無料トライアルの活用方法


各機能には30日間の無料トライアルが付属します。トライアル中は次の手順で実費用を事前予測できます。


① 機能を有効化

② GuardDutyコンソールの「使用状況」タブを開く

③「予想コスト」を確認(トライアル終了後の月額試算が表示される)

④ 費用対効果を判断して本採用の可否を決定。


コストを最適化したら、検知した脅威をいかに素早く運用担当者へ届けるかが重要です。 次は通知自動化の実装を解説します。



   4. 応用:Security Hub連携による通知の自動化(Slack/Teams)


GuardDutyが脅威を検知しても、担当者が気づかなければ意味がありません。

本セクションでは、検知した脅威をSlackやMicrosoft Teamsへリアルタイム通知する自動化パイプラインを紹介します。

これはWell-Architected Frameworkの「セキュリティ」の柱が掲げる「検知の自動化」と「可視化の統合」に沿った構成です。



推奨構成と情報の動き(データフロー)

図2:自動通知フロー(GuardDuty → Security Hub → EventBridge → Lambda → Slack/Teams)。
図2:自動通知フロー(GuardDuty → Security Hub → EventBridge → Lambda → Slack/Teams)。

SNSの要否:Slack・TeamsのWebhook URLへの通知であれば、LambdaからHTTPS POSTで直接送信できるためSNSは不要です。メールや複数の異なるエンドポイントへ同時配信(ファンアウト)したい場合にのみSNSを組み合わせてください。

  • ① 脅威検知(GuardDuty):ネットワークやAPIの異常を検知し、重要度・脅威タイプ・影響リソース・攻撃元IPなどを含むFindings(JSON)を生成。

  • ② 集約・標準化(Security Hub):GuardDutyがASFF(AWS Security Finding Format)形式に変換して送信。Security Hubが集約・一元管理し、マルチアカウント環境でも横断的に可視化できる。

  • ③ フィルタリング・ルーティング(EventBridge):「Security Hub Findings - Imported」をトリガーに起動。重要度「高(High)以上のみ」などの条件でLambdaへ渡す前にフィルタリングできる。

  • ④ 整形・送信(Lambda):ASFF形式のJSONをパースし、発生時刻・アカウントID・影響リソース・重要度などを読みやすく整形して、Webhook URLへHTTPS POSTで直接送信。

  • ⑤ 通知(Slack/Teams):Webhookが受け取り、整形されたメッセージを指定チャンネルに表示。



Lambda関数サンプルコード

このコードの使い方:以下は最小実装のサンプルです。このコードはLambda関数の「コード」エディタに貼り付けるものです。Webhook URLはセキュリティ上コードに直書きせず、Lambdaの「環境変数」SLACK_WEBHOOK_URL に設定します(手順は後述)。

コードに含めるもの:Findingの解析・メッセージ整形・HTTPS送信処理。

関数の設定として用意するもの:環境変数(SLACK_WEBHOOK_URL)、実行ロール(IAM)、EventBridgeトリガー、タイムアウト、ロギング。本番利用ではエラーハンドリングも必ず追加してください。



# Lambda関数サンプル(Python) - Slack Webhook通知

import json, urllib.request, os

 

WEBHOOK_URL = os.environ['SLACK_WEBHOOK_URL'# 環境変数に設定(コードに直書きしない)

 

def lambda_handler(event, context):

    finding  = event.get('detail', {}).get('findings', [{}])[0]

    severity = finding.get('Severity', {}).get('Label', 'UNKNOWN')

    title    = finding.get('Title', '不明な脅威')

    account  = finding.get('AwsAccountId', '不明')

    region   = finding.get('Region', '不明')

    resource = finding.get('Resources', [{}])[0].get('Id', '不明')

    message = {'text': (

        f':rotating_light: GuardDuty [{severity}]\n'

        f'• タイトル: {title}\n'

        f'• アカウント: {account} / {region}\n'

        f'• リソース: {resource}'

    )}

    req = urllib.request.Request(

        WEBHOOK_URL, json.dumps(message).encode(),

        headers={'Content-Type': 'application/json'}, method='POST'

    )

    urllib.request.urlopen(req)



EventBridgeイベントパターン(例)

重要度がHIGH/CRITICALかつ新規(NEW)のFindingのみを通知対象にする例です。実環境に合わせて調整してください。


{

  "source": ["aws.securityhub"],

  "detail-type": ["Security Hub Findings - Imported"],

  "detail": {

    "findings": {

      "Severity": { "Label": ["HIGH", "CRITICAL"] },

      "RecordState": ["ACTIVE"],

      "Workflow": { "Status": ["NEW"] }

    }

  }

}



重要(仕様変更):かつての WorkflowState はASFFで廃止(Retired)され、現在は Workflow オブジェクトの Status フィールド(Workflow.Status)に置き換えられています。値は NEW/NOTIFIED/RESOLVED/SUPPRESSED です(出典:AWS公式ドキュメント「ASFFトップレベル属性」)。旧記述の WorkflowState を使うとパターンが意図どおり一致しないため、上記の Workflow.Status を使用してください。


コンソール設定手順(AWSマネジメントコンソール)


① Security Hub の有効化(前提条件)

コンソール → [Security Hub] → 「Security Hubに移動」→「Security Hubを有効にする」を選択。GuardDutyとの統合は自動で有効化されます。確認方法:Security Hub → 統合 → "Amazon GuardDuty" のステータスが「受け入れ済み」になっていることを確認。


② Lambda 関数の作成

コンソール → [Lambda] → 「関数の作成」→「一から作成」を選択。関数名: guardduty-slack-notify(任意)/ランタイム: Python 3.12 / アーキテクチャ: x86_64。「基本的なLambdaアクセス許可で新しいロールを作成」を選択して作成。


作成後:「コード」タブに上記サンプルコードを貼り付けて「Deploy」。「設定」→「環境変数」→「編集」→ キー: SLACK_WEBHOOK_URL / 値: Slack Incoming Webhook URL を入力して保存。


③ EventBridge ルールの作成

コンソール → [Amazon EventBridge] → 「ルール」→「ルールを作成」。ルール名: guardduty-high-critical-findings / イベントバス: デフォルト。「イベントパターン」→「カスタムパターン(JSONエディター)」を選択し、上記EventBridgeイベントパターンJSONを貼り付け。

「次へ」→ターゲット: 「AWSのサービス」→「Lambda 関数」→ ② で作成した関数を選択 →「次へ」→「ルールを作成」。


④ 動作確認(Lambdaテストイベント)

Lambdaコンソール → 該当関数 → 「テスト」タブ →「新しいテストイベント」→ 以下JSONを貼り付けて実行。Slackに通知が届けば設定完了。


{

  "detail": {

    "findings": [{

      "Severity": {"Label": "HIGH"},

      "Title": "[TEST] GuardDuty通知確認",

      "AwsAccountId": "123456789012",

      "Region": "ap-northeast-1",

      "Resources": [{"Id": "arn:aws:ec2:ap-northeast-1:123456789012:instance/i-test"}]

    }]

  }

}



⑤ VPC内配置時の補足

Lambdaをデフォルト(VPC外)で配置した場合は追加設定不要。プライベートサブネット内に配置する場合は、Slack/TeamsのWebhook URLへの外部HTTPS通信を確保するためにNATゲートウェイまたは適切なVPCエンドポイントが必要です。



優先的に通知すべきイベント例

Finding Type

意味

Backdoor:EC2/C&CActivity.B!DNS

C2サーバ(攻撃者の指令サーバ、EC2とは別物)との通信(踏み台化の疑い)

CryptoCurrency:EC2/BitcoinTool.B!DNS

マイニングツールの実行(リソースの不正利用)

Exfiltration:S3/AnomalousBehavior

S3からの異常なデータ流出(情報漏洩の疑い)


自動化を整えたら、最後に運用コストの目安を具体的な数字で確認しましょう。



   5. 中規模企業におけるコスト概算例と詳細な計算式


AWSアカウント20程度を運用する中規模企業(従業員500〜1,000名規模)を想定した月額試算です。単価はAWS公式料金ページの東京(アジアパシフィック)リージョンの値(2026年5月時点)を用いています。イベント数・GB量・vCPU数は20アカウント規模の代表的な推定値であり、実際の使用量は環境により大きく異なります。

項目(保護機能)

計算式

(数量 ÷ 単位 × 単価)

月額(USD)

基本検知(CloudTrail管理イベント)

200,000,000件 ÷ 1,000,000 × $4.72

$944

基本検知(VPCフローログ/DNS)

500GB × $1.18/GB(最初の500GB)

$590

S3 Protection

500,000,000件 ÷ 1,000,000 × $1.04(最初の5億件)

$520

EKS Protection(監査ログ)

100,000,000件 ÷ 1,000,000 × $2.48(最初の1億件)

$248

RDS Protection

40 vCPU × $1.33/vCPU/月

$53.20

Runtime Monitoring(EC2)

200 vCPU × $1.50/vCPU/月(最初の500 vCPU、本試算ではEC2のみ計上)

$300

Malware Protection for S3

500GB × $0.1185 + 100,000個 ÷ 1,000 × $0.282

$87.45

Malware Protection for EC2(EBS)

500GB × $0.05/GB(スキャン。EBSスナップショット料金別途)

$25.00

合計

$2,767.65


東京リージョン単価について:本試算はすべて東京(アジアパシフィック)リージョンの公式単価(2026年5月時点)です。VPCフローログ/DNS・S3・EKS・Runtimeなどはボリュームディスカウント(段階料金)があり、上表は各機能とも最初の段階の単価で算出しています。


試算対象:図1の参照アーキテクチャに合わせ、EC2・EKS・RDS・S3 を保護する構成を対象としています(Lambdaは構成に無いため除外)。Runtime Monitoringは選択的適用のため本試算ではEC2分のみを計上しています。Malware Protectionは for S3(12か月無料枠適用後)と for EC2/EBS(スキャン量は検知契機により変動、EBSスナップショット料金は別途)を計上しています。


注意:上記は試算です。実コストはワークロード特性により変動します。必ず30日間の無料トライアル中に「使用状況」タブで実績値を確認してください。

最後に、本記事の内容を振り返ります。



\AWSの設定でお困りですか?専門エンジニアがサポートします/





   まとめ


本記事では、Amazon GuardDutyの追加プロテクション機能(S3・EKS・RDS・Lambda・Runtime・Malware Protection)が守る脅威の範囲と、それぞれの課金体系を解説しました。基本検知では捉えにくいS3への不正アクセス・DBへのブルートフォース・コンテナ内プロセス改ざんなど、深部への攻撃を可視化したい場面に特に有効です。


コスト最適化の観点では、全機能の一括有効化ではなく、機密性の高いリソース(S3・RDS)やリスクの高いワークロードを優先する段階的導入が有効です。Security HubとLambdaを組み合わせた通知自動化により、検知から初動対応までの時間を大幅に短縮できます。


  • 優先順位付け:ビジネスインパクトの大きい本番環境や重要データ(S3/RDS)から順次有効化する。

  • 自動化の構築:Security HubとLambdaで、Slack/Teamsへの即時通知体制を整える。

  • 継続的な最適化:30日間の無料トライアルを活用し、コストとリスクのバランスを評価し続ける。


不正アクセスやランサムウェア被害が発生した場合の対応コスト・業務停止・信頼失墜は、月額の監視コストをはるかに上回ります。まずは30日間の無料トライアルで、実際の検知件数とコストを把握し、安全で堅牢なAWS環境を構築しましょう。


参考資料



この記事を書いた人

y.a(システムエンジニア)

🏅保持資格

・AWS Certified Solutions Architect - Associate

・基本情報技術者 など

オンプレミス基盤の構築・運用保守とC言語によるシステム開発に13年従事した後、クラウド領域へ転身して約1年。『土台作り』から『動く仕組み』まで、インフラ構築からアプリ開発まで、上流・下流を問わず一気通貫で対応。





\サービス紹介資料 ダウンロード/




bottom of page