GuardDuty Runtime MonitoringをEC2のタグ指定で有効化し、タグの付け外しでの挙動を確かめてみた

はじめに

かつまたです。

GuardDuty Runtime Monitoring で EC2 を監視する際に、監視したい台だけを選べるようにタグ（GuardDutyManaged:true）を付けた台だけを対象にする方式で有効化することがあるかと思います。

ドキュメントを読んだ範囲では、タグを外したときや、タグの値の大文字小文字が違うときにどうなるかは見つけられませんでした。そこで、検証用の AWS アカウントで実際にタグを付け外しして、挙動を確かめてみました。

やりたいこと

次の点を確かめます。

1. タグを付けてから、監視が始まるまでの時間
2. タグを外したときの挙動（エージェントやカバレッジの状態はどうなるか）
3. タグを付けていない台が、カバレッジ(Runtime Monitoring で監視できている台と、その状態（HEALTHY / UNHEALTHY）の一覧)にどう見えるか
4. タグの値を大文字の True にしたときに、対象になるか
5. 監視対象の台を削除したとき、Runtime Monitoring を無効にしたときに、GuardDuty が自動で作ったリソース（AWS Systems Manager の関連付け、VPC エンドポイント、セキュリティグループ）がどうなるか

前提条件

仕様確認

検証の前に、公式ドキュメントに書かれていることを整理しました。

タグを外したときの扱い、値の大文字小文字、タグのない台のカバレッジ上の見え方、監視対象の台を削除したときの自動作成リソースの扱いは、読んだ範囲では見つけられませんでした。これらを今回の検証項目にしています。無効にしたときの扱いはドキュメントに説明があるため、記載どおりに消えるかを確かめます。

検証環境

やってみた

事前準備

EC2 を作る

3 台とも、GuardDutyManaged タグを付けずに作りました。A・B はカーネル 6.12、C はカーネル 6.18 の AMI です。

AMI_ID="<AMI ID>"          # A・B はカーネル 6.12、C はカーネル 6.18 の AL2023 AMI
SUBNET_ID="<サブネットID>"
SG_ID="<デフォルトSGのID>"
PROFILE_NAME="<SSM用インスタンスプロファイル名>"
NAME=gd-rm-test-A          # B・C は名前を変えて同じコマンドで作成

aws ec2 run-instances --image-id "$AMI_ID" --instance-type t3.micro \
  --subnet-id "$SUBNET_ID" --security-group-ids "$SG_ID" \
  --iam-instance-profile Name="$PROFILE_NAME" \
  --metadata-options HttpTokens=required,InstanceMetadataTags=enabled \
  --tag-specifications "ResourceType=instance,Tags=[{Key=Name,Value=${NAME}}]" \
  --count 1 --query 'Instances[0].InstanceId' --output text

作成から約 40 秒で、3 台とも SSM の管理下（Online）に入りました。この時点では、3 台ともエージェントは入っていません。

Runtime Monitoring を有効にする

RUNTIME_MONITORING を有効にし、EC2 の自動エージェント設定は無効のままにしました。

DETECTOR_ID=$(aws guardduty list-detectors --query 'DetectorIds[0]' --output text)

aws guardduty update-detector --detector-id "$DETECTOR_ID" \
  --features '[{"Name":"RUNTIME_MONITORING","Status":"ENABLED","AdditionalConfiguration":[{"Name":"EC2_AGENT_MANAGEMENT","Status":"DISABLED"},{"Name":"EKS_ADDON_MANAGEMENT","Status":"DISABLED"},{"Name":"ECS_FARGATE_AGENT_MANAGEMENT","Status":"DISABLED"}]}]'

aws guardduty get-detector --detector-id "$DETECTOR_ID" \
  --query 'Features[?Name==`RUNTIME_MONITORING`]'

get-detector の結果で、RUNTIME_MONITORING が ENABLED、3 つの自動エージェント設定が DISABLED になったことを確かめました。

検証手順

観測に使ったコマンド

