Threat Detection via SDK Best Practices

Q: Do GuardDuty and Security Hub need separate multi-account setup?

Yes. Each has its own EnableOrganizationAdminAccount call and its own delegated administrator designation - delegating one does not delegate the other.

Alert triage workflow and finding-suppression hygiene.

This is the checklist to run through when standing up or auditing GuardDuty and Security Hub via SDK. Each item is a rule stated positively with a one-line rationale, grouped from coverage outward through triage, automation, cost, and multi-account operations. Work top to bottom - get detection coverage right first, then build the triage and automation on top of it.

How to Use This List

Treat each box as an audit question against your own threat-detection setup.
Groups run roughly in order of foundation: coverage first, then triage, automation, cost, and multi-account scale.
Most rules apply whether you are running a single account or an Organizations-wide deployment.
Revisit the list whenever you add a region, a new data source, or a remediation automation.

A - Coverage & Enablement

Enable GuardDuty in every region you operate in. It is a regional service; a detector in us-east-1 sees nothing happening in eu-west-1.
Enable Security Hub alongside GuardDuty, not instead of it. Security Hub aggregates and scores; it has no detection logic of its own.
Turn on optional data sources deliberately. S3 protection, EKS audit logs, and Malware Protection each add coverage and cost - enable per actual risk, not uniformly by default.
Subscribe to at least one Security Hub standard. AWS Foundational Security Best Practices is a reasonable default starting point; add CIS AWS Foundations Benchmark if your compliance framework references it.
Verify enablement with GetDetector/DescribeHub, not assumption. Confirm Status is ENABLED and data sources are actually on before relying on the coverage.

B - Reading & Triaging Findings

Filter server-side with FindingCriteria/Filters. Query by severity, type, or compliance status instead of pulling every finding and filtering client-side.
Sort by severity for triage queues. Use SortCriteria on ListFindings so the highest-severity items surface first.
Batch GetFindings calls correctly. Both GuardDuty and Security Hub cap finding-ID batches per call - chunk large ID lists instead of hitting the limit.
Match finding-type prefixes, not exact strings. New finding types are added over time; category-prefix matching keeps routing code from silently missing new types.
Treat NOT_AVAILABLE compliance status as its own case. It means a check could not run (often a permissions gap), not a pass or a fail - investigate separately.

Read findings efficiently with server-side filtering and pagination.

# --- Python (boto3) ---
import boto3
 
guardduty = boto3.client("guardduty", region_name="us-east-1")
 
paginator = guardduty.get_paginator("list_findings")
high_severity_ids = []
for page in paginator.paginate(
    DetectorId="<detector-id>",
    FindingCriteria={"Criterion": {"severity": {"Gte": 7}}},
):
    high_severity_ids.extend(page["FindingIds"])
 
print(f"{len(high_severity_ids)} high-severity findings")

// --- TypeScript (AWS SDK v3) ---
import { GuardDutyClient, ListFindingsCommand } from "@aws-sdk/client-guardduty";
 
const guardduty = new GuardDutyClient({ region: "us-east-1" });
let nextToken: string | undefined;
const highSeverityIds: string[] = [];
 
do {
  const page = await guardduty.send(new ListFindingsCommand({
    DetectorId: "<detector-id>",
    FindingCriteria: { Criterion: { severity: { Gte: 7 } } },
    NextToken: nextToken,
  }));
  highSeverityIds.push(...(page.FindingIds ?? []));
  nextToken = page.NextToken;
} while (nextToken);
 
console.log(`${highSeverityIds.length} high-severity findings`);

C - Suppression & Noise Reduction

Use suppression filters for known-benign recurring findings. A saved filter with Action: "ARCHIVE" handles a pattern automatically instead of manual re-archiving every occurrence.
Archive, don't ignore. Findings you have triaged as accepted risk should be explicitly archived so they stop cluttering active views but remain retrievable by ID.
Review suppression rules periodically. A rule created for a since-remediated situation can quietly hide a real recurrence of the same finding type.
Never suppress by severity alone. Suppressing "everything under severity 4" can also hide the early, low-severity signal of a developing incident - suppress specific known patterns instead.
Document why each suppression exists. A filter with no rationale attached becomes a mystery the next time someone audits alert coverage.

D - Automated Response

Filter EventBridge rules by severity and/or finding-type prefix. A rule matching every GuardDuty finding will trigger automation on informational noise, not just real threats.
Scope the remediation Lambda's IAM role tightly. Grant only the specific actions and, where possible, specific resource ARNs the function needs - it is a high-value target if abused.
Make remediation idempotent. GuardDuty can republish an existing finding as activity accumulates; a remediation function should check current state before acting again.
Log every automated action with a visible trail. Fully silent automation makes it hard to know what happened or to reverse a wrong call - post to SNS or a chat webhook alongside the remediation.
Route different finding types to different, narrow functions. One large catch-all Lambda handling EC2 isolation and IAM revocation both is harder to reason about and to scope permissions for.

