Security Monitoring with GuardDuty

Enable GuardDuty and VPC Flow Logs to detect and resolve security threats.

Introduction

30 Second Summary

Think about how a home security camera watches for suspicious activity around your house. Cloud security monitoring works the same way. It watches your digital resources for anything unusual and alerts you when something looks wrong.

In this project, you will build a security monitoring system on AWS that detects threats and captures network traffic. You'll enable Amazon GuardDuty for intelligent threat detection, configure VPC Flow Logs to monitor traffic, and walk through the investigation workflow security professionals use daily.

What You'll Build

A fully operational security monitoring system on AWS using Amazon GuardDuty for threat detection and VPC Flow Logs for network traffic monitoring.

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

Amazon GuardDuty enabled and actively monitoring your AWS account for threats.
VPC Flow Logs configured to capture network traffic data for your default VPC.
A security alert investigated, analyzed, and resolved through the same workflow security professionals use daily.
Secret Mission: Set up automated email alerts for high-severity findings using Amazon EventBridge and SNS.

Are there any prerequisites?

You'll need an AWS account (free tier eligible). No prior security experience is required. This project uses the AWS Management Console, so there is nothing to install on your computer.

Set Up Your AWS Environment

Before you can monitor threats or capture network traffic, you need a properly configured AWS environment. This means signing into the console, choosing the right region, and confirming your account has the permissions needed to enable security services.

In this step, you will set your region, locate your default VPC (the network your traffic flows through), and verify your IAM permissions cover the services you will configure in later steps.

In this step, get ready to:

Set your AWS Region to US East (N. Virginia).
Identify your default VPC and note its VPC ID.
Verify your IAM permissions for GuardDuty, VPC, CloudWatch Logs, and EC2.

Sign in and set your AWS Region

All the services in this project will live in the same region. Setting the region first ensures every resource you create is in the same place.

Open your browser and navigate to the AWS Management Console at https://console.aws.amazon.com/.
Sign in with your AWS account credentials.
Look at the top-right corner of the console for the region selector (it displays the current region name).
Click the region selector and choose US East (N. Virginia) from the dropdown.
Confirm the region selector now displays US East (N. Virginia).

Why US East (N. Virginia)?

The us-east-1 region is the most commonly used AWS region and has full support for all services including Amazon GuardDuty and VPC Flow Logs. Using a single region keeps all your resources together and simplifies monitoring.

Verify your default VPC

A VPC is a virtual network inside AWS where your resources live and communicate. Every AWS account comes with a default VPC in each region, and this is the network whose traffic you will monitor.

In the console search bar at the top, type VPC and select VPC from the results.
In the left navigation pane, choose Your VPCs.
Look for a row where the Default VPC column shows Yes.
Note the VPC ID value for that row (it starts with vpc-). Write this down or keep the tab open. You will need it in the next step.

What is a VPC?

A VPC (Virtual Private Cloud) is your own isolated section of the AWS network. Think of it as a private room where all your cloud resources talk to each other.

The default VPC is pre-configured by AWS so you can start launching resources immediately. It has public subnets, an internet gateway, and routing already set up.

Don't see a default VPC?

Most accounts created after 2013 have a default VPC in every region. If yours was deleted, you can recreate it by choosing Actions at the top of the VPC console and selecting Create default VPC. Also double-check that your region selector still shows US East (N. Virginia).

Help me find or recreate my default VPC.

Verify your IAM permissions

To enable GuardDuty and configure VPC Flow Logs, your AWS user needs the right permissions. The simplest path is administrative access, but you can also use a more targeted set of permissions.

In the console search bar at the top, type IAM and select IAM from the results.
In the left navigation pane, choose Users.
Click your username in the list.
Select the Permissions tab.
Look for a policy called AdministratorAccess attached to your user (either directly or through a group). This grants full access to all AWS services.

What if I don't have AdministratorAccess?

If you are using the root account (the email you used to create your AWS account), you automatically have full permissions. No policy check is needed.

If you are using an IAM user without AdministratorAccess, you need at minimum permissions for GuardDuty, VPC, CloudWatch Logs, and EC2. Ask your account administrator to attach the required policies.

