AWS Amazon Detective Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Security, identity, and compliance

by

Category

Security, identity, and compliance

1. Introduction

Amazon Detective is an AWS security investigation service that helps you analyze, investigate, and quickly identify the root cause of potential security issues or suspicious activity in your AWS environment.

In simple terms: when a security service like Amazon GuardDuty or AWS Security Hub raises an alert, Amazon Detective helps you “connect the dots” across users, IPs, instances, and API activity so you can understand what happened and what to do next—without manually pulling logs from many places.

Technically, Amazon Detective builds and maintains a regional “behavior graph” from supported AWS telemetry and findings (for example, GuardDuty findings and related activity such as AWS CloudTrail and VPC flow information—verify current supported data sources/regions in official docs). It then provides entity profiles, timelines, relationship visualizations, and guided investigation workflows so analysts can pivot from a finding to the affected resources and the surrounding activity.

Problem it solves: security investigations in AWS often require time-consuming correlation across CloudTrail, network telemetry, and multiple security tools. Amazon Detective reduces investigation time by centralizing and correlating relevant signals into an investigation-ready view.

2. What is Amazon Detective?

Official purpose: Amazon Detective helps you analyze and investigate security issues by providing visualizations and context built from AWS security data so you can determine the nature and scope of suspicious activities more efficiently.
Official docs: https://docs.aws.amazon.com/detective/

Core capabilities

  • Behavior graph: A managed data model that organizes relationships and activity among AWS resources and identities.
  • Investigation workflows: Start from a finding and pivot through related entities and events.
  • Entity context: Profiles, timelines, and relationship views for resources such as IAM principals, EC2 instances, and IP addresses (exact entity types vary—verify in official docs).
  • Finding triage: Tools to group or review related findings (for example, GuardDuty finding groups—verify current availability and naming in your region).

Major components

  • Behavior graph (regional): The core data store and analytics layer for investigations.
  • Administrator account: The AWS account that enables and manages Amazon Detective for a region (often your central security account).
  • Member accounts: Additional AWS accounts added to the behavior graph (commonly via AWS Organizations).
  • Data sources: Supported security telemetry and findings that Detective uses to populate the graph (GuardDuty findings are a common starting point; verify current supported sources).
  • Console experience: The primary interface for investigations and visual analysis.
  • APIs/SDKs: For automation (for example, membership management, graph listing).

Service type

  • Managed security investigation and analytics service (not a SIEM, not an IDS/IPS).
  • Works best paired with detection services (for example, Amazon GuardDuty) and centralized alerting/aggregation (for example, AWS Security Hub).

Scope: regional vs global

Amazon Detective is regional. You enable it per region by creating/enabling a behavior graph in that region. For multi-region environments, you typically enable it in each region where you want investigation coverage.

How it fits into the AWS ecosystem

Amazon Detective sits in the Security, identity, and compliance category and complements: – Amazon GuardDuty for threat detection – AWS Security Hub for centralized findings and security posture aggregation – AWS CloudTrail for API activity history – Amazon VPC Flow Logs for network flow visibility
Detective helps you investigate after detection/alerting by providing correlation, context, and investigation tooling.

3. Why use Amazon Detective?

Business reasons

  • Reduce mean time to investigate (MTTI): Less time spent gathering and correlating logs.
  • Improve incident response consistency: Repeatable investigation workflows and shared context across teams.
  • Lower operational overhead: Fewer custom scripts and ad-hoc log pulls for common investigation tasks.

Technical reasons

  • Correlation across telemetry: Pivots from a finding to related API calls, network activity, and involved entities (based on supported data).
  • Entity-centric investigation: Investigate “who/what” (IAM principal, instance, IP) rather than searching raw logs first.
  • Works well in multi-account AWS environments: Central security teams can investigate across accounts via membership.

Operational reasons

  • Better on-call experience: Faster triage when alerts fire.
  • Investigation readiness: Graph-based context is continuously built, so you’re not starting from zero during an incident.
  • Supports central security operations: Aligns with AWS Organizations and delegated administration patterns (verify current delegated admin support in your org setup).

Security/compliance reasons

  • Improved auditability of investigations: Easier to justify conclusions with supporting activity context (note: you still need source logs for formal forensics).
  • Least-privilege investigations: Centralized read-only investigation access can reduce broad log access sprawl (design carefully).

Scalability/performance reasons

  • Managed scale: You don’t run and scale your own correlation pipelines or graph databases.
  • Faster pivots than manual log searches: Particularly for common incident patterns.

When teams should choose Amazon Detective

  • You use GuardDuty and/or Security Hub and want faster investigations.
  • You run multi-account workloads and need centralized investigation.
  • You have a security operations function (SecOps, IR, SOC) and want a managed investigation view.

When teams should not choose Amazon Detective

  • You need a full SIEM with custom log ingestion and long-term retention across many sources (consider SIEM tooling).
  • You require custom detection rules (Detective is for investigation, not custom detections).
  • You operate mostly outside AWS or require deep endpoint telemetry (use EDR/SIEM integrations).
  • You need guaranteed inclusion of a specific telemetry source not supported by Detective (verify supported sources first).

4. Where is Amazon Detective used?

Industries

  • SaaS and technology companies running multi-account AWS landing zones
  • Financial services (tight incident response and audit requirements)
  • Healthcare and life sciences (security investigations with regulated workloads)
  • Retail and e-commerce (fraud, account compromise, bot activity triage)
  • Media and gaming (high-volume internet-facing workloads)
  • Public sector (investigation workflows and centralized governance)

Team types

  • Security Operations (SOC)
  • Incident Response (IR)
  • Cloud Security Engineering
  • Platform Engineering / SRE (on-call triage)
  • Compliance and audit teams (supporting evidence collection)
  • DevSecOps teams integrating security into operations

Workloads and architectures

  • Multi-account microservices platforms (EKS/ECS/Lambda behind APIs)
  • Internet-facing applications behind ALB/API Gateway/CloudFront
  • Data platforms (S3, Glue, Athena, Redshift) where access anomalies matter
  • Hybrid identity environments (federated IAM) where principal behavior must be analyzed

Real-world deployment contexts

  • Central security account enabling Detective across AWS Organizations
  • Regional investigation coverage aligned to where workloads run
  • Integrations with Security Hub for consolidated findings and triage flows

