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)を、上記の優先度とは独立して選択的に併用を検討します。

図のCheck 1・2は、NAT Gateway経由通信の削減、ALBのアイドル状態の確認・削除、不要なEIP・未使用IGWの削除といった一般的なインフラコスト削減施策です。これらはGuardDutyの課金とは別物ですが、同じ参照アーキテクチャ上で併せて見直すと全体コストを下げやすいため、参考として示しています。 |
30日間無料トライアルの活用方法
各機能には30日間の無料トライアルが付属します。トライアル中は次の手順で実費用を事前予測できます。
① 機能を有効化
② GuardDutyコンソールの「使用状況」タブを開く
③「予想コスト」を確認(トライアル終了後の月額試算が表示される)
④ 費用対効果を判断して本採用の可否を決定。
コストを最適化したら、検知した脅威をいかに素早く運用担当者へ届けるかが重要です。 次は通知自動化の実装を解説します。
4. 応用:Security Hub連携による通知の自動化(Slack/Teams)
GuardDutyが脅威を検知しても、担当者が気づかなければ意味がありません。
本セクションでは、検知した脅威をSlackやMicrosoft Teamsへリアルタイム通知する自動化パイプラインを紹介します。
これはWell-Architected Frameworkの「セキュリティ」の柱が掲げる「検知の自動化」と「可視化の統合」に沿った構成です。
推奨構成と情報の動き(データフロー)

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年。『土台作り』から『動く仕組み』まで、インフラ構築からアプリ開発まで、上流・下流を問わず一気通貫で対応。\サービス紹介資料 ダウンロード/