E - Cost & Multi-Account Operations

Watch data-source volume, not just finding count. S3 protection, EKS audit logs, and Malware Protection bill by volume analyzed - a large estate enabling all of them everywhere can be a meaningful cost line.
Centralize via Organizations delegated administrator, not per-account dashboards. EnableOrganizationAdminAccount plus auto-enable configuration scales far better than manual CreateMembers/InviteMembers per account.
Remember GuardDuty and Security Hub delegate independently. Enabling one service's delegated admin does not enable the other - set up both if you want centralized visibility for each.
Choose ALL vs NEW auto-enable modes deliberately. "NEW" only covers accounts that join after the setting is applied; use "ALL" (or a one-time sweep) to also cover existing accounts.
Track compliance scores per standard, not blended. Each Security Hub standard scores independently - report and alert on them separately rather than as one merged number.

FAQs

What's the minimum viable setup for a new account?

Enable GuardDuty in every region you operate in, enable Security Hub with at least AWS Foundational Security Best Practices, and confirm both with a status check before relying on the coverage.

How do I avoid drowning in low-value findings?

Filter and sort server-side by severity, and use suppression filters for specific known-benign patterns you have already triaged - never suppress broadly by severity range alone.

What's the biggest risk with automated remediation?

An overly broad IAM role on the remediation Lambda. Scope it to the exact actions and resources it needs, since a compromised or buggy remediation function with wide permissions is itself a serious risk.

Do GuardDuty and Security Hub need separate multi-account setup?

Yes. Each has its own EnableOrganizationAdminAccount call and its own delegated administrator designation - delegating one does not delegate the other.

How do I keep automation from firing on every finding?

Scope the EventBridge rule's event pattern with a severity threshold and/or a finding-type prefix match, so only trusted categories and severities reach the remediation function.

Should I track one compliance score or several?

Several. Each Security Hub standard (CIS, FSBP, etc.) computes its own score from its own controls - report them individually rather than blending into a single number.

What's the difference between archiving and suppression filters?

Archiving is a one-off action on findings you have already reviewed. A suppression filter automates that same action going forward for a defined, recurring pattern, so you are not manually re-archiving the same thing repeatedly.

Is the legacy CreateMembers/InviteMembers flow still worth using?

Only for small, static account sets. For anything that grows over time, Organizations-based auto-enable configuration removes the manual per-account invitation step entirely.

Threat Detection Basics - the enable-and-list flow in group A and B.
GuardDuty Detectors & Finding Types - the severity and type filtering behind group B.
Automated Response to GuardDuty Findings - the automation rules in group D in depth.
Multi-Account Security Aggregation via Organizations - the delegated-admin setup in group E.

Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).

Threat Detection via SDK Best Practices

Alert triage workflow and finding-suppression hygiene.

How to Use This List

Treat each box as an audit question against your own threat-detection setup.
Groups run roughly in order of foundation: coverage first, then triage, automation, cost, and multi-account scale.
Most rules apply whether you are running a single account or an Organizations-wide deployment.
Revisit the list whenever you add a region, a new data source, or a remediation automation.

A - Coverage & Enablement

Enable GuardDuty in every region you operate in. It is a regional service; a detector in us-east-1 sees nothing happening in eu-west-1.
Enable Security Hub alongside GuardDuty, not instead of it. Security Hub aggregates and scores; it has no detection logic of its own.
Turn on optional data sources deliberately. S3 protection, EKS audit logs, and Malware Protection each add coverage and cost - enable per actual risk, not uniformly by default.
Subscribe to at least one Security Hub standard. AWS Foundational Security Best Practices is a reasonable default starting point; add CIS AWS Foundations Benchmark if your compliance framework references it.
Verify enablement with GetDetector/DescribeHub, not assumption. Confirm Status is ENABLED and data sources are actually on before relying on the coverage.

B - Reading & Triaging Findings

Filter server-side with FindingCriteria/Filters. Query by severity, type, or compliance status instead of pulling every finding and filtering client-side.
Sort by severity for triage queues. Use SortCriteria on ListFindings so the highest-severity items surface first.
Batch GetFindings calls correctly. Both GuardDuty and Security Hub cap finding-ID batches per call - chunk large ID lists instead of hitting the limit.
Match finding-type prefixes, not exact strings. New finding types are added over time; category-prefix matching keeps routing code from silently missing new types.
Treat NOT_AVAILABLE compliance status as its own case. It means a check could not run (often a permissions gap), not a pass or a fail - investigate separately.

Read findings efficiently with server-side filtering and pagination.

# --- Python (boto3) ---
import boto3
 
guardduty = boto3.client("guardduty", region_name="us-east-1")
 