Production vs dev/test usage

  • Production: Primary value—real incidents and suspicious activity investigations.
  • Dev/test: Useful for training analysts, validating alert playbooks, and rehearsing investigations using sample findings.

5. Top Use Cases and Scenarios

Below are realistic scenarios where Amazon Detective is commonly used. Each assumes you already have detections (often from GuardDuty or Security Hub) and want faster investigation.

1) Investigate suspicious API activity (possible credential compromise)

  • Problem: A finding indicates unusual API calls (for example, reconnaissance or access to sensitive services).
  • Why Detective fits: Helps pivot from the finding to the IAM principal, related API history context, and affected resources.
  • Example: GuardDuty flags suspicious IAM behavior. You use Detective to review the principal profile, recent activity spikes, and related entities.

2) Triage potential crypto-mining on an EC2 instance

  • Problem: Alerts suggest an EC2 instance is communicating with known malicious endpoints or showing abnormal behavior.
  • Why Detective fits: Entity-centric views help assess the instance’s network relationships and surrounding activity.
  • Example: A GuardDuty finding references an EC2 instance. Detective shows related IPs and timelines that help scope impact.

3) Investigate unusual outbound network connections

  • Problem: Unexpected outbound traffic patterns could indicate data exfiltration or malware callbacks.
  • Why Detective fits: Network and entity relationship visualizations help identify what communicated with where (based on supported sources).
  • Example: A VPC-related finding triggers. Detective helps map the instance to destination IPs and peer relationships.

4) Determine blast radius across multiple accounts

  • Problem: A suspicious IP appears across multiple AWS accounts in your organization.
  • Why Detective fits: Centralized behavior graph across member accounts can show where the IP interacts.
  • Example: Security team investigates an IP address entity and finds it involved in activity across dev and prod accounts.

5) Investigate suspicious S3 access patterns

  • Problem: Security Hub surfaces findings about public access or anomalous access attempts (exact finding types vary).
  • Why Detective fits: Helps correlate identity and access activity to determine who accessed what and when (depending on data support).
  • Example: A finding about unusual access leads to a principal profile review and related activity timeline.

6) Confirm whether a GuardDuty finding is a false positive

  • Problem: Teams waste time chasing alerts that aren’t actionable.
  • Why Detective fits: Context helps quickly validate whether activity aligns with known behavior.
  • Example: A developer ran a penetration test. Detective shows related activity consistent with the test window and known IP ranges.

7) Investigate lateral movement signals (cross-resource relationships)

  • Problem: Compromised credentials may pivot across resources.
  • Why Detective fits: Relationship graphs help identify connected entities and unusual linkages.
  • Example: A principal interacts with multiple instances in a short window; Detective helps visualize that spread.

8) Accelerate incident handoffs between on-call and security teams

  • Problem: On-call engineers lack investigation context; security teams lack service context.
  • Why Detective fits: A shared investigation view standardizes what “evidence” to gather.
  • Example: On-call opens Detective, captures entity timeline and related entities, and hands off with clear scope.

9) Support post-incident review with evidence

  • Problem: You need to document what happened and how it was contained.
  • Why Detective fits: Investigation artifacts and timelines help build a coherent narrative (while preserving source logs for compliance).
  • Example: Use Detective views to compile key entities, time windows, and activity patterns.

10) Investigate suspicious behavior across federated identities

  • Problem: Federated sessions can make investigations harder due to session churn.
  • Why Detective fits: Entity-centric profiles help focus on principal behavior patterns (verify how your identity setup appears in Detective).
  • Example: A federated role session triggers a detection; Detective helps correlate activity around that session.

11) Prioritize which findings to tackle first

  • Problem: Too many alerts, limited analyst time.
  • Why Detective fits: Grouping/context can highlight higher-risk clusters (for example, repeated activity from the same IP/entity).
  • Example: Multiple findings reference one instance; Detective makes it clear it’s the common factor.

12) Multi-region investigation alignment

  • Problem: Activity spans regions; teams miss context if they look only in one place.
  • Why Detective fits: Regional graphs let you investigate within each region’s context and standardize workflows across regions.
  • Example: You enable Detective in key regions and develop playbooks for each.

6. Core Features

Note: Amazon Detective features can vary by region and evolve over time. Verify current feature availability and terminology in the official docs: https://docs.aws.amazon.com/detective/

Behavior graph (regional)

  • What it does: Creates a managed data model of entities and their interactions from supported AWS security data.
  • Why it matters: Enables fast pivoting and correlation during investigations.
  • Practical benefit: Analysts spend less time assembling data from multiple logs.
  • Limitations/caveats: Built from supported sources only; not a general-purpose log lake.

Entity profiles

  • What it does: Provides an overview for an entity (such as an IAM principal, EC2 instance, or IP address), including observed activity patterns and related findings (entity types vary).
  • Why it matters: Entity-centric analysis is often faster than log-centric searches.
  • Practical benefit: Quickly assess “Is this normal for this entity?”
  • Limitations/caveats: Profiles depend on available telemetry and retention in the graph.

Timelines and activity details

  • What it does: Shows activity over time around a finding or entity.
  • Why it matters: Incidents are time-bound; timelines help define scope and sequence.
  • Practical benefit: Helps confirm whether suspicious activity started earlier than the first alert.
  • Limitations/caveats: Time granularity and event types depend on supported sources.

Relationship visualizations (graph exploration)

  • What it does: Visualizes relationships among entities (for example, principal → API activity → resource, instance → IP connections).
  • Why it matters: Many incidents involve multiple connected entities.
  • Practical benefit: Faster “blast radius” and dependency mapping during response.
  • Limitations/caveats: Not a full network topology tool; scope is investigation context.

Finding investigation integration (GuardDuty and/or Security Hub)

  • What it does: Lets you start from a security finding and pivot into related context.
  • Why it matters: Keeps investigation anchored to detections your team already uses.
  • Practical benefit: Shortens the “alert → understanding” path.
  • Limitations/caveats: Requires supported finding sources and proper regional enablement.

Multi-account support (administrator/member accounts)

  • What it does: Centralizes investigation across multiple AWS accounts into a single behavior graph (per region) managed by an administrator account.
  • Why it matters: Modern AWS environments use multiple accounts for isolation.
  • Practical benefit: Security teams avoid logging into many accounts to investigate.
  • Limitations/caveats: Requires membership setup and appropriate permissions; cross-account governance must be planned.

