AWS GuardDuty Security Best Practices

Amazon GuardDuty is the cornerstone of threat detection in AWS. It continuously analyzes CloudTrail management and data events, VPC Flow Logs, DNS query logs, and runtime telemetry to identify malicious activity, unauthorized behavior, and compromised workloads across your entire AWS environment. Unlike reactive security tools, GuardDuty uses machine learning, anomaly detection, and integrated threat intelligence to surface threats before they become breaches.

In November 2025, GuardDuty Extended Threat Detection identified an active cryptomining campaign that used compromised IAM credentials to deploy miners across Amazon EC2 and ECS environments -- correlating multiple signals into critical-severity attack sequence findings that security teams could act on immediately. This real-world example underscores why GuardDuty is not optional -- it is foundational.

This guide covers 12 best practices for deploying, configuring, and operationalizing GuardDuty, incorporating the latest 2025-2026 features including Extended Threat Detection, Runtime Monitoring, and Malware Protection for S3 and AWS Backup.

1. Enable GuardDuty in All Regions with Delegated Admin

GuardDuty is a regional service. Threats do not respect region boundaries -- an attacker can spin up resources in any region where GuardDuty is not watching. You must enable GuardDuty in every region, including regions you do not actively use, to detect unauthorized activity such as cryptomining in unused regions.

Delegated Administrator Setup

AWS recommends designating a dedicated security tooling account (not the management account) as the delegated GuardDuty administrator. This account centralizes findings, manages member accounts, and configures protection plans across the organization.

# Step 1: Enable trusted access for GuardDuty in Organizations
aws organizations enable-aws-service-access   --service-principal guardduty.amazonaws.com

# Step 2: Designate delegated administrator (run from management account)
aws guardduty enable-organization-admin-account   --admin-account-id 111122223333

# Step 3: Enable GuardDuty detector in each region
aws guardduty create-detector --enable   --features '[
    {"Name": "S3_DATA_EVENTS", "Status": "ENABLED"},
    {"Name": "EKS_AUDIT_LOGS", "Status": "ENABLED"},
    {"Name": "EBS_MALWARE_PROTECTION", "Status": "ENABLED"},
    {"Name": "RDS_LOGIN_EVENTS", "Status": "ENABLED"},
    {"Name": "RUNTIME_MONITORING", "Status": "ENABLED",
      "AdditionalConfiguration": [
        {"Name": "ECS_FARGATE_AGENT_MANAGEMENT", "Status": "ENABLED"},
        {"Name": "EC2_AGENT_MANAGEMENT", "Status": "ENABLED"}
      ]
    },
    {"Name": "LAMBDA_NETWORK_LOGS", "Status": "ENABLED"}
  ]'

# Step 4: Verify detector status
aws guardduty list-detectors
aws guardduty get-detector --detector-id DETECTOR_ID

Best practice: Use an SCP to prevent member accounts from disabling GuardDuty. See AWS Organizations Security Card for SCP examples that deny guardduty:DeleteDetector and guardduty:DisableOrganizationAdminAccount.

2. Enable All Protection Plans

GuardDuty offers multiple protection plans that extend threat detection beyond the foundational data sources. Each plan provides specialized detection for specific AWS services. Leaving any plan disabled creates blind spots that attackers will exploit.

Available Protection Plans

• S3 Protection (S3_DATA_EVENTS): Monitors S3 data plane events for data exfiltration, unauthorized access, and suspicious API patterns.
• EKS Audit Log Monitoring (EKS_AUDIT_LOGS): Analyzes Kubernetes audit logs for container escape, privilege escalation, and suspicious pod deployments.
• Runtime Monitoring (RUNTIME_MONITORING): OS-level telemetry for ECS Fargate, EKS, and EC2 -- process execution, file access, network connections.
• EBS Malware Protection (EBS_MALWARE_PROTECTION): Agentless scanning of EBS volumes for malware when suspicious behavior is detected.
• RDS Protection (RDS_LOGIN_EVENTS): Anomalous database login detection for Aurora databases.
• Lambda Protection (LAMBDA_NETWORK_LOGS): Network activity monitoring for Lambda functions including DNS queries and outbound connections.