paginator = guardduty.get_paginator("list_findings")
high_severity_ids = []
for page in paginator.paginate(
    DetectorId="<detector-id>",
    FindingCriteria={"Criterion": {"severity": {"Gte": 7}}},
):
    high_severity_ids.extend(page["FindingIds"])
 
print(f"{len(high_severity_ids)} high-severity findings")

// --- TypeScript (AWS SDK v3) ---
import { GuardDutyClient, ListFindingsCommand } from "@aws-sdk/client-guardduty";
 
const guardduty = new GuardDutyClient({ region: "us-east-1" });
let nextToken: string | undefined;
const highSeverityIds: string[] = [];
 
do {
  const page = await guardduty.send(new ListFindingsCommand({
    DetectorId: "<detector-id>",
    FindingCriteria: { Criterion: { severity: { Gte: 7 } } },
    NextToken: nextToken,
  }));
  highSeverityIds.push(...(page.FindingIds ?? []));
  nextToken = page.NextToken;
} while (nextToken);
 
console.log(`${highSeverityIds.length} high-severity findings`);

C - Suppression & Noise Reduction

Use suppression filters for known-benign recurring findings. A saved filter with Action: "ARCHIVE" handles a pattern automatically instead of manual re-archiving every occurrence.
Archive, don't ignore. Findings you have triaged as accepted risk should be explicitly archived so they stop cluttering active views but remain retrievable by ID.
Review suppression rules periodically. A rule created for a since-remediated situation can quietly hide a real recurrence of the same finding type.
Never suppress by severity alone. Suppressing "everything under severity 4" can also hide the early, low-severity signal of a developing incident - suppress specific known patterns instead.
Document why each suppression exists. A filter with no rationale attached becomes a mystery the next time someone audits alert coverage.

D - Automated Response

Filter EventBridge rules by severity and/or finding-type prefix. A rule matching every GuardDuty finding will trigger automation on informational noise, not just real threats.
Scope the remediation Lambda's IAM role tightly. Grant only the specific actions and, where possible, specific resource ARNs the function needs - it is a high-value target if abused.
Make remediation idempotent. GuardDuty can republish an existing finding as activity accumulates; a remediation function should check current state before acting again.
Log every automated action with a visible trail. Fully silent automation makes it hard to know what happened or to reverse a wrong call - post to SNS or a chat webhook alongside the remediation.
Route different finding types to different, narrow functions. One large catch-all Lambda handling EC2 isolation and IAM revocation both is harder to reason about and to scope permissions for.

E - Cost & Multi-Account Operations

Watch data-source volume, not just finding count. S3 protection, EKS audit logs, and Malware Protection bill by volume analyzed - a large estate enabling all of them everywhere can be a meaningful cost line.
Centralize via Organizations delegated administrator, not per-account dashboards. EnableOrganizationAdminAccount plus auto-enable configuration scales far better than manual CreateMembers/InviteMembers per account.
Remember GuardDuty and Security Hub delegate independently. Enabling one service's delegated admin does not enable the other - set up both if you want centralized visibility for each.
Choose ALL vs NEW auto-enable modes deliberately. "NEW" only covers accounts that join after the setting is applied; use "ALL" (or a one-time sweep) to also cover existing accounts.
Track compliance scores per standard, not blended. Each Security Hub standard scores independently - report and alert on them separately rather than as one merged number.

FAQs

What's the minimum viable setup for a new account?

Enable GuardDuty in every region you operate in, enable Security Hub with at least AWS Foundational Security Best Practices, and confirm both with a status check before relying on the coverage.

How do I avoid drowning in low-value findings?

Filter and sort server-side by severity, and use suppression filters for specific known-benign patterns you have already triaged - never suppress broadly by severity range alone.

What's the biggest risk with automated remediation?

Do GuardDuty and Security Hub need separate multi-account setup?

Yes. Each has its own EnableOrganizationAdminAccount call and its own delegated administrator designation - delegating one does not delegate the other.

How do I keep automation from firing on every finding?

Scope the EventBridge rule's event pattern with a severity threshold and/or a finding-type prefix match, so only trusted categories and severities reach the remediation function.

Should I track one compliance score or several?

Several. Each Security Hub standard (CIS, FSBP, etc.) computes its own score from its own controls - report them individually rather than blending into a single number.

What's the difference between archiving and suppression filters?

Is the legacy CreateMembers/InviteMembers flow still worth using?

Only for small, static account sets. For anything that grows over time, Organizations-based auto-enable configuration removes the manual per-account invitation step entirely.

Threat Detection Basics - the enable-and-list flow in group A and B.
GuardDuty Detectors & Finding Types - the severity and type filtering behind group B.
Automated Response to GuardDuty Findings - the automation rules in group D in depth.
Multi-Account Security Aggregation via Organizations - the delegated-admin setup in group E.

Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).

Threat Detection via SDK Best Practices

Search Documentation

Threat Detection via SDK Best Practices