Cloud Intrusion Detection on AWS

Detect threats, send email alerts, and audit every API call in AWS.

Introduction

30 Second Summary

Think about a home security system. Cameras watch for break-ins, sensors detect unusual activity, and you get an alert on your phone the instant something happens.

In this project, you will build an intrusion detection and monitoring system on AWS. You will set up automated threat detection, real-time email alerts, and a persistent audit trail that records every action taken in your account.

What You'll Build

When a threat is detected in your AWS account, GuardDuty catches it, EventBridge routes it through an automated pipeline, and SNS delivers a formatted alert straight to your inbox.

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

Generate simulated threats and watch GuardDuty flag them with severity levels, affected resources, and detailed reports.
Receive real-time email alerts the moment a threat is detected, formatted with the finding type, severity, and a direct link to investigate.
Browse a CloudTrail audit trail showing every API call made in your account, with logs stored in an S3 bucket for long-term forensic analysis.
Secret Mission: Add severity-based filtering so only medium and high severity threats trigger email alerts.

Are there any prerequisites?

No prior AWS experience is needed. This project includes creating an AWS account from scratch. You will need a valid email address to receive alert notifications.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters.

Set Up Your AWS Account and Enable GuardDuty

Before you can detect threats in the cloud, you need two things in place. An AWS account to protect and a detection service watching over it.

Amazon GuardDuty is AWS's managed threat detection service. The moment you enable it, GuardDuty starts analyzing CloudTrail management events, VPC flow logs, and DNS logs for signs of malicious activity.

In this step, get ready to:

Create or sign into your AWS account.
Enable Amazon GuardDuty in the us-east-1 Region.
Confirm GuardDuty is actively monitoring your account.

Create or sign into your AWS account

You need an AWS account to access GuardDuty and the other services in this project. If you already have one, sign in and skip ahead.

✔️ I already have an AWS account

Sign into the AWS Management Console at console.aws.amazon.com
Enter your root user email address and password when prompted.

You are all set. Skip to the next substep to enable GuardDuty.

ⓧ I need to create an account

Open the AWS sign-up page at aws.amazon.com in your browser.
Choose Sign up on the homepage.
Enter your email address and create a password when prompted.
Follow the prompts to add your contact information and verify your phone number.
When asked for a payment method, enter your card details.
On the support plan selection page, choose the Basic Support (Free) plan.
Choose Complete sign up.

Why does AWS need a payment method?

AWS requires a payment method on file for identity verification. The services in this project are all covered by free tiers and free trials, so you will not be charged.

How long does activation take?

Account activation usually takes a few minutes, but can take up to 24 hours. Check your email for a confirmation message before signing in.

Once your account is activated, sign into the AWS Management Console at console.aws.amazon.com.

Having trouble signing in?

Make sure you are signing in as the Root user (not an IAM user). Enter the email address you used to create the account.

If your account was just created, it may still be activating. Wait for the confirmation email before trying again.

help me sign into the AWS Management Console

Enable Amazon GuardDuty

Now that you are in the AWS Management Console, you need to set your Region and turn on GuardDuty.

In the top-right corner of the console, click the Region dropdown.
Select US East (N. Virginia) us-east-1.
Open the Amazon GuardDuty console by navigating to https://console.aws.amazon.com/guardduty/ in your browser.
Select the Amazon GuardDuty - All features option.
Choose Get started.
On the Welcome to GuardDuty page, choose Enable GuardDuty.

What did you just enable?

GuardDuty is now analyzing data from multiple sources across your account. It ingests CloudTrail management events to track API activity, VPC flow logs to monitor network traffic, and DNS logs to detect suspicious domain lookups.

From this moment, GuardDuty is watching for threats like unauthorized access attempts, cryptocurrency mining, and data exfiltration.

Not seeing the Welcome to GuardDuty page?

If you see the Summary dashboard instead of a welcome page, GuardDuty is already enabled in this Region. You are all set.

