Service overview

Q: What is Amazon GuardDuty?

GuardDuty is an intelligent threat detection service that continuously monitors your AWS accounts, Amazon Elastic Compute Cloud (EC2) instances, Amazon Elastic Kubernetes Service (EKS) clusters, and data stored in Amazon Simple Storage Service (S3) for malicious activity without the use of security software or agents. If potential malicious activity, such as anomalous behavior, credential exfiltration, or command and control infrastructure (C2) communication is detected, GuardDuty generates detailed security findings that can be used for security visibility and assisting in remediation. Additionally, using the Amazon GuardDuty Malware Protection feature helps to detect malicious files on Amazon Elastic Block Store (EBS) volumes attached to EC2 instance and container workloads.

Q: What are the key benefits of GuardDuty?

GuardDuty makes it easier to continuously monitor your AWS accounts, workloads, and data stored in Amazon S3. GuardDuty operates completely independently from your resources, so there is no performance or availability impacts to your workloads. The service is fully managed with integrated threat intelligence, machine learning (ML) anomaly detection, and malware scanning. GuardDuty delivers detailed and actionable alerts that are designed to be integrated with existing event management and workflow systems. There are no upfront costs and you pay only for the events analyzed, with no additional software to deploy or threat intelligence feed subscriptions required.

Q: How much does GuardDuty cost?

GuardDuty prices are based on the volume of analyzed service logs and the volume of data scanned for malware. Analyzed service logs are filtered for cost-optimization, and directly integrated with GuardDuty, which means you don’t have to enable or pay for them separately.

See Amazon GuardDuty pricing for additional details and pricing examples.

Q. Does the estimated cost in the GuardDuty payer account show the total aggregated costs for linked accounts, or just that individual payer account?

The estimated cost represents the cost for the individual payer account, and you will see the billed usage and average daily cost for each member account in the GuardDuty administrator account. You must go to the individual account if you want to see the detailed usage info.

 

Q: Is there a free trial of GuardDuty?

Yes, any new account to GuardDuty can try the service for 30 days at no cost. You have access to the full feature set and detections during the free trial. 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.

Q: What are the differences between GuardDuty and Amazon Macie?

GuardDuty provides broad security monitoring of your AWS accounts, workloads, and data to help identify threats, such as attacker reconnaissance; instance, account, bucket, or EKS cluster compromises; and malware. Macie is a fully managed sensitive data discovery service that uses ML and pattern matching to discover your sensitive data in S3.

Q: Is GuardDuty a regional or global service?

GuardDuty is a regional service. Even when multiple accounts are enabled and multiple Regions are used, the GuardDuty security findings remain in the same Regions where the underlying data was generated. This ensures all data analyzed is regionally based and doesn’t cross AWS regional boundaries. However, you can choose to aggregate security findings produced by GuardDuty across Regions using Amazon CloudWatch Events or pushing findings to your data store (like S3) and then aggregating findings as you see fit. You can also send GuardDuty findings to AWS Security Hub and use its cross-Region aggregation capability.

Q: Which Regions does GuardDuty support?

GuardDuty regional availability is listed in the AWS Regional Services List.

Q: Which partners work with GuardDuty?

Many technology partners have integrated and built on GuardDuty. There are also consulting, system integrator, and managed security service providers with expertise about GuardDuty. For details, see the Amazon GuardDuty Partners page.

Q: Does GuardDuty help address payment card industry data security standard (PCI DSS) requirements?

Foregenix published a white paper providing a detailed assessment of GuardDuty effectiveness for assisting in meeting requirements, like PCI DSS requirement 11.4, which requires intrusion detection techniques at critical points in the network.

Enabling GuardDuty

Q: How do I enable GuardDuty?

You can set up and deploy GuardDuty with a few clicks 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.

Q: Can I manage multiple accounts with GuardDuty?

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. CloudWatch 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.

Q: Which data sources does GuardDuty analyze?

GuardDuty analyzes CloudTrail management event logs, CloudTrail S3 data event logs, VPC Flow Logs, DNS query logs, and EKS audit logs. GuardDuty can also scan EBS volume data for possible malware when GuardDuty Malware Protection is enabled and identifies suspicious behavior indicative of malicious software in EC2 instance or container workloads. 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.

Q: How quickly does GuardDuty start working?

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.

Q: Do I have to enable CloudTrail, VPC Flow Logs, DNS query logs, or EKS audit logs for GuardDuty to work?

No, GuardDuty pulls independent data streams directly from CloudTrail, VPC Flow Logs, DNS query logs, and EKS. You don’t have to manage 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 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.

Q: Is there any performance or availability impact to enabling GuardDuty on my account?

GuardDuty operates completely independent of your AWS resources and therefore should have no impact on the performance or availability of your accounts or workloads.

Q: Does GuardDuty manage or keep my logs?

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.