# Enable all features on an existing detector
aws guardduty update-detector   --detector-id DETECTOR_ID   --features '[
    {"Name": "S3_DATA_EVENTS", "Status": "ENABLED"},
    {"Name": "EKS_AUDIT_LOGS", "Status": "ENABLED"},
    {"Name": "EBS_MALWARE_PROTECTION", "Status": "ENABLED"},
    {"Name": "RDS_LOGIN_EVENTS", "Status": "ENABLED"},
    {"Name": "RUNTIME_MONITORING", "Status": "ENABLED"},
    {"Name": "LAMBDA_NETWORK_LOGS", "Status": "ENABLED"}
  ]'

# Auto-enable all features for new organization members
aws guardduty update-organization-configuration   --detector-id DETECTOR_ID   --auto-enable ALL   --features '[
    {"Name": "S3_DATA_EVENTS", "AutoEnable": "ALL"},
    {"Name": "EKS_AUDIT_LOGS", "AutoEnable": "ALL"},
    {"Name": "EBS_MALWARE_PROTECTION", "AutoEnable": "ALL"},
    {"Name": "RDS_LOGIN_EVENTS", "AutoEnable": "ALL"},
    {"Name": "RUNTIME_MONITORING", "AutoEnable": "ALL"},
    {"Name": "LAMBDA_NETWORK_LOGS", "AutoEnable": "ALL"}
  ]'

Cost tip: Use the GuardDuty usage statistics API to understand cost per feature per account, and review coverage gaps in the GuardDuty console. See GuardDuty Security Card for a quick-reference view of all finding types.

3. Leverage Extended Threat Detection for Attack Sequences

Extended Threat Detection, launched at re:Invent 2024 and expanded to EC2 and ECS in December 2025, uses AI/ML to correlate multiple security signals into critical-severity attack sequence findings. Instead of reviewing dozens of individual findings, your security team receives a single, consolidated narrative of a multi-stage attack.

How It Works

Extended Threat Detection analyzes combinations of runtime activity, malware detections, VPC Flow Logs, DNS queries, and CloudTrail events to identify patterns that represent a multistage attack. It generates two types of critical-severity findings:

• AttackSequence:EC2/CompromisedInstanceGroup: Correlates suspicious processes, persistence attempts, cryptomining, and reverse shell creation across EC2 instances.
• AttackSequence:ECS/CompromisedCluster: Identifies multi-stage attacks targeting ECS tasks, including container escape and lateral movement.
• AttackSequence:S3/CompromisedData: Detects data exfiltration sequences involving S3 buckets.

What Each Finding Includes

• An incident summary describing the full attack narrative
• A timeline of observed events in chronological order
• Mapped MITRE ATT&CK tactics and techniques
• Specific remediation guidance for each attack stage
• Affected resources and indicators of compromise (IOCs)

Key point: Extended Threat Detection is automatically enabled when you enable GuardDuty -- no additional configuration is needed. However, it requires Runtime Monitoring to be active for the deepest signal correlation. Ensure all protection plans are enabled to maximize detection fidelity.

4. Configure Runtime Monitoring for ECS and EKS

Runtime Monitoring deploys a lightweight GuardDuty security agent at the OS level to observe process execution, file access, command-line arguments, and network connections. This provides visibility that network-level and API-level monitoring cannot achieve -- for example, detecting a reverse shell spawned inside a container.

Agent Management Options

• Managed agent (recommended): GuardDuty automatically deploys and updates the security agent as a sidecar container (ECS Fargate) or DaemonSet (EKS). No manual intervention required.
• Manual agent: You deploy and manage the agent yourself. Use this if you need fine-grained control over agent versions or have custom container configurations.