If you see a permissions error, make sure you are signed in as the root user or an IAM user with administrator access.

help me enable GuardDuty in the AWS console

Confirm GuardDuty is active

You should now be looking at the GuardDuty Summary dashboard. Before you review it in detail, what do you expect to see now that GuardDuty is running?

Review the Summary dashboard. Confirm that GuardDuty shows an active status.
Look at the protection plans listed on the dashboard. You should see several plans enabled by default, including S3 Protection, EKS Protection, RDS Protection, Lambda Protection, and others.

All of these default protection plans are included in your 30-day free trial.

What are these protection plans?

GuardDuty's protection plans extend threat detection to specific AWS services. S3 Protection monitors bucket activity. EKS Protection watches Kubernetes clusters. RDS Protection covers databases. Lambda Protection checks serverless functions.

All default plans are included in the 30-day free trial. There is no cost for this project.

Your threat detection service is live and watching your account. Next, you will generate simulated threats to see what GuardDuty actually catches.

Generate and Investigate Simulated Threats

GuardDuty is now active and watching your account for threats.

Before you can build automated alerts, you need to understand what threat data actually looks like. GuardDuty includes a sample findings generator that simulates real-world attack scenarios so you can explore threats without waiting for an actual incident.

In this step, get ready to:

Generate sample findings that simulate real-world threats in your account.
Investigate a high-severity finding's details, including severity, affected resources, and attacker actions.
Explore the raw JSON format that powers automated alerting.

Generate sample findings

GuardDuty can generate sample findings that cover dozens of real-world attack scenarios. These range from cryptocurrency mining on hijacked servers to unauthorized access attempts and data exfiltration.

In the GuardDuty console navigation pane, choose Settings.
Under Sample findings, choose Generate sample findings.
In the navigation pane, choose Summary.

The Summary dashboard now shows threat statistics populated from the sample findings you just generated. Charts and counters display data across severity levels and finding categories.

What happened behind the scenes?

GuardDuty generated one sample finding for every finding type it supports. Each sample simulates a different attack scenario, from compromised EC2 instances to suspicious API calls.

The Summary dashboard aggregates these findings by severity and category, giving you a bird's-eye view of your account's threat landscape.

Investigate a high-severity finding

The Summary gives you an overview, but to understand a threat you need to drill into the details of individual findings.

In the navigation pane, choose Findings.

Before you start scrolling through the list, take a moment to predict. What types of threats do you think GuardDuty flagged, and how many findings do you expect to see?

The Current findings page displays dozens of sample findings, each prefixed with [SAMPLE]. You'll see categories including cryptocurrency mining, unauthorized access, and data exfiltration.

Don't see any findings?

Make sure you chose Generate sample findings in Settings. If the Findings page still looks empty, try refreshing your browser.

Help me troubleshoot why my GuardDuty sample findings aren't appearing.

Click on a high-severity finding (look for the red icon) such as CryptoCurrency:EC2/BitcoinTool.B to open the finding details side panel.
Review the severity level displayed at the top of the panel.
Scroll down to the Resource affected section to see which resource was compromised.
Check the Action section to see what the attacker did.

What do these sections tell you?

The severity level tells you how urgent the threat is. GuardDuty uses a numeric scale where low is 1.0-3.9, medium is 4.0-6.9, and high is 7.0-8.9.
Resource affected identifies the specific AWS resource targeted, such as an EC2 instance or an S3 bucket.
Action describes the behavior GuardDuty flagged, such as network connections to known malicious IPs or suspicious API calls.

Explore the raw JSON view

The details panel gives you a human-friendly summary. Underneath, GuardDuty stores every finding as raw JSON. This is the format that automation tools like EventBridge use to route and process alerts.

Click the finding ID at the top of the details pane to open the complete JSON view.

You can now see the full JSON document for this finding. This is the exact data structure that EventBridge receives when GuardDuty detects a real threat.

