If you have GuardDuty enabled on your AWS accounts, you probably feel like you’ve checked the security box. You’re not alone. AWS sells it as a threat detection service, the messaging is aggressive, and the pricing is low.
But here’s the reality: GuardDuty is a detector, not a security operations center. And there’s a massive difference.
What GuardDuty Actually Does
GuardDuty monitors three AWS data sources:
- CloudTrail logs — API activity across your AWS accounts
- VPC Flow Logs — network traffic between instances and resources
- DNS logs — queries your instances make to Route53
It runs these logs through threat intelligence feeds and machine learning models to flag suspicious activity: unusual API calls, known malicious IPs, anomalous data access patterns. When it finds a match, it generates a finding and ships it to your CloudWatch Events queue.
That’s it. It’s good at what it does. But “what it does” is very narrow.
What GuardDuty Misses
1. No Event Correlation
GuardDuty fires on individual suspicious events. It doesn’t ask: “Did this same user make 10 failed login attempts before the successful one?” or “Did this API call happen seconds after a privilege escalation?”
Real security investigations are built on chains of events. A single API call might be innocent. But that API call after an IAM policy modification after three failed console logins? That’s a story.
GuardDuty doesn’t tell stories. It flags data points.
2. No Behavioral Baseline
GuardDuty has global threat intelligence and ML, but it doesn’t know your baseline. It doesn’t know that your CI/CD pipeline normally makes 50,000 API calls per hour, or that your data team usually queries the same S3 buckets at the same time each day.
When your backup job runs at 3 AM and calls ListBuckets 10,000 times, GuardDuty might spike an alert. When a human does the same thing, it might miss it.
A SOC builds per-customer, per-workload baselines. GuardDuty can’t.
3. No Cross-Account Visibility
GuardDuty must be enabled in every account. It doesn’t correlate findings across accounts. So when an attacker pivots from your dev environment to prod by assuming a cross-account role, GuardDuty fires two separate findings in two separate places. You have to manually connect them.
4. No Context from Outside AWS
GuardDuty is blind to:
- Identity events — Okta logins, failed MFA challenges, unusual login locations
- Application logs — errors in your code, suspicious API calls to your backend
- Infrastructure logs — SSH attempts, Kubernetes API calls, database queries
- Email security — phishing attempts, lateral movement via email forwarding
An attacker doesn’t only attack AWS. They attack everywhere. GuardDuty sees one angle.
5. No Investigation Workflow
GuardDuty findings land in your inbox. What do you do with them?
- Click the finding → see the raw CloudTrail event
- Read the description → probably written for an AWS console, not operators
- Search your logs manually → if you have a log aggregator
- Contact your team → who is on call?
A real SOC has a triage workflow: parse the alert, enrich it with context from other data sources, route it to the right team, track the investigation, build a runbook.
GuardDuty requires you to build all of that yourself.
Real Examples of What GuardDuty Misses
Scenario: Account takeover via STS assume role
An attacker gains credentials for a junior engineer’s IAM user. They assume a cross-account role to your production account and create an access key.
- GuardDuty might flag the assume role if it’s from an unusual IP
- But if the assume role comes from your office (same IP as the engineer’s normal activity)? Silent.
- The access key creation? Might be flagged as unusual API activity, or it might blend into your normal provisioning.
- By the time GuardDuty fires, the attacker has already exfiltrated data.
Scenario: Okta + AWS account takeover
An attacker uses credential-stuffing to break into your Okta tenant. They don’t touch AWS for a week—they just enumerate your org, find your AWS SSO integration, and wait.
GuardDuty has no idea. It never sees the Okta compromise. When the attacker finally uses AWS (with a legitimate Okta session), GuardDuty sees nothing unusual.
Scenario: Exfiltration via your own infrastructure
Your attacker gains access to an EC2 instance in your public subnet. They use it to tunnel traffic and exfiltrate data from an RDS instance that lives in your private subnet. All traffic is internal. All IPs are yours. GuardDuty sees a private IP talking to your database at 2 AM, but if your backup jobs do the same thing, this is noisy or missed entirely.
Meanwhile, your app logs show a spike in database queries from a connection string that doesn’t match any known app. GuardDuty has no idea these two events are connected.
What a SOC Actually Does
A SOC (or a SOC-as-a-Service platform) ingests all your logs:
- AWS (CloudTrail, VPC Flow, GuardDuty findings)
- Identity (Okta, Azure AD events)
- Applications and infrastructure
- Email, DNS, proxies, endpoints
Then it:
- Correlates events across sources using MITRE ATT&CK chains and custom rules
- Builds baselines per-customer, per-service, per-time-window
- Enriches findings with threat intel, asset inventory, user profiles
- Routes alerts to the right team with full context
- Tracks investigations with audit trails and runbooks
- Hunts for advanced techniques that single data sources won’t catch (living-off-the-land techniques, dormant access, lateral movement)
GuardDuty is the input. A SOC is the output.
The Cost of Confusion
Every week, we talk to companies that think GuardDuty is their security operations. They have no idea they’re exposed to:
- Account takeovers that happen outside of AWS
- Insider threats (no baseline = no anomaly detection)
- Ransomware campaigns that move slowly (no correlation = no narrative)
- Compliance violations (no audit trail = no proof of monitoring)
And when something bad happens, they’re shocked. “But we have GuardDuty.”
What You Actually Need
If you’re an AWS shop with sensitive data or compliance requirements, you need:
- All your logs in one place (CloudTrail, VPC Flow, Okta, application logs, infrastructure logs)
- A detection layer that correlates across sources (not just flags individual events)
- A response workflow that routes alerts to humans, tracks investigations, and scales with your team
- Behavioral analytics so you catch the attacks that break the rules
GuardDuty is part of that stack. But it’s not the whole stack.
If you’re running a startup or SMB and can’t hire a security team, you need a managed SIEM that does this for you. If you’re mid-market, you need tooling that scales with your organization.
Either way, GuardDuty alone is not enough.
Ready to move beyond GuardDuty? Book a discovery call and we’ll show you what your logs actually contain.