Amazon GuardDuty FAQs

You can set up and deploy GuardDuty in a few steps in the AWS Management Console. Once enabled, GuardDuty immediately starts analyzing continuous streams of account and network activity in near real time and at scale. There are no additional security software, sensors, or network appliances to deploy or manage. Threat intelligence is pre-integrated into the service and is continuously updated and maintained.

Yes, GuardDuty has a multiple account management feature, allowing you to associate and manage multiple AWS accounts from a single administrator account. When used, all security findings are aggregated to the administrator account for review and remediation. EventBridge events are also aggregated to the GuardDuty administrator account when using this configuration. Additionally, GuardDuty is integrated with AWS Organizations, allowing you to delegate an administrator account for GuardDuty for your organization. This delegated administrator (DA) account is a centralized account that consolidates all findings and can configure all member accounts.

The foundational data sources that GuardDuty analyzes include: AWS CloudTrail management event logs, CloudTrail management events, and Amazon EC2 VPC Flow Logs and DNS query logs. GuardDuty protection plans monitor other resource types, including CloudTrail S3 data events (S3 Protection), Amazon EKS audit logs and runtime activity for Amazon EKS (EKS Protection), Amazon ECS runtime activity (ECS Runtime Monitoring), Amazon EC2 runtime activity (EC2 Runtime Monitoring), Amazon EBS volume data (Malware Protection), Amazon Aurora login events (RDS Protection), and network activity logs (Lambda Protection). The service is optimized to consume large data volumes for near real-time processing of security detections. GuardDuty gives you access to built-in detection techniques developed and optimized for the cloud, which are maintained and continuously improved upon by GuardDuty engineering.

Once enabled, GuardDuty starts analyzing for malicious or unauthorized activity. The timeframe to begin receiving findings depends on the activity level in your account. GuardDuty does not look at historical data, only activity that starts after it is enabled. If GuardDuty identifies any potential threats, you will receive a finding in the GuardDuty console.

No, GuardDuty pulls independent data streams directly from CloudTrail, VPC Flow Logs, DNS query logs, and Amazon EKS. You don’t have to manage Amazon S3 bucket policies or modify the way you collect and store logs. GuardDuty permissions are managed as service-linked roles. You can disable GuardDuty at any time, which will remove all GuardDuty permissions. This makes it easier for you to enable the service, as it avoids complex configuration. The service-linked roles also remove the chance that an AWS Identity and Access Management (IAM) permission misconfiguration or Amazon S3 bucket policy change will affect service operation. Lastly, the service-linked roles make GuardDuty extremely efficient at consuming high volumes of data in near real time with minimal to no impact on the performance and availability of your account or workloads.

When you enable GuardDuty for the first time, it operates completely independent of your AWS resources. If you configure GuardDuty Runtime Monitoring to automatically deploy the GuardDuty security agent, this could result in additional resource utilization, and will also create VPC endpoints in VPCs used to run the monitored workloads.

No, GuardDuty does not manage or retain your logs. All data that GuardDuty consumes is analyzed in near real time and discarded thereafter. This allows GuardDuty to be highly efficient and cost effective, and to reduce the risk of data remanence. For log delivery and retention, you should use AWS logging and monitoring services directly, which provide full-featured delivery and retention options.

You can prevent GuardDuty from analyzing your data sources at any time in the general settings by choosing to suspend the service. This will immediately stop the service from analyzing data, but it will not delete your existing findings or configurations. You can also choose to disable the service in the general settings. This will delete all remaining data, including your existing findings and configurations, before relinquishing the service permissions and resetting the service. You can also selectively disable capabilities like GuardDuty S3 Protection or GuardDuty EKS Protection through the Management Console or via the AWS CLI.

GuardDuty gives you access to built-in detection techniques developed and optimized for the cloud. The detection algorithms are maintained and continually improved upon by GuardDuty Engineers. The primary detection categories include the following:

