Lesson 176 · AWS Learning Path

AWS 176: Amazon GuardDuty

Anil Jalela · Published Dec 18, 2025 · 8 min read

Why this lesson matters

Use managed threat-detection findings from AWS data sources, then triage evidence without treating a finding as automatic proof of compromise.

What you will be able to do

By the end, you can:

• explain amazon guardduty in plain language;
• locate the current service controls in the AWS Management Console;
• run the matching CloudShell or AWS CLI queries and explain every important field;
• draw the identity, network, data, failure, and monitoring path;
• choose the service from requirements and reject it when those requirements are absent;
• diagnose a failed or misleading result from evidence;
• state the cost owner and prove cleanup or a no-create result.

Before you start

• Use a personal AWS account only when its owner has approved the lesson. Do not use the root user for daily work.
• CloudShell is the default command environment. AWS028 explains CloudShell; AWS029 and AWS030 explain local AWS CLI installation and profiles.
• The course example Region is ap-south-1. Global services and services with a required control Region are called out in their commands.
• Run aws sts get-caller-identity privately. Redact the account number before sharing evidence.
• Never paste access keys, passwords, secret values, private object data, presigned URLs, or full account-specific ARNs into a submission.
• This is a no-create lesson. Every Console action and AWS CLI command is read-only. Create the practical artifact locally.
• Console wording can change. Use the Console service search if a menu label has moved, then confirm the current field in the official documentation.

The core model

How the request flows

+------------------------------+
|  AWS activity and telemetry  |
+------------------------------+
               |
               v
+-----------------------+
|  GuardDuty detection  |
+-----------------------+
           |
           v
+----------------------------------+
|  Finding triage and correlation  |
+----------------------------------+
                 |
                 v
+----------------------------------------------+
|  Contained, remediated, and closed evidence  |
+----------------------------------------------+

Understand what GuardDuty actually does

GuardDuty is a regional threat-detection service. It analyzes AWS control-plane and workload telemetry and produces findings; it is not a firewall, vulnerability scanner, SIEM, antivirus replacement or automatic incident responder. Foundational analysis covers sources such as CloudTrail management events, VPC flow activity and DNS logs available to the service without requiring you to create duplicate log buckets. Protection plans add resource-specific telemetry and cost.

Current finding families also include attack-sequence/extended detection and other protection-specific findings. Do not memorize a frozen list: read the finding type, resource, service evidence, action, actor, severity and timestamps.

Organization and response architecture

Enable GuardDuty in every required Region, designate an Organizations delegated administrator, define member auto-enablement and protection-plan policy, then verify coverage rather than assuming organization membership means protection. Findings stay regional unless exported/aggregated through the designed operations path.

Send findings through EventBridge to a controlled response workflow such as Security Hub, ticketing, notification, Step Functions or a containment Lambda. Start automation with notification or reversible actions. Preserve evidence before isolating an instance, disabling a key or changing credentials. Suppression rules reduce expected noise; they must not hide unresolved risk. Trusted IP and threat lists affect selected detections and require owner/review dates.

Severity is a starting point. Prioritize business criticality, internet exposure, privilege, blast radius, repeated behavior and corroborating CloudTrail/flow/runtime evidence. Sample findings prove plumbing without creating an attack, but they do not prove each telemetry source has coverage.

Cost and coverage evidence

Protection plans have separate usage dimensions and trial behavior. Enabling GuardDuty can automatically enable several plans, while runtime and some malware plans require separate choices. Before organization rollout, estimate regional CloudTrail event volume, S3 events, flow/DNS activity, database capacity, Lambda network activity, runtime vCPU and malware scanning. Use the GuardDuty usage statistics and current pricing - not “30-day trial” - as production cost evidence.

Architecture decision table

AWS Management Console, step by step

Sign in with the normal non-root learning identity. Write the expected starting state before opening the service.

1. Use the Console service search and open GuardDuty, Summary, Findings, Accounts, and Protection plans; confirm the account and Region before reading the page.
2. Inspect the supplied or owned resource's status, configuration, permissions, networking, encryption, monitoring, tags, and dependencies without changing it.
3. Open the related metrics, logs, events, or history view and record one timestamped signal that would prove or disprove the expected behavior.
4. Return to the resource list, clear filters, and record the final inventory. On the read-only track, do not choose Create, Save, or Delete.

CloudShell and AWS CLI, step by step

Start with a known caller and Region:

export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws configure list

Redact the account part of the ARN in shared evidence. Now run the topic queries:

aws guardduty list-detectors --output table
DETECTOR_ID='replace-with-detector-id'
aws guardduty list-findings --detector-id "$DETECTOR_ID" --finding-criteria '{"Criterion":{"service.archived":{"Eq":["false"]}}}' --max-results 20 --output table

Expected interpretation

A finding includes type, severity, resource, action, service evidence, timestamps, and occurrence count. Triage must correlate it with CloudTrail, network, workload, identity, and owner context.

Practical work

Triage a supplied unauthorized-access finding. Record severity, affected resource, observed action, first and last seen, evidence sources, containment owner, false-positive test, remediation, and closure condition.

Diagnose this topic from its own evidence

• No findings does not prove safety. Check detector status, Region, member relationship, plan configuration, coverage status and telemetry eligibility.
• A finding that disappears may be archived or suppressed; inspect finding ID, service archived state and suppression rules.
• Runtime gaps require resource-level coverage status, agent mode, OS/platform support, VPC endpoint/network path and tag exclusions.
• EventBridge delivery failures require rule pattern, event bus, target role/resource policy, retry/DLQ and target logs.
• During triage, record finding ID/type, first/last seen, count, actor, resource, remote endpoint, action and every containment change.

Cost and cleanup

Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.

Knowledge check

1. What operational purpose is this lesson solving?

Expected direction: Use managed threat-detection findings from AWS data sources, then triage evidence without treating a finding as automatic proof of compromise.

1. Which scope or ownership boundary must be proved first?

Expected direction: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Amazon GuardDuty.

1. What evidence is strong enough to accept the result?

Expected direction: Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Amazon GuardDuty.

1. Which tempting design or shortcut must be rejected?

Expected direction: Avoid auto-deleting resources from a single uncorroborated finding or enabling paid protection without account-owner approval.

1. Which cost dimensions and retained resources need an owner?

Expected direction: Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.

Lesson acceptance

• Distinguish GuardDuty detection from Inspector vulnerability scanning, Macie data discovery, Security Hub aggregation and firewall enforcement.
• Map each enabled protection plan to data source, resource coverage, cost owner and response owner.
• Explain regional and organization administration boundaries and prove member/coverage state.
• Triage a supplied finding without treating severity or ARCHIVED as closure.
• Design a reversible EventBridge response path with evidence retention and failure handling.

Official sources

• GuardDuty User Guide
• GuardDuty findings
• GuardDuty protection plans and pricing dimensions
• Active finding types
• AWS security documentation
• Security Pillar