GuardDuty Runtime Monitoring を EKS / ECS-Fargate / EC2 で本番運用する：セキュリティエージェント・カバレッジ・コスト・トラブルシュート

「GuardDuty を入れたんですが、コンテナの中で何か変なプロセスが動いても気づけますか？」——コンテナ基盤のセキュリティを相談される場で、これは核心を突いた質問です。

答えは「基盤の GuardDuty だけでは気づけない」です。エージェントレスの基盤検知（CloudTrail・VPC Flow Logs・DNS）は、AWS のコントロールプレーン操作とネットワークの外形を見ます。けれど「コンテナの中で見知らぬバイナリが実行された」「/etc/shadow が改変された」「リバースシェルが張られた」といった、ワークロードの内側で起きる OS レベルの挙動は、外からは見えません。ここを埋めるのが GuardDuty Runtime Monitoring です。

この記事は、Runtime Monitoring を EKS / ECS-Fargate / EC2 の3つの面で本番品質で設計・運用するための実装ガイドです。GuardDuty 全体の設計（保護プラン選定・組織統制・EventBridge 自動対応）はこちらのピラー記事に譲り、本稿はそのピラーの「Runtime Monitoring」一行を、配布アーキテクチャ・カバレッジ確認・コスト・トラブルシュートまで一段深く掘り下げることに集中します。私はマルチアカウント AWS 上のサーバーレス決済プラットフォームで IAM・可観測性・DR を横断実装し、ECS on Fargate で本番ワークロードを運用してきました——その経験を土台に、「Runtime Monitoring をあなたの環境にどう設計・実装するか」を語ります。

この記事のルール：仕様・対応 OS／アーキテクチャ・カーネル要件・エージェントのリソース上限・料金体系は AWS 公式ドキュメント（2026年6月時点） に基づきます。対応する OS／カーネル／Kubernetes バージョンは頻繁に更新されるため、本番投入前に必ず公式の「サポートマトリクス（verified platforms）」を確認してください（本文中でも具体的なバージョン列挙は避け、確認手順を示します）。そしてもう一つ——Runtime Monitoring は GuardDuty の一機能（一層）であり、WAF・最小権限 IAM・イメージスキャン・ネットワーク分離を代替しません。コストは保護 vCPU に比例するため、「全部に入れる」ではなく「重要ワークロードに絞る」が設計の基本です。

0. メンタルモデル：Runtime Monitoring は「ワークロードの内側を見る目」

設計を始める前に、Runtime Monitoring が基盤検知と何を補完するのかを一行で固定します。

Runtime Monitoring ＝ EKS / ECS-Fargate / EC2 のワークロードに eBPF セキュリティエージェントを置き、OS レベルの「プロセス実行・ファイルアクセス・ネットワーク接続」を内側から観測して finding を生成する、GuardDuty の任意保護プラン。

公式の定義はこうです——"Runtime Monitoring observes and analyzes operating system-level, networking, and file events"、そしてエージェントは "file access, process execution, command line arguments, and network connections" を可視化します。ここから3つの帰結が出ます。

1. 基盤検知は「外形」、Runtime Monitoring は「内側」。 基盤の VPC Flow Logs は「どの IP と通信したか」をネットワークの外側から見ます。Runtime Monitoring は「どのプロセスがその通信を起こしたか」「コマンドライン引数は何か」「親プロセスは何か（プロセス系統）」まで、ホストの内側から見ます。たとえば暗号資産マイニングは、基盤の DNS 検知でもドメインで引っかかりますが、Runtime Monitoring なら Impact:Runtime/CryptoMinerExecuted として「実際にマイナーバイナリが実行された」事実を捉えます。
2. 見るためには「エージェント」が要る。 基盤検知がエージェントレスなのに対し、Runtime Monitoring はワークロード上で動く eBPF ベースのセキュリティエージェントを必要とします。このエージェントをどう配るかが、本記事の主題です（EKS / Fargate / EC2 で配り方が違う）。
3. 「有効化した＝守れている」ではない。 エージェントが正しく配置され、VPC エンドポイント経由でランタイムイベントが GuardDuty に届いて初めて検知が動きます。この「本当に届いているか」を表すのがカバレッジ状態（Healthy / Unhealthy）です。Unhealthy のまま放置すると、有効化したつもりで一切 finding が出ない穴になります（4 章）。