• Reconnaissance: Activity suggesting reconnaissance by an attacker, such as unusual API activity, intra-VPC port scanning, unusual patterns of failed login requests, or unblocked port probing from a known bad IP.
• Instance compromise: Activity indicating an instance compromise, such as cryptocurrency mining, malware using domain generation algorithms (DGAs), outbound denial of service activity, an unusually high volume of network traffic, unusual network protocols, outbound instance communication with a known malicious IP, temporary Amazon EC2 credentials used by an external IP address, and data exfiltration using DNS.
• Account compromise: Common patterns indicative of account compromise, including API calls from an unusual geolocation or anonymizing proxy, attempts to deactivate CloudTrail logging, unusual instance or infrastructure launches, infrastructure deployments in an unusual region, the exfiltration of credentials, suspicious database login activity, and API calls from known malicious IP addresses.
• Bucket compromise: Activity indicating a bucket compromise, such as suspicious data access patterns indicating credential misuse, unusual Amazon S3 API activity from a remote host, unauthorized Amazon S3 access from known malicious IP addresses, and API calls to retrieve data in Amazon S3 buckets from a user that had no prior history of accessing the bucket or invoked from an unusual location. GuardDuty continuously monitors and analyzes CloudTrail S3 data events (like GetObject, ListObjects, and DeleteObject) to detect suspicious activity across all of your Amazon S3 buckets.
• Malware: GuardDuty can detect the presence of malware—such as trojans, worms, crypto miners, rootkits, or bots—that may be used to compromise your Amazon EC2 instance or container workloads, or that is uploaded to your Amazon S3 buckets.
• Container compromise: Activity identifying possible malicious or suspicious behavior in container workloads is detected by continuously monitoring and profiling Amazon EKS clusters by analyzing its Amazon EKS audit logs and container runtime activity in Amazon EKS or Amazon ECS. 

Here is a full list of GuardDuty finding types.

GuardDuty threat intelligence is made up of IP addresses and domains known to be used by attackers. GuardDuty threat intelligence is provided by AWS and third-party providers, such as Proofpoint and CrowdStrike. These threat intelligence feeds are pre-integrated and continuously updated in GuardDuty at no additional cost.

Yes, GuardDuty allows you to upload your own threat intelligence or trusted IP address list. When this feature is used, these lists are only applied to your account and not shared with other customers.

When a potential threat is detected, GuardDuty delivers a detailed security finding to the GuardDuty console and EventBridge. This makes alerts more actionable and more easily integrated into existing event management or workflow systems. The findings include the category, resource affected, and metadata associated with the resource, such as a severity level.

GuardDuty findings come in a common JSON format, which is also used by Macie and Amazon Inspector. This makes it easier for customers and partners to consume security findings from all three services and incorporate them into broader event management, workflow, or security solutions.

Security findings are retained and made available through the GuardDuty console and APIs for 90 days. After 90 days, the findings are discarded. To retain findings for longer than 90 days, you can enable EventBridge to automatically push findings to an Amazon S3 bucket in your account or another data store for long-term retention.

Yes, you can choose to aggregate security findings produced by GuardDuty across regions using EventBridge or by pushing findings to your data store (like Amazon S3) and then aggregating findings as you see fit. You can also send GuardDuty findings to Security Hub and use its cross-Region aggregation capability.

With GuardDuty, EventBridge, and AWS Lambda, you have the flexibility to set up automated remediation actions based on a security finding. For example, you can create a Lambda function to modify your AWS security group rules based on security findings. If you receive a GuardDuty finding indicating one of your Amazon EC2 instances is being probed by a known malicious IP, you can address it through an EventBridge rule, initiating a Lambda function to automatically modify your security group rules and restrict access on that port.

GuardDuty has a team focused on detection engineering, management, and iteration. This produces a steady cadence of new detections in the service, as well as continual iteration on existing detections. Several feedback mechanisms are built into the service, such as the thumbs-up and thumbs-down in each security finding found in the GuardDuty user interface (UI). This allows you to provide feedback that might be incorporated into future iterations of GuardDuty detections.