Seeing an access denied error?

If you see a message saying you are not authorized to perform an action, your user is missing the required permissions. Ask the account owner to attach the AdministratorAccess managed policy to your IAM user, or use the root account for this project.

Help me fix my IAM permissions for this project.

Your AWS environment is ready. Next up, you will enable VPC Flow Logs to start capturing the network traffic flowing through your default VPC.

Enable VPC Flow Logs

Security monitoring starts with visibility. Before any threat detection tool can identify suspicious activity, you need raw data about who is connecting to your resources and what traffic is flowing through your network.

In this step, you will enable VPC Flow Logs on your default VPC. Flow Logs capture metadata about every network connection, giving you a detailed record of accepted and rejected traffic. This is the same data that services like GuardDuty analyze to detect threats.

In this step, get ready to:

Create a VPC Flow Log on your default VPC that captures all traffic.
Verify your CloudWatch Logs log group is receiving flow log data.
Examine a flow log record to understand the traffic metadata fields.

Create a flow log on your default VPC

A flow log captures IP traffic information for all network interfaces in your VPC. You will configure it to log both accepted and rejected traffic, so you get the full picture of what is happening on your network.

In the AWS Management Console, type VPC in the top search bar and select VPC from the results.
In the left navigation pane, choose Your VPCs.
Select the checkbox next to your default VPC (the one whose VPC ID you noted earlier).
Choose the Actions dropdown, then select Create flow log.

The Create flow log form appears. Configure each field as follows:

For Filter, select All. This logs both accepted and rejected traffic.
For Maximum aggregation interval, choose 1 minute. This gives you the most granular data.
For Destination, choose Send to CloudWatch Logs.
For Destination log group, type vpc-flow-logs-security-monitoring as the new log group name.
For IAM Role, select Set Up Permissions (or choose an existing role if one is available). This opens a new tab where AWS creates a role with permissions to publish logs to CloudWatch Logs.
Leave Log record format set to AWS default format.
Choose Create flow log.

You should see a green success banner confirming your flow log was created.

What is a VPC Flow Log?

A VPC Flow Log captures IP traffic metadata for network interfaces in your VPC. It records who connected, where the traffic went, which ports were used, and whether the connection was accepted or rejected.

Flow Logs do not capture the content of your traffic. They only capture metadata like IP addresses, ports, and byte counts. Think of it as a phone bill that shows who you called and for how long, but not what you said.

Why send logs to CloudWatch?

CloudWatch Logs gives you a centralized place to search, filter, and analyze your flow log records directly in the AWS console. It also integrates with CloudWatch alarms and metrics for automated monitoring.

If you ran into any issues creating the flow log, the troubleshooting tip below can help.

Don't see the Set Up Permissions option?

If the IAM Role dropdown does not show an option to create a new role, your IAM user may need the iam:PassRole permission. Go back to the IAM console and verify your user has administrative permissions, then return to this page and try again.

Help me fix this permission issue

Verify your log group in CloudWatch

Now that your flow log is active, traffic data will start arriving in CloudWatch Logs. It may take a few minutes for the first records to appear.

In the top search bar, type CloudWatch and select CloudWatch from the results.
In the left navigation pane, expand Logs and choose Log groups.
Verify that your vpc-flow-logs-security-monitoring log group appears in the list.
Click on the vpc-flow-logs-security-monitoring log group name to open it.
Look for log streams listed inside the log group. Each stream corresponds to a network interface in your VPC.
Click on any available log stream to view the flow log records inside.

What should I see?

Each log stream is named after the network interface ID (like eni-0abc1234def56789). Inside a stream, you will see rows of space-separated values representing individual traffic records.

If no log streams have appeared yet, wait 2-3 minutes and refresh the page. Flow logs need some time to begin publishing after creation.

Log group not appearing?

Make sure your region is still set to us-east-1 in the top-right corner. CloudWatch Logs are region-specific. Also confirm the flow log was created successfully by returning to the VPC console, selecting your VPC, and checking the Flow Logs tab.

Help me troubleshoot my missing log group