この3点を押さえると、Runtime Monitoring の導入は 「①どの面に・②どう配り（自動 or 手動）・③本当に届いているか確認し・④コストを制御する」 の4設計だと分かります。順に作ります。

1. なぜ基盤検知だけでは足りないのか：Runtime Monitoring が足すもの

ピラー記事で見たとおり、GuardDuty を有効化すると基盤データソースが即オンになります。では Runtime Monitoring は具体的に何を追加で見える化するのか。攻撃のキルチェーンに沿って並べると、補完関係が明確になります。

要点は 「基盤検知は『外で観測できる兆候』を、Runtime Monitoring は『ホスト内部でしか観測できない挙動』を捉える」 ことです。公式が挙げる典型シナリオはこうです——脆弱な Web アプリを動かす単一コンテナが侵害され、設定ミスの認証情報を足がかりにアカウント全体へアクセスが広がる。この「コンテナ侵害 → 権限昇格 → データアクセス」の連鎖は、コンテナの内側を見ない限り初期段階で捕まえられません。

そしてもう一つ決定的なのが、Extended Threat Detection（攻撃シーケンス）との関係です。詳細は攻撃シーケンスの記事に譲りますが、結論だけ：

• ECS の攻撃シーケンス（AttackSequence:ECS/CompromisedCluster）は Fargate-ECS または EC2 の Runtime Monitoring が前提。
• EC2 の攻撃シーケンス（AttackSequence:EC2/CompromisedInstanceGroup）は Runtime Monitoring で強化される。

つまり「ECS/EC2 の多段攻撃を1つの Critical finding に束ねたい」なら、Runtime Monitoring は任意プランではなく前提条件になります。これが「重要ワークロードには入れる価値がある」最大の理由です。

2. 3つの配布面：エージェントはどう届くか

Runtime Monitoring の本質的な難しさは、同じ「セキュリティエージェント」が、リソース種別ごとに全く違う配り方をする点にあります。公式は EKS・Fargate-ECS・EC2 をまとめて**「リソースタイプ（resource type）」**と呼びます。

ここを正確に理解することが、設計判断の土台です。3つの面それぞれの「効きどころ」を見ます。

2.1 EKS：マネージドアドオン aws-guardduty-agent

EKS では、エージェントは EKS マネージドアドオン aws-guardduty-agent として配布されます。実体はクラスタ内の DaemonSet（各ノードに1 Pod）です。

• 自動管理：GuardDuty が必要に応じてアドオンをデプロイ・更新します。"GuardDuty manages the security agent (EKS add-on) on your behalf, it updates the add-on, as needed"。設定パラメータ（CPU/メモリ・PriorityClass・dnsPolicy）はデフォルト値が入りますが、必要なら自分で上書きできます。
• 手動管理：アドオンのバージョンとライフサイクルを自分で握ります。バージョンを厳密に固定したい／クラスタの変更管理プロセスに乗せたい場合に選びます。手動の場合、Kubernetes バージョンがエージェントバージョンをサポートしているかを自分で確認する必要があります（公式に対応表あり——後述）。

EKS の対応範囲（重要）：Runtime Monitoring は EC2 ノード上の EKS クラスタと EKS Auto Mode をサポートします。一方で EKS Hybrid Nodes と AWS Fargate 上の EKS クラスタは非対応です（"GuardDuty doesn't support Amazon EKS clusters running on AWS Fargate"）。「EKS を Fargate で動かしている」場合、この機能では守れない——設計時に必ず確認してください。

2.2 ECS-Fargate：注入されるサイドカー

Fargate ではホスト OS に触れないため、エージェントはサイドカーコンテナとしてタスクに注入されます。ここで最重要の制約——Fargate（ECS）は自動管理のみで、手動管理の選択肢がありません（公式も "with an exception to Fargate (Amazon ECS only)" と明記）。GuardDuty が配置・更新を全面的に担います。