No, GuardDuty removes the heavy lifting and complexity of developing and maintaining your own custom rule sets. New detections are continually added based on customer feedback, along with research from AWS security engineers and the GuardDuty engineering team. However, customer-configured customizations include adding your own threat lists and trusted IP address list.

For current GuardDuty accounts, S3 Protection can be activated in the console on the S3 Protection page, or through the API. This will start a 30-day no-cost trial of the GuardDuty S3 Protection feature.

Yes, there is a 30-day free trial. Each account in each Region gets a 30-day no-cost trial of the GuardDuty that includes the S3 Protection feature. Accounts that already have GuardDuty enabled will also get a 30-day free trial of the S3 Protection feature when they first activate it.

Yes. Any new accounts that enable GuardDuty through the console or API will also have S3 Protection turned on by default. New GuardDuty accounts created using the AWS Organizations auto-enable feature will not have S3 Protection turned on unless the Auto-enable for S3 option is turned on.

No, the GuardDuty service must be enabled in order to use S3 Protection. Current GuardDuty accounts have the option to enable S3 Protection, and new GuardDuty accounts will have the feature by default once the GuardDuty service is enabled.

Yes, S3 Protection monitors all Amazon S3 buckets in your environment by default.

No, GuardDuty has direct access to CloudTrail S3 data event logs. You are not required to enable S3 data event logging in CloudTrail, and therefore will not incur the associated costs. Note that GuardDuty does not store the logs and only uses them for its analysis.

GuardDuty EKS Protection is a GuardDuty feature that monitors Amazon EKS cluster control plane activity by analyzing Amazon EKS audit logs. GuardDuty is integrated with Amazon EKS, giving it direct access to Amazon EKS audit logs without requiring you to turn on or store these logs. These audit logs are security-relevant chronological records documenting the sequence of actions performed on the Amazon EKS control plane. These Amazon EKS audit logs give GuardDuty the visibility needed to conduct continuous monitoring of Amazon EKS API activity and apply proven threat intelligence and anomaly detection to identify malicious activity or configuration changes that might expose your Amazon EKS cluster to unauthorized access. When threats are identified, GuardDuty generates security findings that include the threat type, a severity level, and container-level detail (such as pod ID, container image ID, and associated tags).

GuardDuty EKS Protection can detect threats related to user and application activity captured in Amazon EKS audit logs. Amazon EKS threat detections include Amazon EKS clusters that are accessed by known malicious actors or from Tor nodes, API operations performed by anonymous users that might indicate a misconfiguration, and misconfigurations that can result in unauthorized access to Amazon EKS clusters. Also, using ML models, GuardDuty can identify patterns consistent with privilege-escalation techniques, such as a suspicious launch of a container with root-level access to the underlying Amazon EC2 host. See Amazon GuardDuty Finding types for a complete list of all new detections.

No, GuardDuty has direct access to Amazon EKS audit logs. Note that GuardDuty only uses these logs for analysis; it doesn’t store them, nor do you need to enable or pay for these Amazon EKS audit logs to be shared with GuardDuty. To optimize for costs, GuardDuty applies intelligent filters to only consume a subset of the audit logs that are relevant for security threat detection.

Yes, there is a 30-day free trial. Each new GuardDuty account in each Region receives a 30-day free trial of GuardDuty, including the GuardDuty EKS Protection feature. Existing GuardDuty accounts receive a 30-day trial of GuardDuty EKS Protection at no additional charge. During the trial period, you can view the post-trial costs estimate on the GuardDuty console usage page. If you are a GuardDuty administrator, you will see the estimated costs for your member accounts. After 30 days, you can view actual costs of this feature in the AWS Billing console.

GuardDuty EKS Protection must be turned on for each individual account. You can activate the feature for your accounts with a single action in the GuardDuty console from the GuardDuty EKS Protection console page. If you are operating in a GuardDuty multi-account configuration, you can activate GuardDuty EKS Protection across your entire organization from the GuardDuty administrator account GuardDuty EKS Protection page. This will activate continuous monitoring for Amazon EKS in all individual member accounts. For GuardDuty accounts created using the AWS Organizations auto-activate feature, you must explicitly turn on Auto-activate for Amazon EKS. Once activated for an account, all existing and future Amazon EKS clusters in the account will be monitored for threats without any configuration on your Amazon EKS clusters.

