Loading today’s stories
Build1 distinct publisher3 min readPublished
A new AWS guide draws its coverage line at patterns common to every account, and hands the account-specific half back to the customer as CloudWatch queries.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Read the post's definition of business context closely, because it names four datasets rather than a mindset: which buckets hold sensitive data, which principals have a reason to touch which resources, which role chains your policy permits, and when production change windows open [15]. None of the five detection services the post tells you to switch on first produces any of them [7]. They are yours to build and yours to keep current, and that maintenance is the part that never appears in a service tier.
AWS is direct about the split. GuardDuty handles the threats that look the same in every account, and the context that makes a given action suspicious in yours is what you provide [14]. That is a claim about universality, not difficulty. A burst of List and Describe calls ending in AccessDenied looks identical in any account [3]; whether the identity making them had any business there is a lookup against a table only you hold [15]. Extended Threat Detection is already on wherever GuardDuty is on, needs no queries from you, and arrives with MITRE ATT&CK mapping, a timeline and remediation guidance [11][10], with charging referred to the GuardDuty pricing page [12]. The half you cannot buy is the half with no pricing page.
The order the post recommends carries a staffing consequence. It tells you to turn the services on and tune them before building anything custom, and defines tuning as three continuing jobs: adjusting sensitivity to cut false positives, choosing which data sources each service watches, and suppressing findings for known-good patterns [8]. Read as a work queue, custom correlation sits behind an item that never closes.
The worked example also does not sit neatly on the line the post draws. GuardDuty's base description names CloudTrail, VPC Flow Logs, DNS query logs and S3 data events [5]; the Extended Threat Detection description names CloudTrail, S3 data events, runtime monitoring and EKS audit logs [9]. The example's third stage is a large volume of data leaving toward a domain registered last week [3], which is network and DNS evidence. Both service descriptions end with "and more" [17], so a reader cannot tell from this post whether the default-on correlation covers that leg or whether it is theirs to write.
One detail decides how much of this is real engineering. Attack sequence findings appear in the GuardDuty console beside other findings and route into Security Hub and response workflows the same way [13]. Anything you correlate yourself has to land in the same place, or analysts triage two queues in two formats. The post starts you in CloudWatch Logs Insights and closes by describing how to grow the examples into an automated pipeline [16]. That is the handover: queries you can run this afternoon, and a scheduled job with state, thresholds and its own failure modes if you want the detection to hold.
Ranked by verification strength, evidence, and original report placement.
AWS published a security blog post titled "Detecting multi-stage attacks on AWS: A guide to cross-service signal correlation", aimed at security engineers and security operations teams who run AWS detection services and want to catch patterns specific to their environment.
The post's framing: a single alert from one security service tells you something happened; reading that signal alongside activity from other services and your own business context tells you whether it is part of a multi-stage attack.
The post's example sequence: an identity calls GetCallerIdentity from a source address it has not previously used; within minutes the same identity runs a burst of List and Describe calls across several services, some failing with AccessDenied; soon after, a large volume of data leaves the environment toward a domain registered last week.
Amazon GuardDuty might already flag pieces of that sequence, such as the reconnaissance from an unfamiliar source, through finding types like Recon:IAMUser/* or Discovery:S3/*.
Amazon GuardDuty analyzes activity across AWS CloudTrail, Amazon VPC Flow Logs, DNS query logs, Amazon S3 data events and more, and produces high confidence findings out of the box.
Alongside GuardDuty the post lists Amazon Detective (graph-based investigation context across services and accounts), AWS Security Hub (aggregates findings into a single prioritized dashboard), Amazon Security Lake (centralizes security data in OCSF format for long-term analysis) and Amazon Inspector (correlates vulnerability data with workload context).
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Detailed but wholly first-party
The single supplied source is a primary vendor document that is technically specific — named finding types, named data sources per service, console navigation, prerequisites, multi-account caveats — which makes the descriptive claims about AWS's own products highly credible. But every factual anchor is self-reported by the service owner, with no independent testing, benchmark, customer report or second publisher in the cluster, and no efficacy data behind characterizations like 'high confidence findings out of the box'. The post also leaves a coverage question raised by its own example unresolved.
No adoption data supplied
The cluster contains no deployment counts, customer references, telemetry, revenue or third-party usage evidence. AWS's statement that Extended Threat Detection is default-on for existing GuardDuty customers describes a distribution mechanism, not measured uptake, and the supplied material gives no size for the GuardDuty base or any indication that readers built the described correlations.
Mildly overstated, largely self-limiting
The post is unusually restrained for vendor content: it explicitly bounds its own product ('GuardDuty handles the threats that look the same in every account') and hands the remainder back to the reader, and it defers cost rather than claiming savings. The modest positive gap comes from unevidenced quality language such as 'high confidence findings out of the box' and 'correlates multi-stage attacks for you', combined with hedged, non-identical data-source lists that let the reader assume broader default coverage than the text establishes, and from silence on the real operational cost of the customer-owned query layer it recommends.
Vendor promoting its own paid detection stack
The sole source is AWS writing about AWS. The guide's prescribed first step is enabling and tuning five AWS paid services, its recommended correlation surface is CloudWatch Logs Insights (with Athena and Security Lake as fallbacks), and cost is handled by linking to the GuardDuty pricing page. Increased enablement, log delivery and query volume all accrue to the publisher, and no third-party or competing tooling is considered.
Solid on what was said, thin on independent validation
Confidence is high that the guide exists and says what is recorded here — the source is primary, dated and quoted directly — so the descriptive claims are dependable. It is materially lower on whether the described detection actually performs as characterized, because the cluster has one publisher, no adoption measurement, no efficacy figures and an unresolved coverage ambiguity in the vendor's own example.
build
AWS detection gets a shortlist: seven ATT&CK tactics, and only what has been seen in the wild1 distinct publisher
build
AWS gives software supply chain its own Security Hub category, with two vendors in it1 distinct publisher
build
GuardDuty says exfiltration and the patch is four hours out: revoke the sessions first1 distinct publisher
build
Jumio's sub-100ms feature store is mostly a consistency build, not a speed build1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 26, 2026