This chapter covers two critical AWS security services: Amazon Inspector and Amazon GuardDuty. Both are essential for the SOA-C02 exam under Domain 4.2 (Security), and together they appear in approximately 5-8% of exam questions, often in scenario-based questions asking which service to use for a given requirement. Inspector is a vulnerability management service that scans workloads for software vulnerabilities and unintended network exposure. GuardDuty is a threat detection service that continuously monitors for malicious activity using machine learning and threat intelligence. Understanding their differences, integration points, and exam-specific nuances is vital for passing the SysOps Administrator Associate exam.
Jump to a section
Imagine a corporate office building with two security systems. First, an undercover inspector (Amazon Inspector) walks through the building, checking every door lock, window latch, and alarm sensor against a master checklist of known vulnerabilities. They identify weak spots like outdated locks or missing alarms, and report them to management. This inspector works on a schedule or when triggered by a change, and their reports are detailed but not real-time. Second, a security guard (GuardDuty) monitors live camera feeds and access logs 24/7, looking for suspicious behavior: someone tailgating through a door, an employee accessing a restricted area at 3 AM, or a known threat actor's face appearing on camera. The guard uses machine learning and threat intelligence to spot anomalies and immediately alerts security. The guard does not fix vulnerabilities; they detect ongoing threats. Together, the inspector finds weaknesses before they are exploited, and the guard catches attacks as they happen. In AWS, Inspector scans EC2 instances and container images for vulnerabilities, while GuardDuty analyzes logs (VPC Flow Logs, CloudTrail, DNS) to detect malicious activity. Both services integrate with EventBridge for automated response, but they serve different purposes: Inspector is proactive (find vulnerabilities), GuardDuty is reactive (detect threats).
What is Amazon Inspector?
Amazon Inspector is an automated vulnerability management service that continuously scans AWS workloads for software vulnerabilities and unintended network exposure. It was re-launched in 2021 with a new architecture that supports both EC2 instances and container images stored in Amazon ECR. The service uses a risk-based scoring approach to prioritize findings, helping you focus on the most critical issues.
How Inspector Works Internally
Inspector operates by deploying an AWS-managed agent (the SSM Agent) on EC2 instances to collect system configuration and software inventory. For EC2, Inspector integrates with AWS Systems Manager to gather data without requiring a separate agent installation. The scanning process involves: - Network Reachability: Inspector analyzes network configurations (security groups, network ACLs, VPCs) to determine if instances are exposed to the internet or have unintended access paths. It uses a graph-based analysis of your VPC topology to simulate network paths. - Software Vulnerability Assessment: Inspector compares the software inventory (packages, versions) from each instance against a continuously updated database of known vulnerabilities (CVEs). It also checks for common misconfigurations like missing patches or outdated software. - Container Image Scanning: For container images in ECR, Inspector scans the image layers at rest and during push/pull operations. It extracts software bill of materials (SBOM) and matches against vulnerability databases.
Key Components and Defaults
Inspector Agent: For EC2, the SSM Agent must be installed and configured with appropriate permissions. Inspector uses Systems Manager Inventory to collect data.
Findings: Each vulnerability or network exposure is a finding. Findings include severity (Critical, High, Medium, Low), CVE ID, CVSS score, and remediation guidance.
Risk Score: Inspector calculates a risk score (0-10) based on CVE severity, exploitability, network reachability, and instance context.
Scan Frequency: By default, Inspector scans EC2 instances every 24 hours. Container images are scanned on push and then daily.
Integration: Findings can be sent to AWS Security Hub, EventBridge, and S3. You can also trigger automated remediation via EventBridge and Lambda.
Configuring Inspector
To enable Inspector, you navigate to the Inspector console and choose "Enable Inspector". It automatically discovers EC2 instances and ECR repositories in the account and region. You do not need to install an agent manually for EC2 if SSM Agent is present and the instance has appropriate IAM role (AmazonSSMManagedInstanceCore). For container scanning, ensure ECR scanning is enabled.
What is Amazon GuardDuty?
Amazon GuardDuty is a threat detection service that uses machine learning, anomaly detection, and integrated threat intelligence to identify malicious and unauthorized activity in your AWS environment. It continuously analyzes multiple data sources: VPC Flow Logs (for network traffic), AWS CloudTrail event logs (for API activity), and DNS logs (for domain name queries). GuardDuty does not deploy agents or require network changes—it works by consuming existing logs.
How GuardDuty Works Internally
GuardDuty processes data streams from three primary sources: - VPC Flow Logs: It analyzes network traffic metadata (source/destination IP, ports, protocols) to detect patterns like port scanning, unusual traffic to known bad IPs, or data exfiltration attempts. - CloudTrail Events: It monitors management and data events, looking for anomalous API calls, such as an IAM user creating resources in an unusual region, or a root user logging in after a long period. - DNS Logs: It analyzes DNS queries from EC2 instances, detecting communication with command-and-control (C&C) servers or domains associated with malware.
GuardDuty uses a combination of rule-based detection (e.g., known malicious IP lists) and machine learning models (e.g., baseline behavior for each account) to generate findings. Findings are categorized by severity: High, Medium, Low.
Key Components and Defaults
Data Sources: VPC Flow Logs (must be enabled for GuardDuty to analyze), CloudTrail (management events are enabled by default; data events for S3 are optional but recommended), DNS logs (automatically enabled if VPC DNS resolution is enabled).
Findings: Each finding includes a unique ID, severity, type (e.g., Backdoor:EC2/C&CActivity.B!DNS), resource involved, and detailed evidence.
Threat Intelligence: GuardDuty uses AWS-curated threat intelligence feeds including known malicious IPs, domains, and URLs.
Trusted IP Lists and Threat Lists: You can upload your own trusted IP lists (to suppress findings) and threat lists (to add custom threats).
Integration: Findings are sent to Security Hub, EventBridge, and can be forwarded to third-party SIEMs.
Configuring GuardDuty
Enabling GuardDuty is a one-click operation in the console. It immediately starts analyzing the previous 7-14 days of CloudTrail and VPC Flow Logs (if available). You can configure findings export to S3, set up EventBridge rules for automated response, and manage trusted/threat lists.
How They Interact
Inspector and GuardDuty complement each other. Inspector identifies vulnerabilities (weaknesses), while GuardDuty detects active threats (exploitation attempts). Both integrate with Security Hub for a unified view. For example, if GuardDuty detects a suspicious connection from an EC2 instance, you can use Inspector to check if that instance has any critical vulnerabilities that might have been exploited.
Exam-Specific Details
SOA-C02 Objective 4.2: "Implement and manage security services: AWS Inspector, AWS GuardDuty." The exam tests your ability to choose the correct service for a scenario, understand their capabilities, and know how to enable and configure them.
Common Trap: Candidates often confuse Inspector (vulnerability scanning) with GuardDuty (threat detection). Another trap is thinking Inspector requires its own agent—it uses SSM Agent.
Default Values: Inspector scans EC2 every 24 hours; GuardDuty generates findings within minutes of detecting an anomaly.
Pricing: Inspector is billed per instance scan and per image scan; GuardDuty is billed per GB of CloudTrail events and per GB of VPC Flow Logs analyzed, with a free trial of 30 days.
Commands and Verification
You can use AWS CLI to list findings:
aws inspector2 list-findings --region us-east-1aws guardduty list-findings --detector-id <id> --region us-east-1To enable Inspector2:
aws inspector2 enable --account-ids <account-id> --resource-types EC2 ECRTo enable GuardDuty:
aws guardduty create-detector --enable --region us-east-1Enable Inspector in Console
Navigate to the Amazon Inspector console and click 'Enable Inspector'. This activates the service for the current region and account. Inspector automatically discovers all EC2 instances and ECR repositories. Behind the scenes, it creates a service-linked role (AWSServiceRoleForAmazonInspector2) that grants permissions to read instance metadata, inventory, and network configurations. No immediate action is required on instances if SSM Agent is installed and the instance has an IAM role with AmazonSSMManagedInstanceCore policy. Inspector begins scanning within minutes.
Inspector Scans EC2 and ECR
Inspector collects software inventory from EC2 instances via SSM Agent every 24 hours. It also analyzes network configurations to determine internet exposure. For container images in ECR, it scans on push and then daily. The scanning engine compares software versions against a continuously updated CVE database. Findings are generated with severity levels: Critical, High, Medium, Low. Each finding includes the CVE ID, CVSS score, and a risk score (0-10) that incorporates network reachability and exploitability.
Enable GuardDuty in Console
Navigate to the GuardDuty console and click 'Enable GuardDuty'. This creates a detector (a logical container for findings) in the region. GuardDuty immediately starts analyzing CloudTrail events, VPC Flow Logs (if enabled), and DNS logs. It can process up to 7 days of historical data. A service-linked role (AWSServiceRoleForAmazonGuardDuty) is created. You can optionally configure trusted IP lists and threat lists to customize detection.
GuardDuty Analyzes Logs
GuardDuty continuously ingests and processes logs. VPC Flow Logs are analyzed for network anomalies (e.g., port scans, unusual outbound traffic). CloudTrail events are analyzed for API call anomalies (e.g., unusual region, root user activity). DNS logs are analyzed for queries to known malicious domains or suspicious patterns. Machine learning models establish a baseline of normal behavior per account and detect deviations. Findings are generated with a severity (High, Medium, Low) and a finding type (e.g., 'UnauthorizedAccess:EC2/SSHBruteForce').
Review Findings and Remediate
Both Inspector and GuardDuty send findings to AWS Security Hub (if enabled) and Amazon EventBridge. You can create EventBridge rules to trigger Lambda functions for automated remediation, such as isolating an instance by modifying security groups or sending notifications via SNS. For Inspector, you might patch vulnerabilities or update security groups. For GuardDuty, you might terminate compromised instances or rotate credentials. Findings are retained for 90 days in the service console.
Enterprise Scenario 1: Compliance-Driven Vulnerability Management
A financial services company must comply with PCI DSS, which requires regular vulnerability scans. They deploy Amazon Inspector across all EC2 instances in production and development accounts. Inspector is configured to scan every 24 hours and send findings to Security Hub. The security team uses the risk score to prioritize patching. They also enable Inspector for container images in ECR to scan before deployment. A common issue is that some instances lack the SSM Agent, causing them to be marked as 'Unsupported' and not scanned. The team uses Systems Manager to install the agent via Run Command. They also set up EventBridge rules to trigger a Lambda function that automatically creates a Jira ticket for new Critical findings.
Enterprise Scenario 2: Real-Time Threat Detection for a SaaS Provider
A SaaS provider uses GuardDuty to monitor for compromised instances. They enable VPC Flow Logs and CloudTrail (including S3 data events). GuardDuty detects an instance making DNS queries to a known C&C domain. The finding is sent to EventBridge, which triggers a Lambda function that isolates the instance by modifying its security group to deny all traffic except to a forensic instance. The security team investigates and finds the instance was compromised via an unpatched vulnerability. They use Inspector to scan all instances for the same vulnerability and patch them. GuardDuty also detects brute force SSH attempts from a public IP; the team adds that IP to a custom threat list to block future attempts via network ACLs.
Scenario 3: Multi-Account Management with AWS Organizations
A large enterprise uses AWS Organizations with hundreds of accounts. They enable GuardDuty at the organization level using delegated administrator. This allows centralized management and visibility of findings across all accounts. They also enable Inspector across all accounts using a StackSet. A common pitfall is that GuardDuty's detector is regional, so they must enable it in each region where they operate. They use AWS Config rules to enforce that GuardDuty is enabled in all regions. They also aggregate findings in a central Security Hub account. Performance consideration: GuardDuty's cost scales with log volume; they estimate costs based on expected CloudTrail and VPC Flow Logs volume.
What the SOA-C02 Tests
Objective 4.2 (Security) specifically tests your ability to:
Differentiate between Inspector (vulnerability scanning) and GuardDuty (threat detection).
Know the prerequisites: Inspector requires SSM Agent (or Systems Manager integration) for EC2; GuardDuty requires VPC Flow Logs and CloudTrail to be enabled.
Understand integration: Both send findings to Security Hub and EventBridge.
Know that Inspector scans containers in ECR; GuardDuty does not scan containers directly.
Recognize that Inspector is proactive (find vulnerabilities before they are exploited) and GuardDuty is reactive (detect ongoing threats).
Common Wrong Answers
Using GuardDuty to scan for vulnerabilities: Candidates confuse the two services. GuardDuty does not scan for CVEs; it detects threats via log analysis.
Thinking Inspector requires a separate agent: Inspector uses the SSM Agent already present on EC2. The exam might present a scenario where the SSM Agent is missing, and the correct answer is to install it.
Believing GuardDuty can scan on-premises servers: GuardDuty only analyzes AWS logs (CloudTrail, VPC Flow Logs, DNS). It cannot monitor on-premises resources unless logs are forwarded to AWS.
Assuming Inspector scans in real-time: Inspector scans every 24 hours (or on push for containers). It is not real-time.
Specific Numbers and Terms
Inspector risk score: 0-10.
GuardDuty finding retention: 90 days.
GuardDuty free trial: 30 days.
Inspector scan interval: 24 hours for EC2, on push and daily for ECR.
GuardDuty analyzes logs from the past 7-14 days on enablement.
Finding types: e.g., 'Backdoor:EC2/C&CActivity.B!DNS', 'UnauthorizedAccess:EC2/SSHBruteForce'.
Edge Cases
GuardDuty with no VPC Flow Logs: GuardDuty still works but loses network-based detection. The exam might ask what data sources are used.
Inspector on instances without SSM Agent: Instances appear as 'Unsupported' and are not scanned. The solution is to install SSM Agent.
Multi-region: Both services are regional. Enable them in each region where you have resources.
AWS Organizations: GuardDuty can be enabled at the organization level with a delegated administrator. Inspector can be deployed via StackSets.
How to Eliminate Wrong Answers
When given a scenario:
If the requirement is to detect known vulnerabilities (CVEs), choose Inspector.
If the requirement is to detect suspicious behavior (e.g., brute force, malware), choose GuardDuty.
If the requirement is to scan container images, choose Inspector (not GuardDuty).
If the requirement is to monitor API calls, choose GuardDuty (it uses CloudTrail).
Inspector scans EC2 every 24 hours; container images on push and daily.
GuardDuty analyzes CloudTrail, VPC Flow Logs, and DNS logs for threats.
Inspector uses SSM Agent on EC2; GuardDuty is agentless.
Both integrate with Security Hub and EventBridge for centralized management and automation.
Inspector is for vulnerability management; GuardDuty is for threat detection.
GuardDuty findings are retained for 90 days.
Inspector risk score ranges from 0 to 10.
GuardDuty offers a 30-day free trial.
Enable both services in each region where you have resources.
For multi-account setups, use AWS Organizations to centrally manage GuardDuty and Inspector delegation.
These come up on the exam all the time. Here's how to tell them apart.
Amazon Inspector
Proactive vulnerability scanning for EC2 and ECR.
Uses SSM Agent for EC2; no agent for ECR.
Scans every 24 hours (EC2) or on push (ECR).
Generates findings with CVSS scores and risk scores.
Focuses on software vulnerabilities and network exposure.
Amazon GuardDuty
Reactive threat detection using log analysis.
No agents required; analyzes CloudTrail, VPC Flow Logs, DNS.
Near-real-time detection (minutes).
Generates findings with severity (High, Medium, Low) and threat intelligence.
Focuses on malicious activity (brute force, C&C, anomaly).
Mistake
Inspector requires a separate agent to be installed on EC2 instances.
Correct
Inspector uses the AWS Systems Manager Agent (SSM Agent) which is pre-installed on many Amazon Linux and Windows AMIs. If the SSM Agent is present and the instance has the appropriate IAM role, no additional agent is needed.
Mistake
GuardDuty can detect vulnerabilities in EC2 instances.
Correct
GuardDuty is a threat detection service, not a vulnerability scanner. It analyzes logs for malicious activity (e.g., brute force, C&C communication) but does not check for software vulnerabilities. For vulnerability scanning, use Inspector.
Mistake
Inspector provides real-time scanning of EC2 instances.
Correct
Inspector scans EC2 instances every 24 hours by default. It is not real-time. For near-real-time threat detection, use GuardDuty.
Mistake
GuardDuty requires you to enable VPC Flow Logs manually.
Correct
GuardDuty can analyze VPC Flow Logs if they are enabled, but it also works without them (using only CloudTrail and DNS logs). However, network-based detection is limited without Flow Logs.
Mistake
Both Inspector and GuardDuty can be used to scan on-premises servers.
Correct
Inspector can scan on-premises servers if they are managed by Systems Manager (Hybrid Activations) and have SSM Agent. GuardDuty only analyzes AWS-native logs (CloudTrail, VPC Flow Logs, DNS) and cannot directly monitor on-premises resources.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Amazon Inspector is a vulnerability management service that scans EC2 instances and container images for software vulnerabilities and unintended network exposure. It is proactive and runs scans every 24 hours. Amazon GuardDuty is a threat detection service that continuously monitors AWS logs (CloudTrail, VPC Flow Logs, DNS) for malicious activity using machine learning and threat intelligence. It is reactive and detects threats in near-real-time. For example, Inspector finds missing patches, while GuardDuty detects a brute force attack.
Inspector uses the AWS Systems Manager Agent (SSM Agent) to collect system inventory. The SSM Agent is pre-installed on many official Amazon AMIs. If your EC2 instance does not have the SSM Agent, you must install it. Additionally, the instance must have an IAM role with the AmazonSSMManagedInstanceCore policy. Inspector does not require a separate proprietary agent.
No, GuardDuty does not scan container images for vulnerabilities. It analyzes VPC Flow Logs, CloudTrail events, and DNS logs to detect malicious activity such as unusual network traffic or API calls. For vulnerability scanning of container images in ECR, use Amazon Inspector.
Amazon Inspector scans EC2 instances every 24 hours by default. You can also initiate an on-demand scan. For container images in ECR, scanning occurs on push and then daily. The scan interval is not configurable for EC2; it is fixed at 24 hours.
GuardDuty analyzes three primary data sources: AWS CloudTrail management and data events, VPC Flow Logs (if enabled), and DNS logs. It uses these logs to build a baseline of normal activity and detect anomalies. It also integrates with AWS-curated threat intelligence feeds.
GuardDuty integrates with Amazon EventBridge. You can create EventBridge rules that match specific finding types (e.g., 'UnauthorizedAccess:EC2/SSHBruteForce') and trigger AWS Lambda functions. The Lambda function can automate remediation, such as modifying security groups to isolate the instance, terminating instances, or rotating credentials. Findings are also sent to AWS Security Hub for centralized management.
Yes, but only if the on-premises servers are managed by AWS Systems Manager via Hybrid Activations. The server must have the SSM Agent installed and be registered as a managed instance. Once registered, Inspector can scan it just like an EC2 instance. However, network reachability analysis is limited to the VPC context.
You've just covered AWS Inspector and GuardDuty — now see how well it sticks with free SOA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?