# Threat Detection with GuardDuty and Inspector

> Chapter 11 of the Courseiva AWS-SECURITY-SPECIALTY curriculum — https://courseiva.com/learn/aws-security-specialty/guardduty-and-inspector

**Official objective:** 4.1 — Design and implement threat detection services

## Introduction

Threat detection is the practice of continuously monitoring your cloud environment for malicious activity and security weaknesses. For the SCS-C02 exam, you need to understand how AWS GuardDuty and Inspector help you discover threats and vulnerabilities so you can respond before a breach happens.

## The House Security System and Home Inspector Analogy

Your house sits on a quiet street. You have a security system (GuardDuty) that watches the doors, windows, and motion sensors 24/7 to detect if someone is trying to break in or if a window is left open. It sends you an alert the moment it spots anything unusual.

Separately, you hire a home inspector (Inspector) once a year to walk through your entire house. They check the roof for leaks, test the smoke alarms, look for faulty wiring, and examine the foundation for cracks. The inspector gives you a detailed report of what's vulnerable — things that could become a problem later even if no one is trying to break in right now.

So the security system spots active threats as they happen: someone jiggling the back door at 2am. The home inspector finds weaknesses that could be exploited later: a frayed electrical cord behind the sofa that could start a fire. In AWS, GuardDuty does the active threat detection — looking for suspicious network traffic, unusual API calls, or compromised instances. Inspector does the vulnerability scanning — checking your EC2 instances and container images for missing patches, insecure configurations, or known software vulnerabilities. Together they give you both real-time alerts and a proactive health check.

## Core explanation

Let's start with the big picture. In AWS, you run your applications on virtual servers called EC2 instances, store data in S3 buckets, and manage permissions with IAM roles. But how do you know if someone is doing something bad inside your account? How do you know if one of your EC2 instances has a software vulnerability that hackers could exploit? That is where GuardDuty and Inspector come in.

GuardDuty is a threat detection service. It analyses data from multiple sources — CloudTrail logs (which record API calls), VPC Flow Logs (which capture network traffic), and DNS logs (which show domain name requests). GuardDuty uses machine learning and known threat intelligence to identify patterns that look like an attack. For example, if an EC2 instance suddenly starts talking to a known malicious IP address in Russia, GuardDuty flags it. If an IAM user makes API calls from a location where they have never logged in before, GuardDuty raises an alert. It does this without you installing any software on your instances — it just works by scanning the existing logs and metadata.

Now, Inspector is different. Inspector is a vulnerability management service. It scans your EC2 instances, container images in Amazon ECR, and your network configuration for security issues. It looks for things like missing security patches, misconfigured network access (like a security group that allows SSH from 0.0.0.0/0), and known software vulnerabilities (CVEs). Inspector generates a finding report that tells you the severity of each issue and how to fix it. You can run Inspector scans on a schedule (e.g., every week) or trigger them when new instances launch.

The key difference is timeline. GuardDuty detects threats that are happening right now or have already happened. Inspector finds weaknesses that could allow a future threat to succeed. You need both for complete security.

How do they work together? Suppose Inspector finds that you are running an old version of a web server with a known vulnerability. Later, an attacker scans the internet, finds your vulnerable server, and exploits it. GuardDuty detects the exploit because it sees unusual outbound traffic from that server to a command-and-control server. Now you have two findings: Inspector's vulnerability report (the weak spot) and GuardDuty's threat alert (the exploitation in progress). You use both to understand the full picture and fix the root cause.

Let's define some technical terms you will see in the exam:

- Finding: An alert or report generated by GuardDuty or Inspector about a potential security issue.
- Severity: A rating (High, Medium, Low) that tells you how critical the issue is.
- CVE: Common Vulnerabilities and Exposures — a standard list of known software vulnerabilities.
- CloudTrail: A service that records every API call made in your AWS account.
- VPC Flow Logs: Records of network traffic in your Virtual Private Cloud.
- EC2 Instance: A virtual server in the cloud.
- Security Group: A virtual firewall that controls traffic to and from your instances.

Both services are regional. That means you must enable them in each AWS Region where you want protection. They are also integrated with AWS Security Hub, which aggregates findings from multiple security services into one dashboard.

Why does this matter for your exam? The SCS-C02 exam tests whether you understand the difference between threat detection (GuardDuty) and vulnerability scanning (Inspector). It tests whether you know what data sources each service uses, how to enable them, and how to interpret findings. You will also need to know about multi-account setups — you can enable GuardDuty and Inspector across all accounts in an AWS Organisation using delegated administrator accounts.

In summary: GuardDuty sees the bad guy trying the door. Inspector tells you your door lock is broken. Use both to keep your cloud house secure.