# Enable Runtime Monitoring with managed agent for ECS Fargate and EC2
aws guardduty update-detector   --detector-id DETECTOR_ID   --features '[{
    "Name": "RUNTIME_MONITORING",
    "Status": "ENABLED",
    "AdditionalConfiguration": [
      {"Name": "ECS_FARGATE_AGENT_MANAGEMENT", "Status": "ENABLED"},
      {"Name": "EC2_AGENT_MANAGEMENT", "Status": "ENABLED"},
      {"Name": "EKS_ADDON_MANAGEMENT", "Status": "ENABLED"}
    ]
  }]'

# Verify runtime coverage -- check for gaps
aws guardduty list-coverage   --detector-id DETECTOR_ID   --filter-criteria '{
    "FilterCriterion": [{
      "CriterionKey": "COVERAGE_STATUS",
      "FilterCondition": {"Equals": ["UNHEALTHY"]}
    }]
  }'

EKS Considerations

For EKS, the managed agent deploys the aws-guardduty-agent EKS add-on automatically. Ensure your EKS node IAM role has the AmazonGuardDutyRuntimeMonitoringServiceRolePolicy attached. Monitor the add-on health status and check for version updates regularly.

See AWS ECS Security Card and AWS EKS Security Card for container-specific security configurations that complement Runtime Monitoring.

5. Deploy Malware Protection Across All Tiers

GuardDuty Malware Protection provides agentless malware scanning across three surfaces: EC2 EBS volumes, S3 objects, and AWS Backup recovery points. Each addresses a different attack vector and should be enabled together for comprehensive coverage.

EC2/EBS Malware Protection

When GuardDuty detects suspicious behavior on an EC2 instance (such as communication with a known command-and-control server), it automatically creates a snapshot of the attached EBS volumes and scans them for malware -- without installing an agent or impacting instance performance.

# Enable EBS Malware Protection (GuardDuty-initiated)
aws guardduty update-detector   --detector-id DETECTOR_ID   --features '[{"Name": "EBS_MALWARE_PROTECTION", "Status": "ENABLED"}]'

# Trigger an on-demand scan for a specific instance
aws guardduty start-malware-scan   --resource-arn arn:aws:ec2:us-east-1:111122223333:instance/i-0abc123def456

S3 Malware Protection

Malware Protection for S3 scans newly uploaded objects in real time. This is critical for applications that accept file uploads from users -- documents, images, archives can all carry malware payloads. You can also run on-demand scans for objects that existed before protection was enabled.

# Create a malware protection plan for an S3 bucket
aws guardduty create-malware-protection-plan   --role "arn:aws:iam::111122223333:role/GuardDutyMalwareScanRole"   --protected-resource 'S3Bucket={"BucketName":"my-upload-bucket"}'

# On-demand scan of a specific S3 object
aws guardduty start-malware-scan   --resource-arn arn:aws:s3:::my-upload-bucket/uploads/document.pdf

Malware Protection for AWS Backup (November 2025)

The newest addition to the Malware Protection family, this feature scans backup recovery points before restoration, ensuring you do not restore infected data. It supports EC2, EBS, and S3 backup vaults. Configure scan triggers in your backup plans to automatically validate recovery points.

Security Hub control: [GuardDuty.1] GuardDuty should be enabled. [GuardDuty.8] GuardDuty Malware Protection for EC2 should be enabled.

6. Maximize S3 Protection

S3 Protection monitors CloudTrail S3 data events to detect threats to your storage layer -- data exfiltration, anonymous access from Tor exit nodes, unusual API call patterns, and attempts to disable logging or make buckets public.

Key Finding Types

• Exfiltration:S3/MaliciousIPCaller: S3 data accessed from a known malicious IP address.
• Exfiltration:S3/AnomalousBehavior: Unusual data access patterns suggesting bulk data download.
• Discovery:S3/MaliciousIPCaller.Custom: S3 object listing operations from a threat intelligence IP.
• Policy:S3/BucketAnonymousAccessGranted: A bucket policy was changed to allow anonymous access.
• Stealth:S3/ServerAccessLoggingDisabled: S3 server access logging was disabled, potentially to cover tracks.
• Impact:S3/AnomalousBehavior.Delete: Unusual deletion patterns that may indicate ransomware or sabotage.

