Cloud Threat Detection with GuardDuty

Introduction

30 Second Summary

Every company running applications in the cloud needs to know the moment something suspicious happens. Think of it like a security camera system, but instead of watching doors and windows, it watches API calls, network traffic, and user behavior.

In this project, you will build a threat detection pipeline using AWS that automatically detects simulated attacks and emails you an alert. This is the same pattern that enterprise Cloud Native Application Protection Platforms use to protect cloud environments at scale.

What You'll Build

A cloud-native security operations pipeline that monitors your AWS environment for threats and routes real-time alerts to your email.

By the end of this project, you'll have:

• A live GuardDuty detector analyzing your AWS environment for threats like credential compromise and network reconnaissance.
• An automated alerting pipeline using EventBridge and SNS that emails you when threats are detected.
• A custom IAM policy demonstrating zero trust least-privilege access control.
• Secret Mission: create severity-filtered smart alerts that only fire on high-priority threats, reducing alert fatigue.

Are there any prerequisites?

No prior AWS experience is needed. This guide walks you through creating a new AWS account from scratch. All you need is a web browser and an email address.

Create Your AWS Account and Enable GuardDuty

Every security pipeline starts with visibility. Before you can detect threats in a cloud environment, you need a monitoring system that watches your account around the clock.

In this step, you'll create an AWS account and enable GuardDuty, AWS's threat detection service. GuardDuty automatically analyzes log data from multiple sources to identify suspicious activity.

In this step, get ready to:

• Create a new AWS account with the Free tier.
• Enable GuardDuty and start your 30-day free trial.
• Confirm your detector is active and note your Detector ID.

Create your AWS account

You need an AWS account to access GuardDuty and the other services in this project. The Free tier gives you everything you need at no cost.

• Open https://aws.amazon.com/ in your browser.
• Click Create an AWS Account.
• Enter your email address, choose a password, and provide your account information.
• When prompted to choose an account plan, select Free.
• Complete the sign-up process including phone verification and payment method.

Why do I need a payment method?

AWS requires a valid payment method to verify your identity and prevent abuse. You will not be charged while on the Free plan unless you upgrade to a Paid plan.

• Wait for the activation email from AWS. This usually takes a few minutes but can take up to 24 hours.
• Once activated, sign into the AWS Management Console.
• Check your region in the top-right corner of the console. If it does not show US East (N. Virginia), click the region dropdown and select US East (N. Virginia). Use us-east-1 as your region for all work in this project.

Haven't received the activation email?

Check your spam or junk folder. Activation usually takes only a few minutes, but occasionally takes longer. You can sign into the console while waiting, but AWS services won't be available until activation completes.

Still stuck? Help me troubleshoot my AWS account activation.

Enable GuardDuty

GuardDuty is AWS's threat detection service. Once enabled, it continuously monitors CloudTrail management events, VPC Flow Logs, and DNS logs for malicious activity in your account.

• In the AWS Management Console, type GuardDuty in the search bar at the top.
• Select GuardDuty from the search results.
• Choose Get Started.
• Choose Enable GuardDuty.

What is GuardDuty?

GuardDuty is a managed threat detection service that watches your AWS environment for suspicious activity. It analyzes data from CloudTrail (API call logs), VPC Flow Logs (network traffic), and DNS query logs to identify potential threats.

This is the same type of detection engine that CNAPP platforms like Wiz and Prisma Cloud integrate with. Understanding how it works from the inside gives you credibility when discussing cloud security.

30-day free trial

New accounts get a 30-day free trial for GuardDuty. You won't be charged during the trial period. You'll disable GuardDuty in the Before You Go section at the end of this project.

Confirm GuardDuty is active

Now verify that your detector is running and note your Detector ID for later steps.

• In the GuardDuty console, click Settings in the left navigation pane.
• Locate your Detector ID on the Settings page. This is a 32-character alphanumeric string unique to your account in this region.
• Confirm the status shows as Enabled.
• Copy your Detector ID and save it somewhere accessible. You will reference it later.

What is a Detector ID?

A Detector ID is a unique identifier that GuardDuty assigns to your account in a specific region. All findings, API operations, and configurations reference this ID. Think of it as your account's security monitoring address for that region.