Fargate でコンテナを本番運用しているなら、Runtime Monitoring は最も導入が軽い面です。ホストのパッチも SSM 管理も不要で、有効化すれば GuardDuty がサイドカーを面倒見ます。その代わり、バージョンや配置を自分でコントロールする余地はない——これは Fargate の「サーバーレスでお任せ」という性質と一貫したトレードオフです。

2.3 EC2：SSM 経由のエージェント

EC2 では、エージェントは SSM（AWS Systems Manager） を通じて配布されます。"GuardDuty uses AWS Systems Manager (SSM) to automatically deploy, install, and manage the security agent on your instances"。

• 自動管理の前提：インスタンスが SSM 管理下にあること（Fleet Manager に表示される状態）。自動管理を使うなら、これはハード要件です。
• 手動管理："If you plan to manually install and manage the GuardDuty agent, SSM is not required"。SSM を使わない／使えない環境（特殊なベースイメージなど）では手動を選びます。
• 除外タグ：自動管理下で特定インスタンスを除外したいなら、GuardDutyManaged:false タグを起動前に付与し、インスタンスメタデータ（IMDS）のタグ参照を有効化します。「全部入れたいが一部だけ外す」運用に効きます。

3. Terraform で有効化する：RUNTIME_MONITORING と3つのトグル

設計が固まったら、コードに落とします。Runtime Monitoring は aws_guardduty_detector 本体とは別の aws_guardduty_detector_feature リソースで足します。

# Runtime Monitoring を有効化し、各面のエージェント配置を GuardDuty に自動管理させる。
# コストが保護 vCPU に比例して増えるため、「本当にランタイム可視性が要る環境」に絞って有効化する。
resource "aws_guardduty_detector_feature" "runtime_monitoring" {
  detector_id = aws_guardduty_detector.this.id
  name        = "RUNTIME_MONITORING"
  status      = "ENABLED"

  # --- 面ごとに「エージェントを GuardDuty に自動管理させるか」を個別に切り替える ---
  # ここを ENABLED にすると、その面のエージェント配置・更新を GuardDuty が担う(自動管理)。
  # DISABLED にすると、Runtime Monitoring 自体は有効でも、その面のエージェントは
  # 「手動管理」(自分でアドオン/SSM を回す)前提になる。

  additional_configuration {
    name   = "EKS_ADDON_MANAGEMENT" # EKS: aws-guardduty-agent アドオンを自動デプロイ・更新
    status = "ENABLED"
  }
  additional_configuration {
    name   = "ECS_FARGATE_AGENT_MANAGEMENT" # Fargate: サイドカーを自動注入(手動の選択肢なし)
    status = "ENABLED"
  }
  additional_configuration {
    name   = "EC2_AGENT_MANAGEMENT" # EC2: SSM 経由でエージェントを自動管理
    status = "ENABLED"
  }
}

設計のポイントを3つ。

• トグルは「面ごとの自動管理スイッチ」。RUNTIME_MONITORING を ENABLED にしたうえで、EKS_ADDON_MANAGEMENT / ECS_FARGATE_AGENT_MANAGEMENT / EC2_AGENT_MANAGEMENT を個別に切り替えます。EKS だけ手動管理にしたいなら EKS_ADDON_MANAGEMENT を DISABLED にし、アドオンは別管理（次節）にします。
• EKS アドオンは別リソースで明示できる。自動管理（EKS_ADDON_MANAGEMENT = ENABLED）なら GuardDuty がアドオンを入れますが、手動管理する場合は EKS アドオンを Terraform で明示します。