Yes, any new account that turns on GuardDuty through the console or API will also have GuardDuty EKS Protection turned on by default. For new GuardDuty accounts created using the AWS Organizations auto-enable feature, you need to explicitly enable the auto-enable for EKS Protection option. 

You can disable the feature in the console or by using the API. In the GuardDuty console, you can disable GuardDuty EKS Protection for your accounts on the GuardDuty EKS Protection console page. If you have a GuardDuty administrator account, you can also disable this feature for your member accounts.

If you previously disabled GuardDuty EKS Protection, you can re-enable the feature in the console or by using the API. In the GuardDuty console, you can enable GuardDuty EKS Protection for your accounts on the GuardDuty EKS Protection console page.

GuardDuty EKS Protection must be enabled for each individual account. If you are operating in a GuardDuty multi-account configuration, you can enable threat detection for Amazon EKS across your entire organization with a single click on the GuardDuty administrator account GuardDuty EKS Protection console page. This will enable threat detection for Amazon EKS in all individual member accounts. Once enabled for an account, all existing and future Amazon EKS clusters in the account will be monitored for threats, and no manual configuration is required on your Amazon EKS clusters.

You will not incur any GuardDuty EKS Protection charges if you aren’t using Amazon EKS and you have GuardDuty EKS Protection enabled. However, when you start using Amazon EKS, GuardDuty will automatically monitor your clusters and generate findings for identified issues, and you will be charged for this monitoring.

No, the GuardDuty service must be enabled for GuardDuty EKS Protection to be available.

Yes, GuardDuty EKS Protection monitors Amazon EKS audit logs from both Amazon EKS clusters deployed on Amazon EC2 instances and Amazon EKS clusters deployed on Fargate.

Currently, this capability only supports Amazon EKS deployments running on Amazon EC2 instances in your account or on Fargate.

No, GuardDuty EKS Protection is designed to not have any performance, availability, or cost implications to Amazon EKS workload deployments.

Yes, GuardDuty is a regional service, and thus GuardDuty EKS Protection must be enabled in each AWS Region separately.

GuardDuty Runtime Monitoring uses a lightweight, fully managed security agent that adds visibility into runtime activity such as file access, process execution, and network connections at the pod or instance level for your covered resources. The security agent is automatically deployed as a Daemon set that collects runtime events and delivers them to GuardDuty for security analytics processing. This allows GuardDuty to identify specific instances or containers within your AWS environment that are potentially compromised and detect attempts to escalate privileges to the broader AWS environment. When GuardDuty detects a potential threat, a security finding is generated that includes metadata context that includes instance, container, pod, and process details. 

For current GuardDuty accounts, the feature can be activated from the GuardDuty console on the Runtime Monitoring page, or through the API. Learn more about GuardDuty Runtime Monitoring.

Runtime Monitoring is available for Amazon EKS resources running on Amazon EC2, Amazon ECS clusters running on Amazon EC2 or AWS Fargate, and Amazon EC2 instances. 

Architectural requirements for GuardDuty Runtime Monitoring are available in the GuardDuty User Guide. 

No. GuardDuty Runtime Monitoring is the only protection plan that is not enabled by default when you turn on GuardDuty for the first time. The feature can be activated from the GuardDuty console on the Runtime Monitoring page or through the API. New GuardDuty accounts created using the AWS Organizations auto-enable feature will not have Runtime Monitoring turned on unless the Auto-enable for Runtime Monitoring option is turned on.

AWS publishes GuardDuty agent updates on a regular basis. For Amazon ECS on Amazon EC2, you can update to the latest agent version by updating to the latest ECS optimized AMI or ECS agent. For Amazon ECS on Fargate, the Fargate agent pulls the latest GuardDuty agent version automatically.