## Real-world context

Imagine you work as a cloud security analyst for a medium-sized e-commerce company. Your company runs its website on EC2 instances behind a load balancer, stores customer data in S3, and uses IAM roles for permissions. You have just been tasked with implementing threat detection across your AWS environment. Here is exactly what you would do step by step.

First, you enable GuardDuty in the AWS Console for your primary region. You go to the GuardDuty dashboard, click 'Enable GuardDuty', and it starts analysing your CloudTrail, VPC Flow Logs, and DNS logs for free for the first 30 days. You notice that GuardDuty immediately starts generating findings — mostly low-severity things like 'Unusual pattern of API calls from a known Tor exit node'. You investigate and find it is just a developer who uses Tor for privacy. You suppress that finding to reduce noise.

Next, you enable Inspector. You go to the Inspector console and create a scan target — which EC2 instances to scan. You install the SSM Agent on your instances (which Inspector requires to scan the operating system). You create a scan schedule: every Sunday at 2am to minimise impact on production traffic. The first scan reveals 15 vulnerabilities: three high-severity CVEs in your web server software, ten medium-severity misconfigurations (like port 22 open to the world), and two low-severity items. You prioritise the high-severity CVE patches and apply them via AWS Systems Manager Patch Manager.

Now, three weeks later, you get a GuardDuty finding with High severity: 'UnauthorisedAccess:EC2/SSHBruteForce'. Someone is trying to brute-force the SSH password on one of your instances. You check Inspector's findings and see that this instance still has port 22 open to the internet (a misconfiguration Inspector already flagged). You immediately update the security group to restrict SSH access to only your office IP range. The brute-force attempt stops. You then create a Jira ticket to patch the root cause — the open SSH port.

You also set up AWS Security Hub to aggregate findings from both GuardDuty and Inspector into a single dashboard. You create automated responses using EventBridge rules: for example, when a High-severity GuardDuty finding appears, it triggers a Lambda function that isolates the compromised instance by changing its security group.

Over time, you tune both services. You exclude known safe IP addresses from GuardDuty's threat intelligence. You create custom Inspector rules to check for company-specific compliance requirements (e.g., PCI-DSS). You enable GuardDuty in every region where your company operates, using a delegated administrator account in AWS Organizations so you can manage all accounts from one place.

In a real business, security is never a one-time task. Your team reviews GuardDuty findings weekly and Inspector reports monthly. You integrate them into your incident response plan: if a Critical finding appears, the on-call engineer gets paged immediately. This combination of real-time threat detection and proactive vulnerability scanning is exactly what companies need to meet compliance frameworks like SOC 2, ISO 27001, and HIPAA.

## Exam focus

The SCS-C02 exam has a dedicated domain for threat detection, and GuardDuty and Inspector are the two most heavily tested services in that domain. Based on the official exam guide and real question patterns, here is exactly what you need to know.

First, the exam will ask you to distinguish between GuardDuty and Inspector. A common question scenario: 'A security engineer wants to detect if EC2 instances are communicating with known malicious IP addresses. Which service should they use?' The answer is GuardDuty. Another scenario: 'A company needs to identify missing security patches on their EC2 instances. Which service?' The answer is Inspector. Memorise this: GuardDuty = threat detection (bad behaviour happening now). Inspector = vulnerability scanning (weaknesses that could be exploited).

The exam also tests the data sources each service uses:

- GuardDuty analyses: CloudTrail management events, CloudTrail S3 data events, VPC Flow Logs, DNS logs, and EKS audit logs.
- Inspector scans: EC2 instances (via SSM Agent), Amazon ECR container images, and network configurations (security groups, network ACLs).

You need to know that GuardDuty does not require you to install any agent — it works by scanning logs that are already generated. Inspector does require the SSM Agent to be installed on EC2 instances for operating system scans.

Another trap in the exam: they love to test 'multi-account' and 'multi-region' setups. GuardDuty and Inspector can both be enabled across multiple accounts using a delegated administrator in AWS Organizations. The delegated administrator manages all member accounts from one place. You must know that this is separate from simply enabling the service in each account individually.

The exam will also test integration with other services:

- GuardDuty findings can be sent to AWS Security Hub, Amazon EventBridge, and AWS Lambda for automated remediation.
- Inspector findings can also be sent to Security Hub and EventBridge.
- Both can be integrated with AWS Systems Manager for patch management (Inspector identifies the missing patch, Systems Manager applies it).

Key definitions to memorise:

- Finding: A security issue (threat or vulnerability) detected by the service.
- Severity levels: GuardDuty uses Critical, High, Medium, Low. Inspector uses High, Medium, Low. Critical in GuardDuty means active compromise is likely.
- CVE: The standard identifier for known vulnerabilities — Inspector scans for CVEs.
- Suppression rule: A way to automatically archive low-value findings (e.g., known safe IPs).

