How do you enable Amazon GuardDuty protection plans such as S3, EKS and runtime monitoring?

What it means to turn on GuardDuty protection plans in practice

Enabling GuardDuty protection plans is a scope decision as much as a setup task. S3 protection, EKS protection and runtime monitoring each cover a different part of the attack surface, so the key question is not “is GuardDuty on?” but “which telemetry sources are active in this account and region, and are they actually covering the resources you care about?”

For AWS security teams, the practical model is per account and per region. That matters because coverage gaps often appear in overlooked regions, newly created accounts, or workloads that were never brought under the same security baseline. If you manage AWS at scale, AWS Security Guide is the broader control context for understanding how GuardDuty fits alongside logging, identity, and account governance.

Each protection plan is aimed at a different detection problem. S3 protection helps surface suspicious data access and bucket activity, EKS protection improves visibility into Kubernetes activity and workload behaviour, and runtime monitoring is about what is happening inside the workload at execution time. If you enable only one of these, you are choosing depth in one attack path while leaving other paths less observable.

Which coverage gaps matter most when you enable S3, EKS and runtime monitoring?

The biggest implementation mistake is assuming the service is “enabled” when only the detector exists. In practice, you need to verify that the plan is switched on and that the underlying resources are covered in the places where you expect detections. Missing a plan usually means missing a class of events, not just losing a few extra alerts.

For S3-focused risk, the concern is unauthorized reads, unusual access patterns, and the kind of abuse that follows exposed credentials or excessive access. The threat is not theoretical, because S3 activity is often the first place attackers look once they obtain AWS credentials. A useful operational comparison is the pattern described in Codefinger S3 ransomware 2025, where compromised AWS keys were used to target S3 data directly.

For EKS and runtime monitoring, the important gap is blind spots between cloud control-plane activity and what workloads actually do after they start. A cluster can look healthy from the outside while a pod, container or node is being abused internally. That is why runtime coverage should be treated as a separate decision from cluster visibility, not as a default consequence of enabling the EKS plan.

When you are validating coverage, check for the exact accounts, regions, clusters and workloads that should be in scope. If you cannot point to a specific resource set and show it is covered, the protection plan is not yet doing useful security work.

How to operationalize GuardDuty protection plans without leaving blind spots

Start with the account and region inventory, then confirm which protection plans are enabled where. That sounds basic, but it is the only reliable way to avoid partial rollouts that create a false sense of protection. In multi-account AWS estates, the right implementation pattern is to treat coverage as a governed baseline, not an ad hoc console setting.

Runtime monitoring deserves special attention because it is usually where detection becomes most actionable. It is also the plan most likely to be underused if teams only think in terms of storage or cluster protection. CNAPP Guide is useful here because it frames runtime protection, cloud attack paths and workload visibility as connected controls rather than isolated features.

If you are standardizing response, align the GuardDuty rollout with the team that owns account provisioning and workload onboarding. New accounts, new clusters and newly deployed services should inherit the same coverage pattern automatically, or they will become the usual place where attackers find less-monitored surfaces.

Practitioner Guidance: Treat protection-plan enablement as a coverage-management exercise, not a feature toggle. The decision point is whether each plan covers the specific data paths and workload paths you are willing to defend, and whether you can prove that coverage persists as accounts, regions and clusters change.

What to verify: Confirm that S3, EKS and runtime monitoring are enabled in every in-scope account and region, then validate that the resources you expect to be protected are actually being evaluated. A partial rollout should be treated as incomplete, not acceptable.

Common mistake: Teams often enable GuardDuty and stop there, even though the meaningful control is the combination of enabled plans plus verified resource coverage. That leaves detection gaps exactly where attackers tend to operate first.

Practitioner takeaway: The right question is not whether GuardDuty is on, but whether the specific protection plans you rely on are active everywhere they need to be and are still covering the right resources after environment changes.

Related resources from NHI Mgmt Group

• What is the difference between code scanning and runtime identity monitoring?
• How do you enable Amazon GuardDuty across all regions in an AWS Organization?
• How do you know if browser runtime protection is actually working?
• How should security teams harden pods in Amazon EKS hybrid environments to reduce runtime risk?