API/SDK for automation (membership/graph operations)

  • What it does: Enables programmatic management (for example, listing graphs, managing members).
  • Why it matters: Helps integrate with account vending and security automation.
  • Practical benefit: Repeatable organization onboarding/offboarding.
  • Limitations/caveats: Investigation workflows are primarily console-driven; automation is stronger for administration than for human analysis.

Auditability via AWS CloudTrail

  • What it does: Detective API actions can be captured in CloudTrail.
  • Why it matters: Security tooling actions should be auditable.
  • Practical benefit: Track who enabled/disabled graphs or changed membership.
  • Limitations/caveats: Ensure CloudTrail is configured appropriately in each account/region.

7. Architecture and How It Works

High-level architecture

  1. You enable Amazon Detective in a specific AWS region, creating or enabling a behavior graph.
  2. Detective ingests and processes supported security telemetry and findings (commonly GuardDuty findings plus supporting context such as CloudTrail/VPC flow-related signals—verify exact sources).
  3. When a finding arrives (for example, in GuardDuty and/or Security Hub), analysts open Detective to: – Review finding details – Explore related entities (IAM principals, instances, IPs, etc.) – Use timelines and relationship views to identify root cause and blast radius
  4. Analysts take response actions outside Detective (for example, isolate an instance, disable keys, update security groups, block IPs, rotate credentials).

Data / request / control flow

  • Control plane: Enabling Detective, adding members, and configuring access are management actions (API/Console) typically performed by the security/platform team.
  • Data plane: Detective continuously processes supported telemetry into the behavior graph.
  • Investigation flow: Humans (or workflows) pivot from a finding to related graph context.

Integrations with related services (common patterns)

  • Amazon GuardDuty: Produces threat detections; Detective helps investigate them.
  • AWS Security Hub: Aggregates findings from multiple products; Detective can be used for investigation context for supported findings (verify current integration behavior).
  • AWS Organizations: Helps manage multi-account membership and delegated administration patterns (verify specifics for Detective in your org).
  • AWS CloudTrail / VPC Flow Logs: Often part of the underlying telemetry that makes investigations useful (Detective may use supported subsets; verify).

Dependency services

  • CloudTrail and VPC Flow Logs are typically prerequisites for strong investigation context across AWS, even if Detective handles ingestion/processing itself.
  • GuardDuty is commonly the primary detection source used with Detective.

Security/authentication model

  • Uses AWS IAM for authentication and authorization.
  • Access is typically granted via IAM policies to security roles/groups in the administrator account and (if needed) member accounts.
  • Detective creates/uses service-linked roles as required (verify the exact role names and permissions in docs for your region).

Networking model

  • Detective is an AWS managed service accessed via the AWS console and API endpoints.
  • You do not deploy agents or manage network endpoints for Detective itself.
  • Investigation access is via AWS APIs over the internet or via corporate egress (standard AWS service access patterns). If you require private connectivity constraints, verify available endpoint options (for example, VPC endpoints) in official docs—do not assume.

Monitoring/logging/governance considerations

  • AWS CloudTrail: Log Detective API calls for governance.
  • AWS Organizations SCPs: Can control who can enable/disable Detective or modify membership (use carefully).
  • Tagging: Detective itself is not a resource you “tag” like EC2; governance is more about account/region standards and access controls.
  • Runbooks: Define how findings are escalated and how Detective is used in incident response.

Simple architecture diagram (Mermaid)

flowchart LR
  GD[Amazon GuardDuty Findings] --> D[Amazon Detective<br/>Behavior Graph (Regional)]
  SH[AWS Security Hub Findings] --> D
  CT[AWS CloudTrail] --> D
  VPCF[VPC Flow Logs] --> D

  Analyst[Security Analyst] -->|Investigate| D
  D -->|Context: entities, timelines, relationships| Analyst

Production-style architecture diagram (Mermaid)

flowchart TB
  subgraph Org[AWS Organizations]
    A1[Security Tooling Account<br/>(Delegated Admin)]
    A2[Prod Accounts]
    A3[Dev/Test Accounts]
    A4[Shared Services Accounts]
  end

  subgraph Region1[Region: Enabled]
    GD1[GuardDuty] --> SH1[Security Hub]
    GD1 --> D1[Amazon Detective<br/>Behavior Graph]
    SH1 --> D1
    CT1[CloudTrail] --> D1
    VPC1[VPC Flow Logs] --> D1
  end

  subgraph Ops[Security Operations]
    SOAR[SOAR / Ticketing<br/>(Optional)]
    IR[Incident Response Playbooks]
    Analyst2[Analysts / On-call]
  end

  A1 --> GD1
  A1 --> SH1
  A1 --> D1

  A2 --> GD1
  A2 --> SH1
  A2 --> CT1
  A2 --> VPC1

  A3 --> GD1
  A3 --> SH1
  A3 --> CT1
  A3 --> VPC1

  Analyst2 --> D1
  D1 --> SOAR
  IR --> Analyst2

8. Prerequisites

AWS account and organization requirements

  • An AWS account with permissions to enable and manage Amazon Detective.
  • For multi-account setups: AWS Organizations recommended (not strictly required for all setups, but common).

Permissions / IAM roles

You need IAM permissions to: – Enable Detective / manage behavior graphs – Manage members (invite/disassociate) – View investigation data in the console

Start by reviewing official IAM guidance for Detective and use least privilege: https://docs.aws.amazon.com/detective/latest/adminguide/security-iam.html (verify URL path if it changes)

A common operational pattern: – Security administrators: can enable/disable graphs and manage members. – Security analysts: read-only investigation access.

Billing requirements

  • A valid AWS payment method.
  • Awareness that enabling Detective can generate charges once the free trial (if available) ends; see Pricing section.

Tools (optional but helpful)

  • AWS CLI v2: https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html
  • Access to AWS Console
  • A text editor for notes/runbooks

Region availability

  • Amazon Detective is not available in all AWS regions.
  • Choose regions where you run workloads and where GuardDuty/Security Hub produce findings.
  • Verify current region list in official docs: https://docs.aws.amazon.com/detective/latest/adminguide/regions.html (verify)

