2026-08-25 | 0gulcandogan | Imported from Medium| 17 min read

Nothing Moves in AWS Without Someone Noticing: A Field Guide to Threat Detection

This time it’s Threat Detection, the “how does AWS even notice” half of the domain officially called Threat Detection and Incident Response. I’m deliberately stopping at the noticing part. What happens after a finding lands, the playbooks, the automated remediation, the actual incident response machinery, is its own beast and lives in its own notes. Mixing the two muddies both, so this one stays narrow on purpose: eight services whose entire job is watching, recording, and raising a hand.

Think of it as a surveillance system with very specific division of labor. Some pieces are the cameras. Some are the archive. One is the detective who actually reads the tape. Let’s meet the cast.

Let’s dive it🙌

Security Hub: The Situation Room

Security Hub doesn’t detect anything on its own, and that’s the first thing worth getting straight. It’s an aggregation layer. GuardDuty, Inspector, Macie, Firewall Manager, IAM Access Analyzer, SSM Patch Manager, they all forward findings here, and Security Hub normalizes them into one view instead of five browser tabs open at 2 AM. Under the hood it leans on AWS Config rules for its own continuous checks, and pushes results out through EventBridge, which is where the automation piece would live, if we were talking about automation.

Three standards get auto-checked the moment you enable it, and these show up on the exam by name, not by description:

AWS Foundational Security Best Practices v1.0, the baseline: MFA, password policy, no public S3 buckets
CIS AWS Foundations Benchmark v1.2, logging and monitoring fundamentals
PCI DSS v3.2.1, if card data is anywhere near your environment

The one sentence to keep: Security Hub is a detective control that aggregates other detective controls. It’s the situation room, not the field agent.

GuardDuty: The Watchdog That Never Sleeps

GuardDuty is the field agent. It runs two detection engines in parallel: Threat Intelligence, which cross-references your activity against known-bad IPs, domains, and URLs (feeds from AWS, CrowdStrike, Proofpoint, and others), and ML / Anomaly Detection, which builds a baseline of what “normal” looks like for your account and flags the moment something drifts from it.

Three data sources are mandatory the second you turn it on: VPC Flow Logs, CloudTrail (management and data events), and DNS query logs. Everything past that lives under an optional Protection Plan, and here’s the detail that actually trips people up: every protection plan is enabled by default, except one. EKS Runtime Protection needs an actual agent add-on installed on your cluster, so it’s the lone plan you flip on manually. EKS audit logs, by contrast, are automatic. Same service, two defaults, know which is which.

The finding-name syntax looks intimidating until you decode one:

ThreatPurpose:ResourceTypeAffected/ThreatFamilyName.DetectionMechanism!Artifact

CryptoCurrency:EC2/BitcoinTool.B!DNS reads as: cryptocurrency abuse, on an EC2 instance, from a known bitcoin-mining tool family, caught via a DNS lookup to a bad domain. Decode one and the rest read themselves.

Severity is numeric and worth memorizing exactly: 7.0–8.9 is High (assume compromise, act now), 4.0–6.9 is Medium (deviating from baseline, escalates if ignored), 1.0–3.9 is Low (already blocked, just a data point). Two oddly specific limits: only one active Trusted IP list per account per region, but up to six active Threat Lists at once, AWS clearly expects you to whitelist sparingly and blocklist liberally.

For multi-account setups, one account becomes the administrator, the rest become members, findings flow up automatically, linked either through AWS Organizations (recommended, via a delegated admin) or manual invitations for accounts outside the org. And the permissions gotcha worth remembering: AmazonGuardDutyFullAccess includes creating the Malware Protection service-linked role, but does not include permission to upload a Trusted IP or Threat List, that's a separate, narrower grant.

A real number to anchor all this: in us-east-1, 55 million CloudTrail events runs about $220/month, 500 GB of VPC Flow and DNS logs adds $500, S3 and EKS protection on top add a few more dollars, landing around $727/month total. Cheap insurance against finding out your S3 bucket has been quietly mining crypto for a month.