# 【手動管理を選んだ場合のみ】EKS アドオンを自分で管理する。
# バージョンを固定し、クラスタの変更管理プロセスに乗せたいときに有効。
# 自動管理(EKS_ADDON_MANAGEMENT = ENABLED)なら、このリソースは不要。
resource "aws_eks_addon" "guardduty_agent" {
  cluster_name = aws_eks_cluster.this.name
  addon_name   = "aws-guardduty-agent"

  # バージョンは公式の対応表で「使用中の Kubernetes バージョンが
  # そのエージェントバージョンをサポートするか」を確認してから固定する。
  # ハードコードせず、変数 or data source で管理する(対応表は更新されるため)。
  addon_version = var.guardduty_agent_addon_version

  # 既存設定との衝突時の挙動。手動でパラメータ(CPU/メモリ等)を上書きするなら PRESERVE。
  resolve_conflicts_on_update = "PRESERVE"
}

• 組織で一括有効化するなら、ピラー記事の aws_guardduty_organization_configuration_feature と同じ構造で RUNTIME_MONITORING を組織全体に展開できます。ただしコストドライバなので、組織全社デフォルト ON にする前にコストを試算してください（6 章）。

EKS_RUNTIME_MONITORING との関係（要確認）：歴史的に、EKS 専用の EKS_RUNTIME_MONITORING という独立した機能が存在しました。現在は RUNTIME_MONITORING（EKS/ECS/EC2 を束ねる統合機能）への集約が進んでいます。新規構築では RUNTIME_MONITORING を使うのが正解です。既存環境で EKS_RUNTIME_MONITORING を使っている場合の移行可否・期限は改定され得るため、公式ドキュメントで現時点の扱いを必ず確認してください（本記事執筆時点で「統合方向」という事実は確認済み、具体的な廃止スケジュールは公式準拠）。

4. カバレッジを確認する：「有効化したつもり」の穴を塞ぐ

Runtime Monitoring 運用で最も事故が起きるポイントがここです。「Terraform で有効化した」だけでは不十分で、エージェントが本当にイベントを届けているかを別途確認しなければなりません。これを表すのがカバレッジ状態です。

4.1 Healthy / Unhealthy が意味するもの

公式の定義は明快です。カバレッジ状態は3つの条件が揃って初めて Healthy になります。

Coverage status is determined by making sure that you have enabled Runtime Monitoring, your Amazon VPC endpoint has been created, and the GuardDuty security agent for the corresponding resource has been deployed.

決定的なのは——Unhealthy の間は finding がゼロだという点です。「有効化したのにアラートが来ない」のが「平和だから」なのか「Unhealthy で目が見えていないから」なのかは、カバレッジを見ない限り区別がつきません。だから「有効化」と「カバレッジ Healthy の確認」は必ずセットにします。

4.2 bash でカバレッジを確認する

GuardDuty にはカバレッジ統計と個別リソースの状態を返す API があります。CI やデプロイ後の検証スクリプトに組み込めます。

#!/usr/bin/env bash
# Runtime Monitoring のカバレッジを確認し、Unhealthy なリソースを洗い出す。
# デプロイ後の検証 or 定期監査に使う。「有効化したつもり」の穴を機械的に塞ぐ。
set -euo pipefail

DETECTOR_ID="${1:?Usage: check-coverage.sh <detector-id>}"

# ① 種別ごとのカバレッジ統計(Healthy/Unhealthy のカウント)を取得。
#    全体像を一目で掴む。
echo "=== Coverage statistics by resource type ==="
aws guardduty get-coverage-statistics \
  --detector-id "$DETECTOR_ID" \
  --statistics-type COUNT_BY_COVERAGE_STATUS \
  --output table

# ② Unhealthy なリソースだけを列挙(個別の調査対象を特定)。
#    フィルタで coverage status = UNHEALTHY のものに絞る。
echo "=== Unhealthy resources (need troubleshooting) ==="
aws guardduty list-coverage \
  --detector-id "$DETECTOR_ID" \
  --filter-criteria '{
    "FilterCriterion": [
      { "CriterionKey": "COVERAGE_STATUS", "FilterCondition": { "Equals": ["UNHEALTHY"] } }
    ]
  }' \
  --query 'Resources[].{Id:ResourceId,Type:ResourceDetails.ResourceType,Status:CoverageStatus,Issue:Issue}' \
  --output table