Examine a flow log record

Each flow log record is a single line of space-separated fields that describe one network flow. Understanding these fields is essential for investigating security alerts later.

Inside a log stream, look at any individual record (one line of text).
Count the space-separated fields from left to right. The default format contains 14 fields in a fixed order.

Here is what the default format fields represent, in order:

version - the flow log format version (always 2 for the default format).
account-id - the AWS account ID that owns the network interface.
interface-id - the network interface ID where traffic was recorded.
srcaddr - the source IP address of the traffic.
dstaddr - the destination IP address.
srcport - the source port number.
dstport - the destination port number.
protocol - the IANA protocol number (e.g., 6 for TCP, 17 for UDP).
packets - the number of packets transferred during the flow.
bytes - the number of bytes transferred.
start - the start time of the flow (Unix timestamp).
end - the end time of the flow (Unix timestamp).
action - whether the traffic was ACCEPTed or REJECTed by security group or network ACL rules.
log-status - the logging status (OK, NODATA, or SKIPDATA).

Why does this data matter for security?

This is the raw traffic data that threat detection services like GuardDuty analyze to identify suspicious patterns. A sudden spike in rejected traffic to unusual ports could indicate a port scan. Repeated connections to known malicious IP addresses could indicate a compromised instance.

By understanding what these fields mean, you will be able to make sense of the security findings GuardDuty generates in the next step.

Your VPC Flow Logs are now actively capturing network traffic data. Next up, you will enable Amazon GuardDuty to analyze this kind of data automatically and detect threats using machine learning.

Enable Amazon GuardDuty

Your VPC Flow Logs are now capturing raw network traffic data. That's like having security cameras installed, but nobody watching the footage.

In this step, you'll enable Amazon GuardDuty. GuardDuty uses machine learning and threat intelligence to analyze your account activity and flag suspicious behavior automatically.

In this step, get ready to:

Enable Amazon GuardDuty with All Features in your AWS account.
Explore the Summary dashboard for security findings.
Note your Detector ID and confirm your 30-day free trial.

Enable GuardDuty in your account

GuardDuty continuously monitors three foundational data sources: CloudTrail management events, VPC Flow Logs, and DNS query logs. Once you enable it, monitoring begins immediately with no additional configuration.

Navigate to the GuardDuty console by entering this URL in your browser's address bar:

https://console.aws.amazon.com/guardduty/

Select the Amazon GuardDuty - All features option.
Choose Get started.
On the Welcome to GuardDuty page, review the service terms.
Choose Enable GuardDuty.

GuardDuty is now active. It immediately begins analyzing CloudTrail management events, VPC Flow Logs, and DNS query logs across your account.

What is GuardDuty actually doing?

GuardDuty uses its own independent access to your VPC Flow Logs, CloudTrail events, and DNS logs. It feeds this data through machine learning models and threat intelligence feeds to identify suspicious patterns.

The Flow Logs you set up in the previous step are for your own review of raw traffic. GuardDuty handles its own data ingestion behind the scenes.

Don't see the Get started button?

If you see a GuardDuty dashboard instead of the welcome page, GuardDuty may already be enabled in this region. Check the top-right corner to confirm your region is set to US East (N. Virginia) us-east-1.

If your IAM user lacks permission, you'll see an access denied message. Confirm you have administrative permissions or at minimum GuardDuty full access.

Help me troubleshoot enabling GuardDuty in my AWS account.

Explore the Summary dashboard

The Summary dashboard is your central command center for security findings. It shows you what threats have been detected, their severity, and which resources are affected.

Click Summary in the left navigation pane.
Note the dashboard widgets: findings by severity, most common finding types, and resources with findings.

Since you just enabled GuardDuty, there are no real findings yet. The dashboard will be empty or show placeholder content. In the next step, you'll generate sample findings to populate this view.

What will the Summary dashboard show once findings exist?

When findings are present, the dashboard displays up to eight top findings sorted by severity (Critical first). You'll also see a pie chart of the top five finding types and a bar chart of findings by severity level.

Note your Detector ID and free trial status

