Service Overview

Q: What is Amazon GuardDuty?

Amazon GuardDuty offers threat detection that enables you to continuously monitor and protect your Amazon Web Services accounts, workloads, and data stored in Amazon S3. GuardDuty analyzes continuous streams of meta-data generated from your account and network activity found in Amazon CloudTrail Events, Amazon VPC Flow Logs, and DNS Logs. It also uses integrated threat intelligence such as known malicious IP addresses, anomaly detection, and machine learning to identify threats more accurately.

Q: What are the key benefits of Amazon GuardDuty?

Amazon GuardDuty makes it easy for you to enable continuous monitoring of your Amazon Web Services accounts, workloads, and data stored in Amazon S3. It operates completely independently from your resources so there is no risk of performance or availability impacts to your workloads. It’s fully managed with integrated threat intelligence, anomaly detection, and machine learning. Amazon GuardDuty delivers detailed and actionable alerts that are easy to integrate 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 subscriptions to threat intelligence feeds required.

Q: How much does Amazon GuardDuty cost?

Amazon GuardDuty is priced based on the quantity of Amazon CloudTrail Events analyzed and the volume of Amazon VPC Flow Log and DNS Log data analyzed. There is no additional charge to enable these log sources for GuardDuty analysis.

  • Amazon CloudTrail Management Event analysis – GuardDuty continuously analyzes CloudTrail management events, monitoring all access and behavior of your Amazon Web Services accounts and infrastructure. CloudTrail management event analysis is charged per 1,000,000 events per month and pro-rated.
  • Amazon CloudTrail S3 Data Event analysis – GuardDuty continuously analyzes CloudTrail S3 data events, monitoring access and activity of all your Amazon S3 buckets. CloudTrail S3 data event analysis is charged per 1,000,000 events per month and are pro-rated.
  • VPC Flow Log and DNS Log analysis – GuardDuty continuously analyzes VPC Flow Logs and DNS requests and responses to identify malicious, unauthorized, or unexpected behavior in your Amazon Web Services accounts and workloads. Flow log and DNS log analysis is charged per Gigabyte (GB) per month. Flow log and DNS log analysis is offered with tiered volume discounts.

There are no upfront charges and you pay only for the data analyzed.

See Amazon GuardDuty pricing for details and pricing examples.

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

The estimated cost represents only the cost for the individual payer account. In the case of the Master account, you will only see the estimated cost for the Master account.

Q: Is there a free trial?

Yes, there is a 30-day free trial in Amazon Web Services China (Ningxia) region, operated by NWCD. where any new account to Amazon GuardDuty can try the service for 30-days at no cost. You will have access to the full feature set and detections during the free trial. GuardDuty will display the volume of data processed and estimated daily average service charges for your account. This makes it easy for you to experience Amazon GuardDuty at no cost and forecast the cost of the service beyond the free trial.

Q: What is the difference between Amazon GuardDuty and Amazon Macie?

Amazon GuardDuty provides broad protection of your Amazon Web Services accounts, workloads, and data by helping to identify threats such as attacker reconnaissance, instance compromise, account compromise, and bucket compromise. Amazon Macie helps you discover and protect your sensitive data in Amazon S3 by helping you classify what data you have and the security and access controls associated with that data.

Q: Is Amazon GuardDuty a regional or global service?

Amazon GuardDuty is a regional service. Even when multiple accounts are enabled and multiple regions are used, the Amazon 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 Amazon Web Services regional boundaries. Customers can choose to aggregate security findings produced by Amazon GuardDuty across regions by utilizing Amazon CloudWatch Events, pushing findings to a data store in the customer’s control, like Amazon S3, and then aggregating findings as they see fit.

Q: What regions does Amazon GuardDuty support?

The regional availability of Amazon GuardDuty is listed here: Amazon Web Services Region Table.

Q: Does Amazon GuardDuty help with addressing some of the requirements in Payment Card Industry Data Security Standard (PCI DSS)?

GuardDuty analyses events from multiple Amazon Web Services data sources, such as Amazon CloudTrail events, Amazon VPC Flow Logs, and DNS logs and detects suspicious activity based on threat intelligence feeds received from Amazon Web Services and other services such as CrowdStrike.

Enabling GuardDuty

Q: How do I enable Amazon GuardDuty?

Amazon GuardDuty can be enabled with a few clicks in the Amazon Web Services 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 are continuously updated and maintained.  

Q: Can I manage multiple accounts with Amazon GuardDuty?

Yes, Amazon GuardDuty has a multiple account feature that allows you to associate and manage multiple Amazon Web Services accounts from a single master account. When used, all security findings are aggregated to the administrator or Amazon GuardDuty master account for review and remediation. Amazon CloudWatch Events are also aggregated to the Amazon GuardDuty master account when using this configuration.

Q: What data sources does Amazon GuardDuty analyze?