Don't see an Enabled status?

Make sure you're in the us-east-1 region. GuardDuty is a regional service, so you must be in the same region where you enabled it. Check the region dropdown in the top-right corner of the console.

Need help? My GuardDuty status is not showing as Enabled after following the steps.

Your threat detection engine is live. Next up, you'll generate simulated attack findings and investigate them like a security analyst.

Generate and Investigate Threat Findings

Your GuardDuty detector is live and monitoring your AWS environment. Now you need to understand what it actually detects.

In this step, you'll generate simulated attack findings and investigate them like a security analyst. These are the exact finding types that CNAPP platforms surface to customers every day.

In this step, get ready to:

• Generate sample threat findings that simulate real-world attacks.
• Explore the findings list and examine high-severity alerts.
• Investigate three specific finding types relevant to CNAPP interviews.

Generate sample findings

GuardDuty can create one sample finding for every finding type it supports. These simulate attacks like SSH brute-force, cryptocurrency mining, IAM credential exfiltration, and data access from Tor exit nodes.

• In the GuardDuty console, click Settings in the left navigation pane.
• Scroll down to the Sample findings section.
• Click Generate sample findings.

What did this just do?

GuardDuty created dozens of simulated findings across all its supported detection categories. These findings are prefixed with [SAMPLE] so you can distinguish them from real threats.

No actual attack happened in your account. GuardDuty is simply showing you what each type of threat looks like when detected.

Explore the findings list

• Click Findings in the left navigation pane.
• You will see dozens of findings prefixed with [SAMPLE].
• Click the Severity column header to sort findings with High severity first.
• Click on a High-severity finding like [SAMPLE] UnauthorizedAccess:EC2/TorClient to open the details panel.

What should I see in the details panel?

Every GuardDuty finding has a consistent structure that tells you the full story of a potential attack:

• Resource affected tells you which EC2 instance, S3 bucket, or IAM principal is involved.
• Action describes what the suspicious activity was (API call, network connection, DNS query).
• Actor identifies who or what triggered the finding (IP address, IAM user, AWS account).
• Severity score rates the risk from 1.0 (Low) to 8.9 (High).

Not seeing any findings?

Sample findings can take a minute or two to appear after generation. Try refreshing the page by clicking Findings in the left navigation again.

If the Findings page is still empty, return to Settings and click Generate sample findings one more time.

Still stuck? Ask for help.

Investigate three critical finding types

These three finding types represent the exact categories of cloud misconfigurations that CNAPP platforms detect and alert on. Understanding them gives you concrete interview examples.

• In your findings list, search for or scroll to find [SAMPLE] UnauthorizedAccess:IAMUser/MaliciousIPCaller.
• Click on it to open the details panel.
• Note: What resource is affected? What is the attack vector? What would remediation look like?
• Repeat this investigation for [SAMPLE] Recon:EC2/PortProbeUnprotectedPort.
• Repeat once more for [SAMPLE] Policy:S3/BucketPublicAccessGranted.

What do these three findings mean?

UnauthorizedAccess:IAMUser/MaliciousIPCaller means an IAM credential was used from a known malicious IP address. This indicates credential compromise. Remediation: rotate the affected access keys and tighten the IAM policy.

Recon:EC2/PortProbeUnprotectedPort means an EC2 instance has an unprotected port being probed by an external actor. This indicates a network misconfiguration. Remediation: restrict the security group to allow only necessary traffic.

Policy:S3/BucketPublicAccessGranted means an S3 bucket was made publicly accessible. This is a data exposure risk. Remediation: enable S3 Block Public Access and review bucket policies.

Why do these matter for your CNAPP interview?

These three findings map directly to core CNAPP capabilities. Credential compromise maps to CIEM (Cloud Infrastructure Entitlement Management). Network misconfiguration maps to CSPM (Cloud Security Posture Management). Data exposure maps to attack path analysis, where individual misconfigurations chain together into exploitable routes.

When you discuss these in an interview, you're speaking the same language as the product team.

You can now read GuardDuty findings like a security analyst. Next up, you'll wire these findings into an automated alerting pipeline so threats trigger real-time email notifications.