You also need to understand that GuardDuty has a 30-day free trial in each region, after which you pay per volume of logs analysed. Inspector has a free tier for network scans, but EC2 and ECR scans are paid.

Finally, the exam will test your understanding of 'pricing' and 'enablement'. For example: 'A company wants to enable GuardDuty in all regions for all accounts. What is the most efficient way?' The answer: Enable GuardDuty as a delegated administrator in AWS Organizations and automatically enrol new accounts. This is a classic correct answer pattern.

Traps to watch out for:

- Confusing GuardDuty with Amazon Macie (which detects sensitive data in S3). The exam loves to offer Macie as a distractor for GuardDuty questions.
- Thinking Inspector can scan on-premises servers — it cannot (only EC2 and ECR).
- Assuming GuardDuty generates findings instantly — there is a latency of a few minutes while logs are analysed.
- Forgetting that both services are regional — a common wrong answer is 'enable GuardDuty globally' when you actually need to enable it per region.

## Step by step

1. **Enable GuardDuty in a Single Region** — Go to the GuardDuty console and click 'Enable GuardDuty'. This activates the service in that region, which starts analysing your existing CloudTrail and VPC Flow Logs for suspicious activity. No further setup is required.
2. **Review Initial GuardDuty Findings** — After a few minutes, GuardDuty will generate findings. Each finding includes a severity level, a description, and recommended actions. You should review the first batch to understand what is normal for your environment.
3. **Configure GuardDuty Suppression Rules** — If you receive false positives (e.g., alerts for known safe tools like a VPN), create suppression rules to automatically archive those findings. This reduces noise and helps you focus on real threats.
4. **Enable Inspector and Create a Scan Target** — In the Inspector console, create a scan target by selecting which EC2 instances (by tag or name) you want to scan. Ensure the SSM Agent is installed on those instances. Then create a scan schedule (e.g., weekly) and start the initial scan.
5. **Remediate Inspector Findings** — Inspector generates a list of vulnerabilities and misconfigurations. Prioritise the highest severity ones — typically critical CVEs or open ports. Apply patches via AWS Systems Manager Patch Manager or update security groups directly.
6. **Set Up Cross-Account and Cross-Region Management** — If you have multiple AWS accounts, designate a delegated administrator account in AWS Organizations. This allows you to enable GuardDuty and Inspector across all accounts and regions from a single point.

## Comparisons

### GuardDuty vs Inspector

**GuardDuty:**
- Detects active threats like brute-force attacks or compromised instances
- Analyses CloudTrail, VPC Flow Logs, and DNS logs
- Agentless — no installation required on EC2 instances

**Inspector:**
- Finds vulnerabilities like missing patches or open ports
- Scans EC2 instances, ECR images, and network configurations
- Requires SSM Agent for OS-level scanning on EC2 instances

### Trial Period vs Permanent Usage

**Trial Period:**
- GuardDuty offers 30-day free trial per region
- Inspector has a free tier for network scans only
- After trial, you pay based on log volume or scan count

**Permanent Usage:**
- Both services can run continuously after the free period
- Costs are incurred monthly for ongoing protection
- Budget alerts can help manage costs

### Single Account Setup vs Multi-Account via Organizations

**Single Account Setup:**
- You enable the service manually in each account and region
- Suitable for small, single-account environments
- Findings are visible only in that account's dashboard

**Multi-Account via Organizations:**
- Use a delegated administrator to manage all accounts centrally
- Automatically enables the service for new accounts
- Findings from all accounts appear in one dashboard

## Diagram

_Diagram showing how GuardDuty and Inspector collect data from different sources and send findings to AWS Security Hub._

```mermaid
flowchart TD
    A[AWS Environment] --> B[GuardDuty]
    A --> C[Inspector]
    B --> D[CloudTrail Logs]
    B --> E[VPC Flow Logs]
    B --> F[DNS Logs]
    F --> G[Detects Active Threats]
    E --> G
    D --> G
    C --> H[EC2 Instances]
    C --> I[ECR Container Images]
    C --> J[Network Configs]
    H --> K[Finds Vulnerabilities]
    I --> K
    J --> K
    G --> L[AWS Security Hub]
    K --> L
```

## Common misconceptions