Amazon GuardDuty analyzes Amazon CloudTrail, VPC Flow Logs, and Amazon DNS logs. The service is optimized to consume large volumes of data for near real-time processing of security detections. GuardDuty gives you access to built-in detection techniques that are developed and optimized for the cloud and maintained and continuously improved upon by Amazon Web Services services.

Q: How quickly does GuardDuty start working?

Once enabled, Amazon GuardDuty immediately 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’ll receive a finding in the GuardDuty console.

Q: Do I have to enable Amazon CloudTrail, VPC Flow Logs, and DNS logs for Amazon GuardDuty to work?

No. Amazon GuardDuty pulls independent streams of data directly from Amazon CloudTrail, VPC Flow Logs, and Amazon DNS logs. You don’t have to manage Amazon S3 bucket policies or modify the way you may collect and store your logs. GuardDuty permissions are managed as Service Linked Roles that you can revoke at any time by disabling GuardDuty. This makes it easy to enable the service without complex configuration and it eliminates the risk that an Amazon IAM permission modification or S3 bucket policy change will affect the operation of the service. It also makes GuardDuty extremely efficient at consuming high-volumes of data in near real-time without affecting the performance or availability of your account or workloads.

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

No. Amazon GuardDuty operates completely independent of your Amazon Web Services resources and there is no risk of impact to your accounts or workloads. This makes it easy for GuardDuty to be enabled across many accounts in an organization without impacting existing operations.

Q: Does Amazon GuardDuty manage or keep my logs?

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

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

You can stop Amazon GuardDuty from analyzing your data sources at any time by choosing to suspend the service in the general settings. This will immediately stop the service from analyzing data, but 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 findings and configurations before relinquishing the service permissions and resetting the service.

GuardDuty Findings

Q: What can Amazon GuardDuty detect?

Amazon GuardDuty gives you access to built-in detection techniques that are developed and optimized for the cloud. The detection algorithms are maintained and continuously improved upon by Amazon Web Services services. The primary detection categories include:

  • 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 (DGA), outbound denial of service activity, 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 include API calls from an unusual geolocation or anonymizing proxy, attempts to disable Amazon CloudTrail logging, unusual instance or infrastructure launches, infrastructure deployments in an unusual region, 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 user that had no prior history of accessing the bucket or invoked from an unusual location. Amazon GuardDuty continuously monitors and analyzes Amazon CloudTrail S3 data events (e.g. GetObject, ListObjects, DeleteObject) to detect suspicious activity across all of your Amazon S3 buckets.

Q: What is Amazon GuardDuty threat intelligence?

Amazon GuardDuty threat intelligence is made up of IP addresses and domains known to be used by attackers. GuardDuty threat intelligence is provided by Amazon Web Services services 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. Amazon GuardDuty makes it easy to upload your own threat intelligence or IP safe 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 threat is detected, Amazon GuardDuty delivers a detailed security finding to the GuardDuty console and Amazon CloudWatch Events. This makes alerts actionable and easy to integrate into existing event management or workflow systems. The findings include the category, resource affected, and meta-data associated with the resource, such as a severity level.

Q: What is the format of Amazon GuardDuty findings?

Amazon GuardDuty findings come in a common JSON format that is also used by Amazon Macie and Amazon Inspector. This makes it easy 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 Amazon GuardDuty?

Security findings are retained and made available through the Amazon 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 Amazon CloudWatch Events to automatically push findings to an Amazon S3 bucket in your account or other data store for long-term retention.

Q: Can I take automated preventative actions using Amazon GuardDuty?

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

Q: How are Amazon GuardDuty detections developed and managed?

Amazon GuardDuty has a team focused on the development, management, and iteration of detections. This produces a steady cadence of new detections in the service and continuous 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 UI. This allows customers to provide feedback that is incorporated into future iterations of GuardDuty detections.

Q: Can I write custom detections in Amazon GuardDuty?

No. Amazon GuardDuty removes the heavy lifting and complexity of developing and maintaining your own custom rule sets. New detections are continuously added based on customer feedback and research done by Amazon Web Services services and the GuardDuty team. Customer configured customizations include adding your own Threat Lists and IP Safe Lists.

GuardDuty for S3 Protection

Q: I am currently using Amazon GuardDuty, how can I get started with GuardDuty for S3 protection?

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

Q: Is there a free trial of GuardDuty for S3 protection?

Yes, there is a 30-day free trial Amazon Web Services China (Ningxia) region, operated by NWCD Each account, in the region gets a 30-day free trial of the GuardDuty for S3 protection. Accounts that already have GuardDuty enabled will also get 30-days for free of the GuardDuty for S3 protection capability.

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

Yes. Any new accounts that enable GuardDuty via the console or API will also have GuardDuty for S3 protection turned on by default. New GuardDuty accounts that are created by using the Amazon Organizations "auto-enable" feature, will not have GuardDuty for S3 protection turned on by default unless "auto-enable for S3" is turned on.

Q: Can I enable GuardDuty for S3 protection only, without enabling the full GuardDuty service (VPC Flow Logs, DNS query logs and CloudTrail Management Events)?