検証経路を先に作る：私はこのスクリプトを CI のデプロイ後フックに置くことを薦めます。Terraform で RUNTIME_MONITORING を ON にした直後に走らせ、重要ワークロードが Healthy であることを確認するまでデプロイを「完了」と見なさない——「有効化したつもり」を構造的に潰す、最も効くガードです。

4.3 Unhealthy の典型原因とトラブルシュート

Unhealthy の原因は、3条件のどこかが欠けています。面ごとに切り分けます。

手動管理を選んだ場合、VPC エンドポイントの作成は自分の責任になる点に注意してください（自動管理なら GuardDuty が作ります）。"Install agent manually, which requires you to create the VPC endpoint as a prerequisite."——これを忘れると、エージェントは動いていてもイベントが届かず Unhealthy のまま、という典型的な落とし穴にハマります。

5. エージェントは「軽量」か：CPU/メモリ上限を数字で押さえる

「セキュリティエージェントを本番に入れる」と聞くと、まず気になるのがワークロードへの負荷です。Runtime Monitoring のエージェントが「軽量」と言われる根拠は、明示的な上限が設けられていることにあります。憶測ではなく公式の数字で押さえます。

ポイントを3つ。

• EC2 は「割合」で上限。"The maximum CPU limit for the GuardDuty security agent associated with Amazon EC2 instances is 10 percent of the total vCPU cores." インスタンスが大きいほど絶対量は増えますが、**比率は一定（10%）**なので、ワークロードを圧迫しにくい設計です。
• EKS は「絶対値」で上限。アドオンのデフォルトは CPU 200m〜1000m、メモリ 256Mi〜1024Mi。v1.5.0 以降は CPU／Memory／PriorityClass／dnsPolicy を設定変更可能で、ワークロードやインスタンスサイズに合わせて調整できます。Insights が「上限に達している」と示したら、ここを引き上げます。
• 実測で監視する。公式は CPU/メモリの消費を Container Insights で監視することを推奨しています（ECS も EKS も）。「軽量」を信じきらず、実測する——これが本番の規律です。

PriorityClass の注意：EKS アドオンのデフォルト PriorityClass は「エージェント Pod の優先度に基づく特別扱いをしない」設定です。ノードがリソース逼迫した際にエージェント Pod が真っ先に退避（evict）されると、その瞬間カバレッジが Unhealthy に落ちます。セキュリティの可視性を切らしたくないクラスタでは、system-node-critical 等への変更をトレードオフ（重要ワークロードの退避リスク vs 監視の継続性）込みで検討します。

6. コスト規律：保護 vCPU に比例する最大のドライバ

ここが Runtime Monitoring 運用の意思決定の核心です。Runtime Monitoring は保護 vCPU に比例して課金され、GuardDuty の保護プランの中で最もコストが高くなりやすい機能です。GuardDuty 全体のコスト最適化は専用記事に譲りますが、Runtime Monitoring 固有の勘所を3つ。

6.1 課金は「保護したワークロードの vCPU 規模 × 稼働時間」

公式の課金単位は 「監視対象として保護されたプロビジョン済みインスタンス／タスクの vCPU 数 × 稼働時間」 をベースにします。つまりvCPU の大きいワークロードを長時間守るほど高い。基盤検知（イベント量・GB 課金）とは課金の性質が違い、「資産の規模」に直結します。だから——「とりあえず全 EC2・全クラスタに入れる」は、vCPU 課金が雪だるま式に膨らむ最短ルートです。

6.2 だから「重要ワークロードに絞る」

設計の基本は 「重要度でスコープを絞る」 です。私が薦める段階導入：

1. 攻撃シーケンスが要る面から：ECS/EC2 の攻撃シーケンス（Critical finding）を取りたい本番の重要ワークロードにまず入れる。
2. 機微データを扱う面：決済・個人情報・認証基盤など、侵害時のインパクトが大きいワークロード。
3. それ以外は見送るか、EC2 の除外タグで明示的に外す。

「全部入れて安心」より、**「インパクトの大きい資産に集中投資し、ETD の相関効果も含めて費用対効果を最大化」**するほうが、限られたセキュリティ予算では勝ります。