Locate the following key fields in the JSON: type, severity, description, accountId, and region.

Why do these fields matter?

These are the fields you will extract in the next step to build human-readable email alerts.

type identifies the specific finding type (like CryptoCurrency:EC2/BitcoinTool.B).
severity is the numeric severity score that tells you how urgent the threat is.
description provides a human-readable explanation of the threat.
accountId and region identify where the finding occurred.

You now understand GuardDuty's threat data and the JSON fields that power automated alerting. Right now, though, you can only see these findings by manually logging into the console and checking.

Next up, you'll build an automated alert pipeline that delivers findings straight to your email the moment a threat is detected.

Build an Automated Alert Pipeline

You've explored what GuardDuty findings look like. You reviewed severity levels, affected resources, and the raw JSON data behind each threat.

There's a gap in what you have so far. The only way to see those threats is to log into the GuardDuty console and manually check.

In production, that means threats go unnoticed until someone remembers to look. In this step, you'll wire up two AWS services to build an automated pipeline that delivers threat alerts straight to your email the moment a finding appears.

In this step, get ready to:

Create an SNS topic and subscribe your email address for alert delivery.
Build an EventBridge rule that captures every GuardDuty finding.
Configure an input transformer so alerts arrive as human-readable emails instead of raw JSON.

Create an SNS topic and email subscription

Amazon SNS (Simple Notification Service) delivers messages to subscribers like email addresses. You'll create a topic as the channel for your GuardDuty alerts, then subscribe your email to receive them.

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

What is an SNS topic?

A topic is a communication channel. When something publishes a message to the topic, SNS forwards it to every subscriber.

In your case, EventBridge will publish GuardDuty findings to this topic, and SNS will forward them to your email.

Your topic is created. Now you need to subscribe your email address so SNS knows where to deliver alerts.

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

SNS needs to confirm you actually own the email address before it starts delivering messages. Check your inbox for a confirmation email.

Open your email inbox and look for a confirmation email from AWS Notifications.
Click the Confirm subscription link in the email.
Return to the SNS console and refresh the page.

The subscription status should now show Confirmed. This means your email is live and ready to receive alerts.

Don't see the confirmation email?

Check your spam or junk folder. The email comes from AWS Notifications.
Double-check that you entered the correct email address. If it was wrong, delete the subscription and create a new one with the right address.
Wait a minute or two and refresh your inbox. The email sometimes takes a moment to arrive.

Still stuck? Ask for help.

Create an EventBridge rule for GuardDuty findings

Amazon EventBridge is an event routing service. It listens for specific events happening in your AWS account and routes them to targets you define. You'll create a rule that captures every GuardDuty finding and sends it to your SNS topic.

Open the Amazon EventBridge console at https://console.aws.amazon.com/events/.
In the navigation pane, choose Rules.
Choose Create rule.
For Name, enter GuardDuty-Finding-Alert.
For Event bus, choose default.
For Rule type, choose Rule with an event pattern.
Choose Next.

You're now on the event pattern page. This is where you tell EventBridge exactly which events to capture.

For Event source, choose AWS events.
For AWS service, choose GuardDuty.
For Event type, choose GuardDuty Finding.
Choose Next.

What does this event pattern do?

The pattern you just configured tells EventBridge to listen for any event with source aws.guardduty and detail-type GuardDuty Finding. Every time GuardDuty generates a new finding, EventBridge captures it and routes it to your target.

Configure the target with an input transformer

The target is where EventBridge sends captured events. You'll point it at your SNS topic. But raw GuardDuty JSON is hard to read in an email, so you'll also add an input transformer that extracts key fields and formats them into a clean, readable message.

For Target types, choose AWS service.
For Select a target, choose SNS topic.
For Topic, select GuardDuty-Alerts.

Now configure the input transformer so your emails contain readable text instead of raw JSON.