Diagram above walks through one realistic chain end to end: a leaked IAM access key, an EC2 instance spun up to mine crypto, and the GuardDuty finding that catches it. That’s the detection half everything up to the red GuardDuty box is what this post is actually about. Everything after it (Incident Manager, quarantine via Systems Manager, rebuilding from a trusted AMI, rotating the credential) is remediation, and that’s its own post with its own playbooks. It’s shown here so the picture doesn’t feel like it just stops the moment the alarm goes off.

Detective: The One Who Actually Reads the Case File

Amazon Detective exists for the moment “there’s a suspicious login” isn’t enough and you need to know what that login touched, what it talked to, and how far back it goes. It auto-ingests CloudTrail management events, VPC flow data, GuardDuty and Security Hub findings, and EKS audit logs, no separate CloudTrail or VPC Flow Log setup required, and builds it all into a behavior graph: entities (accounts, users, roles, IPs, instances) connected by relationships (an IP hitting an instance, a role assuming another role).

The prerequisite chain is a favorite exam trap: GuardDuty must already be enabled, and Detective can only be turned on 48 hours after that. It’s regional too, so multi-region workloads mean enabling it region by region, each with its own separate graph. Give it two weeks past that and it starts building a real historical baseline.

Numbers worth knowing: up to 1,200 member accounts per behavior graph, data retained for a full year, and pricing that scales with volume, AWS estimates roughly $1,000/month at 500 GB in us-east-1, climbing to $8,500 at 10,000 GB and $11,000 at 20,000 GB.

Finding Groups is the feature worth knowing about beyond the basics: it uses ML and graph analysis to collapse potentially thousands of individual findings into one connected security event, tagged with the actual tactics involved, initial access, privilege escalation, defense evasion, lateral movement, exfiltration. Instead of manually stitching forty findings into a story, Detective hands you the story already assembled.

Inspector: The Scanner With No Patience for Old CVEs

Amazon Inspector scans EC2, ECR container images, and Lambda for known vulnerabilities, and the architectural detail that matters is that the current version runs on the SSM Agent rather than a dedicated Inspector agent, the opposite of how the deprecated “Inspector Classic” worked. Discovery and scanning are fully automatic, nothing to schedule, if a resource changes, it gets rescanned on its own. Severity comes out in standard CVSS scoring against the National Vulnerability Database.

Findings live in one of three states, and the distinction is a favorite trap: Active means real and unresolved, Suppressed means you’ve explicitly hidden it (it’s still being generated, just not shown), and Closed means Inspector itself confirmed the fix, you never manually close a finding. Suppression hides visibility; it does nothing to the underlying detection.

AWS Config: The Ledger That Remembers Everything

AWS Config is off by default, the first real step is standing up a Config Recorder. Once running, every resource gets a Configuration Item: metadata, attributes, relationships to other resources, and the current configuration, all in JSON.

The distinction that consistently shows up on exams:

Configuration History, a timeline for one specific resource, delivered to S3 every six hours
Configuration Snapshot, a point-in-time capture of every resource in the account, on-demand or scheduled

Multi-account or multi-region visibility runs through an Aggregator, pulling everything into one place. Config Rules ship 320+ AWS-managed options across 55+ services, and compliance resolves to Compliant, Non-Compliant, or Insufficient Data (the rule never ran, a custom Lambda is silently failing, or the resource was deleted). Custom rules come from a Lambda function, optionally scaffolded with the Rule Development Kit, or from CloudFormation Guard, the one exception worth remembering: Config only evaluates resources that already exist (detective), while cfn-guard validates IaC templates before deployment (proactive).

The sentence worth remembering above all: Config never prevents a non-compliant resource from being created. It’s pure visibility, not a gatekeeper. That distinction alone answers a surprising number of exam questions.

CloudTrail: The Flight Recorder

CloudTrail logs every API call, split into three event types worth keeping straight: Management Events (account-level operations, on by default), Data Events (resource-level, like S3 GetObject, opted into separately because of volume), and Insight Events (anomalous Write API behavior, off by default and easy to forget exists).

Trails come in three flavors: All-Region (the recommended default), Single-Region (CLI-only, for deliberately narrow scope), and Organization Trail (created from the Management account, applying org-wide, member accounts can view but never modify it).

