AWS GuardDuty Alerts: A Complete Guide for 2025

If you run a business on AWS, aws guard duty alerts are one of the most practical security tools you can activate today — and most small business owners haven’t set them up properly. Cloud threats are not slowing down. According to the Cybersecurity and Infrastructure Security Agency (CISA), cloud-targeting attacks have grown sharply in recent years, and small businesses are frequently the path of least resistance for bad actors.

The good news: AWS GuardDuty does a lot of the heavy lifting for you. It monitors your AWS environment around the clock, flags suspicious behavior, and plugs into automation tools so your team can respond fast — without needing a dedicated security operations center.

This guide breaks down everything you need to know as a small business owner: how GuardDuty findings work, how to cut through alert noise, how to automate responses, and how to avoid the most common setup mistakes. By the end, you’ll have a clear action plan to protect your AWS environment in 2025.

What Is AWS GuardDuty?

Amazon GuardDuty is a fully managed, serverless threat detection service built directly into AWS. You don’t install software, configure servers, or maintain infrastructure. You turn it on, and it starts watching.

GuardDuty uses a combination of machine learning, anomaly detection, and threat intelligence feeds — including known malicious IP addresses, suspicious domains, and dangerous file hashes — to spot problems before they become disasters. It’s constantly learning what “normal” looks like in your environment so it can flag what isn’t.

When you enable GuardDuty, it automatically starts pulling data from three foundational sources:

• AWS CloudTrail management events — tracks API calls and account activity
• VPC Flow Logs — records network traffic in and out of your EC2 instances
• DNS logs — captures domain lookup requests made within your environment

No extra configuration required. GuardDuty ingests all three immediately. It scales across your entire AWS footprint — EC2 instances, S3 buckets, IAM users and roles, Aurora databases, Lambda functions — and automatically discovers new resources as you add them. For a small business, that means comprehensive coverage without the complexity of traditional security tooling.

Understanding GuardDuty Findings and Severity Levels

When GuardDuty detects something suspicious, it generates a security finding. Think of a finding as a detailed security report: it includes a unique ID, the affected resource, the type of threat detected, and a severity rating to help you prioritize your response.

Severity levels fall into four categories:

• Critical — immediate action required
• High — serious threat that warrants prompt investigation
• Medium — potential issue worth reviewing soon
• Low — minor or informational; monitor but don’t panic

One of GuardDuty’s most practical features is that findings are dynamic. If new suspicious activity ties back to an existing finding, GuardDuty updates that finding rather than generating a brand-new alert. That design choice alone significantly reduces alert fatigue — a real problem when you’re a small team juggling multiple responsibilities.

Common aws guard duty alerts you’ll encounter include:

• Compromised IAM credentials — an IAM user accessing resources from an unusual geographic location
• Reconnaissance activity — port scanning from external sources probing your environment
• Crypto-mining — unauthorized use of your compute resources to mine cryptocurrency
• S3 data exfiltration — unusual bulk downloads from your S3 buckets
• Malware — malicious files or behavior detected in your workloads

GuardDuty also includes Extended Threat Detection at no additional cost. Instead of evaluating each event in isolation, it correlates sequences of events across your foundational data sources to identify multi-step attack patterns. A single unusual API call might look harmless. That same call, followed by a permissions change and an unusual data transfer, tells a very different story.

GuardDuty Protection Plans and Coverage Options

Out of the box, GuardDuty covers your foundational AWS activity through CloudTrail, VPC Flow Logs, and DNS logs. That’s a solid baseline. But if your business runs serverless functions, stores sensitive data in S3, or uses containers, you’ll want to look at the optional protection plans.

Here’s what’s available:

• Malware Protection for S3 — scans objects uploaded to S3 for malicious content; can be enabled independently without the full GuardDuty suite
• Lambda Protection — monitors network activity from Lambda functions to catch crypto-mining or communication with malicious command-and-control servers
• Runtime Monitoring — watches OS-level events, file activity, and network behavior inside EKS clusters and EC2 instances
• ECS and EKS Protection — purpose-built coverage for container workloads, which are increasingly targeted in cloud-native attacks

Each protection plan is enabled per AWS Region, which means you can activate exactly what you need based on where your workloads actually run. There’s no requirement to enable everything everywhere.

For most small businesses, the right starting point is enabling Malware Protection for S3 if you accept file uploads from users, and Lambda Protection if serverless functions are part of your architecture. If you’re running Kubernetes on EKS, Runtime Monitoring and EKS Protection belong on your list too.

Managing Alert Volume and Reducing Noise

Here’s the honest truth about aws guard duty alerts: if you don’t tune them, you’ll get overwhelmed. A busy AWS environment can generate a lot of findings, not all of which deserve your immediate attention. Managing that volume intelligently is what separates teams that act on alerts from teams that start ignoring them.

The primary tool for noise reduction is suppression rules. These let you tell GuardDuty to automatically filter out findings that match criteria you define. For example, if your development team runs automated penetration tests weekly, you can suppress findings generated by that known activity so they don’t flood your queue.

Entity lists give you another layer of control:

• Trusted IP lists — whitelists for known-safe sources like your office VPN or a third-party monitoring tool, so GuardDuty doesn’t flag their activity
• Threat IP lists — custom lists of malicious IP addresses or command-and-control domains specific to your industry or threat profile, triggering immediate alerts when contacted

You can manage entity lists through the AWS console, the API, or Infrastructure as Code (IaC) tools like Terraform or CloudFormation. Using IaC is the right call for consistency — it ensures your suppression rules and trusted lists are version-controlled, reproducible, and applied uniformly across Regions.