If you choose to manually deploy the agent per cluster, then you will be responsible to also update the agent when GuardDuty publicizes the release of a new version. New agent versions are carefully tested and monitored before, during, and after release. GuardDuty maintains a subset of previous agent versions so that you can roll back an update in the case where your application has a unique conflict with the agent; you can find detailed agent release history in the GuardDuty User Guide. For CVE patches and other urgent updates, follow AWS update guidelines included in your PHD notices.

No, the GuardDuty service must be enabled in order to use GuardDuty Runtime Monitoring.

When you enable Amazon ECS Runtime Monitoring, GuardDuty becomes ready to consume the runtime events from a task. These tasks run within the Amazon ECS clusters, which in turn run on AWS Fargate instances. For GuardDuty to receive these runtime events, you must use the Automated agent configuration.

When you enable Runtime Monitoring for Amazon EC2 or Amazon EKS, you have the option to either deploy the GuardDuty security agent manually, or allow GuardDuty to manage it on your behalf with Automated agent configuration.

Visit Key concepts - Approaches to manage GuardDuty security agent in the GuardDuty User Guide for more details.
 

For a full list of Regions where Runtime Monitoring is available, visit Region-specific feature availability.

GuardDuty Runtime Monitoring must be enabled for each individual account. If you are operating in a GuardDuty multi-account configuration, you can turn it on across your entire organization in a single step on the GuardDuty administrator account GuardDuty Runtime Monitoring console page. This will activate runtime monitoring for desired workloads in all individual member accounts. Once activated for an account, all existing and future selected workloads in the account will be monitored for runtime threats, and no manual configuration will be required.

GuardDuty Runtime Monitoring allows you to selectively configure which Amazon EKS clusters or Amazon ECS clusters are to be monitored for threat detection. With cluster-level configurability, you can selectively monitor specific clusters for threat detection or continue using account-level configurability to monitor all EKS or ECS clusters, respectively, in a given account and Region.

You will not incur any GuardDuty Runtime Monitoring charges if you have GuardDuty Runtime Monitoring enabled for a workload that you are not running. However, when you start using Amazon EKS, Amazon ECS, or Amazon EC2 and GuardDuty Runtime Monitoring is enabled for that workload, you will be charged when GuardDuty automatically monitors your clusters, tasks, and instances and generate findings for identified issues. 

Like all security, observability, and other use cases requiring an on-host agent, the GuardDuty security agent introduces resource utilization overhead. The GuardDuty security agent is designed to be lightweight, and it is carefully monitored by GuardDuty to minimize utilization and cost impact to covered workloads. The exact resource utilization metrics will be made available for application and security teams to monitor in Amazon CloudWatch.

If you configure GuardDuty Runtime Monitoring to automatically deploy the GuardDuty security agent, this could result in additional resource utilization, and will also create VPC endpoints in VPCs used to run AWS workloads. 

GuardDuty Runtime Monitoring can be disabled for an AWS account or organization on the GuardDuty console Runtime Monitoring page. If the security agent was deployed automatically by GuardDuty, then GuardDuty will also remove the security agent when the feature is disabled.

If you opted to deploy the GuardDuty agent manually (applicable only to EKS Runtime Monitoring and EC2 Runtime Monitoring), then you will need to manually remove it, and any VPC endpoints that were created must be manually deleted. Steps for manual removal for EKS Runtime Monitoring and EC2 Runtime Monitoring are detailed in the GuardDuty User Guide. 

Amazon EBS data volumes: If you have this data source enabled for Malware Protection, GuardDuty begins a malware detection scan when it identifies suspicious behavior indicative of malicious software in Amazon EC2 instance, or container workloads. It scans a replica Amazon EBS volume that GuardDuty generates based on the snapshot of your Amazon EBS volume for trojans, worms, crypto miners, rootkits, bots, and more. GuardDuty Malware Protection generates contextualized findings that can help validate the source of the suspicious behavior. These findings can also be routed to the proper administrators and can initiate automated remediation.

