Measure GuardDuty runtime coverage from the resource outward

Define the population before the percentage

A coverage panel answers a question about the resources represented in that panel. A security program usually has a wider question: which resources were intended to receive runtime monitoring, and which are actually receiving it? The two populations can differ because of region, account, compatibility, exclusions or an incomplete inventory.

GuardDuty Runtime Monitoring supports specified EC2, Amazon ECS on Fargate and Amazon EKS configurations. AWS distinguishes these supported environments from unsupported combinations, including EKS on Fargate. The feature's scope should be read from current documentation rather than inferred from the broad term “container monitoring.” ^[1]

Start with an independent inventory snapshot and name the reporting unit. For an EC2 review, that may be an instance in an account and region at a stated time. For an ECS review, retain the cluster and task context needed to understand coverage. Record which resources the organization intends to protect before reading a service-reported count.

Check supported runtime configurations

AWS publishes EC2 Runtime Monitoring prerequisites covering supported operating-system, kernel and architecture combinations and the relevant deployment method. Managed agent deployment has its own requirements. Compatibility should be checked against the current matrix for the actual resource, not against a remembered list of operating-system family names. ^[5]

Preserve enough inventory detail to explain the compatibility decision. Record the platform version, architecture, account, region and agent deployment approach used in the review. Where a field is missing, mark the resource unresolved instead of assuming that a similar instance elsewhere proves compatibility.

Unsupported resources need an explicit control decision. Name the workload owner, the reason runtime monitoring is unavailable and the alternative evidence or control being used. Avoid removing these resources from the main inventory merely to make a coverage percentage look better. If an eligible-only percentage is useful, label its denominator and present the unsupported population beside it.

Verify agent and delivery health

GuardDuty's coverage guidance distinguishes healthy and unhealthy runtime states and describes prerequisites such as the security agent and the required connectivity path. An unhealthy resource cannot be treated as successfully monitored for runtime findings. This is a statement about Runtime Monitoring, not proof that every other GuardDuty capability is disabled. ^[2]

For each resource, preserve the reported health state and any reason associated with it. Compare that result with the intended deployment state. An agent package being present is useful configuration evidence, but it should not replace a current service health result. Conversely, a historical healthy result may not describe a resource after a network or workload change.

Route unhealthy cases to an owner with enough context to act: resource identity, account, region, reason, first observation and the change that may have preceded it. Keep remediation status separate from the original health evidence. Closing a ticket should require a new observation of the intended state rather than only confirmation that a configuration command ran.

Source. Primary documentation ^{[1] [2] [3] [4] [5] [6]}. Accessed August 28, 2026.

Method. Original review-state matrix synthesized from GuardDuty documentation. Rows describe evidence and disposition for a future inventory review; they do not report an AWS account's measured coverage.

Accessible table and figure data

Figure 1 accessible table

Review state	Required evidence	Disposition
Healthy	Supported configuration and healthy runtime status	Monitor for loss of health
Unhealthy	Recorded service reason and affected resource	Assign remediation owner
Excluded	Approved exclusion and expiry or review date	Keep visible outside protected population
Unsupported	Documented compatibility gap	Use a separate control decision
Unresolved	Inventory or status mismatch	Do not count as protected

Figure 1 accessible table

Review state	Required evidence	Disposition
Healthy	Supported configuration and healthy runtime status	Monitor for loss of health
Unhealthy	Recorded service reason and affected resource	Assign remediation owner
Excluded	Approved exclusion and expiry or review date	Keep visible outside protected population
Unsupported	Documented compatibility gap	Use a separate control decision
Unresolved	Inventory or status mismatch	Do not count as protected

Download imageDownload table CSV

Account for workload lifecycle

AWS documents ECS Runtime Monitoring coverage at the cluster level and explains how Fargate task lifecycle affects the agent. Existing tasks do not automatically acquire a changed agent configuration in place; task replacement or restart can be part of the documented deployment path. Any such action requires workload-owner approval and an availability plan. ^[4]

Record the relationship between a cluster's reported state and the tasks that were running during the review. A configuration change for future tasks may leave older tasks operating under a different state until their lifecycle advances. Do not describe the desired configuration as deployed to every task merely because the cluster setting changed.

For EC2, AWS's coverage guidance provides instance-oriented information. Keep that unit intact when comparing it with the independent instance inventory. ^[3] A report that adds an EC2 instance count to an ECS cluster count produces a number without a consistent resource meaning, even if both inputs came from valid service responses.

Reconcile service statistics with inventory

The GetCoverageStatistics API returns coverage statistics for a detector and supports filters and grouping. Those parameters define the returned population. Record the account, region, detector, filters and collection time so another reviewer can understand what was counted and what the response could not include. ^[6]

For resource-level reconciliation, use ListCoverage, which returns resource identifiers and coverage details, and follow its pagination. Aggregated GetCoverageStatistics counts cannot supply the individual identifiers needed for this join. ^[7][6] Compare those detailed records with the independent inventory using the selected resource unit. Investigate resources present in only one side. Timing, lifecycle changes, exclusions or an inventory gap may explain a mismatch, but the mismatch itself does not select the explanation.

Use explicit states such as healthy, unhealthy, excluded, unsupported and unresolved. The matrix is a proposed review vocabulary, not a measured account result. If a percentage is later calculated, publish the numerator, denominator, snapshot time and exclusions with it. Keep the raw categories so a reader can see whether an improvement came from remediation or from changing the population being counted.

When the inventory and service snapshots are not simultaneous, retain both timestamps. Investigate resources created or removed between them before calling the difference a monitoring failure. The report should distinguish a real coverage gap from a comparison that used two different moments.

Make health loss operationally visible

Coverage is a changing condition. Establish a review or notification process for loss of health and for newly discovered resources that have no matching coverage record. Assign an owner to unresolved cases and define when exclusions must be reconsidered. A one-time inventory reconciliation cannot demonstrate ongoing coverage after the estate changes.

Define how old a health observation may be before the report marks it stale. Keep that rule visible in the report and retain the last observation time for each resource. An unchanged label without a recent observation should not silently count as fresh evidence.

Separate monitoring health from threat-detection outcomes. No runtime finding may mean no relevant suspicious behavior was detected, but it is not a substitute for evidence that the monitoring path was healthy. Likewise, a healthy path does not prove that every possible attack would generate a finding. These are different claims with different supporting evidence.

The operational handoff should make a specific resource easy to trace from inventory to compatibility decision, current health and remediation owner. When a workload changes platform or deployment method, revisit that chain. The resulting report can remain useful without a headline percentage because it tells the team exactly which resources require a decision and which evidence would close each gap.