Set Up Automated Alerting with EventBridge and SNS

You have investigated real-world threat findings and understand what GuardDuty detects. The next challenge is making sure you actually know when a threat appears.

In a production environment, nobody sits watching a dashboard all day. Security teams rely on automated alerting instead. You will wire up two AWS services to make this happen: EventBridge routes events between services, and SNS delivers notifications to your email.

In this step, get ready to:

• Create an SNS topic and subscribe your email to receive alerts.
• Create an EventBridge rule that listens for GuardDuty findings.
• Test the pipeline by regenerating sample findings and receiving an email notification.

Create an SNS topic for alerts

SNS (Simple Notification Service) is AWS's messaging service. You create a topic (a communication channel), then subscribe your email to it. Any message published to the topic gets forwarded to your inbox.

• Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.
• In the left navigation pane, choose Topics.
• Choose Create topic.
• For Type, select Standard.
• For Name, enter GuardDuty-Alerts.
• Choose Create topic.

What is an SNS topic?

Think of a topic as a mailing list. Anyone (or any AWS service) can publish a message to it, and every subscriber receives a copy. In your pipeline, EventBridge will publish GuardDuty findings to this topic, and your email subscription will deliver them to your inbox.

Now you need to subscribe your email address so you actually receive the alerts.

• On the topic detail page, choose Create subscription.
• For Protocol, select Email.
• For Endpoint, enter your personal email address.
• Choose Create subscription.

AWS sends a confirmation email to the address you entered. You must confirm it before any alerts can be delivered.

• Open your email inbox and find the confirmation email from Amazon SNS.
• Click Confirm subscription in the email.
• Return to the SNS console. Your subscription status should now show Confirmed.

Don't see the confirmation email?

Check your spam or junk folder. The email comes from no-reply@sns.amazonaws.com and some providers filter it automatically.

If it still has not arrived after a couple of minutes, go back to the SNS console, select your subscription, and choose Request confirmation to resend it.

Help me troubleshoot my SNS subscription confirmation email not arriving.

Create an EventBridge rule

EventBridge is the event router that connects AWS services together. You will create a rule that watches for GuardDuty findings and forwards them to your SNS topic.

• Open the Amazon EventBridge console at https://console.aws.amazon.com/events/.
• In the left navigation pane under Buses, choose Rules.
• Choose Create rule.
• For Name, enter guardduty-to-sns.
• For Event bus, confirm that default is selected.
• For Rule type, select Rule with an event pattern.
• Choose Next.

Why an event pattern rule?

EventBridge rules can be schedule-based (like a cron job) or event-pattern-based (triggered by matching events). Since GuardDuty emits an event every time it detects something, a pattern rule lets you react instantly rather than polling on a timer.

Configure the event pattern and target

Now you will tell EventBridge exactly which events to match and where to send them.

• For Event source, select AWS events or EventBridge partner events.
• For Creation method, select Use pattern form.
• For AWS service, select GuardDuty.
• For Event type, select GuardDuty Finding.
• Choose Next.

Now configure the target so matched events get delivered to your SNS topic.

• On the Select target(s) page, for Target types, select AWS service.
• For Select a target, choose SNS topic.
• For Topic, select GuardDuty-Alerts.
• Choose Next.
• Choose Next again to skip the tags page.
• Choose Create rule.

You should see your guardduty-to-sns rule listed with a status of Enabled.

What does this pipeline do?

Every time GuardDuty generates a finding, it emits an event on the default EventBridge bus with source aws.guardduty and detail-type GuardDuty Finding. Your rule matches that pattern and forwards the event payload to your SNS topic, which emails it to you.

This is the same pattern CNAPP platforms use. They ingest native cloud security events and route them through automated workflows to notify the right people instantly.

Now test the full pipeline to confirm email delivery is working end to end.

• Switch back to the GuardDuty console.
• In the left navigation pane, choose Settings.
• Under Sample findings, choose Generate sample findings.
• Check your email inbox. Within a few minutes, you should receive email notifications containing finding details from GuardDuty.

Not receiving alert emails?

Confirm your SNS subscription status shows Confirmed in the SNS console. If it still says Pending confirmation, you have not clicked the link in the confirmation email yet.