S3 object scanning: Once a bucket is configured for malware protection, GuardDuty automatically scans newly uploaded files and, if malware is detected, generates an Amazon EventBridge notification with details about the malware, allowing for integration with existing security event management or workflow systems. You can configure to automatically quarantine malware by moving the object to an isolated bucket in your account, or use object tags to add the disposition of the scan result, allowing to better identify and categorize the scanned objects based on tags.

GuardDuty findings for Amazon EC2 that will initiate a malware scan can be found in the GuardDuty User Guide.

Malware Protection supports detection of malicious files by scanning Amazon EBS attached to Amazon EC2 instances. Supported file system types can be found in the GuardDuty User Guide.

Malware Protection for S3 can scan files belonging to most synchronous S3 storage classes, such as S3 Standard, S3 Intelligent-Tiering, S3 Standard-IA, S3 One Zone-IA, and Amazon S3 Glacier Instant Retrieval, with GuardDuty’s malware scanning engine.  It will scan the file formats known to be used to spread or contain malware including executables, .pdf files, archives, binaries, packed files, scripts, installers, e-mail databases, plain emails, images, and encoded objects.

Malware Protection scans for threats such as trojans, worms, crypto miners, rootkits, and bots, that might be used to compromise workloads, repurpose resources for malicious use, and gain unauthorized access to data.

Consult the GuardDuty User Guide for a comprehensive list of finding types.

Service logging does not need to be enabled for GuardDuty or the Malware Protection feature to work. The Malware Protection feature is part of GuardDuty, which is an AWS service that uses intelligence from integrated internal and external sources.

Instead of using security agents, GuardDuty Malware Protection will create and scan a replica based on the snapshot of Amazon EBS volumes attached to the potentially infected Amazon EC2 instance or container workload in your account. The permissions you granted to GuardDuty through a service-linked role allows the service to create an encrypted volume replica in the GuardDuty service account from that snapshot that remains in your account. GuardDuty Malware Protection will then scan the volume replica for malware.

For objects in Amazon S3, GuardDuty begins reading, decrypting, and scanning objects uploaded to buckets that you have configured for GuardDuty Malware Protection. You can limit the scope of objects to scan in a bucket by defining that only objects certain prefixes are scanned. GuardDuty will scan uploaded objects that match on these defined prefixes, and generate a security finding and an Amazon EventBridge notification with a detailed scan result: Infected, Clean, Skipped, or Failed. The notification will also include scan metrics related to number of objects and bytes scanned. You can also define post-scan actions that GuardDuty will execute on the object based on the scan result, such as automated quarantine or object tagging.

Yes, each new GuardDuty account in each Region receives a 30-day free trial of GuardDuty, including the Malware Protection feature (available for GuardDuty-initiated scanning of EBS data volumes only; there is not a free trial for GuardDuty Malware Protection for Amazon S3). Existing GuardDuty accounts receive a 30-day trial of Malware Protection at no additional charge the first time it is enabled in an account. During the trial period, you can view the post-trial costs estimate on the GuardDuty console usage page. If you are a GuardDuty administrator, you will see the estimated costs for your member accounts. After 30 days, you can view actual costs of this feature in the AWS Billing console.

You can enable Malware Protection in the GuardDuty console by going to the Malware Protection page or using the API. If you are operating in a GuardDuty multi-account configuration, you can enable the feature across your entire organization in the GuardDuty administrator account’s Malware Protection console page. This will enable monitoring for malware in all individual member accounts. For GuardDuty accounts created using the AWS Organizations auto-enable feature, you need to explicitly enable the auto-enable for the Malware Protection option.

For Malware Protection for S3, you can integrate malware scanning in your applications following two steps. First, as an application owner, you need to set up the bucket protection configuration on the buckets that you want to monitor. You can set this up in the GuardDuty console programmatically for an existing bucket, or when creating a new bucket. GuardDuty will send scan metrics to your EventBridge events for each protected S3 bucket, allowing you to set up alarms and define post-scan actions, such as tagging the object or copying the malicious object to a quarantine bucket that GuardDuty will execute based on the scan result. If GuardDuty is enabled for your account, then a security finding is also generated in GuardDuty.