Q: How can I prevent GuardDuty from looking at my logs and data sources?

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 Kubernetes Protection through the Management Console or via the AWS CLI.

GuardDuty findings

Q: What can GuardDuty detect?

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 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, 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 S3 API activity from a remote host, unauthorized S3 access from known malicious IP addresses, and API calls to retrieve data in 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 S3 buckets.
  • Malware detection: GuardDuty begins a malware detection scan when it identifies suspicious behavior indicative of malicious software in EC2 instance or container workloads. GuardDuty generates temporary replicas of EBS volumes attached to such EC2 instance or container workloads and scans the volume replicas for trojans, worms, crypto miners, rootkits, bots, and more, that might be used to compromise the workloads, repurpose resources for malicious use, and gain unauthorized access to data. GuardDuty Malware Protection generates contextualized findings that can validate the source of the suspicious behavior. These findings can be routed to the proper administrators and initiate automated remediation.
  • Container compromise: Activity identifying possible malicious or suspicious behavior in container workloads is detected by continuously monitoring and profiling EKS clusters by analyzing its EKS audit logs.

Q: What is GuardDuty threat intelligence?

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.

Q: Can I supply my own threat intelligence?

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.

Q: How are security findings delivered?

When a potential threat is detected, GuardDuty delivers a detailed security finding to the GuardDuty console and CloudWatch Events. 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.

Q: What is the format of GuardDuty findings?