Your Detector ID is a unique identifier for your GuardDuty instance. You'll need it if you ever interact with GuardDuty through the CLI or API.

Click Settings in the left navigation pane.
Find your Detector ID displayed on the page. Make a mental note of where it is for future reference.
Look for the 30-day free trial indicator. It shows your remaining trial days and estimated daily cost after the trial ends.

What does the free trial cover?

GuardDuty offers a 30-day free trial per region for new accounts. All protection plans are enabled by default during the trial (S3 Protection, EKS Protection, RDS Protection, Lambda Protection, and Malware Protection for EC2). Runtime Monitoring is the one exception and is not enabled by default.

You'll clean this up in the Before You Go section if you don't want charges after the trial period.

Your security monitoring system now has two layers: raw traffic capture through VPC Flow Logs and intelligent threat detection through GuardDuty. Next, you'll generate sample security findings to see what real threats look like in this system.

Generate and Review Sample Security Findings

In the previous step, you enabled GuardDuty and confirmed it is actively monitoring your account.

Now it is time to see what a real security alert looks like. Since your account likely has no actual threats, GuardDuty provides sample findings that simulate every type of threat it can detect. You will generate these samples, sort them by severity, and examine the details that a security analyst would review during an investigation.

In this step, get ready to:

Generate sample findings covering every threat type GuardDuty supports.
Sort and explore findings by severity level.
Open a High severity finding and review its full details including JSON format.

Generate sample findings in GuardDuty

GuardDuty can produce one sample finding for every threat type it supports. This gives you a safe, comprehensive preview of what real alerts look like without needing actual malicious activity in your account.

In the GuardDuty console, choose Settings in the left navigation pane.
Scroll down to the Sample findings section.
Choose Generate sample findings.

What does generating sample findings do?

This creates one sample finding for every finding type GuardDuty supports. Each sample is prefixed with [SAMPLE] in the console so you can distinguish them from real alerts.

The samples cover threats across EC2 instances, S3 buckets, IAM credentials, Kubernetes clusters, and more. They give you a complete picture of GuardDuty's detection capabilities.

You should see a brief confirmation banner indicating sample findings have been generated.

Don't see a confirmation?

Make sure you are on the Settings page (not Summary or Findings). The Generate sample findings button is specifically under the Sample findings heading on this page.

Help me find the Generate sample findings button in GuardDuty

Sort findings by severity

With dozens of sample findings now available, you need a way to focus on the most critical threats first. Sorting by severity surfaces the alerts that would demand immediate attention in a real environment.

In the left navigation pane, choose Findings.
The findings table displays all your sample findings, each prefixed with [SAMPLE].
Click the Severity column header to sort findings from highest to lowest severity.

What do severity levels mean?

GuardDuty assigns a numeric severity to each finding. Low severity ranges from 1.0 to 3.9, Medium from 4.0 to 6.9, and High from 7.0 to 8.9.

High severity findings represent active threats that need immediate investigation. Medium findings suggest suspicious activity worth reviewing. Low findings are informational and may not require action.

You should see High severity findings appear at the top of the list after sorting.

Examine a High severity finding in detail

Each finding contains structured data that tells you exactly what happened, which resource is affected, and who triggered the alert. This is the information a security analyst uses to decide how to respond.

Click the title of a High severity finding (such as one related to EC2 compromise or credential misuse) to open the finding details side panel.
In the details panel, review the Finding type field. This tells you what category of threat was detected.
Review the Severity field to see the numeric urgency rating.
Review the Resource affected section to identify which AWS resource is involved.
Review the Actor section to see who or what triggered the alert.
To view the complete JSON details, select the finding using its checkbox, then choose the Actions menu and select View and export JSON.

Why does the JSON format matter?

The JSON representation of a finding contains every data point GuardDuty captured about the threat. This is the format that automated tools, SIEM systems, and security orchestration platforms ingest for processing.

Key fields include type (the finding category), severity (numeric rating), resource (affected AWS resource details), and service (action details including remote IPs and API calls).

How are finding types named?

