Threat detection: GuardDuty, SCC & Defender
Managed detection, findings pipelines, and alert quality.
Writing every detection rule yourself does not scale across accounts and services. The managed detectors — GuardDuty, Security Command Center, Defender for Cloud — analyze logs, flow, DNS, and threat intelligence to raise prioritized findings, so your effort goes into turning those findings into action rather than into building the analytics from scratch.
Turn it on everywhere, automatically
The single biggest failure mode is partial coverage: detection enabled in some accounts and regions but not others, leaving blind spots exactly where a quiet attacker wants to live. Enable the detector org-wide and set new accounts to auto-enroll, so coverage is a property of the organization rather than a checklist someone forgets. Aggregate findings into your security-tooling account for one place to triage.
# Delegate GuardDuty to the security account, then auto-enable every account# and every future account — no per-account manual step to forget.aws guardduty enable-organization-admin-account --admin-account-id 333333333333aws guardduty update-organization-configuration \--detector-id DET123 --auto-enable-organization-members ALL \--features '[{"Name":"RUNTIME_MONITORING","AutoEnable":"ALL"}]'# Route findings to a pipeline instead of a console nobody watches:aws events put-rule --name guardduty-highsev \--event-pattern '{"source":["aws.guardduty"],"detail":{"severity":[{"numeric":[">=",7]}]}}'
Findings pipeline and alert quality
A finding that lands only in a dashboard is a finding nobody acts on. Route them into a pipeline — SIEM for correlation, SOAR or an events rule for automated first response — and treat alert quality as a first-class concern. Tune out the known-benign, deduplicate, and prioritize by severity and asset criticality so responders spend attention on what matters. High-severity findings can trigger automated containment: isolate a resource, revoke a session, or open an incident, in seconds.