Configure AWS GuardDuty for Threat Detection and Automated Response
Imagine getting a GuardDuty alert about a critical incident at 3 AM. Without proper setup, it's likely a false positive. But if it's a real attack, every hour of downtime costs significant money, and a data breach could lead to multi-million-dollar losses. Without correct configuration, you risk missing a critical attack or drowning in false positives. We configure GuardDuty so you see only real threats, with automated response blocking attacks in minutes. We've done hundreds of projects—from startups to enterprises with dozens of accounts. After our setup, false positives drop by 90%. We document every step and train your team. With 5 years in the market, our AWS security expertise speaks for itself.
Why GuardDuty Needs Proper Configuration
GuardDuty can be enabled in three clicks in the console, but without proper configuration, it's useless. You need to:
- specify which data to analyze (CloudTrail, VPC Flow Logs, DNS, S3 logs);
- set up multi-account via Organizations to avoid manual per-account activation;
- define alert channels (Slack, PagerDuty, Telegram) and create severity filters;
- write suppression rules for trusted sources—pen test servers, scanners, legitimate scripts.
Without these steps, you risk missing an attack or being overwhelmed by false positives. One missed incident could lead to recovery costs far exceeding reasonable limits. In our practice, a startup with 5 accounts received over 3,000 alerts in a month, of which only 15 were real—the rest was noise from security scanners. After configuring suppression rules and severity filtering, false positives dropped to 5%.
How GuardDuty Analyzes Data: Sources and Severity
GuardDuty analyzes three data layers and produces findings in three categories.
Compromised Credentials
-
UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B— successful login from an anomalous IP or unusual geolocation. -
Recon:IAMUser/MaliciousIPCaller— attempts to enumerate IAM resources from TOR IPs or known attacking networks.
Compromised Instances
-
Backdoor:EC2/C&CActivity.B— EC2 communicating with C2 infrastructure. -
CryptoCurrency:EC2/BitcoinTool.B!DNS— DNS queries to mining pools (classic after web vulnerability compromise).
Data Anomalies
-
Exfiltration:S3/AnomalousBehavior— sudden large data download from S3 in a short period.
| Severity | Range | Example | Action |
|---|---|---|---|
| Low | 1–3.9 | PortProbe | Ignore or archive |
| Medium | 4–6.9 | MaliciousIPCaller | Manual analysis |
| High | 7–8.9 | C&CActivity | Automatic block (WAF/SG) |
| Critical | 9–10 | ConsoleLoginSuccess | Immediate alert via PagerDuty |
How to Automate Incident Response with EventBridge
GuardDuty sends findings to EventBridge. From there, to SNS, Lambda, SQS. A minimal alert setup:
resource "aws_cloudwatch_event_rule" "guardduty_high" {
name = "guardduty-high-severity"
description = "GuardDuty findings severity >= 7"
event_pattern = jsonencode({
source = ["aws.guardduty"]
detail-type = ["GuardDuty Finding"]
detail = {
severity = [{
numeric = [">=", 7]
}]
}
})
}
resource "aws_cloudwatch_event_target" "sns" {
rule = aws_cloudwatch_event_rule.guardduty_high.name
target_id = "SendToSNS"
arn = aws_sns_topic.security_alerts.arn
}Severity in GuardDuty: Low (1–3.9), Medium (4–6.9), High (7–8.9), Critical (9–10). For automatic IP blocking in WAF or Security Group, react to High and above. Medium goes into a queue for manual analysis.
Economic Impact of Deployment
GuardDuty is one of the most cost-effective security tools. The average cost for a company with 10 accounts is low, and preventing a single incident can save hundreds of thousands of dollars. According to AWS, deployment typically pays for itself within a few months. In our practice, clients report significantly reduced incident investigation costs.
5-Step Setup Process
- Audit current logs and security configuration.
- Enable detector with required data sources (S3, Kubernetes, Malware Protection).
- Connect multi-account via AWS Organizations with a delegated administrator.
- Create EventBridge rules for alerts (Slack, PagerDuty, Telegram).
- Write suppression rules for trusted IPs and standard scanners.
Each step includes Terraform code and documentation. Average deployment time: 2 days. The result is a working system with automated response and a clear action plan for each incident type.
What's Included in the Work
| Documentation | Access Control | Training | Support |
|---|---|---|---|
| Infrastructure Terraform code, incident runbook | IAM roles, Service Control Policies for member accounts | Webinar for your team on handling findings | 2 weeks post-release support |
How to test GuardDuty operation?
To verify, use the sample findings generator: aws guardduty create-sample-findings --detector-id .... This creates fake findings of all types and severities. Ensure alerts reach the right channels and suppression rules correctly archive known events.
Terraform Multi-Account Configuration
In AWS Organizations, it's best to configure GuardDuty centrally. One account (Security or Audit) becomes the delegated administrator and collects findings from all member accounts.
# In management account
resource "aws_guardduty_organization_admin_account" "main" {
admin_account_id = var.security_account_id
}
# In security account
resource "aws_guardduty_detector" "main" {
enable = true
datasources {
s3_logs {
enable = true
}
kubernetes {
audit_logs {
enable = true
}
}
malware_protection {
scan_ec2_instance_with_findings {
ebs_volumes {
enable = true
}
}
}
}
}
resource "aws_guardduty_organization_configuration" "main" {
auto_enable_organization_members = "ALL"
detector_id = aws_guardduty_detector.main.id
}auto_enable_organization_members = "ALL" automatically enables GuardDuty for new accounts. Otherwise, each account must be enabled manually.
Suppression Rules: How to Eliminate Noise
After enabling GuardDuty, expect noise the first few weeks. A typical example: internal penetration testing generates Recon:EC2/PortProbeUnprotectedPort. For known sources, create a suppression rule:
resource "aws_guardduty_filter" "pentest_suppression" {
detector_id = aws_guardduty_detector.main.id
name = "suppress-internal-pentest"
action = "ARCHIVE"
rank = 1
finding_criteria {
criterion {
field = "service.action.networkConnectionAction.remoteIpDetails.ipAddressV4"
equals = ["10.0.1.50"] # IP of pentest server
}
}
}Suppression does not delete findings—they are archived. The full history is retained for auditing.
To set up optimal suppression rules for your infrastructure, contact us—we'll analyze your logs and propose ready-made rules. Get a consultation on implementing GuardDuty for your project.