Beyond suppression, route findings by severity and type to the right people. Critical findings should page your on-call person immediately. Low-severity findings can go into a weekly review digest. Building that routing logic upfront saves hours of manual triage later.

For more on managing AWS costs and services efficiently, see our guide on AWS cost optimization for small businesses.

Automating GuardDuty Alert Responses with EventBridge

Manual review of every aws guard duty alert isn’t realistic for a small team. Automation is where GuardDuty goes from useful to genuinely powerful. The key integration is Amazon EventBridge, AWS’s event routing service.

By default, GuardDuty publishes findings to EventBridge every 6 hours. You can adjust that frequency:

• Every 6 hours — default; fine for low-severity review workflows
• Every 1 hour — good for active monitoring environments
• Every 15 minutes — recommended for high-severity findings that need fast response

Once findings hit EventBridge, you have options. The most common setup for small teams is a two-step email workflow: create an EventBridge rule that filters findings by severity, route those findings to an SNS (Simple Notification Service) topic, and configure that topic to send emails to your team’s security alias. Critical findings go to the on-call person. Medium findings go to a shared inbox for weekly review.

You can also route findings to webhooks that connect to tools your team already uses — Slack, PagerDuty, or your ticketing system. Amazon EventBridge’s official documentation covers the supported targets and integration patterns in detail.

For more advanced setups, EventBridge can trigger remediation workflows directly. A High-severity finding about a compromised IAM credential can automatically trigger a Lambda function that revokes that credential’s active sessions and notifies your team — all without anyone touching a keyboard. That kind of automation dramatically reduces your mean time to respond (MTTR).

If you’re running multiple AWS accounts — which many growing businesses do — use AWS Organizations with a designated administrator account. That account aggregates findings from all member accounts into a single pane of glass, making centralized monitoring practical even without a dedicated security team. No account gets left unmonitored, and alert triage stays manageable.

How to Set Up and Customize GuardDuty for Your Business

Getting GuardDuty working well for your business takes less time than you’d expect. Here’s the practical sequence:

1. Enable GuardDuty in all AWS Regions. Go to the GuardDuty console and activate it in every Region where you have resources. If you use AWS Organizations, your administrator account can enable it across all accounts and Regions from a single location. Don’t skip Regions — attackers will target unmonitored areas first.
2. Activate the protection plans relevant to your workloads. Run through your architecture and match it to the available plans. Using S3 for file uploads? Enable Malware Protection. Running Lambda functions? Enable Lambda Protection. Containers on EKS? Enable Runtime Monitoring and EKS Protection. There’s no need to enable everything — just what applies to your environment.
3. Configure EventBridge rules and SNS topics. Set up at least one EventBridge rule that catches Critical and High findings and routes them to an SNS topic connected to your team’s email or messaging tool. Adjust the publishing frequency to 15 minutes for those severity levels. This is the step most small businesses skip — and the one that makes everything else actually useful.
4. Set suppression rules and entity lists, then test. Add your office IP ranges and VPN addresses to your trusted IP list. Create suppression rules for known-safe activity. Then use GuardDuty’s built-in sample findings feature to generate test alerts and walk through your workflow. This is how you find gaps before a real incident does.

AWS offers a 30-day free trial so you can evaluate GuardDuty in your actual environment before committing. Use that window to run sample findings, tune your suppression rules, and make sure your notification pipeline works end to end.

If you’re building out a broader cloud security posture, check out our overview of cloud security basics for small business owners.

Common Mistakes to Avoid with GuardDuty Alerts

Most GuardDuty problems aren’t technical — they’re setup and configuration issues. Here are the four mistakes small businesses make most often, and how to fix them.

Mistake 1: Enabling GuardDuty in only one Region. GuardDuty is Region-specific. If you enable it only in us-east-1 but run workloads in eu-west-1, those workloads are completely unmonitored. The fix is using AWS Organizations to push GuardDuty across all Regions from your administrator account in a single operation.

Mistake 2: Ignoring alert fatigue from default settings. Default GuardDuty settings generate a lot of findings, and teams that don’t tune them quickly start ignoring everything — including the findings that actually matter. Set up suppression rules and severity-based routing within the first week of enablement. Treat alert management as part of the setup, not an afterthought.

Mistake 3: Skipping protection plans for Lambda and Runtime Monitoring. The foundational data sources cover a lot, but they don’t cover everything. If your architecture includes Lambda functions or containerized workloads — which most modern small business AWS environments do — those protection plans fill critical gaps. Enable them based on what you actually run, not what you think you might run someday.

Mistake 4: Never testing your findings workflow. A lot of teams set up GuardDuty and assume it’s working. Then a real incident happens and they discover their SNS topic was misconfigured, the emails went to a dead inbox, or nobody knew what the findings meant. Use the sample findings feature regularly. Run a fire drill. Make sure your team knows what a real alert looks like and what to do with it.

The NIST Cybersecurity Framework recommends regular testing of detection and response capabilities as a core practice — GuardDuty’s sample findings feature makes that easy to do without waiting for a real threat.

Start Monitoring Before You Need To

The biggest mistake small businesses make with cloud security is waiting until something goes wrong. By then, the damage is done — whether that’s a compromised customer database, unauthorized compute charges from crypto-mining, or exposed credentials used for a broader attack.

AWS GuardDuty alerts give you a proactive defense layer that doesn’t require a security team to operate. Set it up correctly, tune it to your environment, plug it into EventBridge for automated notifications, and test your workflow regularly. That combination puts you miles ahead