- **Misconception:** GuardDuty scans your EC2 instances for malware by installing an agent on them. **Reality:** GuardDuty does not scan instances directly. It analyses CloudTrail logs, VPC Flow Logs, and DNS logs to detect suspicious behaviour. It never installs anything on your instances. (People often think threat detection requires an agent because antivirus software on laptops does that. GuardDuty's agentless approach is unique and often misunderstood.)
- **Misconception:** Inspector and GuardDuty both detect the same types of threats, just in different ways. **Reality:** GuardDuty detects active threats (e.g., brute-force attacks, unusual API calls). Inspector finds vulnerabilities (e.g., missing patches, open ports). They serve completely different purposes. (Both are security services, so beginners assume they are redundant. The exam explicitly tests the difference.)
- **Misconception:** You must enable GuardDuty in every AWS account manually, one at a time. **Reality:** You can use AWS Organizations to automatically enable GuardDuty across all accounts from a delegated administrator account. Manual per-account setup is inefficient. (Many people learn about GuardDuty in a single-account tutorial and never consider the multi-account management feature.)
- **Misconception:** Inspector can scan any resource, including RDS databases and Lambda functions. **Reality:** Inspector only scans EC2 instances, ECR container images, and network configurations. Database security is covered by other services like Amazon RDS Security Hub or AWS Trusted Advisor. (The name 'Inspector' sounds like it inspects everything, so beginners overgeneralise its scope.)
- **Misconception:** GuardDuty findings are always accurate and never produce false positives. **Reality:** GuardDuty uses machine learning and can generate false positives. You need to tune it with suppression rules and whitelists for known safe behaviour. (Security vendors market their products as 'intelligent', so beginners believe alerts are always true. In reality, false positives are common in cloud security.)

## Key takeaways

- GuardDuty detects active threats (like brute-force attacks) by analysing CloudTrail, VPC Flow Logs, and DNS logs without installing any agents.
- Inspector finds vulnerabilities (like missing patches and open ports) on EC2 instances and container images, requiring the SSM Agent for OS scans.
- Both services are regional and must be enabled in each AWS Region where you need protection.
- The most efficient way to enable GuardDuty or Inspector across multiple accounts is through a delegated administrator in AWS Organizations.
- GuardDuty and Inspector integrate with AWS Security Hub, EventBridge, and Lambda for centralised management and automated responses.
- A common exam trap is confusing GuardDuty (threat detection) with Amazon Macie (sensitive data discovery) or Inspector (vulnerability scanning).

## FAQ

**Do I need to install anything on my EC2 instances for GuardDuty to work?**

No. GuardDuty is agentless — it analyses CloudTrail logs, VPC Flow Logs, and DNS logs that AWS already generates. You only need to install the SSM Agent for Inspector scans.

**Can GuardDuty detect someone stealing data from an S3 bucket?**

Yes, if the data exfiltration involves unusual API calls (like downloading a large number of objects from a new IP address). GuardDuty analyses CloudTrail S3 data events to detect such anomalies.

**How often does Inspector scan my instances?**

You define a schedule — common choices are daily or weekly. You can also trigger a scan manually or automatically when a new instance launches.

**What is the difference between a GuardDuty 'finding' and an Inspector 'finding'?**

A GuardDuty finding indicates a potential active threat (like a brute-force attack). An Inspector finding indicates a vulnerability (like a missing security patch). Both are security issues but from different phases.

**Is Inspector free to use?**

Inspector has a free tier for network reachability scans (checking open ports). EC2 instance scans and ECR container image scans incur charges based on the number of images and instance hours scanned.

**Can I use GuardDuty and Inspector together with other AWS security services?**

Yes, both integrate with AWS Security Hub to aggregate findings, and with Amazon EventBridge to trigger automated actions (like isolating a compromised instance via Lambda).

## Check your understanding

1. **A security team wants to detect if any EC2 instances in their environment are communicating with known malicious IP addresses. Which AWS service should they use?**

   Answer: GuardDuty, because it analyses VPC Flow Logs and DNS logs to identify connections to malicious IPs using threat intelligence.

2. **What data sources does AWS GuardDuty analyse to generate findings? (Name at least three.)**

   Answer: CloudTrail management and data events, VPC Flow Logs, and DNS logs. (Also EKS audit logs.)

3. **A company wants to identify missing security patches on their EC2 instances. Should they use GuardDuty or Inspector?**

   Answer: Inspector, because it performs vulnerability scanning of EC2 instances and checks for missing patches and CVEs.

4. **What is the most efficient way to enable GuardDuty across 50 AWS accounts?**

   Answer: Use a delegated administrator account in AWS Organizations to automatically enable GuardDuty for all accounts and regions.

5. **If GuardDuty generates a 'High' severity finding for an EC2 instance, what does that indicate?**

   Answer: It indicates a likely active threat, such as a brute-force attack or communication with a command-and-control server, requiring immediate investigation.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/aws-security-specialty/guardduty-and-inspector