タグを付けたあとは、次のコマンドをまとめておおむね 30 秒ごとに実行し、状態の変化を追いました。以降の所要時間は、この 30 秒間隔で観測した時刻を基準にしています。

DETECTOR_ID=$(aws guardduty list-detectors --query 'DetectorIds[0]' --output text)

aws guardduty list-coverage --detector-id "$DETECTOR_ID"
aws guardduty get-coverage-statistics --detector-id "$DETECTOR_ID" \
  --statistics-type COUNT_BY_COVERAGE_STATUS

DETECTOR_ID=$(aws guardduty list-detectors --query 'DetectorIds[0]' --output text)

aws guardduty list-coverage --detector-id "$DETECTOR_ID" \
  --query 'Resources[].[ResourceDetails.Ec2InstanceDetails.InstanceId,CoverageStatus,Issue,ResourceDetails.Ec2InstanceDetails.ManagementType,ResourceDetails.Ec2InstanceDetails.AgentDetails.Version]' \
  --output table

aws ssm list-associations \
  --association-filter-list key=AssociationName,value=GuardDutyRuntimeMonitoring
ASSOCIATION_ID=$(aws ssm list-associations \
  --association-filter-list key=AssociationName,value=GuardDutyRuntimeMonitoring \
  --query 'Associations[0].AssociationId' --output text)
aws ssm describe-association --association-id "$ASSOCIATION_ID"
aws ssm describe-association-executions --association-id "$ASSOCIATION_ID"
EXECUTION_ID=$(aws ssm describe-association-executions --association-id "$ASSOCIATION_ID" \
  --query 'AssociationExecutions[0].ExecutionId' --output text)
aws ssm describe-association-execution-targets \
  --association-id "$ASSOCIATION_ID" --execution-id "$EXECUTION_ID"

aws ec2 describe-vpc-endpoints \
  --filters Name=service-name,Values=com.amazonaws.ap-northeast-1.guardduty-data
aws ec2 describe-security-groups --filters Name=tag-key,Values=GuardDutyManaged

INSTANCE_ID=i-0aaaaaaaaaaaaaaaa

COMMAND_ID=$(aws ssm send-command --document-name AWS-RunShellScript \
  --instance-ids "$INSTANCE_ID" \
  --parameters 'commands=["uname -r","systemctl is-active amazon-guardduty-agent","rpm -qa | grep -i guardduty"]' \
  --query 'Command.CommandId' --output text)

# 実行が終わるまで数秒待ってから結果を表示する
aws ssm get-command-invocation --command-id "$COMMAND_ID" --instance-id "$INSTANCE_ID" \
  --query '[Status,StandardOutputContent]' --output text

1. A と C にタグを付ける

Runtime Monitoring を有効にしたあと、A と C に GuardDutyManaged:true を付けました。

タグを付けると、約 40 秒後の観測で SSM の関連付け、VPC エンドポイント、セキュリティグループが見えるようになりました。関連付けの主な項目は次のとおりです。

{
    "AssociationName": "GuardDutyRuntimeMonitoring-do-not-delete",
    "Targets": [{"Key": "tag:GuardDutyManaged", "Values": ["true"]}],
    "ScheduleExpression": "rate(1 day)",
    "MaxConcurrency": "10%"
}

A と C の進み方の違いは、結果で後述します。

2. A からタグを外す

A と C がカバレッジで HEALTHY になったのを確かめてから、A のタグを外しました。

3. B に大文字の True を付ける

タグのない B に GuardDutyManaged:True（先頭が大文字）を付けました。

ID_A=i-0aaaaaaaaaaaaaaaa
ID_B=i-0bbbbbbbbbbbbbbbb
ID_C=i-0cccccccccccccccc

aws ec2 create-tags --resources "$ID_B" --tags Key=GuardDutyManaged,Value=True
aws ec2 describe-tags \
  --filters "Name=resource-id,Values=${ID_A},${ID_B},${ID_C}" Name=key,Values=GuardDutyManaged \
  --output text