The Amazon GuardDuty service must be enabled for GuardDuty for S3 protection to also be available. Current GuardDuty accounts have the option to enable GuardDuty for S3 protection. New GuardDuty accounts will get GuardDuty for S3 protection by default once the GuardDuty service is enabled.

Q: Does GuardDuty monitor all buckets in my account for S3 protection?

Yes. GuardDuty for S3 protection by default monitors all S3 buckets in your environment.

Q: Do I need to turn on Amazon CloudTrail S3 Data Event logging for GuardDuty for S3 protection?

No. GuardDuty has direct access to Amazon CloudTrail S3 Data Event logs and you are not required to enable S3 data event logging in CloudTrail and incur the associated costs. Note that GuardDuty does not store the logs and only uses it for its analysis.

GuardDuty for EKS Protection

Q: How does Amazon GuardDuty for EKS Protection work?

Amazon GuardDuty for EKS Protection is a GuardDuty feature that monitors Amazon Elastic Kubernetes Service (Amazon EKS) cluster control plane activity by analyzing the Kubernetes audit logs. GuardDuty is integrated with Amazon EKS, giving it direct access to the Kubernetes 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 Kubernetes 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 may 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.

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

GuardDuty for EKS Protection can detect threats related to user and application activity captured in Kubernetes audit logs. Kubernetes 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 machine learning (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 Elastic Compute Cloud (Amazon EC2) host. See Amazon GuardDuty
Findings Types
 for a complete and detailed list of all new detections.

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

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

Q: Is there a free trial of GuardDuty for EKS Protection?

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

Q: I am currently using Amazon GuardDuty. How can I get started with GuardDuty for EKS Protection?

GuardDuty for EKS Protection needs to be enabled for each individual account. You can enable GuardDuty for EKS Protection with a single click in the GuardDuty console, go to the Kubernetes Protection page and enable GuardDuty for EKS Protection for your accounts. If you are operating in a GuardDuty multi-account configuration, you can enable monitoring Amazon EKS across your entire organization in the GuardDuty administrator account Kubernetes Protection page. This will enable continuous monitoring for Amazon EKS in all individual member accounts. For GuardDuty accounts created using the Amazon Organizations "auto-enable" feature you need to explicitly turn on “auto-enable for EKS”. Once enabled 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.

Q: I am a new user to Amazon GuardDuty. Is GuardDuty for EKS Protection enabled by default for my accounts?

Yes. Any new account that enables GuardDuty via the console or API will also have GuardDuty for EKS Protection turned on by default. Note, new GuardDuty accounts created using the Amazon Organizations "auto-enable" feature will not have GuardDuty for EKS Protection turned on by default unless "auto-enable for EKS" is turned on.

Q: How do I disable GuardDuty for EKS Protection?

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

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

If the feature was disabled, you can enable GuardDuty for EKS Protection by enabling the feature in the console or using the API. In the GuardDuty console, go to the Kubernetes Protection page, where you can enable GuardDuty for EKS Protection for your accounts.

Q: Do I have to enable Amazon GuardDuty for Amazon EKS Protection on each Amazon Web Services account and Amazon EKS cluster individually?

GuardDuty for EKS Protection needs to 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 in the GuardDuty administrator account Kubernetes Protection 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.

Q: If I don’t use Amazon EKS and I enable EKS Protection in GuardDuty will I be charged?

If you aren’t using Amazon EKS and you have EKS Protection enabled you will not incur any GuardDuty for EKS Protection charges. However, when you start using Amazon EKS your clusters will be automatically monitored by GuardDuty and you will receive findings for identified issues.

Q: Can I enable GuardDuty for EKS Protection only, without enabling the full GuardDuty service (e.g., VPC Flow Logs, DNS query logs, and CloudTrail management events analysis)?

The Amazon GuardDuty service must be enabled for GuardDuty for EKS Protection to be available.

Q: Does GuardDuty for EKS Protection support multi-account management?

GuardDuty has multi-account management through Amazon Organizations integration. This integration helps security and compliance teams ensure full coverage of GuardDuty on all existing and future Amazon EKS clusters across all accounts in an organization.

Q: Does GuardDuty monitor Kubernetes audit logs for EKS deployments on Amazon Fargate

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

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

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

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

No. Once enabled, GuardDuty begins monitoring Kubernetes audit logs from all existing and new EKS clusters in the account for threats with nothing more to deploy, no log sources to enable, and no configuration changes to make.

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

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

Q: Do I have to enable GuardDuty for EKS Protection in each Amazon Web Services Region individually?

Yes. Amazon GuardDuty is a regional service, and threat detection for EKS has to be enabled in each Amazon Web Services Region separately.

Q: Can I aggregate GuardDuty finding?

Yes. You can aggregate the GuardDuty findings from multiple accounts and multiple Regions using Amazon Web Services Security Hub’s cross-Region aggregation capabilities.