Expand Additional settings.
For Configure target input, choose Input transformer.
Choose Configure input transformer.

In the Input path field, paste the following JSON:

{"severity":"$.detail.severity","Finding_ID":"$.detail.id","Finding_Type":"$.detail.type","region":"$.region","Finding_Description":"$.detail.description"}

What does this input path do?

The input path extracts five specific fields from the raw GuardDuty finding JSON and assigns each one a short variable name:

severity pulls the numeric threat level.
Finding_Type pulls the threat category (like CryptoCurrency:EC2/BitcoinTool.B).
Finding_Description pulls a plain-English description of what happened.
Finding_ID and region are used to build a direct link to the finding in the console.

In the Template field, paste the following:

"You have a severity <severity> GuardDuty finding type <Finding_Type> in the <region> region."
"Finding Description:"
"<Finding_Description>."
"For more details open the GuardDuty console at https://console.aws.amazon.com/guardduty/home?region=<region>#/findings?search=id%3D<Finding_ID>"

What does this template do?

The template arranges the extracted fields into a readable email body. Instead of a wall of JSON, you'll get a message that tells you the severity level, what type of threat was detected, which region it came from, and a description of the finding.

The last line builds a clickable link straight to the finding in the GuardDuty console, so you can investigate immediately without hunting for it.

Choose Confirm.
Choose Next.
Choose Next again to skip the tags page.
Choose Create rule.

You should see your GuardDuty-Finding-Alert rule listed on the Rules page with a status of Enabled.

Don't see your rule listed?

Make sure you chose Create rule on the final review page. If you navigated away before creating it, the wizard resets and you'll need to start from Create rule again.
Check that the Event bus dropdown at the top of the Rules page shows default. Your rule lives on the default bus.

Still stuck? Ask for help.

Why EventBridge instead of CloudWatch Events?

EventBridge and CloudWatch Events share the same underlying service and API. EventBridge is the current recommended name per AWS documentation, and the console routes you to EventBridge by default.

Your detection-to-notification pipeline is built. In the next step, you'll put it to the test by generating new threats and watching the formatted alerts land in your inbox.

Test the Pipeline and Create an Audit Trail

In the last step, you connected GuardDuty to SNS and EventBridge so that threat findings have a path from detection to your inbox. Your alert pipeline is built, but you have not proven it works end to end.

You also have no record of your own actions in this account. In this step, you will test the full pipeline and then create a CloudTrail audit trail that logs every API call to S3. This gives you a persistent record for compliance and forensic investigation.

In this step, get ready to:

Verify the detection-to-notification pipeline by generating new sample findings and receiving email alerts.
Create a CloudTrail trail that logs every API call to an S3 bucket.
Browse Event History to see a timestamped record of your project activity.

Test your alert pipeline end to end

Right now you can see findings by manually checking the GuardDuty console, but you have not confirmed that your EventBridge rule and SNS topic actually deliver alerts to your inbox. Time to find out.

Return to the GuardDuty console. In the navigation pane, choose Settings.
Under Sample findings, choose Generate sample findings.

Before you check your email, think about what you expect to find there. Will you see one alert or many? What information will each email contain?

Wait 2 to 5 minutes for EventBridge to route the findings to SNS.
Open your email inbox and look for messages from AWS Notifications.

You should see multiple formatted alert emails. Each one contains the severity level, the finding type, a description of the threat, and a direct link to the finding in the GuardDuty console.

What do these emails look like?

Each email follows the template you configured in the EventBridge input transformer. It reads something like: "You have a severity 8 GuardDuty finding type CryptoCurrency:EC2/BitcoinTool.B in the us-east-1 region." Below that is the finding description and a clickable link back to the GuardDuty console.

The fact that these emails arrived confirms that GuardDuty generated a finding, EventBridge matched the event pattern and extracted the fields, and SNS delivered the formatted message to your inbox. Your full detection-to-notification pipeline is working.

Not receiving any emails?