GuardDuty uses a structured naming format: ThreatPurpose:ResourceTypeAffected/ThreatFamilyName.DetectionMechanism. For example, Recon:EC2/PortProbeUnprotectedPort tells you an EC2 instance has an unprotected port being probed by a potential attacker.

You should see a JSON window displaying the full structured data for the finding, including nested objects for the resource, service, and action details.

Finding details panel not opening?

Make sure you are clicking the finding's title text (the blue hyperlinked text), not the checkbox next to it. The checkbox is for bulk actions. The title opens the details side panel.

Help me open a finding's detail panel in GuardDuty

You have now seen the full lifecycle of a security finding, from generation through detailed analysis. Next, you will investigate a specific alert and practice the resolution workflow that security professionals use daily.

Investigate and Resolve a Security Alert

You now have a full set of sample security findings to explore. In a real environment, each of these findings would represent a potential threat demanding your attention.

In this step, you will walk through the exact investigation and resolution workflow that security professionals use daily. You will open a high-severity finding, understand its context, and formally resolve it by archiving.

In this step, get ready to:

Locate and open a high-severity finding to read its details.
Practice the investigation workflow for determining if a threat is real.
Resolve the finding by archiving it and verifying the status change.

Locate and open a high-severity finding

Security teams prioritize findings by severity. A high-severity finding means something potentially dangerous is happening right now and needs immediate attention.

Return to the Findings page in the GuardDuty console.
Locate the finding titled [SAMPLE] UnauthorizedAccess:EC2/MaliciousIPCaller.Custom in your findings list.
Click the finding title to open its details side panel.
Read the Description section to understand what this alert means.
Review the Resource affected section to identify which EC2 instance would need investigation.

What does this finding mean?

The UnauthorizedAccess:EC2/MaliciousIPCaller.Custom finding tells you that an EC2 instance is communicating with a known malicious IP address. This could indicate that the instance has been compromised and is sending data to an attacker.

In a real scenario, this would be an urgent alert requiring immediate action to contain the threat and prevent data loss.

What is alert severity?

GuardDuty assigns a numeric severity to each finding. Low ranges from 1.0 to 3.9, Medium from 4.0 to 6.9, and High from 7.0 to 8.9. Security teams focus on high-severity findings first because they represent the most immediate threats.

Practice the investigation workflow

Finding a threat is only the first step. Security professionals follow a structured investigation process to determine whether the activity is genuinely malicious or a false positive.

With the finding details panel still open, review the Actor section to see the IP address and geolocation of the suspected threat.
Look for the filter icons (+ or - magnifying glass) next to finding details.
Click the + magnifying glass icon next to the resource ID to filter for all findings related to the same resource.
Click the + magnifying glass icon next to the actor IP to filter for all findings involving the same actor.

What would a real investigation look like?

In a production environment, you would check whether the traffic is legitimate. Perhaps a misconfigured application is calling an IP that was recently flagged as malicious.

You would also examine the VPC Flow Logs for that instance to see the full traffic pattern. Multiple connections to the same malicious IP over time would strengthen the case that the instance is compromised.

Filtering saves time during incidents

The + and - magnifying glass icons let you quickly narrow down findings to a single resource or actor. During a real incident, this helps you answer "is this an isolated event or part of a larger attack?" in seconds.

Resolve the alert by archiving it

Once an investigation is complete and remediation is confirmed, the final step is to archive the finding. This marks it as resolved and clears it from your active findings queue.

Close the details side panel by clicking anywhere outside it, or press the back arrow.
Select the finding by checking its checkbox on the left side of the row.
Click the Actions menu at the top of the findings table.
Select Archive.

The finding disappears from your current findings list. It has been moved to the archived state.

Switch the Status dropdown from Current to Archived at the top of the Findings page.
Verify that your [SAMPLE] UnauthorizedAccess:EC2/MaliciousIPCaller.Custom finding appears in the archived list.

Why archive instead of delete?

In GuardDuty, archiving is the standard way to resolve a finding. It moves the finding from your active queue to a historical record. You cannot delete findings entirely because the audit trail is important for compliance and post-incident reviews.

In a production environment, you would archive a finding only after confirming that remediation is complete. The instance has been isolated, credentials rotated, and the root cause addressed.

