Amazon GuardDuty helps security teams recognize suspicious activity inside AWS accounts before a single unusual API call, network connection or workload event becomes a larger incident. Its findings can identify indicators of compromised credentials, malicious network communication, malware or suspicious changes to cloud resources. The service reduces the effort needed to correlate certain threat signals, but it does not replace an incident-response plan, a protected audit trail or the obligation to confirm that an alert represents real risk to the business.
Consider a company running a customer portal in AWS. It uses several accounts for production, testing and security operations; orders are stored in a database, receipts are uploaded to S3, and the application runs partly on EC2 and containers. One morning GuardDuty reports unexpected API activity by an assumed role, followed by connections to a suspicious destination. The security team must determine whether the role was compromised, which resources were affected, whether information left the account and how to contain the activity without disrupting legitimate customers. That scenario shows why threat detection, evidence collection, coverage and response must be designed together.
Understand foundational monitoring before adding protection plans
GuardDuty uses threat intelligence, anomaly analysis and machine-learning techniques to evaluate AWS activity. After GuardDuty is enabled in an account and Region, its foundational detection analyzes a service-managed stream of CloudTrail management events, VPC flow logs associated with EC2 instances and DNS query data. You do not have to create your own CloudTrail trail or VPC Flow Logs destination for GuardDuty to use those foundational feeds. This independence is useful, but it does not mean GuardDuty becomes a searchable archive of the underlying raw logs.
Security investigations still need durable evidence. GuardDuty extracts fields for analysis and does not act as the long-term storage system for every underlying event. Maintain the organization’s required CloudTrail audit history, service logs and retention controls separately. If an analyst must prove which principal changed a policy or whether a specific S3 object was read, the original recorded activity and available event coverage matter as much as the finding summary. Not every AWS action is captured by the same source or enabled logging option.
GuardDuty protection plans extend beyond that foundational coverage. Depending on the supported Region and configuration, additional options analyze S3 object activity, EKS audit logs, RDS login activity, Lambda network activity and runtime behavior on supported EC2, EKS and ECS Fargate workloads. Other plans support malware scans of EC2 volumes, S3 objects and eligible backup resources. GuardDuty also has AI Protection for supported workloads using Amazon Bedrock, Bedrock AgentCore and SageMaker AI. These are separate detection capabilities with distinct permissions, prerequisites and costs; enabling the GuardDuty detector should not be interpreted as proof that every resource is fully monitored by every plan.
The initial configuration matters. AWS’s current guide describes automatic enabling of most protection plans on a newly enabled GuardDuty account, excluding Runtime Monitoring, but existing customers do not necessarily receive every newly released protection plan automatically. Inventory what is actually active in each account and Region, then compare that state with the threats the application faces. A company with critical S3 receipts but no S3 Protection should identify the gap explicitly instead of assuming the word enabled in the GuardDuty console covers every object-access threat.
Deploy consistent coverage across AWS Organizations and Regions
A multi-account organization should choose a delegated GuardDuty administrator rather than rely on a different security operator in each application account. AWS Organizations supports central account management and options to enable GuardDuty for existing accounts, only newly joined accounts or neither group automatically. The choice should follow the organization’s onboarding and change-control model. If the security team wants every future production account enrolled, that intention must be reflected in actual auto-enable settings and tested after a new account joins.
GuardDuty management is Region-specific. Configuring a delegated administrator or a protection plan in one Region does not prove that all workloads in every opted-in Region receive equivalent coverage. Use the same delegated administrator across Regions, review where the company actually runs workloads and include newly introduced Regions in the operating checklist. A central dashboard can make a program look consolidated even when a recently deployed Region has no detector or lacks a necessary protection plan.
Define ownership of the rollout: security engineering manages policies and aggregation, cloud platform teams ensure account and Region enrollment, and workload owners supply the context needed to interpret findings. Decide who may disable a detector or protection plan and what evidence or approval is required. When a protection agent is needed for runtime monitoring, its installation, version and coverage status belong in deployment operations rather than being assumed to appear automatically on every container or EC2 instance.
A useful acceptance test creates or selects an appropriate GuardDuty sample finding in a nonproduction account, confirms that the delegated administrator can view it and checks that the event reaches the chosen notification and triage workflow. A generated sample proves that some finding-routing components work; it does not validate detection of every actual threat. For full coverage, also review resource-level status and compare observed costs against the monitored account and Region inventory.
Read findings as hypotheses supported by evidence
GuardDuty findings identify potentially compromised resources and provide structured details such as a finding type, affected resource, severity, relevant activity, observed time and available network or identity context. A credential-compromise signal might involve unusual API requests or a known malicious destination. A reconnaissance signal might identify unexpected scanning behavior. The finding category tells analysts what to investigate, not that a specific person has conclusively performed an attack.
Prioritize by more than severity. A moderately scored finding involving a high-value production role and sensitive datasets may demand prompt attention, while a higher-scored finding in a deliberately isolated security test can have a documented explanation. The team should assess resource exposure, effective permissions, expected workload behavior and temporal relationships between events. A suspicious outbound connection alone is not proof of data exfiltration; evidence of object reads, transferred bytes and related identity events would strengthen that conclusion.
GuardDuty’s Extended Threat Detection can correlate activity over time and across resource types into attack-sequence findings. This helps when an individual event looks ordinary but its position in a longer chain is suspicious. For the portal scenario, an unusual credential use, a changed security policy and later abnormal data access could together justify a stronger investigation. Analysts still need to confirm which account, resource and time window the sequence covers, and which extra protection plans were enabled to supply sufficient evidence.
Keep a repeatable triage note with the suspected threat, affected AWS identity or resource, supporting source events, business owner, containment decision and reasons for ruling out alternatives. If the finding is related to an assumed role, investigate its session context and associated policies rather than simply disabling every application user. A focused IAM permission review helps determine what the role could actually do and which explicit denies or organization-level controls constrained it.
Use Security Hub, EventBridge and investigation tools for response
GuardDuty findings can feed broader security operations through supported AWS integrations. AWS Security Hub can aggregate and prioritize findings across security services and accounts, while Amazon EventBridge can match selected finding events and route them to notifications, incident tooling or a controlled automation. Those services have separate roles: GuardDuty detects and describes possible threats; Security Hub helps with consolidated posture and finding management; EventBridge delivers selected events to workflow consumers.
Use an escalation path proportionate to risk. A low-confidence finding can generate a ticket with links to evidence, while a confirmed compromised role may justify a carefully scoped containment action. AWS Lambda can execute response logic from a permitted EventBridge target, but its execution role must be tightly limited. A workflow that unconditionally terminates production instances or deletes compromised resources can destroy forensic evidence and cause an outage before an analyst verifies the impact. The relevant Lambda automation model is useful when a response must be reproducible and reversible.
Amazon Detective and investigation views can help analysts correlate entity activity, relationships and time-based signals where available. They do not eliminate the need for raw or appropriately retained source records, and their own availability, Region support and data-handling settings must be confirmed. A useful investigation asks which role called an API, which workload was running, what destination was contacted and whether the same pattern appeared in other accounts. It is better to collect a small, coherent evidence trail than to produce a long list of unrelated console screenshots.
Close the response loop. When containment is authorized, record what was changed, whether the expected malicious activity stopped and whether legitimate service access was disrupted. Follow with credential remediation, resource recovery, detection-rule tuning and a documented lesson about the incident’s root cause. A finding marked archived is not proof that the underlying threat was contained; status handling and security action are separate operations.
Protect S3, databases and compute with the right specialized plan
GuardDuty S3 Protection analyzes applicable CloudTrail S3 data events to identify suspicious authenticated object-level access, including possible exfiltration or destructive activity. This does not mean every unauthenticated public object read is analyzed as a GuardDuty S3 Protection event, or that simply storing files in S3 turns on complete malware scanning. The S3 Protection feature and Malware Protection for S3 serve different detection problems. S3 Protection looks for suspicious access patterns; Malware Protection for S3 inspects newly uploaded objects when configured for the protected buckets.
For receipt uploads, a team might place objects into a quarantine state until a malware scan has completed, then make approved objects available to downstream processing. A scan result is a useful gate but not proof that the content is safe to execute or trust. Application upload permissions, format validation and ownership checks remain necessary. Learn how the S3 permission boundary prevents a legitimate customer from reading another customer’s object, independently of whether GuardDuty sees a suspicious access pattern.
Malware Protection for EC2 scans suitable EBS volumes under its configured workflow; it is not the same capability as Runtime Monitoring. Runtime Monitoring uses a security agent to observe process, file and network behavior on supported EC2 instances, EKS workloads and ECS tasks on Fargate. The actual coverage depends on agent deployment, permissions, resource type and configuration. EKS Protection’s audit-log monitoring is separate from agent-level runtime events. These distinctions matter when an incident depends on what a container process actually executed rather than on which API calls were made to the Kubernetes control plane.
RDS Protection monitors supported database login activity for suspicious behavior, while Lambda Protection analyzes supported network activity related to Lambda functions. AI Protection has its own supported data and threat scenarios involving AI services. Check eligibility, resource coverage and the enabled protection-plan settings for each feature. Do not promise that a single detector captures every database query, container command or AI prompt in an account: monitoring scope is intentionally specific and evolves as AWS adds supported integrations.
Reduce noise without hiding meaningful compromises
Security teams quickly lose attention when every recurring authorized test is treated as an unexplained incident. GuardDuty supports mechanisms for trusted IP lists, threat lists and finding suppression rules, depending on the intended behavior. These should be applied only after investigating the underlying activity and deciding that the exception is genuinely understood. A trusted source range may host both benign testing and compromised infrastructure later; adding it broadly to an exception mechanism can hide a threat instead of improving detection.
Keep exceptions narrow and attributable. Record which account, workload, finding type, source condition, owner and review date justify the suppression. Revisit the exception after an application deployment or a network topology change. A finding should not be suppressed merely because the organization sees it frequently. Recurrence might be a sign of a broken automation that is legitimately too permissive or a real misconfiguration that has not been fixed.
Use sample findings to test alert routing without producing hostile traffic. For a realistic validation, review one simulated credential-compromise finding and trace the intended ticket, assigned owner, escalation time and response decision. Make sure duplicate events do not create unbounded numbers of incidents. A notification path that works in a demo may still fail in production if the target queue, Lambda role or incident platform is unavailable, so design bounded retries and a visible failure destination.
Analyze trends in findings alongside workload and audit evidence. A sustained change in alert volume may reflect new legitimate use, an added Region, enabled protection plans or malicious behavior. Amazon CloudWatch metrics and application logs can provide operational context, but GuardDuty findings should not be replaced by a generic infrastructure-health dashboard. A secure response requires both visibility into suspicious activity and understanding of normal production behavior.
Manage coverage, cost and the lifecycle of security findings
GuardDuty uses different data sources and features with usage-based cost implications. AWS offers initial trial periods for eligible GuardDuty capabilities, but new protection plans, data-volume growth and runtime monitoring can change the bill. Review estimated charges by account, Region and plan, and decide which monitoring is proportionate to the business risk. Disabling a useful protection to reduce a surprise bill may create an unacknowledged security gap; the better response is to understand the sources of usage and adjust the design deliberately.
Coverage monitoring should identify which supported resources are being watched and why others are not. For example, EKS Runtime Monitoring may require a deployed agent and appropriate cluster configuration; S3 malware scanning requires configured protected buckets. A green organization-level GuardDuty status alone does not prove that every production workload has the right protection. Use inventory reconciliation to compare cloud resources, assigned owners and the features actually active for them.
Plan retention and escalation according to incident needs. GuardDuty finding records and notifications can support detection and triage, but investigations may require access to earlier CloudTrail, workload, authentication and object activity. For organizations with several accounts, a centralized CloudTrail evidence store can help preserve relevant events under appropriate permissions and retention. GuardDuty analysis should complement, not replace, this protected record of activity.
Return to the customer’s suspicious assumed-role incident and walk the complete process: confirm that the necessary account and Region protection was enabled, read the finding without treating it as a verdict, locate the related API and network evidence, assess the role’s effective permissions, contain only verified risk, and document how to prevent recurrence. That workflow is what makes GuardDuty useful. Its value comes from combining focused detections with accountable investigation, measured coverage and safe recovery—not from the number of alerts a console can display.