The number that catches people off guard: the console’s Event History only holds 90 days. Beyond that requires an actual Trail writing to S3 or CloudWatch Logs, which is exactly why Trails exist as a separate concept.

Inside each event, a handful of fields matter more than the rest: userIdentity (who), eventTime / eventSource / eventName (when, which service, which action), sourceIPAddress (from where), responseElements (success or failure), and readOnly, true for a read, false for a write, don't mistake false for an error. On the IAM side: CloudTrailServiceRolePolicy exists purely for CloudTrail's own service-linked role, AWSCloudTrail_FullAccess covers trail management plus its S3/SNS/CloudWatch/KMS dependencies, and AWSCloudTrail_ReadOnlyAccess limits you to Get, Describe, List, and LookupEvents.

CloudTrail Lake: Turning the Black Box Into a Queryable Database

CloudTrail Lake solves a specific annoyance: standard CloudTrail hands you a pile of JSON in S3, and real analysis normally means wiring up Athena or something similar yourself. Lake removes that step, an immutable data lake for CloudTrail events, CloudTrail Insights, and AWS Config items (plus third-party sources), queryable with plain SQL, retained for up to 10 years.

Setup is two steps. First, an Event Data Store: what to ingest, how long to keep it, which accounts and regions. The pricing choice here isn’t a formality: one-year extendable retention gives 366 days free before pay-as-you-go, and it’s the right call under 25 TB/month, with mixed sources like Config or third-party feeds, or when you need retention past seven years. Seven-year retention drops storage cost entirely and only bills ingestion, but only pays off past that 25 TB/month line. Picking the seven-year option on a low-volume account doesn’t save money, it just locks you into a window you don’t need.

Second, you query. SQL by hand, or plain English translated by generative AI if you know what you want but not the exact schema. Results visualize as bar, line, or pie charts, summarize automatically in plain text, and save for reuse. The billing detail worth remembering precisely: writing, saving, and AI-generating queries costs nothing, you’re only billed when you actually run one, based on data scanned per gigabyte.

CloudWatch: The Pulse Monitor

CloudWatch is the broader observability layer, and the piece we care about most here is turning CloudTrail data into actionable alerts. Take a failed console login: CloudTrail records it as a management event, a Metric Filter scans that CloudTrail log group for the pattern and counts it toward a threshold, and once we cross that threshold the Alarm moves out of OK. Alarms sit in one of three states: OK, ALARM, or INSUFFICIENT_DATA (just started, or not enough data yet for us to evaluate).

That state change doesn’t just sit there, CloudWatch automatically emits it as an event, and EventBridge is what we use to actually do something with it. A Rule filters incoming events (including alarm state changes) and fans them out to one or more Targets through an Event Bus, in our case SNS for a page, Lambda for auto-remediation, SQS for a queue another system picks up later, all from the same alarm, no extra wiring required on our end. Contributor Insights answers “who’s actually triggering this rule the most,” with CIS-aligned sample rules ready out of the box, and Log Insights gives us a purpose-built query language for digging through logs, exportable as CSV, JSON, or XLSX.

The pricing detail worth remembering: our first 3 dashboards and 50 metrics are free, every dashboard past that costs us $3/month. Trivial for an enterprise, but the kind of thing that quietly adds up on a personal test account.

Where the Story Actually Ends (For Now)

Line these eight up and a shape emerges: something generates signal (GuardDuty, Inspector, Config, CloudTrail), something aggregates and normalizes it (Security Hub, CloudWatch), something adds context and narrative (Detective, CloudTrail Lake). Notice what’s missing from that list: nothing here acts. Nobody isolates an instance, revokes a credential, or spins up a forensic snapshot. That’s the whole point of drawing the line here, detection is the part where AWS taps you on the shoulder. What you do next is a different domain entirely, with its own playbooks and its own automation.

References

Original: https://medium.com/@0gulcandogan/nothing-moves-in-aws-without-someone-noticing-a-field-guide-to-threat-detection-5e43a77e8a27?source=rss-746132cb79a8------2

#cloud-security #cybersecurity #aws-certification #threat-detection #aws

Thanks for reading

If this write-up helped, consider sharing it or exploring more of the log.

← All posts About the author