You deployed your first real production app to AWS last month.
It's running. Users are happy.
And then someone on the security team slacks you: "Hey, we're seeing some weird API calls from your account. You spinning up instances in regions you don't use?"
You weren't.
That's the moment most of us first hear about GuardDuty.
Why does this even exist?
Let's go back to around 2013-2014.
AWS was growing fast. More companies were moving real workloads to the cloud. And attackers noticed.
Here's what was happening: someone would steal AWS credentials, maybe from a leaked GitHub repo or a phishing attack. They'd quietly spin up hundreds of EC2 instances to mine cryptocurrency. Or exfiltrate data from S3 buckets. Or scan for vulnerabilities across entire VPCs.
Companies wouldn't notice for days. Sometimes weeks.
Because here's the thing, AWS gives you logs. CloudTrail logs every API call. VPC Flow Logs show network traffic. DNS logs capture queries.
But nobody was actually watching them in real time!!!
Security teams were drowning in log files. Trying to spot malicious patterns manually was like finding a needle in a haystack the size of a data center.
AWS needed a service that would just... watch. Constantly. And yell when something looked wrong.
That's why GuardDuty launched in 2017.
So what actually is it?
GuardDuty is a threat detection service.
It continuously monitors your AWS account for malicious or unauthorized behavior. Think of it as a security camera that never sleeps and actually knows what suspicious looks like.
It analyzes three main data sources automatically:
VPC Flow Logs (your network traffic), CloudTrail events (API calls and management actions), and DNS logs (what your resources are communicating with).
You don't send GuardDuty these logs. It accesses them directly. You just turn it on.
What does it actually catch?
Here's where it gets practical.
GuardDuty looks for patterns that indicate real attacks. Not just theoretical vulnerabilities, but actual "someone is doing something bad right now" situations.
Common things it detects:
Compromised EC2 instances. Like when your instance starts communicating with known malware command-and-control servers. Or when it's suddenly being used for cryptocurrency mining.
Stolen credentials. If someone's using your IAM credentials from an unusual location or making API calls they've never made before, GuardDuty notices.
Reconnaissance activity. When attackers are probing your infrastructure, port scanning, or trying to map your network.
Data exfiltration attempts. Unusual data transfers or access patterns that look like someone's trying to steal information.
The findings show up in your AWS console with a severity level: Low, Medium, or High.
Each finding explains what happened, which resources are involved, and suggests what to do about it.
When do people actually use this?
Honestly? Most teams turn it on and forget about it.
That's kind of the point.
If you're running anything in production, you should probably have GuardDuty enabled. It's not something you "use" actively like you'd use CloudFormation or Lambda.
You enable it. Set up alerts (usually SNS to Slack or PagerDuty). And then it just runs in the background.
The real question is what you do when it alerts you.
The cost thing nobody talks about upfront
GuardDuty isn't free.
It charges based on the volume of events it analyzes. CloudTrail events, VPC Flow Logs volume, DNS queries.
For a small account, you might pay $5-20 a month. For larger production environments with lots of traffic, it can be hundreds.
There's a 30-day free trial though. Most people start there to see what the actual cost looks like for their usage.
Setting it up is weirdly simple
You literally just enable it in the console.
No agents to install. No log shipping to configure. No complex rules to write.
Go to the GuardDuty section in AWS Console, click "Get Started," click "Enable GuardDuty."
That's it.
Within minutes it starts analyzing your account activity. Findings appear in the console as they're detected.
If you want to get fancy, you can set up automated responses using EventBridge. Like automatically isolating a compromised instance or revoking suspicious credentials.
But honestly? Start simple. Enable it, hook up an SNS topic for alerts, and learn what normal findings look like for your environment.
The multi-account reality
Here's something that confused me early on.
If you're using AWS Organizations (and most companies are), GuardDuty works across all your accounts. You designate one account as the GuardDuty administrator, and it can monitor findings from all member accounts.
This is huge for companies with dozens or hundreds of AWS accounts.
You don't want your security team checking GuardDuty in 50 different accounts. Centralized monitoring makes way more sense.
What it doesn't do
GuardDuty won't prevent attacks.
It detects them. Big difference.
It's not a firewall. It's not blocking malicious traffic. It's not automatically remediating issues.
It's telling you "hey, this thing that just happened looks really suspicious."
What you do about it is up to you.
That's why most teams pair GuardDuty with other services. Security Hub for centralized security management. Systems Manager for automated remediation. WAF for actual blocking at the application layer.
GuardDuty is one piece of your security setup, not the entire thing.
The findings you'll actually see
When you first enable GuardDuty, you might see findings immediately. Or you might see nothing for weeks.
Common early findings that freak people out but are usually fine:
"UnauthorizedAccess:EC2/SSHBruteForce" - Someone's trying to brute force SSH on your instances. If they're internet-facing, this happens constantly. Make sure you're using key-based auth and maybe restrict IPs.
"Recon:EC2/PortProbeUnprotectedPort" - Someone's scanning your ports. Again, super common if you have public IPs. Review your security groups.
The scary findings are the High severity ones about compromised credentials or instances communicating with known malicious IPs. Those need immediate attention.
Learning what's normal for your environment
Here's something they don't tell you in the docs.
Every AWS environment has its own "normal."
You'll get findings that are false positives for your use case. Maybe you have a legitimate reason to access AWS from multiple countries. Maybe your application does unusual API call patterns.
You can suppress findings that aren't relevant. Or adjust your alerting so you're not getting paged for Low severity findings at 3am.
This tuning process takes a few weeks usually. Don't expect perfect signal-to-noise on day one.
Why you should probably just turn it on
Look, I get it. Another AWS service. Another thing to monitor. Another bill.
But here's the reality: if someone compromises your AWS account and you don't catch it quickly, the cost of that incident will make GuardDuty's monthly fee look like pocket change.
Plus, if you're working at a company with any kind of compliance requirements (SOC 2, HIPAA, PCI), having GuardDuty enabled is basically table stakes. Auditors love seeing it.
Even if you're a solo developer running a side project, the free tier gives you a month to see what it catches. You might be surprised.
Enable it in one account. See what findings you get. Learn what they mean.
You don't need to become a security expert overnight. Just having visibility into what's happening in your AWS account is already a huge step forward from where most teams were a few years ago.
And who knows, maybe you'll catch something weird before it becomes a real problem. That's kinda the whole point, right?
Top comments (0)