AWS says GuardDuty catches the universal attacks. The rest is your detection engineering.

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 ^[14]. None of the five detection services the post tells you to switch on first produces any of them ^[16]. 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 ^[13]. 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 ^[14]. 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 ^[10][9], with charging referred to the GuardDuty pricing page ^[11]. 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 ^[7]. 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 ^[8]. 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 ^[12]. 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 ^[15]. 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.