GuardDuty findings come in a common JavaScript Object Notation (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.

Q: How long are security findings made available in GuardDuty?

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 CloudWatch Events to automatically push findings to an S3 bucket in your account or another data store for long-term retention.

Q: Can I aggregate GuardDuty findings?

Yes, you can choose to aggregate security findings produced by GuardDuty across regions using CloudWatch Events or by pushing findings to your data store (like 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.

Q: Can I take automated preventative actions using GuardDuty?

With GuardDuty, CloudWatch Events, 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 EC2 instances is being probed by a known malicious IP, you can address it through a CloudWatch Events rule, initiating a Lambda function to automatically modify your security group rules and restrict access on that port.

Q: How are GuardDuty detections developed and managed?

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.

Q: Can I write custom detections in Amazon GuardDuty?

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.

GuardDuty S3 Protection

Q: How can I get started with S3 Protection if I am currently using GuardDuty?

For current GuardDuty accounts, S3 Protection can be enabled in the console or through the API. In the GuardDuty console, you can go to the S3 Protection console page and can enable this feature for your accounts. This will start a 30-day no-cost trial of the GuardDuty S3 Protection feature.

Q: Is there a free trial of GuardDuty S3 Protection?

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.

Q: If I am a new user to GuardDuty, is S3 Protection enabled by default for my accounts?

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 by default unless the Auto-enable for S3 option is turned on.

Q: Can I use GuardDuty S3 Protection without enabling the full GuardDuty service (including the analysis of VPC Flow Logs, DNS query logs, and CloudTrail management events)?

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.

Q: Does GuardDuty monitor all buckets in my account to help protect my S3 deployment?

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

Q: Do I need to turn on CloudTrail S3 data event logging for S3 Protection?

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 Kubernetes Protection

Q: How does GuardDuty Kubernetes Protection work?

GuardDuty Kubernetes Protection is a GuardDuty feature that monitors EKS cluster control plane activity by analyzing EKS audit logs. GuardDuty is integrated with EKS, giving it direct access to 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 EKS control plane. These EKS audit logs give GuardDuty the visibility needed to conduct continuous monitoring of EKS API activity and apply proven threat intelligence and anomaly detection to identify malicious activity or configuration changes that might expose your 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).

Q: What types of threats can GuardDuty Kubernetes Protection detect on my EKS workloads?

GuardDuty Kubernetes Protection can detect threats related to user and application activity captured in EKS audit logs. EKS threat detections include 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 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 EC2 host. See Amazon GuardDuty Finding types for a complete list of all new detections.

Q: Do I need to turn on EKS audit logs?

No, GuardDuty has direct access to 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 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.

Q: Is there a free trial of GuardDuty Kubernetes Protection?

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 Kubernetes Protection feature. Existing GuardDuty accounts receive a 30-day trial of GuardDuty Kubernetes 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.

Q: How can I get started with GuardDuty Kubernetes Protection if I am currently using GuardDuty?

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

Q: Is GuardDuty Kubernetes Protection enabled by default for my accounts if I am a new GuardDuty user?

Yes, any new account that enables GuardDuty through the console or API will also have GuardDuty Kubernetes Protection turned on by default. Note, new GuardDuty accounts created using the AWS Organizations Auto-enable feature will not have GuardDuty Kubernetes Protection turned on by default unless the Auto-enable for EKS option is turned on.

Q: How do I disable GuardDuty Kubernetes Protection?

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

Q: If I disable GuardDuty Kubernetes Protection, how do I enable it again?

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

Q: Do I have to enable GuardDuty Kubernetes Protection on each AWS account and EKS cluster individually?

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

Q: Will I be charged if I don’t use EKS and I enable GuardDuty Kubernetes Protection in GuardDuty?

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

Q: Can I enable GuardDuty Kubernetes Protection without enabling the full GuardDuty service (including the analysis of VPC Flow Logs, DNS query logs, and CloudTrail management events)?

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

Q: Does GuardDuty Kubernetes Protection monitor EKS audit logs for EKS deployments on AWS Fargate?

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

Q: Does GuardDuty monitor non-managed EKS on EC2 or Amazon EKS Anywhere?

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

Q: Will using GuardDuty Kubernetes Protection impact the performance or cost of running containers on Amazon EKS?

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

Q: Do I have to enable GuardDuty Kubernetes Protection in each AWS Region individually?

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

GuardDuty Malware Protection

Q: How does Amazon GuardDuty Malware Protection work?

GuardDuty begins a malware detection scan when it identifies suspicious behavior indicative of malicious software in EC2 instance or container workloads. It scans a replica EBS volume that GuardDuty generates based on the snapshot of your 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.

Q: Which GuardDuty EC2 finding types will initiate a malware scan?

GuardDuty EC2 findings that will initiate a malware scan are listed here.

Q: Which resources and file types can GuardDuty Malware Protection scan?

Malware Protection supports detection of malicious files by scanning EBS attached to EC2 instances. It can scan any file present on the volume, and the supported file system types can be found here.

Q: Which types of threats can GuardDuty Malware Protection detect?

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.

Q: Do I need to turn on logging for GuardDuty Malware Protection to work?

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.

Q: How does GuardDuty Malware Protection accomplish scanning without agents?

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

Q: Is there a free trial of GuardDuty Malware Protection?

Yes, each new GuardDuty account in each Region receives a 30-day free trial of GuardDuty, including the Malware Protection feature. 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.

Q: If I am currently using GuardDuty, how can I get started with GuardDuty Malware Protection?

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.

Q: If I am a new user to GuardDuty, is Malware Protection enabled by default for my accounts?

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

Q: How do I disable GuardDuty Malware Protection?

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.

Q: If I disable GuardDuty Malware Protection, how do I enable it again?

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.

Q: If no GuardDuty malware scans are performed during a billing period, will there be any charges?

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.

Q: Does GuardDuty Malware Protection support multi-account management?

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.

Q: Do I need to make any configuration changes, deploy any software, or modify my AWS deployments?

No. Once the feature is enabled, GuardDuty Malware Protection will initiate a malware scan in response to relevant 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.

Q: Will using GuardDuty Malware Protection impact the performance of running my workloads?

GuardDuty Malware Protection is designed to not affect the performance of your workloads. For example, 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.

Q: Do I have to enable GuardDuty Malware Protection in each AWS Region individually?

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

Q: How does GuardDuty Malware Protection use encryption?

GuardDuty Malware Protection scans a replica based on the snapshot of EBS volumes attached to the potentially infected EC2 instance or container workload in your account. If your 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 EBS volume. For unencrypted EBS volumes, GuardDuty uses its own key to encrypt the replica EBS volume.

Q: Will the EBS volume replica be analyzed in same Region as the original volume?

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

Q: How can I estimate and control spend on GuardDuty Malware Protection?

Each new GuardDuty account, in each Region, receives a 30-day free trial of GuardDuty, including the Malware Protection feature. 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 this feature is based on the GB of data scanned in a volume. You can apply customizations using scan options from the console to mark some EC2 instances, using tags, to be included or excluded from scanning, thus controlling the cost. In addition, GuardDuty will only scan an EC2 instance once every 24 hours. If GuardDuty generates multiple EC2 findings for an EC2 instance within 24 hours, a scan will only occur for the first relevant EC2 finding. If EC2 findings continue, for an instance, 24 hours after the last malware scan, a new malware scan will be initiated for that instance.

Q: Can I keep the snapshots taken by GuardDuty Malware Protection?

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.

Q: By default, what is the maximum length of time a replica EBS volume will be retained?

GuardDuty Malware Protection will retain each replica EBS volume it generates and scans for up to 24 hours. By default, replica 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 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 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 EBS volume after the outage or failure is addressed or once the extended retention period lapses.

Q: Will multiple GuardDuty findings for a single EC2 instance or container workload that indicate possible malware initiate multiple malware scans?

No, GuardDuty only scans a replica based on the snapshot of EBS volumes attached to the potentially infected 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.

Q: If I disable GuardDuty, do I also have to disable the Malware Protection feature?

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

Learn more about product pricing

See pricing examples and free trial details

Learn more 
Sign up for a free trial

Get access to the Amazon GuardDuty free trial. 

Start free trial 
Start building in the console

Get started with Amazon GuardDuty in the AWS Console.

Sign in