- Newest
- Most votes
- Most comments
Have you looked at the Pricing Examples on this page?
Generally, reading through the examples helps clarify things.
https://aws.amazon.com/guardduty/pricing/
Pricing examples
CloudTrail management event analysis
In your environment, in one month, GuardDuty processes 40,000,000 CloudTrail management events in the US East (N. Virginia) Region.
Total charges:
40 management events * $4.00 (40 million management events, priced per million)
Total = $160 per month
VPC Flow Log and DNS query log analysis
In your environment, in one month, GuardDuty processes 2,000 GB of VPC Flow Logs and 1,000 GB of DNS query logs, for a total volume of 3,000 GB of logs.
Total charges:
500 GB logs * $1.00 (first 500 GB)
- 2,000 GB logs * $0.50 (next 2,000 GB)
- 500 GB logs * $0.25 (last 500 GB)
Total = $1,625 per month
For the CloudTrail events and VPC flow log entries, it means you are charged for all the event/log data GuardDuty analyses, regardless of whether the data triggers findings. The pricing unit would be "findings" otherwise. Note that if you're using runtime protection, VPC flow log charges are waived for instances with the GuardDuty agent active, because it provides GuardDuty with equivalent visibility into network traffic.
For runtime monitoring, the pricing page https://aws.amazon.com/guardduty/pricing/ answers that at the bottom of the pricing sheet on the Runtime Monitoring tab. Only "active" (=running) instances and container tasks are charged:
vCPUs per month for an instance = (total hours a supported provisioned instance or task being monitored is active) * number of vCPUs on the instance or task / (number of hours in a month)
For Security Hub, the pricing is based on the findings/events ingested, regardless of whether malicious intent is attributed to them.
Hi Leo K, thank you for your answer, it helps me understand more about how GuardDuty, but I still I have some questions lead from your answer.
-
By number of vCPU on the instance or task, it means charge vCPu are active used for task or all of active and non-active vCPU inside each EC2 run or used for task? Like ec2 has 4 vCPUs but only used 2 vCPUs active to run. So AWS charge me for 2 or 4 vCPUs?
-
If GuardDuty collect all logs, so are there any way to manage the logs such as, collect logs followed by some prefix or where can we check logs that GuardDuty collect
-
- When you use your own EC2 instances, either as regular virtual servers or to run ECS container tasks, you're charged for all the vCPUs in those EC2 instances while they're running. For the hours your EC2 instances are powered off, you aren't charged. If you run ECS tasks on Fargate, the EC2 instances aren't yours, and my understanding is that the runtime monitoring charges are based on the vCPU capacity allocated to the tasks running on Fargate. If you're using Fargate and this point is important to you, I advise you to raise support ticket and ask for written confirmation directly from AWS.
- For the standard AWS logs that GuardDuty analyses, such as CloudTrail and VPC flow logs, the logging configuration is done in a completely standard way, behind the scenes, by the GuardDuty service, so there's no way to configure filtering for the logs sent to be analysed. Also, you can't access the raw log data collected by GuardDuty. For example, if you want to access VPC flow logs, you have to pay for the VPC flow logs configured and collected by GuardDuty and pay separately for the VPC flow logs you configure to be sent to your own S3 bucket or CloudWatch log group.
Thank you so much for helping me so far, Leo K. I have 1 last question. Can you estimate how long GuardDuty generate a new findings or duplicate findings but not remediate yet. Same for Security Hub, how long will it get new findings when we demo a the same use case over and over
Most controls in Security Hub are change-triggered (https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-schedule.html), and they mostly detect findings and corrections within a few minutes. Other controls run on a schedule, usually once every 24 hours, so they are that much slower. GuardDuty mostly detects unusual, suspicious events happening, so aside from malware scanning, there's no concept of automatically detecting a finding as remediated or a false alarm, unless you manually classify it as such. A malware scan can return a "clean" result.
Relevant content
- asked 3 years ago
- asked a year ago
Hi iBehr, I understand how GuardDuty charge based on log, events but the thing that I don't know is GuardDuty takes the malicious logs and events that generate the findings or it takes all of them include those are not malicious logs and events. For example, in your last example, GuardDuty processes 2,000GB of VPC Flow logs, so in 2,000GB logs contains all non-malicious and malicious logs or just only malicious logs that GuardDuty filter out when it collects and generate findings for us.
To get the findings, GuardDuty has to constantly process all logs watching for anomalous behavior. As such, you pay for processing of all the logs. In the above example, of the 3000GB of logs could contain 100 findings or zero, but you have to pay for the process of all 3000GB looking for findings.
Hope that helps!
So as for Runtime Monitoring aws charge for each vCPU, so if i used 4 EC2 each of them has 4 vCPUs & have Guardduty agent installed but when run task, they only used total of 7 vCPUs to run. So does AWS charge me for 7 active vCPUs or all 16 vCPUs?
Hi, to know if an event is malicious or not, GuardDuty needs to analyze it (how could he know otherwise ?) Then the pricing is very clear: "all analyzed events are charged"
So it is same case for EC2, ECS right? GuardDuty analyze all vCPUs whether it is used to task or not right?
And do you know how long or the maximum amount of time will GuardDuty generate a findings if a malicious activity occurs.