Yes, any new account that enables GuardDuty using the console or API will also have GuardDuty Malware Protection enabled by default (for EBS volumes scanning). For new GuardDuty accounts created using the AWS Organizations auto-enable feature, you need to explicitly enable the auto-enable for Malware Protection option. 

You can disable the feature in the console or using the API. You will see an option to disable Malware Protection for your accounts in the GuardDuty console, on the Malware Protection console page. If you have a GuardDuty administrator account, you can also disable Malware Protection for your member accounts.

If Malware Protection was disabled, you can enable the feature in the console or using the API. You can enable Malware Protection for your accounts in the GuardDuty console, on to the Malware Protection console page.

No, there will be no charges for Malware Protection if there are no scans for malware during a billing period. You can view costs of this feature in the AWS Billing console.

Yes, GuardDuty has a multiple account management feature, allowing you to associate and manage multiple AWS accounts from a single administrator account. GuardDuty has multi-account management through AWS Organizations integration. This integration helps security and compliance teams ensure full coverage of GuardDuty, including Malware Protection, across all accounts in an organization.

No. Once the feature is enabled, GuardDuty Malware Protection will initiate a malware scan in response to relevant Amazon EC2 findings. You don’t have to deploy any agents, there are no log sources to enable, and there are no other configuration changes to make.

GuardDuty Malware Protection is designed to not affect the performance of your workloads. For example, Amazon EBS volume snapshots created for malware analysis can only be generated once in a 24-hour period, and GuardDuty Malware Protection retains the encrypted replicas and snapshots for a few minutes after it completes a scan. Further, GuardDuty Malware Protection uses GuardDuty compute resources for malware scanning instead of customer compute resources.

Yes, GuardDuty is a regional service, and Malware Protection has to be enabled in each AWS Region separately.

GuardDuty Malware Protection scans a replica based on the snapshot of Amazon EBS volumes attached to the potentially infected Amazon EC2 instance or container workload in your account. If your Amazon EBS volumes are encrypted with a customer managed key, you have the option to share your AWS Key Management Service (KMS) key with GuardDuty and the service uses the same key to encrypt the replica Amazon EBS volume. For unencrypted Amazon EBS volumes, GuardDuty uses its own key to encrypt the replica Amazon EBS volume.

Yes, all replica Amazon EBS volume data (and the snapshot the replica volume is based on) stays in the same Region as the original Amazon EBS volume.

Each new GuardDuty account, in each Region, receives a 30-day free trial of GuardDuty, including the Malware Protection feature (only for EBS data volume scans that are initiated by GuardDuty; there is not a free trial for Malware Protection for Amazon S3). Existing GuardDuty accounts receive a 30-day trial of Malware Protection at no additional charge the first time it is enabled in an account. During the trial period, you can estimate the post-trial costs estimate on the GuardDuty console usage page. If you are a GuardDuty administrator, you will see the estimated costs for your member accounts. After 30 days, you can view actual costs of this feature in the AWS Billing console.

Pricing for malware scanning of EBS volumes is based on the GB of data scanned in a volume. You can apply customizations using scan options from the console to mark some Amazon EC2 instances, using tags, to be included or excluded from scanning, thus controlling the cost. In addition, GuardDuty will only scan an Amazon EC2 instance once every 24 hours. If GuardDuty generates multiple Amazon EC2 findings for an Amazon EC2 instance within 24 hours, a scan will only occur for the first relevant Amazon EC2 finding. If Amazon EC2 findings continue, for an instance, 24 hours after the last malware scan, a new malware scan will be initiated for that instance.

Pricing for malware scanning of storage objects in S3 buckets is based on the GB of data scanned, as well as the number of files scanned in a designated S3 bucket that is configured for malware scanning. GuardDuty will only scan for newly-uploaded files into configured buckets, and will not scan existing files or files in buckets not designated for malware scanning.

Yes, there is a setting where you can enable snapshot retention when Malware Protection scan detects malware. You can enable this setting from the GuardDuty console, on the Settings page. By default, snapshots are deleted a few minutes after it completes a scan and after 24 hours if the scan did not complete.