Also verify that the EventBridge rule status shows Enabled in the Rules list. A disabled rule will not route any events.

Help me figure out why my GuardDuty to SNS alerting pipeline is not sending emails.

Your detection pipeline is now live. Any finding GuardDuty generates will land in your inbox automatically. Next up, you will create IAM policies that demonstrate the difference between dangerous over-permissioning and zero-trust least privilege.

Demonstrate IAM Least Privilege

You have a detection pipeline that spots threats and alerts you by email. The next question a customer (or interviewer) will ask is: how do you prevent those threats from succeeding in the first place?

The answer is IAM least privilege. In this step, you will create two policies side by side to demonstrate the difference between dangerously open access and tightly scoped zero trust permissions.

In this step, get ready to:

• Create an intentionally insecure wildcard IAM policy.
• Create a scoped least-privilege policy for a security analyst role.
• Compare the two policies to build your interview remediation story.

Create the overly permissive policy

The most common misconfiguration CNAPP platforms detect is wildcard IAM permissions. You will create one on purpose so you can see exactly what the problem looks like.

• Open the IAM console at https://console.aws.amazon.com/iam/.
• In the left navigation pane, choose Policies.
• Choose Create policy.
• In the Policy editor section, choose the JSON option.
• Delete any existing content in the editor, then paste the following intentionally insecure policy:

{
    "Version": "2012-10-17",
    "Statement": [{
        "Sid": "OverlyPermissive",
        "Effect": "Allow",
        "Action": "*",
        "Resource": "*"
    }]
}

What does this policy do?

This policy grants permission to perform every possible action on every possible resource in your AWS account. A single compromised credential with this policy attached gives an attacker full control.

In a real environment, this is the exact pattern that enables lateral movement, privilege escalation, and data exfiltration. CNAPP tools flag this as a Critical finding.

• You may see security warnings from IAM Access Analyzer below the editor flagging that this policy is overly permissive. That is expected. Choose Next to continue.
• On the Review and create page, enter INSECURE-FullAccess as the Policy name.
• Choose Create policy.

You should see a green success banner confirming the policy was created. The policy now appears in your Policies list.

Policy creation blocked by warnings?

IAM Access Analyzer may display security findings when you paste the wildcard policy. These are informational warnings, not blockers. You can proceed by choosing Next even with the warnings visible.

If you see a red Errors banner instead, double-check that you pasted the JSON exactly as shown above. A missing brace or comma will prevent creation.

Help me troubleshoot my IAM policy creation

Create the least-privilege replacement policy

Now you will create a policy that follows the zero trust principle: grant only the permissions a security analyst actually needs to do their job.

• Return to the Policies page in the IAM console.
• Choose Create policy.
• Choose the JSON option in the Policy editor section.
• Delete any existing content, then paste this scoped-down policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ViewSecurityFindings",
            "Effect": "Allow",
            "Action": [
                "guardduty:GetFindings",
                "guardduty:ListFindings",
                "guardduty:GetDetector",
                "guardduty:ListDetectors"
            ],
            "Resource": "*"
        },
        {
            "Sid": "ViewCloudTrailLogs",
            "Effect": "Allow",
            "Action": [
                "cloudtrail:LookupEvents",
                "cloudtrail:GetTrailStatus"
            ],
            "Resource": "*"
        },
        {
            "Sid": "ViewSecurityAlerts",
            "Effect": "Allow",
            "Action": [
                "sns:ListTopics",
                "sns:ListSubscriptions"
            ],
            "Resource": "*"
        }
    ]
}

What does this policy do?

This policy has three statements, each granting read-only access to one service:

• ViewSecurityFindings lets the analyst view GuardDuty findings and detector status.
• ViewCloudTrailLogs lets the analyst look up CloudTrail events for investigation.
• ViewSecurityAlerts lets the analyst see which SNS topics and subscriptions exist for alerting.

No statement allows creating, modifying, or deleting anything. If this credential is compromised, the attacker can only read. The blast radius is minimal.

• Choose Next.
• Enter SecurityAnalyst-ReadOnly as the Policy name.
• Choose Create policy.

