🎯 最初に結論：GuardDutyのトラフィック分析で分かること
GuardDutyは3つの基盤データソース（CloudTrailログ、VPCフローログ、DNS クエリログ）を自動的に取り込み、機械学習と脅威インテリジェンスで不審なトラフィックパターンを検出します。
DNSクエリログ分析
「どこ宛に手紙を出そうとしているか」を監視。マルウェアC&Cサーバーや暗号通貨マイニング関連ドメインへの問い合わせを検出
VPCフローログ分析
「誰がどこに出入りしたか」を記録。異常な通信量、不審なポートスキャン、既知の悪意あるIPとの通信を検出
機械学習＋脅威インテリジェンス
過去の「正常パターン」を学習し、逸脱を検出。AWSとサードパーティの脅威情報も組み合わせて高精度に判定
🏢 たとえ話：「高層ビルのセキュリティシステム」
GuardDutyの仕組みを、高層オフィスビルのセキュリティに例えて理解しましょう
あなたのAWS環境 ＝ 高層オフィスビル
ビルにはたくさんのテナント（EC2インスタンスやサービス）が入居しています。
GuardDutyは、このビル全体を見守るAIセキュリティシステムです。
ビルの「郵便物の行き先」と「出入りの記録」の2つを常時チェックしています。
DNSクエリログ ＝ 郵便物の宛先チェック
ビルから発送されるすべての郵便物の宛先を確認するシステム。「この宛先は詐欺グループの住所では？」「このテナントが急に海外に大量の郵便物を出している」といった異常を検出します。
VPCフローログ ＝ 入退館記録システム
ビルのすべてのゲートで「誰が、いつ、どこへ、どのくらいの荷物を持って」出入りしたかを記録。異常に大きな荷物（大量データ転送）や深夜の不審な出入りを監視します。
脅威インテリジェンス ＝ ブラックリスト
警察や業界団体から提供される「要注意人物リスト」「詐欺グループの住所リスト」。これと照合して、ビルのテナントが危険な相手と取引していないかチェックします。
機械学習 ＝ AIが覚えた「いつもの行動」
各テナントの「普段の行動パターン」をAIが学習。「このテナントは平日9-18時しか荷物を出さないのに、深夜3時に大量の荷物が…」という異変を即座に検知します。
📐 GuardDuty トラフィック分析アーキテクチャ
GuardDutyがデータソースを取り込み、脅威を検出して通知するまでの全体像
Route 53 Resolver
EC2 ネットワーク
API アクティビティ
機械学習 + 脅威インテリジェンス + 異常検知
イベント通知
統合管理
詳細調査
自動隔離・修復
チーム通知
IPブロック
🔎 2つのトラフィックデータソースを深掘り
GuardDutyが「何を見て」「何を判断しているか」を具体的に理解する
DNSクエリログ分析
Route 53 Resolver経由のDNS問い合わせを監視
📍 何を見ているか
EC2インスタンスが「どのドメイン名を問い合わせたか」のリクエストとレスポンスをリアルタイムで分析
🚨 検出できる脅威
C&Cサーバーへの通信、DGAドメイン（ランダム生成ドメイン）、暗号通貨マイニング、DNSデータ漏洩（DNS経由のデータ持ち出し）、フィッシングサイトへのアクセス
⚠️ 前提条件
AWS標準のDNSリゾルバ（Route 53 Resolver）を使用していることが必要。OpenDNSやGoogleDNS等のサードパーティDNSでは分析不可
VPCフローログ分析
EC2インスタンスのネットワークインターフェースのIPトラフィックをキャプチャ
📍 何を見ているか
送信元/送信先IP、ポート番号、プロトコル、パケット数、バイト数、許可/拒否のステータスをリアルタイムで分析
🚨 検出できる脅威
ポートスキャン（偵察行為）、既知の悪意あるIPとの通信、異常な通信量（DoS/データ漏洩）、不正な暗号通貨マイニング通信、異常なプロトコル使用
⚠️ 重要ポイント
GuardDutyは独立したストリームでフローログを取得。ユーザー自身でVPCフローログを有効化する必要はなく、追加料金も不要（別途保管する場合は別）
🏢 たとえ話フロー：ビルのセキュリティが脅威を発見するまで
📬 テナントが郵便物を出す（＝ DNSクエリ発生）
3階のテナントA社が「xyz-suspicious.example.com」宛に郵便物を出そうとする。セキュリティシステムは全ての郵便物の宛先を自動的に記録・分析。
🚗 同時に、ゲートの記録も分析（＝ VPCフローログ）
テナントA社が深夜3時にビルの裏口から大量の荷物を搬出中。普段は9-18時しか稼働しないのに、明らかに異常なパターン。
📋 宛先を要注意リストと照合（＝ 脅威インテリジェンス）
セキュリティシステムが警察のブラックリストを参照。「xyz-suspicious.example.com」は既知のC&Cサーバー（指令サーバー）であることが判明！
🧠 AIが普段のパターンと比較（＝ 機械学習モデル）
「A社は過去30日間、こんな宛先に連絡したことがない」「深夜のデータ搬出量が通常の50倍」。学習済みベースラインからの逸脱度をスコアリング。
🚨 Finding（検出結果）を生成して通知
「Backdoor:EC2/C&CActivity.B!DNS」（重大度：高）を生成。「テナントA社がC&Cサーバーと通信しています！即座に対処してください」とセキュリティチームに通知。
⚡ EventBridge → Lambda で自動隔離を実行
セキュリティシステムが自動で「A社の出入口を封鎖」（セキュリティグループ変更でネットワーク隔離）。同時にセキュリティチームにSlack通知とメール送信。
🚨 主要な検出タイプ（Finding Types）
DNSログとVPCフローログから検出される代表的な脅威パターン
⚖️ DNSログ vs VPCフローログ 比較
2つのデータソースは何が違い、それぞれ何が得意なのか
| 比較項目 | 📬 DNSクエリログ | 🚗 VPCフローログ |
|---|---|---|
| 何を見るか | ドメイン名の問い合わせ（どこに行こうとしているか） | 実際のIPトラフィック（誰がどこに通信したか） |
| 🏢 たとえ | 郵便物の「宛先」を確認 | ゲートの「入退館記録」を分析 |
| 得意な検出 | C&Cサーバー通信、DGA、暗号通貨、DNS漏洩 | ポートスキャン、DoS、大量データ転送、異常プロトコル |
| 前提条件 | AWS標準DNSリゾルバ（Route 53）を使用 | 特になし（GuardDutyが独自に取得） |
| パケット内容 | 問い合わせドメイン名のみ | メタデータのみ（内容は見ない） |
| IPv6対応 | ✓ 対応 | ✗ 非対応 |
| 追加コスト | GuardDuty利用料に含む（GB課金） | GuardDuty利用料に含む（GB課金） |
| 手動有効化 | 不要（自動取り込み） | 不要（独立ストリームで自動取得） |
🛠️ 実装ステップ：GuardDutyの有効化からアラート設定まで
GuardDutyの有効化は非常に簡単。基盤データソースは自動で取り込まれます。
GuardDutyを有効化（全リージョンで推奨）
コンソールから数クリック、またはCLI1行で有効化。基盤データソース（CloudTrail、VPCフローログ、DNSログ）は自動的に分析開始。
EventBridgeルールでアラート通知を設定
GuardDutyのFindingをEventBridgeで受け取り、SNS経由でチームに通知。重大度でフィルタリングも可能。
Trusted IP / Threat IP リストを設定
自社の既知IPをTrusted IPリストに登録して誤検知を防止。独自の脅威IPリストも追加可能。
Lambda関数で自動対応を構築
高重大度の検出結果に対して、セキュリティグループの変更やインスタンス隔離を自動実行。
⚡ 自動対応フロー：脅威検出から修復まで
GuardDuty
脅威を検出
Finding生成
EventBridge
イベントを
ルーティング
Lambda
自動隔離
修復実行
SNS通知
チームに
即座に連絡
Detective
根本原因
詳細調査
🏭 業界別ユースケース
GuardDutyのトラフィック分析が各業界でどう役立つか
金融業界
顧客データを扱うEC2が突然、東欧の未知のIPアドレスに大量データを送信開始。VPCフローログから異常な送信パターンを検出し、情報漏洩を未然に防止。
医療業界
患者データベースサーバーがC&Cサーバーのドメインを問い合わせていることをDNSログから検出。ランサムウェア感染初期段階で隔離に成功。
EC/小売業界
決済処理サーバーで暗号通貨マイニング関連ドメインへのDNS問い合わせを検出。内部犯行による不正マイニングを早期発見。
ゲーム/テック業界
開発環境のEC2が大量のポートスキャンを実行していることをVPCフローログで検出。侵害されたインスタンスが踏み台として悪用されていた。
✅ ベストプラクティス & よくある落とし穴
✅ 全リージョンで有効化する
攻撃者は使用していないリージョンでリソースを立ち上げることがある。全リージョンでGuardDutyを有効化し、グローバルサービス（IAM等）の監視も確保。
✅ AWS標準DNSリゾルバを使用する
サードパーティDNS（GoogleDNS、OpenDNS等）を使うと、DNSクエリログの分析ができなくなる。Route 53 Resolverを使用して検出範囲を最大化。
✅ Trusted IPリストを適切に設定する
社内VPNやパートナーIPをTrusted IPリストに登録し、誤検知（False Positive）を削減。ただし登録しすぎると検出漏れのリスクに注意。
✅ Security Hub と統合する
GuardDuty FindingをSecurity Hubに集約し、他のセキュリティサービス（Inspector、Config等）の検出結果と合わせて優先順位を判断。
❌ Findingを放置しない
GuardDutyは検出するだけで自動修復はしない。EventBridge + Lambdaの自動対応を構築するか、最低限SNS通知を設定してチームが迅速に対応できる体制を整備。
❌ サプレッションルールの過剰設定
誤検知を抑制するために安易にサプレッションルールを追加すると、本物の脅威を見逃すリスクがある。ルールは必要最小限に。
❌ カスタムDNSで検出範囲を狭めない
独自DNSサーバーを構築するとGuardDutyのDNSモニタリングが機能しない。必要な場合はRoute 53 Resolverとの併用を検討。
❌ 単一リージョンのみで運用しない
攻撃者は未使用リージョンを狙う。「東京リージョンだけ」の有効化では、他リージョンでの不正リソース作成を検知できない。
💰 コスト構造を理解する
VPCフローログ & DNSログ
分析したデータ量（GB）に対して課金。月の利用量が増えるほど単価が下がる段階的割引あり。
30日間無料トライアル
初回有効化時は全基盤データソースの分析が30日間無料。この間に推定月額コストを確認可能。
Runtime Monitoring利用時
EC2のRuntime Monitoringエージェントが有効な場合、そのインスタンスのVPCフローログ分析は二重課金されない。
❓ よくある質問（FAQ）
GuardDutyのトラフィック分析に関するよくある疑問