Quotas / limits

  • Detective has service limits (for example, number of member accounts per behavior graph).
  • Always check current limits: https://docs.aws.amazon.com/detective/latest/adminguide/limits.html (verify)

Prerequisite services (recommended)

  • Amazon GuardDuty enabled in the same region (recommended for meaningful findings to investigate).
  • AWS Security Hub optionally enabled for consolidated findings (recommended in many orgs).
  • AWS CloudTrail organization trail and appropriate logging strategy (recommended for broader security and investigation readiness).
  • VPC Flow Logs for key VPCs/subnets (recommended, cost-aware).

9. Pricing / Cost

Official pricing page (always validate current rates and dimensions):
https://aws.amazon.com/detective/pricing/

AWS Pricing Calculator:
https://calculator.aws/#/

Pricing dimensions (how you are charged)

Amazon Detective pricing is usage-based and commonly depends on: – The volume of security data analyzed for the behavior graph (for example, GB analyzed per month), with rates that can vary by region. – Potential differences by data type/source (verify current pricing breakdown on the official page).

Detective is a managed service; you typically do not pay for “instances” or “nodes.” You pay for the analysis/processing volume.

Free tier / free trial

AWS sometimes offers a free trial period for new Detective behavior graphs (commonly 30 days in many regions historically), but this can change.
Verify the current free trial terms on the official pricing page.

Primary cost drivers

  • Number of accounts and how much activity they generate.
  • Regions enabled (each region has its own behavior graph and associated analysis).
  • Traffic volume and API activity that increases analyzed telemetry.
  • GuardDuty findings volume (often correlates with environment activity and exposure).

Hidden or indirect costs (important)

Even if Detective’s own price is manageable, investigation readiness often relies on upstream telemetry that can add cost: – VPC Flow Logs can add CloudWatch Logs or S3 ingestion/storage costs. – CloudTrail (especially data events) can increase log volume and storage costs. – Security Hub and GuardDuty have their own pricing. – Data transfer: Detective is an AWS service; you generally won’t pay data transfer just to view the console, but your overall logging architecture can incur transfer/storage charges (for example, cross-region log aggregation).

Storage/compute/API/request pricing factors

  • Detective pricing is not typically “per API request” in the way some AWS services are; it’s mainly based on analyzed data volume (verify on pricing page).
  • You don’t provision compute; AWS manages it.

How to optimize cost

  • Enable Detective only in regions that matter (where production workloads and detections exist).
  • Start with a small scope (one region, key accounts), then expand.
  • Control upstream log volume:
  • Use VPC Flow Logs strategically (critical VPCs/subnets; filter where appropriate).
  • Use CloudTrail data events selectively (they can be high volume).
  • Use AWS Organizations to standardize which accounts are onboarded and avoid “shadow” graphs.

Example low-cost starter estimate (model, not numbers)

A realistic “starter” approach: – 1 region – 1–2 accounts – GuardDuty enabled – Investigate sample findings for training Cost expectation: – You may pay little or nothing during a free trial (if available). – After the trial, charges depend on analyzed GB/month. Do not assume a fixed monthly fee.

Example production cost considerations

For production, plan around: – Multiple regions enabled (common for resiliency and latency) – Dozens to hundreds of accounts – High CloudTrail and network activity
Recommendation: – Use the AWS Pricing Calculator and run a 30-day measurement window after enabling (if trial available) to understand your analyzed volume. – Establish budgets/alerts in AWS Budgets for Detective, GuardDuty, and Security Hub.

10. Step-by-Step Hands-On Tutorial

Objective

Enable Amazon Detective in one AWS region, generate Amazon GuardDuty sample findings, and use Amazon Detective to investigate a finding using entity profiles and relationship context—then clean up.

Lab Overview

You will: 1. Choose a region and confirm prerequisites. 2. Enable GuardDuty (if not already enabled). 3. Enable Amazon Detective (create/enable a behavior graph). 4. Generate GuardDuty sample findings. 5. Use Amazon Detective to investigate one of those findings. 6. Validate that Detective is ingesting and showing investigation context. 7. Clean up by disabling Detective (and optionally GuardDuty).

Estimated time: 45–90 minutes (depends on console familiarity and data availability).
Cost: Low for a short lab; charges may apply after any free trial. Always review the pricing page.

Step 1: Pick a region and confirm access

  1. Sign in to the AWS Console with an account that can manage security services.
  2. In the console region selector, choose a region where Amazon Detective is supported.

Expected outcome: You are operating in a region that supports Detective and GuardDuty.

Verification: – Open the Detective console and confirm it loads for the selected region: https://console.aws.amazon.com/detective/home

Common issues: – If the console says the service isn’t available: switch to a supported region (verify region list in docs).

Step 2: Enable Amazon GuardDuty (required for this lab’s findings)

Amazon Detective is most useful when you have findings to investigate. This lab uses GuardDuty sample findings.

  1. Open GuardDuty: https://console.aws.amazon.com/guardduty/home
  2. If GuardDuty is not enabled, choose Get Started / Enable GuardDuty (wording varies).

Expected outcome: GuardDuty is enabled in the selected region.

Verification: – GuardDuty console shows Enabled status.

Notes: – If you manage security centrally, consider enabling GuardDuty via AWS Organizations delegated administrator. For this lab, a single-account enablement is enough.

Step 3: Enable Amazon Detective (create/enable the behavior graph)

  1. Open Amazon Detective: https://console.aws.amazon.com/detective/home
  2. Choose Enable Amazon Detective (or similar action).
  3. Review any prompts about the behavior graph and confirm.

Expected outcome: A behavior graph is enabled for the current region and account.

Verification (Console): – Detective console shows the service as enabled and provides navigation such as Investigations/Findings/Entities (names vary by release).

Verification (Optional AWS CLI): If you have AWS CLI configured for the account/region:

aws detective list-graphs --region <your-region>

You should see a graph ARN in the response if enabled.

Common issues and fixes: – AccessDeniedException: ensure your IAM identity has Detective permissions (see Detective IAM docs). – Not supported in region: select a supported region.

Step 4: (Optional) Add a member account (multi-account glimpse)

If you have a second AWS account you can use for testing, you can add it as a member. If not, skip this step.

High-level steps (console wording varies): 1. In Detective, go to Accounts / Members. 2. Choose Add accounts and provide the member account ID. 3. Send invitation. 4. In the member account, accept the invitation in Detective.