# Verify S3 Protection status
aws guardduty get-detector   --detector-id DETECTOR_ID   --query "Features[?Name=='S3_DATA_EVENTS'].Status"

# List S3-related findings
aws guardduty list-findings   --detector-id DETECTOR_ID   --finding-criteria '{
    "Criterion": {
      "service.featureName": {"Eq": ["S3_DATA_EVENTS"]},
      "severity": {"Gte": 7}
    }
  }'

Best practice: Pair GuardDuty S3 Protection with Amazon Macie for sensitive data discovery. GuardDuty detects threats; Macie identifies which buckets contain sensitive data that requires the strongest protection. See also AWS S3 Security Card for bucket security hardening.

7. Enable RDS Protection for Database Threat Detection

RDS Protection monitors login activity for Amazon Aurora databases (MySQL and PostgreSQL-compatible editions). It creates behavioral baselines of normal access patterns per database and detects anomalous login attempts, brute force attacks, and logins from unusual locations or previously unseen IAM users.

Key Finding Types

• CredentialAccess:RDS/AnomalousBehavior.SuccessfulLogin: A successful login from an unusual location, new user agent, or anomalous time.
• CredentialAccess:RDS/AnomalousBehavior.FailedLogin: An unusual pattern of failed login attempts indicating brute force.
• CredentialAccess:RDS/AnomalousBehavior.SuccessfulBruteForceLogin: A successful login following a pattern of brute force attempts -- highest severity.
• CredentialAccess:RDS/MaliciousIPCaller.SuccessfulLogin: A successful database login from a known malicious IP.
• CredentialAccess:RDS/TorIPCaller.SuccessfulLogin: A successful database login from a Tor exit node.

# Enable RDS Protection
aws guardduty update-detector   --detector-id DETECTOR_ID   --features '[{"Name": "RDS_LOGIN_EVENTS", "Status": "ENABLED"}]'

# Check RDS login findings
aws guardduty list-findings   --detector-id DETECTOR_ID   --finding-criteria '{
    "Criterion": {
      "type": {"Eq": ["CredentialAccess:RDS/AnomalousBehavior.SuccessfulBruteForceLogin"]}
    }
  }'

Important: RDS Protection currently supports Amazon Aurora only -- not RDS for MySQL, PostgreSQL, or other engines directly. For non-Aurora databases, monitor database access through VPC Flow Logs and CloudTrail API-level events. See AWS RDS Security Card for additional database hardening practices.

8. Configure Automated Response with EventBridge

Detecting threats is only half the equation. Automated response reduces mean time to containment (MTTC) from hours to seconds. GuardDuty publishes all findings to Amazon EventBridge, enabling you to build automated remediation workflows using Lambda, Step Functions, or Systems Manager.

Architecture Pattern

GuardDuty Finding --> EventBridge Rule --> Lambda/Step Functions --> Remediation Action

Example: Auto-Isolate Compromised EC2 Instance

# Create EventBridge rule for high-severity EC2 findings
aws events put-rule   --name "guardduty-ec2-high-severity"   --event-pattern '{
    "source": ["aws.guardduty"],
    "detail-type": ["GuardDuty Finding"],
    "detail": {
      "severity": [{"numeric": [">=", 7]}],
      "resource": {
        "resourceType": ["Instance"]
      }
    }
  }'

# Add Lambda target for auto-remediation
aws events put-targets   --rule "guardduty-ec2-high-severity"   --targets '[{
    "Id": "isolate-instance",
    "Arn": "arn:aws:lambda:us-east-1:111122223333:function:isolate-ec2-instance"
  }]'

Common Automated Responses