You should see the green success banner again. Both policies now appear in your Policies list.

Don't see both policies in the list?

Type INSECURE or SecurityAnalyst in the search bar at the top of the Policies page to filter. Customer managed policies sometimes appear below AWS managed policies.

Help me find my custom IAM policies

Compare the two policies

Now look at both policies side by side and think about what each one means for your interview.

• On the Policies page, search for INSECURE-FullAccess and click its name to open the policy details.
• Note that the Permissions defined section shows access to All services and All actions.
• Go back to the Policies list, search for SecurityAnalyst-ReadOnly, and click its name.
• Note how the permissions are scoped to exactly three services with read-only actions.

Why does this matter for your interview?

The INSECURE-FullAccess policy is what you would show a customer as the problem that CNAPP detects. Wildcard permissions enable lateral movement (moving between services), privilege escalation (gaining admin access), and blast radius expansion (one credential compromises everything).

The SecurityAnalyst-ReadOnly policy is the remediation story. It follows zero trust: never trust, always verify, grant only what is needed. This is what CSPM tools recommend after flagging the wildcard policy.

You now have a concrete, visual demonstration of what CNAPP platforms detect and how security teams remediate it. Next up, you will tie everything together into a polished interview narrative.

Build Your Interview Narrative

You now have two IAM policies sitting side by side that tell a powerful story about cloud security. One grants unrestricted access to everything. The other follows zero trust principles with tightly scoped permissions.

In this final step, you'll tie everything together into a cohesive interview narrative. You'll review your security pipeline end-to-end, practice answering common interview questions, and clean up the insecure policy you created for demonstration purposes.

In this step, get ready to:

• Review your GuardDuty Summary dashboard and connect it to CNAPP concepts.
• Write interview talking points covering CNAPP, zero trust, incident response, and attack paths.
• Delete the insecure IAM policy from your account.

Review your GuardDuty Summary dashboard

The GuardDuty Summary page gives you a high-level view of all findings by severity. This is analogous to what CNAPP dashboards show customers at a glance.

• In the GuardDuty console, click Summary in the left navigation pane.
• Note the finding counts grouped by severity (High, Medium, Low).
• Observe how the dashboard surfaces the most critical issues first.

How does this map to what CNAPP products do?