Expected outcome: The member account is associated with the behavior graph.

Verification: – In the administrator account’s Detective console, the member shows Enabled or Associated (exact status text varies).

Caveat: Multi-account enablement is easiest with AWS Organizations. Verify the recommended org onboarding workflow in official docs.

Step 5: Generate GuardDuty sample findings

  1. Go back to the GuardDuty console: https://console.aws.amazon.com/guardduty/home
  2. Find the option to Generate sample findings (typically in Settings or within the findings area; UI changes over time).
  3. Generate sample findings.

Expected outcome: GuardDuty produces multiple sample findings in the region.

Verification: – In GuardDuty Findings, you see new findings with titles indicating they are sample/test findings.

Common issues: – If you don’t see the option, check GuardDuty documentation for the current UI flow (it changes periodically). – Ensure you are in the same region where GuardDuty is enabled.

Step 6: Investigate a finding in Amazon Detective

Now you’ll use Detective to pivot from a finding into context.

  1. Open Detective console: https://console.aws.amazon.com/detective/home
  2. Navigate to the section that lists findings or integrations (for example, Findings, Investigations, or GuardDuty findings—wording varies).
  3. Select a sample finding (pick one that references an EC2 instance or IAM principal if available; those tend to show richer pivots).
  4. In the finding view: – Review summary and severity – Identify referenced entities (for example, instance ID, IAM role/user, IP)
  5. Choose an entity (for example, the IAM principal or EC2 instance) to open its entity profile.
  6. Explore: – Timeline around the finding time window – Related entities and relationships – Any available activity panels

Expected outcome: You can see an investigation-oriented view that connects the finding to entities and surrounding activity in the behavior graph.

What “good” looks like: – The entity profile loads without errors. – You can pivot among at least two entity types (for example, finding → instance → IP, or finding → principal → related activity).

Notes: – Sample findings may not perfectly reflect your environment; the goal is to learn the workflow and UI.

Step 7: Capture an investigation note (operational habit)

Detective isn’t a ticketing system, but you should practice repeatable investigation documentation.

Create a small incident note template in your runbook (example):

Investigation Summary (Template)
- Finding ID / Type:
- Region:
- Affected Account:
- Primary Entity (principal/instance/IP):
- Time Window (UTC):
- Observed Relationships:
- Likely Root Cause:
- Containment Actions Taken:
- Follow-up Actions:

Expected outcome: You have a repeatable documentation format to pair with Detective context.

Validation

Use the checklist below to confirm the lab worked:

  • [ ] GuardDuty is enabled in the region.
  • [ ] Detective is enabled and shows a behavior graph in the region.
  • [ ] GuardDuty sample findings are visible in GuardDuty.
  • [ ] At least one finding is visible/investigable in Detective.
  • [ ] You can open an entity profile and view related context (timeline/relationships).

Optional CLI validation:

aws detective list-graphs --region <your-region>
aws guardduty list-detectors --region <your-region>

Troubleshooting

Issue: No findings appear in Detective

  • Confirm you are in the same region for GuardDuty and Detective.
  • Wait a bit: ingestion/correlation can take time.
  • Verify GuardDuty has findings (in GuardDuty console).
  • Verify Detective is enabled for the account/region.

Issue: Access denied when opening Detective or entity profiles

  • Ensure your IAM identity has the required Detective permissions.
  • If using federated roles, ensure the role policy allows Detective actions.
  • Check for SCPs in AWS Organizations blocking Detective actions.

Issue: Region mismatch in multi-account setups

  • Behavior graphs are regional. Ensure member accounts are associated in the same region(s).
  • Standardize a region enablement matrix for security tooling.

Cleanup

To avoid ongoing charges, disable services you enabled for the lab.

Disable Amazon Detective

  1. Open Detective console in the region: https://console.aws.amazon.com/detective/home
  2. If you added member accounts, remove/disassociate them first (recommended).
  3. Choose Disable Amazon Detective (or delete/disable behavior graph, depending on UI).

Expected outcome: Detective is disabled in the region and stops analyzing data.

(Optional) Disable GuardDuty

If this account is only for labs and you don’t want GuardDuty charges: 1. Open GuardDuty: https://console.aws.amazon.com/guardduty/home 2. Disable GuardDuty in the region.

Expected outcome: GuardDuty stops generating findings and charges end (subject to billing cycle).

Cost check

  • Review Billing → Cost Explorer and Bills for Detective/GuardDuty.
  • Consider setting a short-lived AWS Budget alert for the lab account.

11. Best Practices

Architecture best practices

  • Centralize security tooling: Use a dedicated security account as the Detective administrator, especially in AWS Organizations.
  • Enable in the right regions: Start with production regions; expand based on threat model and operations coverage.
  • Pair with detection services: Detective is most valuable with GuardDuty and Security Hub feeding findings to investigate.
  • Define investigation playbooks: Document “how to investigate” common finding categories using Detective pivots.

IAM/security best practices

  • Least privilege:
  • Separate roles for administration (enable/disable, membership) and investigation (read-only analysis).
  • Use SSO/federation roles for analysts with short-lived sessions.
  • Restrict destructive actions (like disabling Detective) using SCPs or tightly controlled admin roles.
  • Audit all access: Ensure CloudTrail is enabled and logs are centrally stored.

Cost best practices

  • Scope intentionally: Avoid enabling every region “just in case.”
  • Onboard accounts deliberately: Focus on production and internet-facing accounts first.
  • Optimize upstream logging: Be strategic with VPC Flow Logs and CloudTrail data events; they can drive downstream analysis volume and separate logging costs.
  • Use budgets/alerts: Add Detective (and GuardDuty/Security Hub) to cost allocation and budgets.

Performance best practices (investigation efficiency)

  • Standardize incident metadata: Always capture region, account, principal, resource IDs, and time window.
  • Train analysts on pivots: From finding → entity profile → related entities → timeline.
  • Use a consistent time zone: Use UTC in incident handling to avoid confusion.

Reliability best practices

  • Multi-region readiness: Incidents can occur in any enabled region; ensure your SOC can access Detective there.
  • Redundancy in evidence: Detective accelerates analysis but shouldn’t be your only evidence store—retain source logs (CloudTrail, VPC Flow Logs) according to policy.

