A Brief Overview on AWS GuardDuty

A Brief Overview on AWS GuardDuty

AWS GuardDuty promises to be the solution for hard to configure security solutions, but comes with a hefty pricetag


4 min read

Since my last article on EDR solutions and Mandiant’s recent acquisition by Google Cloud, many have asked me about AWS GuardDuty. It’s an intelligent threat detection service from AWS, more closer to an IDS since it’s focuses on detection and not prevention. It combines machine learning, anomaly detection, network monitoring, and malicious file discovery, utilizing both AWS-developed and third-party rulesets to help protect workloads and data on AWS.

I can only speak on GuardDuty’s capabilities for the protection of IAM Accounts, EC2/EBS instances, and S3 buckets. I haven’t experimented with protection for EKS systems as it would require me to experiment in more complex cluster environments that i simply do not have access to right now.

Installation Experience

The way to install GuardDuty is relatively painless with just a few clicks, certainly a far cry from the days we needed to setup Snort/Surricata policies via terminals. Even if you have an organization with hundreds of AWS accounts, enabling it wouldn’t take more than 10 minutes via the console.

Currently, GuardDuty detect issues in the following services:

  • IAM (account irregularities, credential exfiltration, etc)
  • S3 (policy evaluations, tor node communications, suspicious data exfil, etc)
  • EC2 (malware/webshell detection, cryptominer detections, recon attempts, etc)
  • EKS (malicious IPs, sensitive container mounters, exposed dashboards, privileged containers, etc)

These services create different types of data sources such as VPC flow logs, DNS query logs, CloudTrail event logs, EBS storage data, kubernetes audit logs, and others. All of these data sources are collected and analyzed by AWS, so no need to explicitly setup data sources like what you might need to do when using third party solutions.

If you are a major company (lets say something along the lines of a major tech startup to a Fortune 500) you probably invested somewhat into AWS Security Hub for Cloud Security Posture Management (CSPM) and the results from GuardDuty are seamlessly integrated to the Security Hub.


Customization is truly one of the main cornerstone of any good security suite, and AWS have some (but admittedly sort of lacking) customization functionality present in GuardDuty.

GuardDuty has the option to whitelist/blacklist certain IPs using trusted IP lists and threat lists. Findings for these lists are generated if the IPs were found in VPC Flow logs and CloudTrail logs.

You can add a trusted IP list to whitelist some addresses from GuardDuty alerts being generated by irregular services being run in your systems, for example network scanners that run on EC2 instances or control servers for tools such as Threatmapper who constantly beam telemetry data from kubernetes clusters. But you can have only one trusted IP list per AWS account per region.

Threat lists are the exact opposite of a trusted IP list. These lists contain IP addresses of threat actors, malware CNC servers, and more. If there’s any communication to these IPs, a finding gets generated. This is handy if there is an urgent major threat actor you need to monitor for, but hasn’t been covered on some IP blocklists provided by AWS. You can add up to 6 threat lists per AWS account per region, with the ability to integrate great threatlists coming from sources such as Proofpoint’s Emerging Threat Rules.

What i would like to see is several more options for customizability like DNS-based threat lists to circumvent rogue DNS servers, S3 protection for specific subset of buckets, and the ability to reset the baseline for GuardDuty’s proprietary machine learning models.

But Unfortunately, It’s not Magic

Its detection capabilities are great, but no automated security suite is pure magic as there are many publically documented cases of people being able to circumvent GuardDuty detection

Pricing & Conclusion

GuardDuty is an amazing service that automatically detects a plethora of threats that AWS products face in production environments. It’s very easy to setup for even large organizations with multiple complex infrastructure deployments and IAM accounts and it also seamlessly integrates into many AWS products and services.

It does have some issues especially the ones i’ve outlined regarding customizability, but another that i haven’t mentioned is pricing since like all SaaS SIEM/Observability tools they charge you proportionally to the number of logs they generate. This can easily be an issue if you want to deploy GuardDuty on systems that generate alot of data such as S3 buckets that are used for data warehousing needs which will increase the amount of S3 log events generated.

The way i see it is that to deploy GuardDuty you need to really try to cull your expenses by trying to disable S3 protection that doesn’t contain production data. For log intensive applications such as data lakes, consider just enacting stronger S3 data control policies instead of using GuardDuty for active monitoring.

As with all cloud products, it’s an ecosystem that you need to manage wisely or else you will see costs balooning to the heavens.