6.3 知っておくと得する「VPC Flow Logs 二重課金の免除」

Runtime Monitoring のコストを語るうえで見落とされがちな救済がこれです。公式の原文：

When you manage the security agent ... and GuardDuty is presently deployed on an Amazon EC2 instance and receives the Collected runtime event types from this instance, GuardDuty will not charge your AWS account for the analysis of VPC flow logs from this Amazon EC2 instance. This helps GuardDuty avoid double usage cost in the account.

つまり——EC2 インスタンス上でエージェントが動き、GuardDuty がそのインスタンスのランタイムイベントを受け取っている場合、GuardDuty はそのインスタンスの VPC Flow Logs 解析費を課金しません。Runtime Monitoring がネットワーク接続をエージェント経由で見ているので、基盤の VPC Flow Logs 解析と二重に取らない設計です。Runtime Monitoring の vCPU 課金は、基盤の Flow Logs 課金の一部を相殺する——コスト試算ではこの免除を織り込みます（これを知らずに「Runtime Monitoring は純粋に上乗せ」と見積もると過大になります）。

新規リージョンの30日無料トライアル：Runtime Monitoring にも30日の無料トライアルが付きます。本番量での想定請求額を、課金開始前に把握できます。重要ワークロードに絞る判断は、このトライアル期間の実測でさらに精度が上がります。

7. finding を読む：Runtime Monitoring の型ファミリー

Runtime Monitoring の finding は、リソースセグメントが Runtime であることで一目で識別できます（型 : Runtime / 脅威名）。基盤の EC2/S3/IAMUser 等とは別系統です。主要なファミリーを、攻撃段階ごとに整理します。

実装上の要点を2つ。