Operations best practices

  • Access reviews: Periodically review who has investigation access.
  • Membership lifecycle: Automate onboarding/offboarding when accounts are created/closed.
  • Document runbooks: Include step-by-step Detective investigation procedures for top alerts.

Governance/tagging/naming best practices

  • Use consistent naming for:
  • Security accounts and roles (for example, SecurityInvestigatorReadOnly, SecurityToolingAdmin)
  • Regions enabled (document a “security tool coverage matrix”)
  • Use AWS Organizations policies for guardrails, not daily operations.

12. Security Considerations

Identity and access model

  • Amazon Detective uses IAM for access control.
  • Use separate personas:
  • Detective Admin: enable/disable graphs, manage members
  • Detective Investigator: view findings, entities, profiles
  • Consider restricting investigators from changing org configuration or disabling tools.

Encryption

  • Data is encrypted in transit using TLS.
  • Data stored by AWS managed services is generally encrypted at rest.
    Verify whether Detective supports customer-managed KMS keys for your use case/region; do not assume.

Network exposure

  • Detective is accessed via AWS public service endpoints (standard console/API access).
  • If you require private connectivity or restricted egress, verify available options (for example, VPC endpoints support) in official docs rather than assuming.

Secrets handling

  • Detective does not require you to store secrets in it.
  • Protect investigation access credentials via:
  • IAM Identity Center (SSO)
  • MFA enforcement
  • Short session durations
  • Conditional access policies (where applicable)

Audit/logging

  • Enable CloudTrail and centralize logs.
  • Monitor for:
  • Disabling Detective
  • Membership changes
  • Permission changes granting broad investigation access

Compliance considerations

  • Detective helps with investigation context but is not a substitute for:
  • Log retention policies
  • Evidence preservation
  • Chain-of-custody requirements in regulated environments
  • Document how Detective is used in your incident response process and how source logs are retained.

Common security mistakes

  • Granting broad admin access to too many users (“everyone can enable/disable tools”).
  • Enabling Detective in only one region while production spans many.
  • Treating Detective as a SIEM replacement and neglecting raw log retention.

Secure deployment recommendations

  • Use a central security account and delegated admin where appropriate.
  • Enforce least privilege and MFA.
  • Keep source logs (CloudTrail, VPC Flow Logs) in immutable storage (for example, S3 with Object Lock where required—outside Detective).

13. Limitations and Gotchas

Always validate current limits and regional behavior in official docs.

Known limitations / constraints

  • Regional service: You must enable Detective separately per region.
  • Not a SIEM: No general-purpose custom log ingestion for arbitrary sources.
  • Depends on supported data sources: If your key telemetry isn’t supported, context may be limited.
  • Console-centric investigations: Many investigation workflows are UI-driven; APIs are more for administration than full investigation automation.

Quotas and scale boundaries

  • Limits exist for member accounts, invitations, and potentially data handling.
    Verify limits: https://docs.aws.amazon.com/detective/latest/adminguide/limits.html (verify)

Regional constraints

  • Not all AWS regions support Detective.
  • Even in supported regions, feature parity may vary.

Pricing surprises

  • Enabling in many regions and accounts can increase analyzed volume quickly.
  • Logging architecture costs (CloudTrail, VPC Flow Logs, Security Hub, GuardDuty) can exceed Detective’s cost.

Compatibility issues

  • Multi-account onboarding varies depending on AWS Organizations setup and delegated admin configuration.
  • If you use multiple partitions (commercial, GovCloud, China), treat them separately and verify support.

Operational gotchas

  • Analysts often forget region context—investigations “look empty” if you’re in the wrong region.
  • If GuardDuty is disabled or not generating findings, Detective may feel underutilized.
  • Incident response still requires response tooling (isolation, credential rotation). Detective helps analysis, not remediation.

Migration challenges

  • Moving from an ad-hoc investigation approach requires training analysts on entity/graph pivots.
  • If you already use a SIEM, you’ll need to define when to use SIEM searches vs Detective pivots.

Vendor-specific nuances

  • Detective is designed for AWS telemetry and AWS security integrations; it’s not intended to be cloud-agnostic.

14. Comparison with Alternatives

Amazon Detective is best viewed as an investigation accelerator. Alternatives typically fall into: detection services, aggregation hubs, log analytics/SIEM, and third-party incident response platforms.

Comparison table

Option Best For Strengths Weaknesses When to Choose
Amazon Detective Investigating AWS security findings with correlated context Managed behavior graph, entity profiles, fast pivots from findings, multi-account support Not a SIEM; limited to supported sources; regional graphs You use GuardDuty/Security Hub and want faster root-cause investigations
Amazon GuardDuty Threat detection Purpose-built detections, broad AWS integration Not an investigation workspace; doesn’t provide the same graph-style pivots You need managed threat detection (pair with Detective for investigation)
AWS Security Hub Centralized findings aggregation and posture One place for findings across products, standards checks Not deep investigation/correlation by itself You need centralized security alerts and compliance visibility
AWS CloudTrail Lake / Athena on logs Deep log analytics and custom queries Powerful query capability, custom investigations, long-term retention More manual correlation; requires schema/query skills and log pipeline You need bespoke queries, compliance reporting, or long retention searches
Amazon OpenSearch / SIEM on AWS Centralized search across logs Flexible ingestion, dashboards, correlation rules You manage pipelines, scale, tuning, retention You need custom ingestion and SIEM-like operations
Microsoft Sentinel (Azure) Cloud SIEM/SOAR in Azure ecosystem SIEM + automation + connectors Not AWS-native; requires cross-cloud ingestion You centralize security in Sentinel and ingest AWS logs
Google Security Command Center (GCP) GCP security posture & findings Strong GCP-native view Not AWS-native You primarily run on GCP
Splunk / Elastic Security (self-managed or SaaS) Enterprise SIEM Powerful correlation, custom sources, long retention Cost and operational overhead; integration work You need cross-platform SIEM with custom sources and mature SOC workflows

15. Real-World Example