Check your spam or junk folder. AWS notification emails sometimes land there.
Make sure you confirmed the SNS subscription in Step 3. Return to the SNS console, choose Subscriptions, and verify the status shows Confirmed.
Verify that your EventBridge rule GuardDuty-Finding-Alert is Enabled on the EventBridge Rules page. A disabled rule silently drops all events.

Still stuck? Help me troubleshoot why my GuardDuty alert emails are not arriving.

Create a CloudTrail trail for audit logging

Your threat detection and alerting pipeline is proven. There is still a gap though. You have no record of your own actions in this AWS account.

CloudTrail fills that gap by recording every API call made in your account and delivering the logs to an S3 bucket. This gives you a persistent audit trail you can revisit long after the 90-day default Event History window expires.

Open the CloudTrail console at https://console.aws.amazon.com/cloudtrail/.
Choose Create trail.
In the Trail name field, enter security-audit-trail.
Under Storage location, select Create new S3 bucket.
Enter a unique bucket name, such as security-audit-trail-yourname-2026. S3 bucket names must be globally unique, so include your name and the year.
Clear the checkbox for Log file SSE-KMS encryption to disable it. Your logs will use the default SSE-S3 encryption instead.

What is CloudTrail?

CloudTrail is an AWS service that records every API call made in your account. Every time you click something in the console, create a resource, or run a CLI command, CloudTrail logs who did it, when, from where, and what changed.

The trail you are creating delivers these logs to an S3 bucket for long-term storage. Without a trail, you can only see the last 90 days of activity in Event History. With a trail, you keep a permanent archive.

On the Choose log events page, keep the default Management events selected.
Confirm that both Read and Write are selected under Management events.
Choose Next.
On the Review and create page, review your settings and choose Create trail.

The Trails page now shows your new trail. It is set to Multi-region trail by default and logging is turned on automatically.

Why is it a multi-region trail?

All trails created through the CloudTrail console are multi-region by default. This means your trail captures API activity across all enabled AWS Regions, not just us-east-1. It is an AWS best practice because threats and accidental changes can happen in any region.

Trail creation failed?

If you see a bucket name error, your S3 bucket name is not unique. Try adding extra characters or digits to make it globally unique.
If you see a permissions error, make sure you are signed in with an account that has administrative access.

Still stuck? Help me troubleshoot my CloudTrail trail creation error.

Browse your audit trail in Event History

Your trail is now logging to S3 for long-term storage. CloudTrail also provides an Event History page that shows the last 90 days of management events at no extra charge. This is where you can see every action taken during this project.

Before you open Event History, think about what you expect to see. What API calls have you made during this project so far?

In the CloudTrail navigation pane, choose Event history.
You will see a filtered list of events with the most recent events first. The default filter is Read only set to false, which shows write events only.
Browse the timestamped log of API calls. Look for event names like CreateDetector (enabling GuardDuty), CreateTopic (creating the SNS topic), PutRule (creating the EventBridge rule), and CreateTrail (the trail you just created).

Every action you took during this project is recorded here with a timestamp, the user identity, and the source IP address.

To filter for a specific event, choose Event name from the Lookup attributes dropdown.
Enter CreateTopic in the filter text box and press Enter. You should see the exact moment you created the GuardDuty-Alerts SNS topic.
Click on the CreateTopic event name to open its details. You can see the full event record, including the request parameters and the user who performed the action.

Why does this matter?

In a real security investigation, Event History is where you would trace exactly what happened and when. If an unauthorized user created a resource or changed permissions, you would see it here. Combined with GuardDuty alerts, this gives you both real-time detection and historical evidence.

Not seeing your events?

Make sure you are viewing Event History in the us-east-1 region. Event History shows events for the current region only.
Clear any existing filters by clicking the X next to the filter box. The default Read only filter set to false hides read events. Clearing it shows all events.
CloudTrail events may take a few minutes to appear after the action was performed.