GuardDuty Malware Protection will retain each replica Amazon EBS volume it generates and scans for up to 24 hours. By default, replica Amazon EBS volumes are deleted a few minutes after GuardDuty Malware Protection completes a scan. In some instances, however, GuardDuty Malware Protection may need to retain a replica Amazon EBS volume for longer than 24 hours if a service outage or connection problem interferes with its malware scan. When this occurs, GuardDuty Malware Protection will retain the replica Amazon EBS volume for up to seven days to give the service time to triage and address the outage or connection problem. GuardDuty Malware Protection will delete the replica Amazon EBS volume after the outage or failure is addressed or once the extended retention period lapses.

No, GuardDuty only scans a replica based on the snapshot of Amazon EBS volumes attached to the potentially infected Amazon EC2 instance or container workload once every 24 hours. Even if GuardDuty generates multiple findings that qualify to initiate a malware scan, it will not initiate additional scans if it has been less than 24 hours since a prior scan. If GuardDuty generates a qualified finding after 24 hours from the last malware scan, GuardDuty Malware Protection will initiate a new malware scan for that workload.

No, disabling the GuardDuty service also disables the Malware Protection feature.

No, GuardDuty S3 Malware Protection gives you flexibility, allowing applications owners to set up Malware Protection for their S3 buckets even when base GuardDuty is not enabled for the account. Base GuardDuty includes default monitoring of foundational sources, such as AWS CloudTrail management events, VPC Flow Logs and DNS query logs.

GuardDuty RDS Protection can be turned on with a single action in the GuardDuty console, with no agents to manually deploy, no data sources to activate, and no permissions to configure. Using tailored ML models, GuardDuty RDS Protection begins by analyzing and profiling login attempts to existing and new Amazon Aurora databases. When suspicious behaviors or attempts by known malicious actors are identified, GuardDuty issues actionable security findings to the GuardDuty and Amazon Relational Database Service (RDS) consoles, Security Hub, and Amazon EventBridge, allowing for integration with existing security event management or workflow systems. Learn more about how GuardDuty RDS Protection uses RDS login activity monitoring.

For current GuardDuty accounts, the feature can be activated from the GuardDuty console on the RDS Protection page, or through the API. Learn more about GuardDuty RDS Protection.

Yes. Any new accounts that activate GuardDuty through the console or API will also have RDS Protection turned on by default. New GuardDuty accounts created using the AWS Organizations auto-enable feature will not have RDS Protection turned on unless the auto-enable for RDS option is turned on.

No, the GuardDuty service must be enabled in order to use GuardDuty RDS Protection.

For a full list of Regions where RDS Protection is available, visit Region-specific feature availability.

Please see the list of supported Amazon Aurora database versions.

No, GuardDuty threat detection for Aurora databases is designed to not have performance, availability, or cost implications to your Amazon Aurora databases.

GuardDuty Lambda Protection continuously monitors network activity, starting with VPC Flow Logs, from your serverless workloads to detect threats such as Lambda functions maliciously repurposed for unauthorized cryptocurrency mining, or compromised Lambda functions that are communicating with known threat actor servers. GuardDuty Lambda Protection can be enabled with a few steps in the GuardDuty console, and using AWS Organizations, can be centrally enabled for all existing and new accounts in an organization. Once enabled, it automatically starts monitoring network activity data from all existing and new Lambda functions in an account.

For current GuardDuty accounts, the feature can be activated from the GuardDuty console on the Lambda Protection page, or through the API. Learn more about GuardDuty Lambda Protection.

Yes. Any new accounts that activate GuardDuty through the console or API will also have Lambda Protection turned on by default. New GuardDuty accounts created using the AWS Organizations auto-enable feature will not have Lambda Protection turned on unless the auto-enable for Lambda option is turned on.

For a full list of Regions where Lambda Protection is available, visit Region-specific feature availability.

No, GuardDuty Lambda Protection is designed to not have performance, availability, or cost implications to your Lambda workloads.