Enterprise example (regulated, multi-account landing zone)

  • Problem: A bank runs hundreds of AWS accounts with centralized GuardDuty and Security Hub. Analysts struggle to investigate GuardDuty findings quickly because evidence is spread across CloudTrail, flow logs, and multiple accounts.
  • Proposed architecture:
  • AWS Organizations with a dedicated Security Tooling account as delegated admin
  • GuardDuty enabled org-wide in key regions
  • Security Hub enabled for centralized findings
  • Amazon Detective enabled per production region with member accounts onboarded
  • CloudTrail org trail and a log archive account for long-term retention (outside Detective)
  • Why Amazon Detective was chosen:
  • Accelerates investigation with entity profiles and relationship context
  • Reduces cross-account console hopping
  • Fits into AWS-native security operations while retaining raw logs for compliance
  • Expected outcomes:
  • Reduced time to determine whether findings are real incidents
  • More consistent incident narratives (who/what/when/where)
  • Fewer escalations caused by lack of context

Startup/small-team example (lean SecOps)

  • Problem: A startup has a small engineering team on call. GuardDuty occasionally flags suspicious activity, but the team spends hours pulling logs to decide if it’s a true incident.
  • Proposed architecture:
  • Single AWS account (or a small number of accounts)
  • GuardDuty enabled in the main region
  • Amazon Detective enabled in that region
  • Basic incident runbook: investigate in Detective first, then contain using IAM/EC2 controls
  • Why Amazon Detective was chosen:
  • Minimal operational overhead vs building a full SIEM pipeline
  • Faster triage for a small team without dedicated analysts
  • Expected outcomes:
  • Faster on-call resolution
  • Better confidence when declaring false positives
  • Clearer “next steps” during real incidents (which entity is compromised, blast radius)

16. FAQ

1) Is Amazon Detective a SIEM?

No. Amazon Detective is an investigation service that helps analyze and correlate AWS security signals. A SIEM typically supports broad custom ingestion, rule creation, long-term retention, and cross-environment correlation.

2) Do I need GuardDuty to use Amazon Detective?

You can enable Detective without GuardDuty, but most teams use Detective primarily to investigate GuardDuty and/or Security Hub findings. For practical value, you typically want GuardDuty enabled.

3) Is Amazon Detective regional?

Yes. You enable it per region by enabling a behavior graph in that region.

4) Can Amazon Detective investigate across multiple AWS accounts?

Yes, via administrator/member account setup. In AWS Organizations, you can centralize investigation in a security account (verify current org onboarding options in docs).

5) Does Amazon Detective store raw logs?

Detective maintains an investigation-ready data model (behavior graph) derived from supported sources. It is not a general raw log archive. Keep CloudTrail and flow logs according to your retention policy.

6) How long does Amazon Detective retain data?

Detective retains investigation context for a defined period (historically up to a year in many cases), but retention can vary by feature/region. Verify in official docs for current retention.

7) Can I ingest my own application logs into Detective?

Generally, Detective is not designed for arbitrary custom log ingestion like a SIEM. Verify current supported data sources in official docs.

8) Can I automate investigations with APIs?

Detective provides APIs primarily for administration (graphs, membership). Investigation workflows are mainly performed in the console. Check SDK/API docs for current capabilities.

9) Is Amazon Detective suitable for compliance evidence?

It helps provide investigation context and supports incident narratives, but compliance evidence usually requires retaining source logs (CloudTrail, flow logs) and formal processes.

10) Does enabling Detective affect performance of my workloads?

Detective is a managed service analyzing supported telemetry; it does not install agents on your instances. Indirectly, enabling upstream logs (like VPC Flow Logs) can have operational and cost impacts.

11) How does Detective relate to Security Hub?

Security Hub aggregates findings; Detective helps investigate findings by providing entity context and relationships (for supported findings). Many teams use both.

12) What’s the best way to roll out Detective in an organization?

Start with: – A central security account as administrator – One production region – A subset of key accounts Then expand region/account coverage after validating cost and operational value.

13) Can I restrict who can disable Detective?

Yes. Use IAM least privilege and consider AWS Organizations SCPs for strong guardrails.

14) Does Detective support GovCloud/China regions?

Support varies by partition and region. Verify in the official region availability docs for your partition.

15) How do I keep costs predictable?

Limit regions, onboard accounts deliberately, monitor analyzed volume, and set budgets/alerts. Also monitor upstream log costs (CloudTrail, flow logs, GuardDuty, Security Hub).

16) What’s the first thing to check when Detective looks empty?

Region. Ensure you’re viewing the same region where Detective is enabled and where findings are produced.

17) Can Detective replace my incident response team’s tooling?

No. Detective helps analysis; you still need response tooling (IAM key rotation, instance isolation, network blocking, ticketing/SOAR).

17. Top Online Resources to Learn Amazon Detective

Resource Type Name Why It Is Useful
Official documentation Amazon Detective Documentation — https://docs.aws.amazon.com/detective/ Authoritative setup, concepts, permissions, limits, and workflows
Official pricing Amazon Detective Pricing — https://aws.amazon.com/detective/pricing/ Current pricing dimensions and regional rates
Pricing tool AWS Pricing Calculator — https://calculator.aws/#/ Build estimates across Detective + GuardDuty + Security Hub + logging costs
Getting started Getting started with Amazon Detective — https://docs.aws.amazon.com/detective/latest/adminguide/getting-started.html (verify) Step-by-step enablement and basic usage
IAM guidance Security and IAM for Detective — https://docs.aws.amazon.com/detective/latest/adminguide/security-iam.html (verify) Least-privilege policy guidance and access patterns
Service limits Detective quotas/limits — https://docs.aws.amazon.com/detective/latest/adminguide/limits.html (verify) Helps plan multi-account scale and onboarding
Region availability Detective supported regions — https://docs.aws.amazon.com/detective/latest/adminguide/regions.html (verify) Ensures you design for regional coverage correctly
Related service docs Amazon GuardDuty Docs — https://docs.aws.amazon.com/guardduty/ Understanding findings and generating sample findings for labs
Related service docs AWS Security Hub Docs — https://docs.aws.amazon.com/securityhub/ Central findings aggregation that often feeds Detective investigations
Reference architecture AWS Security Reference Architecture (SRA) — https://aws.amazon.com/solutions/implementations/aws-security-reference-architecture/ Best-practice multi-account security architecture patterns
Videos AWS YouTube Channel — https://www.youtube.com/@amazonwebservices Search for “Amazon Detective” to find walkthroughs and feature updates
Product page Amazon Detective Product Page — https://aws.amazon.com/detective/ High-level service overview and latest announcements
SDK/API reference Amazon Detective API Reference — https://docs.aws.amazon.com/detective/latest/APIReference/ (verify) Automate membership and graph operations