Still stuck? Help me find my API events in CloudTrail Event History.

Secret mission

Filter Alerts by Threat Severity

Your alert pipeline currently sends an email for every single GuardDuty finding, including low-severity informational ones. In production, this creates alert fatigue and buries the threats that actually matter. Your mission: add severity-based filtering to your EventBridge rule so only medium and high severity threats trigger email alerts.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project uses AWS services that are free or nearly free during the 30-day trial and at this scale, so there is no immediate cost pressure.

Resources you used:

Amazon GuardDuty detector in us-east-1 (30-day free trial active).
CloudTrail trail security-audit-trail logging management events to S3.
S3 bucket storing CloudTrail logs (named something like security-audit-trail-yourname-2026).
SNS topic GuardDuty-Alerts with a confirmed email subscription.
EventBridge rule GuardDuty-Finding-Alert on the default event bus.

Keep everything running

No action needed. Choose this if you plan to keep using this AWS account and want GuardDuty actively monitoring for real threats.

GuardDuty continues monitoring your account at no cost for the remainder of your 30-day free trial. After the trial, charges are based on data volume analysed.
CloudTrail continues logging management events to S3 at no cost (the first trail delivering management events to S3 is free).
The SNS topic and EventBridge rule incur no charges at this scale.

Pause - I'll come back to this later

Shut down active monitoring to stop any future charges, but keep your configurations in place so you can resume later.

Suspend GuardDuty: open the GuardDuty console, choose Settings in the navigation pane, then choose Suspend GuardDuty and Confirm. GuardDuty stops monitoring and no charges accrue while suspended.
Stop CloudTrail logging: open the CloudTrail console, choose Trails, select security-audit-trail, then choose Stop logging and confirm. Existing logs remain in S3.

Delete - I don't want to use this again

Remove all project resources and start fresh. Follow each step below in order.

Disable GuardDuty: open the GuardDuty console at https://console.aws.amazon.com/guardduty/. In the navigation pane, choose Settings. In the Suspend GuardDuty section, choose Disable GuardDuty, then choose Confirm. This permanently deletes your findings and configuration.
Delete the EventBridge rule: open the EventBridge console at https://console.aws.amazon.com/events/. In the navigation pane, choose Rules. Select the button next to GuardDuty-Finding-Alert, choose Delete, then choose Delete again to confirm.
Delete the SNS topic: open the SNS console at https://console.aws.amazon.com/sns/v3/home. In the navigation pane, choose Topics. Select GuardDuty-Alerts, choose Delete. In the confirmation dialog, type delete me and choose Delete.
Delete the CloudTrail trail: open the CloudTrail console at https://console.aws.amazon.com/cloudtrail/. Choose Trails, then choose the trail name security-audit-trail. At the top of the trail details page, choose Delete, then choose Delete to confirm. This does not delete the S3 bucket or its log files.
Empty and delete the S3 bucket: open the S3 console at https://console.aws.amazon.com/s3/. In the General purpose buckets list, select the bucket you created for CloudTrail logs. Choose Empty, type permanently delete to confirm, then choose Empty. After the bucket is emptied, select it again, choose Delete, type the bucket name to confirm, and choose Delete bucket.

Nice Work!

You just built a complete cloud intrusion detection and monitoring system on AWS. Your account is now protected by the same architecture that security teams use in production environments.

Here's what you accomplished:

Enabled Amazon GuardDuty and explored simulated threat findings including cryptocurrency mining, unauthorized access, and data exfiltration scenarios.
Built an automated detection-to-email alert pipeline using Amazon SNS and Amazon EventBridge with a human-readable input transformer.
Created a persistent audit trail with AWS CloudTrail logging every API call to an S3 bucket, and investigated your own account activity in Event History.
Secret Mission: Added severity-based filtering to your EventBridge rule so only medium and high severity threats trigger email alerts, reducing alert noise.

Ready to quiz yourself?