• EC2 compromise: Replace security groups with an isolation group (no inbound/outbound), snapshot the EBS volume for forensics, tag the instance.
• IAM credential compromise: Attach a deny-all inline policy to the IAM user/role, revoke active sessions, disable access keys.
• S3 data exfiltration: Enable versioning and object lock, restrict bucket policy to VPC endpoint only, notify the data owner.
• RDS brute force: Update security group to block the source IP, rotate database credentials, enable enhanced monitoring.
• Attack sequence (critical): Trigger a Step Functions workflow that orchestrates multiple remediation steps and creates an incident in your ITSM tool.

See AWS EventBridge Security Card and Step Functions Security Card for secure event-driven architecture patterns.

9. Implement Multi-Account Management with AWS Organizations

In a multi-account environment, centralized management is essential. The delegated administrator account can view and manage findings from all member accounts, configure protection plans organization-wide, and enforce consistent security coverage.

Organization Configuration

# From the delegated admin account: auto-enable for all member accounts
aws guardduty update-organization-configuration   --detector-id DETECTOR_ID   --auto-enable ALL   --features '[
    {"Name": "S3_DATA_EVENTS", "AutoEnable": "ALL"},
    {"Name": "EKS_AUDIT_LOGS", "AutoEnable": "ALL"},
    {"Name": "EBS_MALWARE_PROTECTION", "AutoEnable": "ALL"},
    {"Name": "RDS_LOGIN_EVENTS", "AutoEnable": "ALL"},
    {"Name": "RUNTIME_MONITORING", "AutoEnable": "ALL",
      "AdditionalConfiguration": [
        {"Name": "ECS_FARGATE_AGENT_MANAGEMENT", "AutoEnable": "ALL"},
        {"Name": "EC2_AGENT_MANAGEMENT", "AutoEnable": "ALL"},
        {"Name": "EKS_ADDON_MANAGEMENT", "AutoEnable": "ALL"}
      ]
    },
    {"Name": "LAMBDA_NETWORK_LOGS", "AutoEnable": "ALL"}
  ]'

# List member accounts and their GuardDuty status
aws guardduty list-members   --detector-id DETECTOR_ID   --only-associated "true"

# Check organization-wide configuration
aws guardduty describe-organization-configuration   --detector-id DETECTOR_ID

Multi-Region Deployment

GuardDuty must be enabled in every region for each member account. Use AWS CloudFormation StackSets or Terraform to automate region-by-region deployment. Create a StackSet that enables GuardDuty in all regions, and deploy it to all OUs in your organization.

Best practice: Use a dedicated security tooling account as the delegated administrator -- not the management account. Centralize GuardDuty, Security Hub, Inspector, and Macie in this same account for unified security operations. See AWS Organizations Security Card for multi-account architecture patterns.

10. Tune Findings with Suppression Rules and Trusted IP Lists

Out-of-the-box GuardDuty generates findings that may include expected behavior in your environment -- penetration testing tools, internal scanners, known partner IP addresses. Suppression rules and trusted IP lists reduce noise so your team focuses on genuine threats.

Suppression Rules

Suppression rules automatically archive findings that match specific criteria. The findings are still generated and logged, but they do not appear in the active findings list or trigger EventBridge notifications.

# Create a suppression rule for known scanner IPs
aws guardduty create-filter   --detector-id DETECTOR_ID   --name "suppress-internal-scanner"   --action ARCHIVE   --finding-criteria '{
    "Criterion": {
      "service.action.networkConnectionAction.remoteIpDetails.ipAddressV4": {
        "Eq": ["10.0.1.50", "10.0.1.51"]
      },
      "type": {
        "Eq": ["Recon:EC2/PortProbeUnprotectedPort"]
      }
    }
  }'

# List all suppression rules
aws guardduty list-filters --detector-id DETECTOR_ID

Trusted IP Lists and Threat IP Lists

# Upload a trusted IP list (no findings generated for these IPs)
aws guardduty create-ip-set   --detector-id DETECTOR_ID   --name "corporate-egress-ips"   --format TXT   --location s3://my-security-bucket/trusted-ips.txt   --activate