GuardDuty detects threats (like a CNAPP's detection engine). EventBridge routes them (like a CNAPP's workflow automation). SNS alerts you (like a CNAPP's notification system).

IAM policies are what gets remediated (like a CNAPP's posture management recommendations). You've now touched every layer of this pipeline with your own hands.

Write your interview talking points

Having hands-on experience is powerful, but only if you can articulate it clearly. You'll now write brief answers to four common interview questions using what you built today as evidence.

• Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
• Type VS Code and press Enter to open it.
• Create a new file by pressing Cmd+N (macOS) or Ctrl+N (Windows).
• Save the file to your Desktop as interview-notes.txt.

Now write brief answers to each of these four questions in your file.

Question 1: "What is a CNAPP?"

• Write your answer covering: Cloud Native Application Protection Platform. It provides unified security across code, infrastructure, and runtime.
• Mention specific vendors like Wiz, Palo Alto Prisma Cloud, and Orca Security.
• Note that CNAPP unifies CSPM (Cloud Security Posture Management), CWPP (Cloud Workload Protection), CIEM (Cloud Infrastructure Entitlement Management), and attack path analysis.

Question 2: "What is zero trust?"

• Write your answer covering: Never trust, always verify. Every access request is authenticated and authorized regardless of network location.
• Reference the two IAM policies you created. The wildcard policy trusts everything. The scoped policy verifies every request against a specific permission set.

Question 3: "Walk me through a cloud security incident."

• Write your answer as a story: GuardDuty detected unauthorized API calls from a suspicious IP. The finding was routed via EventBridge to our alerting system. Investigation showed an overly permissive IAM role. Remediation: tightened permissions to least privilege.
• This mirrors exactly what you built today. You have real evidence to back up every sentence.

Question 4: "What are attack paths?"

• Write your answer covering: Chains of misconfigurations that together create an exploitable route to critical assets.
• Include an example: a public S3 bucket combined with an overly permissive IAM role combined with unencrypted data creates a data exfiltration path.
• Note that this is a key differentiator for CNAPP platforms over traditional vulnerability scanners, which only find individual issues without connecting them.

• Save interview-notes.txt once you've written all four answers.

Use your own words

Don't memorize these definitions word for word. The power of your answers comes from being able to point to what you actually built. "I set this up myself yesterday" is more convincing than any textbook definition.

Delete the INSECURE-FullAccess policy

You created the wildcard policy to demonstrate what CNAPP tools flag as a Critical finding. Leaving it in your account is itself a security risk, so you'll remove it now.

• Switch back to the AWS Management Console in your browser.
• Navigate to the IAM console by typing IAM in the search bar at the top.
• In the left navigation pane, click Policies.
• Search for INSECURE-FullAccess in the search field.
• Select the radio button next to INSECURE-FullAccess.
• Click Actions, then click Delete.
• Type the policy name to confirm deletion, then click Delete.

You should see a success banner confirming the policy has been deleted. The SecurityAnalyst-ReadOnly policy remains in your account as an example of proper least-privilege design.

Can't delete the policy?

If the Delete option is greyed out, make sure the policy is not attached to any users, groups, or roles. Check the Policy usage tab on the policy details page to see if anything is using it.

help me delete an IAM policy that won't delete

Why delete it instead of keeping it as a reference?

An unused wildcard policy sitting in your account is a risk if anyone accidentally attaches it to a role later. In a real environment, this is exactly the kind of "policy drift" that CNAPP tools detect and flag.

Secret mission

Severity-Filtered Smart Alerts

Your current alerting rule sends you an email for every single GuardDuty finding, regardless of severity. In a real environment, this creates alert fatigue. Can you build a smarter rule that only fires on medium and high severity threats, and formats the email so you can triage at a glance?

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

GuardDuty is free for 30 days after activation. After your trial ends, charges apply based on data volume. SNS and EventBridge both fall within their free tiers for this project's usage.

Cost warning

If you leave GuardDuty enabled past your 30-day free trial, you will be charged based on the volume of data analyzed. Set a calendar reminder to return and disable it before your trial ends if you do not plan to keep using it.

Resources you used:

• GuardDuty detector (free for 30 days, then charges based on data volume).
• SNS topic GuardDuty-Alerts with email subscription (free tier: 1,000 email notifications/month).
• EventBridge rules guardduty-to-sns and guardduty-high-severity-alerts (free tier: first 14 million events/month).
• IAM policy SecurityAnalyst-ReadOnly (no cost).

Keep everything running

No action needed. Choose this if you are still actively building or want to keep exploring GuardDuty findings.

• GuardDuty will continue monitoring during your 30-day free trial at no cost.
• After 30 days, return and disable it to avoid charges.
• SNS and EventBridge remain within free tier for this level of usage.

Pause - I'll come back to this later

Suspend GuardDuty to stop monitoring and avoid future charges, while keeping your configuration intact.

• Open the GuardDuty console.
• In the navigation pane, choose Settings.
• In the Suspend GuardDuty section, choose Suspend GuardDuty, then confirm your action.
• To re-enable later, return to Settings and choose Re-enable GuardDuty.

Your EventBridge rules and SNS topic will remain configured but will not generate new alerts while GuardDuty is suspended.

Delete - I don't want to use this again

Remove all project resources completely and start fresh.

• Disable GuardDuty:
• Delete EventBridge rules:
• Delete the SNS topic:
• Delete the IAM policy:

That's a Wrap!

That's a Wrap!

Nice work! You just built a production-grade threat detection and alerting pipeline in AWS. This is the exact system that CNAPP platforms like Wiz and Prisma Cloud operate at scale.

You've learned how to:

• Built an automated alerting pipeline using EventBridge and SNS that emails you when GuardDuty detects threats in your environment.
• Investigated simulated threat findings like a security analyst, mapping attack vectors to concrete remediation steps.
• Created and compared IAM policies demonstrating the difference between overly permissive access and zero-trust least privilege.
• Secret Mission: Built severity-filtered smart alerts with formatted output, demonstrating noise reduction and risk prioritization.

Ready to quiz yourself?