18. Training and Certification Providers

Institute Suitable Audience Likely Learning Focus Mode Website URL
DevOpsSchool.com DevOps engineers, SREs, platform and security engineers AWS operations and DevSecOps fundamentals, security tooling overviews Check website https://www.devopsschool.com/
ScmGalaxy.com Beginners to intermediate engineers DevOps/Cloud learning paths and foundational training Check website https://www.scmgalaxy.com/
CLoudOpsNow.in Cloud operations and platform teams CloudOps practices, monitoring/operations, cloud fundamentals Check website https://cloudopsnow.in/
SreSchool.com SREs and reliability-focused engineers SRE principles, operational readiness, incident response Check website https://sreschool.com/
AiOpsSchool.com Operations teams exploring AIOps AIOps concepts, automation for operations, tooling awareness Check website https://aiopsschool.com/

19. Top Trainers

Platform/Site Likely Specialization Suitable Audience Website URL
RajeshKumar.xyz Cloud/DevOps training and guidance (verify offerings) Beginners to experienced engineers seeking mentorship https://rajeshkumar.xyz/
devopstrainer.in DevOps training (verify course catalog) DevOps engineers, SREs, platform teams https://devopstrainer.in/
devopsfreelancer.com Freelance DevOps expertise and training (verify services) Teams needing hands-on help or coaching https://devopsfreelancer.com/
devopssupport.in DevOps support and training (verify services) Ops teams needing practical support https://devopssupport.in/

20. Top Consulting Companies

Company Likely Service Area Where They May Help Consulting Use Case Examples Website URL
cotocus.com Cloud/DevOps consulting (verify offerings) Cloud architecture, operations, and enablement Multi-account setup guidance, operational runbooks, security tooling integration planning https://cotocus.com/
DevOpsSchool.com DevOps/Cloud consulting and training (verify offerings) DevOps transformation, platform enablement Designing operational processes around AWS security tooling; training teams on investigation workflows https://www.devopsschool.com/
DEVOPSCONSULTING.IN DevOps consulting (verify offerings) Delivery support, automation, operational improvements Building standardized incident response playbooks and access models https://devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before Amazon Detective

To get real value from Amazon Detective, you should understand: – AWS core concepts: accounts, regions, IAM, VPC basics – Logging fundamentals: – AWS CloudTrail (management vs data events) – VPC Flow Logs (what they capture, cost implications) – Security services basics: – Amazon GuardDuty (finding types and workflow) – AWS Security Hub (finding aggregation and standards)

What to learn after Amazon Detective

  • Incident response in AWS:
  • Credential containment (disable/rotate keys, revoke sessions)
  • Instance isolation (security groups, NACLs, SSM Session Manager approaches)
  • Centralized logging and forensics:
  • CloudTrail Lake or Athena over S3 logs
  • OpenSearch/SIEM architectures
  • Governance at scale:
  • AWS Organizations, SCPs, delegated administration
  • AWS Control Tower (if used)

Job roles that use it

  • Security Analyst / SOC Analyst (AWS-focused)
  • Cloud Security Engineer
  • Incident Responder
  • SRE / On-call Engineer in cloud-native environments
  • Platform Security / DevSecOps Engineer

Certification path (AWS)

Amazon Detective is not a standalone certification topic, but it supports skills relevant to: – AWS Certified Security – Specialty (if available; verify current AWS cert catalog) – AWS Certified Solutions Architect – Associate/Professional (security operations awareness) – AWS Certified SysOps Administrator – Associate (operations and monitoring foundations)

Always check the official AWS certification list: https://aws.amazon.com/certification/

Project ideas for practice

  1. Build an “investigation runbook” for top 10 GuardDuty finding types and map each to Detective pivots.
  2. Create a multi-account lab with Organizations: – Central security account – Two member accounts – Enable GuardDuty + Detective in one region – Practice cross-account investigations
  3. Cost governance project: – Enable Detective in one region – Track analyzed volume for 2–4 weeks – Create budgets and a region/account rollout plan

22. Glossary

  • Amazon Detective: AWS service for investigating security findings using correlated context and graph-based exploration.
  • Behavior graph: Detective’s regional data model that represents entities and relationships built from supported telemetry and findings.
  • Entity: An item you can investigate (for example, IAM principal, EC2 instance, IP address). Exact entity types vary by feature/region.
  • Entity profile: A consolidated view of an entity’s observed behavior, related findings, and context.
  • Finding: A detection produced by a security service (commonly GuardDuty; also aggregated by Security Hub).
  • GuardDuty: AWS threat detection service that produces findings from AWS telemetry and threat intelligence.
  • Security Hub: AWS service that aggregates security findings and posture checks across accounts and products.
  • CloudTrail: AWS service that logs API activity (management events and optional data events).
  • VPC Flow Logs: Records network flow metadata for traffic to/from network interfaces in a VPC.
  • AWS Organizations: Service for centrally managing multiple AWS accounts.
  • Delegated administrator: An account in an AWS Organization designated to administer a service across the organization (availability varies by service and setup—verify for Detective).
  • Least privilege: Security principle of granting only the minimum permissions required.
  • MTTI: Mean time to investigate—how long it takes to understand an alert/incident.
  • Blast radius: The scope of impact—what systems, identities, and data may be affected.

23. Summary

Amazon Detective is an AWS Security, identity, and compliance service designed to speed up investigations by building a regional behavior graph from supported AWS security data and helping analysts pivot from findings to entities, timelines, and relationships.

It matters because most security time is spent correlating context—who did what, from where, and what was impacted. Detective reduces that manual work, especially in multi-account AWS environments where investigations can otherwise require hopping across accounts and log stores.

Cost is usage-based and typically driven by analyzed data volume, regions enabled, and overall activity levels—plus indirect costs from upstream logging and related services like GuardDuty and Security Hub. Security-wise, use least-privilege IAM roles, centralize administration, and keep source logs for compliance and forensics.

Use Amazon Detective when you already have detections (especially GuardDuty/Security Hub) and need faster, more consistent investigations. Next step: enable Detective in one production region with GuardDuty, train your team on standard pivots, and formalize investigation runbooks that pair Detective context with containment actions.