# Upload a custom threat intelligence IP list
aws guardduty create-threat-intel-set   --detector-id DETECTOR_ID   --name "custom-threat-intel"   --format TXT   --location s3://my-security-bucket/threat-ips.txt   --activate

Warning: Be conservative with suppression. Over-suppression creates blind spots. Review suppressed findings monthly and remove rules that are no longer relevant. Never suppress critical-severity attack sequence findings.

11. Integrate with SIEM and Security Lake

GuardDuty findings must flow into your broader security operations ecosystem. Whether you use a cloud-native SIEM, a third-party platform like Splunk or Datadog, or Amazon Security Lake, integrating findings ensures they are correlated with signals from other sources and acted upon through established incident response workflows.

Amazon Security Lake

Security Lake centralizes security data from GuardDuty, CloudTrail, VPC Flow Logs, Route 53 resolver logs, and third-party sources into a single data lake using the Open Cybersecurity Schema Framework (OCSF). This enables cross-source correlation and long-term retention for compliance and forensics.

# Enable Security Lake (run from the delegated admin account)
aws securitylake create-data-lake   --configurations '[{
    "region": "us-east-1",
    "lifecycleConfiguration": {
      "expiration": {"days": 365},
      "transitions": [{"days": 30, "storageClass": "ONEZONE_IA"}]
    }
  }]'

# Add GuardDuty as a log source
aws securitylake create-aws-log-source   --sources '[{
    "regions": ["us-east-1", "eu-west-1"],
    "sourceName": "AMAZON_GUARDDUTY",
    "sourceVersion": "2.0"
  }]'

Third-Party SIEM Integration

• Splunk: Use the AWS Add-on for Splunk to ingest GuardDuty findings via EventBridge or S3. Map findings to the Splunk CIM for normalized alerting.
• Datadog: Enable the Datadog AWS integration and activate the GuardDuty tile. Findings appear as security signals in the Datadog SIEM.
• Microsoft Sentinel: Use the Amazon Web Services S3 connector to ingest GuardDuty findings exported to S3.
• Custom SIEM: Export findings to S3 via EventBridge, or use the Security Lake subscriber API for OCSF-formatted data.

# Export all findings to S3 via EventBridge for SIEM ingestion
aws events put-rule   --name "guardduty-to-s3"   --event-pattern '{
    "source": ["aws.guardduty"],
    "detail-type": ["GuardDuty Finding"]
  }'

aws events put-targets   --rule "guardduty-to-s3"   --targets '[{
    "Id": "s3-export",
    "Arn": "arn:aws:firehose:us-east-1:111122223333:deliverystream/guardduty-findings",
    "RoleArn": "arn:aws:iam::111122223333:role/EventBridgeFirehoseRole"
  }]'

See AWS CloudTrail Security Card for complementary log aggregation patterns that pair well with GuardDuty findings in your SIEM.

12. Monitor Coverage Gaps, Usage Statistics, and Costs

GuardDuty is only effective when it has full coverage. Regularly audit coverage gaps (accounts or resources without active monitoring), review usage statistics to understand cost drivers, and optimize spend by identifying unused features or over-scanned resources.

Coverage Monitoring

# List resources with unhealthy runtime monitoring coverage
aws guardduty list-coverage   --detector-id DETECTOR_ID   --filter-criteria '{
    "FilterCriterion": [{
      "CriterionKey": "COVERAGE_STATUS",
      "FilterCondition": {"Equals": ["UNHEALTHY"]}
    }]
  }'

# Get coverage statistics by resource type
aws guardduty get-coverage-statistics   --detector-id DETECTOR_ID   --statistics-type COUNT_BY_COVERAGE_STATUS   --filter-criteria '{
    "FilterCriterion": [{
      "CriterionKey": "RESOURCE_TYPE",
      "FilterCondition": {"Equals": ["ECS_CLUSTER"]}
    }]
  }'

Usage and Cost Analysis