• Runtime セグメントでルーティングできる。EventBridge の自動対応（ピラー記事の6章）で、type が *:Runtime/* のものは「コンテナ／ホスト内部の侵害」として、ネットワーク隔離だけでなく該当 Pod／タスクの停止・隔離まで踏み込んだ対応を検討できます。プロセス系統の情報が finding に含まれるため、調査が速い。
• finding フィールドのサニタイズ必須：公式が明記する重要な注意——Runtime Monitoring の finding は攻撃者が制御し得るファイルパス等を含むため、"When processing Runtime Monitoring findings outside of GuardDuty console, you must sanitize finding fields. For example, you can HTML encode finding fields." 自動対応や通知で finding を Web 表示・転送する際は、HTML エスケープなどのサニタイズを必ず通す（信頼できない入力として扱う）。これは私のルート規約の「外部入力は検証・エスケープ」と完全に一貫します。

8. 意思決定表：どの面に・自動 or 手動で入れるか

ここまでを実務の判断に落とし込みます。**「どのワークロードに、どの面で、自動か手動か」**を一枚で。

意思決定の軸は2つだけです：①そのワークロードは「ランタイム可視性／攻撃シーケンス」に見合う重要度か（＝コストを払う価値があるか）、②バージョン管理を自分で握る必要があるか（＝自動 vs 手動）。この2軸で、上の表に落ちます。

9. まとめ：GuardDuty Runtime Monitoring 本番チートシート

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

• 何の層か：Runtime Monitoring はワークロードの内側（OS レベルのプロセス・ファイル・ネットワーク）を eBPF セキュリティエージェントで観測する任意保護プラン。エージェントレスの基盤検知（外形）を補完する。
• 3つの配布面：EKS＝マネージドアドオン aws-guardduty-agent（DaemonSet）／ECS-Fargate＝注入サイドカー（自動のみ）／EC2＝SSM 経由。配り方が面ごとに違うことを理解するのが第一歩。
• 自動 vs 手動：迷ったら自動（運用負荷が低い）。手動はバージョン固定・変更管理に乗せたい時だけ。Fargate は手動の選択肢なし。手動時は VPC エンドポイント作成が自己責任。
• Terraform：aws_guardduty_detector_feature の RUNTIME_MONITORING ＋ 3トグル（EKS_ADDON_MANAGEMENT / ECS_FARGATE_AGENT_MANAGEMENT / EC2_AGENT_MANAGEMENT）。新規は RUNTIME_MONITORING を使う（EKS_RUNTIME_MONITORING は統合方向）。
• カバレッジ確認（必須）：有効化＝守れている、ではない。Healthy = Runtime Monitoring 有効 + VPC エンドポイント + エージェント配置の3点が揃った状態。Unhealthy だと finding はゼロ。get-coverage-statistics／list-coverage で機械的に確認し、CI に組み込む。
• 軽量さは数字で：EC2 は総 vCPU の最大10%、EKS アドオンは CPU 200m〜1000m・メモリ 256Mi〜1024Mi（v1.5.0 以降は設定変更可）。Container Insights で実測する。
• コスト規律：保護 vCPU に比例する GuardDuty 最大のコストドライバ。重要ワークロードに絞る。ただしエージェントが動く EC2 の VPC Flow Logs 解析費は免除（二重課金なし）——試算に織り込む。30日無料トライアルで実測。
• 対応スコープの罠：Fargate 上の EKS／EKS Hybrid Nodes は非対応。EC2 ノード上の ECS は ECS 攻撃シーケンス非対応（Fargate-ECS か EC2 が前提）。設計前に必ず確認。
• サポートマトリクス：対応 OS／カーネル／K8s バージョンは頻繁に更新される。ハードコードせず、公式の verified platforms を確認。CONFIG_DEBUG_INFO_BTF=y などカーネル要件も忘れずに。

Runtime Monitoring は「有効化すれば中まで見てくれる箱」ではなく、「①どの面に・②どう配り・③カバレッジを確認し・④コストを制御するか」を設計しきって初めて価値が出る機能です。最大のレバレッジは**「重要ワークロードに絞り、カバレッジ Healthy を CI で担保し、Flow Logs 免除込みでコストを最適化する」**規律にあります。

私はマルチアカウントのサーバーレス決済プラットフォームで IAM・可観測性・DR を横断実装し、ECS on Fargate で本番ワークロードを運用してきました。Runtime Monitoring の導入も同じ思想で設計します——①重要ワークロードを見極めてスコープを絞り、②自動/手動を要件で選び分け、③カバレッジ Healthy を検証経路に組み込み、④vCPU 課金と Flow Logs 免除を織り込んでコストを読む。「有効化したつもり」の穴を構造的に潰し、検知を運用に載せきります。

「自社の EKS / Fargate / EC2 に Runtime Monitoring をどう設計し、どこまで自動管理に任せ、どうコストを抑えるか」——配布面の選定から Terraform 実装、カバレッジ検証、コスト試算、攻撃シーケンス連携まで、一人 ×生成AI（Claude Code）で速く・安全に伴走できます。 要件の整理段階からでも、お気軽にご相談ください。

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

• GuardDuty Runtime Monitoring — Runtime Monitoring の定義・対応リソース・セキュリティエージェントの観測対象
• How Runtime Monitoring works — 有効化＋エージェント管理の2段階、VPC エンドポイント、VPC Flow Logs 二重課金の免除
• Managing GuardDuty security agents — 自動／手動管理、面ごとのエージェント管理、Healthy/Unhealthy の前提
• Reviewing runtime coverage statistics and troubleshooting — カバレッジ状態の定義（Healthy=3条件充足／Unhealthy=finding ゼロ）
• Prerequisites for Amazon EC2 instance support — SSM 管理、対応アーキテクチャ、EC2 の CPU 上限（総 vCPU の10%）、カーネル要件
• Prerequisites for Amazon EKS cluster support — verified platforms（OS/カーネル/K8s 対応表）、EKS アドオンの CPU/メモリ上限、Fargate-EKS／Hybrid Nodes 非対応
• Configure GuardDuty security agent (add-on) parameters for Amazon EKS — v1.5.0+ の CPU/メモリ・PriorityClass・dnsPolicy 設定
• GuardDuty Runtime Monitoring finding types — *:Runtime/* の finding 型一覧とサニタイズ注意
• Amazon GuardDuty pricing — Runtime Monitoring の保護 vCPU ベース課金・30日無料トライアル