Can't find the finding after archiving?

Make sure you switched the Status dropdown to Archived. Archived findings do not appear under the Current filter. If you have many sample findings archived, use the search bar to filter by the finding type name.

Still having trouble? Help me find my archived GuardDuty finding

Secret mission

Set Up Automated Email Alerts for High-Severity Findings

Right now, you would have to manually check the GuardDuty console to see new findings. What if GuardDuty could email you the moment a high-severity threat is detected? In this secret mission, you will wire up Amazon EventBridge and SNS to send real-time email alerts whenever GuardDuty flags something urgent.

Clean Up Your Resources

This project uses AWS services that may incur charges after the 30-day GuardDuty free trial ends. Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Cost warning

After the 30-day free trial, GuardDuty charges based on data volume analyzed. VPC Flow Logs published to CloudWatch Logs also incur ingestion charges beyond the 5 GB free tier. If you are not actively using these services, choose Pause or Delete below to avoid unexpected charges.

Resources you used:

Amazon GuardDuty detector (30-day free trial, then pay-per-use based on data volume).
VPC Flow Log publishing to CloudWatch Logs (ingestion charges apply after free tier).
CloudWatch Logs log group vpc-flow-logs-security-monitoring (5 GB free ingestion, 5 GB free storage per month).
SNS topic guardduty-high-severity-alerts (free tier eligible).
Amazon EventBridge rule (free tier eligible).

Keep everything running

No action needed. Choose this if you are still actively exploring GuardDuty findings or experimenting with your security monitoring setup.

GuardDuty remains free for 30 days from the date you enabled it. Monitor your estimated costs on the GuardDuty **Settings** page.
VPC Flow Logs and CloudWatch Logs charges are minimal for a single VPC with low traffic.
SNS and EventBridge stay within their free tiers for this project's usage.

Pause - I'll come back to this later

Shut down active monitoring to stop incurring charges while keeping your configuration intact.

Suspend GuardDuty to stop charges while preserving your configuration. Navigate to the GuardDuty console, choose Settings in the navigation pane, then choose Suspend GuardDuty and confirm your action.
Delete the VPC Flow Log to stop CloudWatch Logs ingestion charges. Navigate to the VPC console, choose Your VPCs, select your default VPC, choose the Flow Logs tab, select the flow log, then choose Actions, Delete flow logs. Type delete to confirm.
Your CloudWatch log group, SNS topic, and EventBridge rule can stay. They do not generate ongoing charges when idle.

Delete - I don't want to use this again

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

Disable GuardDuty. Navigate to the GuardDuty console, choose Settings in the navigation pane, then choose Disable GuardDuty and confirm your action. This permanently deletes your findings and configuration.
Delete the VPC Flow Log. Navigate to the VPC console, choose Your VPCs, select your default VPC, choose the Flow Logs tab, select the flow log, then choose Actions, Delete flow logs. Type delete to confirm.
Delete the CloudWatch Logs log group. Open the CloudWatch console. In the navigation pane, choose Logs, then Log groups. Select the vpc-flow-logs-security-monitoring log group, then choose Actions, Delete. Confirm the deletion.
Delete the SNS topic. Open the SNS console. In the left navigation pane, choose Topics. Select the guardduty-high-severity-alerts topic, then choose Delete. In the confirmation dialog, enter delete me and choose Delete.
Delete the EventBridge rule. Open the EventBridge console. In the navigation pane, choose Rules. Select the rule you created for GuardDuty high-severity findings, then choose Delete and confirm.

That's a Wrap!

Nice work! You just built a real security monitoring system on AWS that detects threats and captures network traffic.

You've learned how to:

Configured VPC Flow Logs to capture network traffic metadata and enabled Amazon GuardDuty for intelligent threat detection across your AWS account.
Generated sample security findings and explored threat categories ranging from credential misuse to malicious IP communication.
Investigated a high-severity alert, reviewed its context and affected resources, and resolved it by archiving the finding.
Secret Mission: Set up automated email alerts for high-severity findings using Amazon EventBridge and SNS.

Ready to quiz yourself?