# Get usage statistics by data source for cost analysis
aws guardduty get-usage-statistics   --detector-id DETECTOR_ID   --usage-statistic-type SUM_BY_DATA_SOURCE   --usage-criteria '{
    "DataSources": ["CLOUD_TRAIL", "DNS_LOGS", "FLOW_LOGS",
      "S3_LOGS", "EKS_AUDIT_LOGS", "EC2_MALWARE_SCAN"]
  }'

# Get per-account usage in multi-account setup
aws guardduty get-usage-statistics   --detector-id DETECTOR_ID   --usage-statistic-type SUM_BY_ACCOUNT   --usage-criteria '{
    "AccountIds": ["111122223333", "444455556666"]
  }'

Cost Optimization Strategies

• Review high-volume data sources: VPC Flow Logs and S3 data events are typically the largest cost drivers. If specific VPCs generate excessive flow log volume, investigate whether network segmentation can reduce noise.
• Malware scan scope: Configure scan inclusions/exclusions for EBS Malware Protection to skip known-clean volumes (e.g., immutable AMI-based instances that rebuild from trusted images).
• 30-day free trial: GuardDuty offers a 30-day free trial for each protection plan independently. Enable all plans during the trial to evaluate cost before committing.
• Volume discounts: GuardDuty pricing uses tiered volume discounts -- costs per GB decrease as your usage increases.

Security Hub controls: [GuardDuty.1] GuardDuty should be enabled. [GuardDuty.5] EKS Audit Log Monitoring should be enabled. [GuardDuty.6] Lambda Protection should be enabled. [GuardDuty.7] EKS Runtime Monitoring should be enabled. [GuardDuty.8] Malware Protection for EC2 should be enabled. [GuardDuty.9] RDS Protection should be enabled. [GuardDuty.10] S3 Protection should be enabled. [GuardDuty.11] Runtime Monitoring should be enabled. [GuardDuty.12] ECS Runtime Monitoring should be enabled. [GuardDuty.13] EC2 Runtime Monitoring should be enabled.

---

Common Misconfigurations

Misconfiguration	Risk	Detection
GuardDuty not enabled in all regions	Attackers deploy resources in unmonitored regions	Check list-detectors in every region
Protection plans partially enabled	Blind spots for S3, RDS, Lambda, or container threats	get-detector Features array
Runtime Monitoring without managed agent	No OS-level visibility into container workloads	list-coverage with UNHEALTHY filter
No EventBridge rules for findings	Threats detected but never acted upon	Audit EventBridge rules for aws.guardduty source
Over-suppression of findings	Genuine threats hidden by overly broad suppression rules	Review suppression filters monthly
No multi-account delegation	Fragmented visibility across accounts	list-organization-admin-accounts

---

Quick Reference Checklist

#	Practice	Priority
1	Enable GuardDuty in all regions with delegated admin	Critical
2	Enable all protection plans	Critical
3	Leverage Extended Threat Detection	High
4	Configure Runtime Monitoring for ECS/EKS	High
5	Deploy Malware Protection across all tiers	High
6	Maximize S3 Protection	High
7	Enable RDS Protection	Medium
8	Configure automated response with EventBridge	Critical
9	Implement multi-account management	Critical
10	Tune findings with suppression rules	Medium
11	Integrate with SIEM and Security Lake	High
12	Monitor coverage gaps and optimize costs	Medium

---

Related Resources

• AWS GuardDuty Security Card -- Quick-reference card with finding types and remediation actions
• AWS Security Hub Security Card -- Centralized security posture and finding aggregation
• AWS CloudTrail Security Card -- API audit logging that feeds GuardDuty
• AWS IAM Security Card -- Identity security fundamentals
• AWS ECS Security Card -- Container security for ECS workloads
• AWS EKS Security Card -- Kubernetes security for EKS clusters
• AWS S3 Security Card -- Storage security and data protection
• AWS EventBridge Security Card -- Event-driven security automation
• AWS Organizations Security Card -- Multi-account governance and SCPs