TAGS	GuardDutyManaged	i-0cccccccccccccccc	instance	true
TAGS	GuardDutyManaged	i-0bbbbbbbbbbbbbbbb	instance	True

A が HEALTHY になるまでにかかった時間の約 2 倍にあたる 8 分間観測し、打ち切りました。

4. 3 台を削除する

3 台を削除（terminate）し、そのあとも Runtime Monitoring は有効のまま、自動作成のリソースが残るかを観測しました。

ID_A=i-0aaaaaaaaaaaaaaaa
ID_B=i-0bbbbbbbbbbbbbbbb
ID_C=i-0cccccccccccccccc

aws ec2 terminate-instances --instance-ids "$ID_A" "$ID_B" "$ID_C" \
  --query 'TerminatingInstances[].[InstanceId,CurrentState.Name]' --output text
aws ec2 wait instance-terminated --instance-ids "$ID_A" "$ID_B" "$ID_C"

5. Runtime Monitoring を無効にする

最後に Runtime Monitoring を無効に戻し、自動作成のリソースが消えるかを観測しました。

DETECTOR_ID=$(aws guardduty list-detectors --query 'DetectorIds[0]' --output text)

aws guardduty update-detector --detector-id "$DETECTOR_ID" \
  --features '[{"Name":"RUNTIME_MONITORING","Status":"DISABLED","AdditionalConfiguration":[{"Name":"EC2_AGENT_MANAGEMENT","Status":"DISABLED"},{"Name":"EKS_ADDON_MANAGEMENT","Status":"DISABLED"},{"Name":"ECS_FARGATE_AGENT_MANAGEMENT","Status":"DISABLED"}]}]'

最終確認で、GuardDuty の Runtime Monitoring の設定、SSM の関連付け、VPC エンドポイント、セキュリティグループ、カバレッジが、すべて開始前と同じ状態に戻ったことを確かめました。手動で削除したリソースはありません。

結果

時系列

確認できた挙動を、3 台を作成した時点を 0:00 とした経過時間で並べてみます。

① タグを付けてから監視開始までの時間

A は 4 分以内、C は約 7 分で HEALTHY になりました。

② タグを外したときの挙動

タグを外しても、A の監視は止まりませんでした。

タグを外した台は、手エージェントを止めるにはアンインストールが別に必要になると考えていますが、その手順は今回試していません。

エージェントを入れた台と同じ扱い（MANUAL）になり、監視は続きます。

③ タグのない台の見え方

• Runtime Monitoring を有効にすると、タグのない台もカバレッジに UNHEALTHY / No Agent Reporting / MANUAL で出てきました
• タグのない台には、エージェントは入りませんでした（B は最後まで入らず）

④ タグの値の大文字小文字

GuardDutyManaged:True を付けた B は対象になりませんでした。

• エージェントは入らず、カバレッジは UNHEALTHY / MANUAL のままでした
• 関連付けの実行は増えず（{Success=2} のまま）、B の関連付けの状態も空でした

関連付けの対象は tag:GuardDutyManaged の値 true なので、値は小文字の true と完全に一致する必要があると読み取りました。

⑤ EC2を削除したとき・Runtime Monitoring を無効にしたとき

削除してから観測できた約 4 分間、関連付け・VPC エンドポイント・セキュリティグループは残ったままでした。監視対象の台がなくなっても、Runtime Monitoring が有効な間は、これらのリソースはすぐには消えませんでした。

Runtime Monitoring を無効にすると、3 つとも自動削除され、手動の削除は不要でした。

参考資料

https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/how-runtime-monitoring-works-ec2.html
https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/manage-agent-ec2-standalone-account.html
https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html
https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/prereq-runtime-monitoring-cpu-os-kernel-support.html
https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/gdu-assess-coverage-ec2.html
https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/runtime-monitoring-agent-resource-clean-up.html

クラスメソッドオペレーションズ株式会社について

クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイト をぜひご覧ください。
※2026年1月 アノテーション㈱から社名変更しました