Amazon GuardDuty and Inspector: Threat Detection and Vulnerability Scanning

You've got a production pipeline that deploys every hour. Your security team is drowning in alerts from a dozen tools, most of which are false positives. Meanwhile, a real vulnerability sits in a container image that's been running for three weeks. This is the reality of cloud security at scale: too much noise, not enough signal. Amazon GuardDuty and Inspector are AWS's answer to this mess. GuardDuty eats CloudTrail, VPC Flow Logs, and DNS logs to spot threats like compromised credentials or crypto mining. Inspector scans your EC2 instances and container images for CVEs and network exposure. They're not silver bullets—you'll still need to tune them and integrate with incident response workflows—but they eliminate the need to cobble together open-source tools that break every other sprint. If you're not using them in production, you're relying on hope as a security strategy.

Why GuardDuty and Inspector Are Not Optional

In production environments, threat detection and vulnerability scanning are not nice-to-haves—they are survival mechanisms. Amazon GuardDuty provides intelligent threat detection by analyzing AWS CloudTrail logs, VPC Flow Logs, and DNS logs for malicious activity. Amazon Inspector continuously scans workloads for software vulnerabilities and unintended network exposure. Together, they form a defense-in-depth layer that catches both active threats and latent weaknesses. Without them, you are flying blind: a single unpatched CVE or a compromised IAM key can lead to data exfiltration or ransomware. In my experience, teams that skip these services often discover breaches weeks later during audits, costing orders of magnitude more to remediate. The key is to treat GuardDuty and Inspector as automated security guards that never sleep, not as optional add-ons.

#!/bin/bash
# Enable GuardDuty in all regions
regions=$(aws ec2 describe-regions --query 'Regions[].RegionName' --output text)
for region in $regions; do
  echo "Enabling GuardDuty in $region"
  aws guardduty create-detector --region $region --enable
  # Optionally set finding publishing frequency
  detector_id=$(aws guardduty list-detectors --region $region --query 'DetectorIds[0]' --output text)
  aws guardduty update-detector --detector-id $detector_id --finding-publishing-frequency FIFTEEN_MINUTES --region $region
done

Setting Up GuardDuty for Multi-Account Environments

In organizations with multiple AWS accounts, managing GuardDuty individually is a nightmare. Instead, use AWS Organizations to delegate an administrator account that manages GuardDuty across all member accounts. This centralizes findings, reduces noise, and simplifies response. The delegated administrator can configure trusted IP lists, threat lists, and suppression rules. Member accounts automatically get findings forwarded. To set this up, enable GuardDuty in the management account (or a delegated admin), then use the enable-organization-admin-account API. All existing and future accounts are automatically enrolled. This pattern is critical for compliance frameworks like SOC 2 or PCI DSS that require centralized monitoring. Without it, you'll have orphaned detectors and blind spots.

#!/bin/bash
# Assumes AWS Organizations is set up and you have admin access
ADMIN_ACCOUNT_ID="123456789012"

# Enable GuardDuty in the admin account
aws guardduty create-detector --region us-east-1 --enable

# Enable organization admin account
aws guardduty enable-organization-admin-account --admin-account-id $ADMIN_ACCOUNT_ID --region us-east-1

# List all member accounts (should show all accounts in org)
aws guardduty list-members --region us-east-1

# Optional: Add a trusted IP list (e.g., corporate VPN CIDR)
aws guardduty create-ip-set --detector-id $(aws guardduty list-detectors --query 'DetectorIds[0]' --output text) --name "Corporate VPN" --format TXT --location "s3://my-bucket/trusted-ips.txt" --activate --region us-east-1

Configuring Inspector for Continuous Vulnerability Scanning

Amazon Inspector scans EC2 instances and container images for known vulnerabilities (CVEs) and network reachability issues. For EC2, you install the SSM Agent and attach an IAM role that allows Inspector to assess the instance. For containers, Inspector integrates with Amazon ECR to scan images on push or on a schedule. The key is to enable 'continuous scanning' mode, which automatically rescans when new CVEs are published. Inspector generates findings with severity levels (Critical, High, Medium, Low) and provides remediation guidance. In production, you should set up automatic remediation workflows: for example, use EventBridge to trigger a Lambda function that patches critical vulnerabilities or quarantines instances. Never rely on manual review alone—by the time you read the finding, the vulnerability may already be exploited.

resource "aws_inspector2_enabler" "example" {
  account_ids = ["123456789012"]
  resource_types = ["EC2", "ECR"]
}

resource "aws_iam_role" "inspector_assessment" {
  name = "inspector-assessment-role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = "inspector2.amazonaws.com"
        }
      }
    ]
  })
}

resource "aws_iam_role_policy_attachment" "inspector_policy" {
  role       = aws_iam_role.inspector_assessment.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AmazonInspector2ServiceRolePolicy"
}

# Attach to EC2 instance profile
resource "aws_iam_instance_profile" "inspector_profile" {
  name = "inspector-instance-profile"
  role = aws_iam_role.inspector_assessment.name
}

Automating Remediation with EventBridge and Lambda

Findings from GuardDuty and Inspector are useless if nobody acts on them. The most effective approach is to automate remediation using Amazon EventBridge rules that trigger AWS Lambda functions. For example, a GuardDuty finding of type 'UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration' should immediately revoke the compromised IAM key and isolate the instance. For Inspector findings with 'CRITICAL' severity, you can automatically patch the instance or create a ticket in Jira. The key is to have a tiered response: critical findings trigger automated containment, high findings trigger notification, and medium/low findings are batched for review. Always include a 'rollback' mechanism in your Lambda functions—automation can break things. Test your remediation playbooks in a non-production environment first.

import boto3
import os

def lambda_handler(event, context):
    # Extract finding details
    detail = event['detail']
    finding_type = detail['type']
    resource_arn = detail['resource']['instanceDetails']['instanceArn']
    
    if 'UnauthorizedAccess' in finding_type:
        # Isolate the instance by modifying security group
        ec2 = boto3.client('ec2')
        instance_id = resource_arn.split('/')[-1]
        
        # Remove all security groups and attach an isolated one
        isolation_sg = os.environ['ISOLATION_SG_ID']
        ec2.modify_instance_attribute(
            InstanceId=instance_id,
            Groups=[isolation_sg]
        )
        
        # Optionally stop the instance
        ec2.stop_instances(InstanceIds=[instance_id])
        
        print(f"Isolated instance {instance_id} due to finding: {finding_type}")
        return {'statusCode': 200, 'body': f'Isolated {instance_id}'}
    
    return {'statusCode': 200, 'body': 'No action taken'}

Integrating GuardDuty and Inspector with SIEM and Ticketing

While AWS provides a console, production teams need to integrate findings with existing security tools like Splunk, Datadog, or Jira. Use EventBridge to forward all findings to a central SNS topic or Kinesis stream. Then, a downstream consumer (e.g., a Lambda function) can format and send findings to your SIEM or ticketing system. For GuardDuty, you can also enable 'findings export' to S3 in JSON format for long-term storage and analysis. Inspector findings can be exported via the same mechanism. The goal is to have a single pane of glass where security teams can triage all findings. Avoid the trap of having security alerts in multiple places—consolidate. Also, set up severity-based routing: critical findings go to PagerDuty, high to Slack, medium to email.

resource "aws_sns_topic" "security_findings" {
  name = "security-findings"
}

resource "aws_cloudwatch_event_rule" "guardduty_findings" {
  name        = "guardduty-findings"
  description = "Capture all GuardDuty findings"
  event_pattern = jsonencode({
    source      = ["aws.guardduty"]
    detail-type = ["GuardDuty Finding"]
  })
}

resource "aws_cloudwatch_event_target" "sns_target" {
  rule      = aws_cloudwatch_event_rule.guardduty_findings.name
  target_id = "sns"
  arn       = aws_sns_topic.security_findings.arn
}

resource "aws_sns_topic_policy" "default" {
  arn = aws_sns_topic.security_findings.arn
  policy = data.aws_iam_policy_document.sns_topic_policy.json
}

data "aws_iam_policy_document" "sns_topic_policy" {
  statement {
    effect = "Allow"
    principals {
      type        = "Service"
      identifiers = ["events.amazonaws.com"]
    }
    actions   = ["SNS:Publish"]
    resources = [aws_sns_topic.security_findings.arn]
  }
}

Managing False Positives and Suppression Rules

Both GuardDuty and Inspector generate noise. GuardDuty might flag legitimate admin activity as suspicious; Inspector might report CVEs that are not exploitable in your environment. To avoid alert fatigue, use suppression rules and trusted IP lists. For GuardDuty, you can create filters to suppress findings based on criteria like 'service.name' or 'resource.instanceDetails.tags'. For Inspector, you can disable specific rules or use 'deferral' to postpone findings. However, be careful: over-suppression can hide real threats. A better approach is to tag resources with 'environment: production' and 'environment: staging', then route findings differently. Production findings go to the security team; staging findings go to developers. This way, you don't suppress—you route. Also, regularly review suppressed findings to ensure they are still valid.

#!/bin/bash
# Suppress a specific GuardDuty finding type for a given account
DETECTOR_ID=$(aws guardduty list-detectors --region us-east-1 --query 'DetectorIds[0]' --output text)

# Create a filter to suppress 'Backdoor:EC2/C&CActivity.B' for non-production instances
FILTER_NAME="suppress-backdoor-nonprod"
FILTER_CRITERIA='{
  "findingType": [{"Equals": ["Backdoor:EC2/C&CActivity.B"]}],
  "resource.instanceDetails.tags": [{"Key": "environment", "Value": "production"}]
}'

aws guardduty create-filter \
  --detector-id $DETECTOR_ID \
  --name $FILTER_NAME \
  --action ARCHIVE \
  --finding-criteria "$FILTER_CRITERIA" \
  --region us-east-1

echo "Filter created: $FILTER_NAME"

Cost Optimization for GuardDuty and Inspector

GuardDuty and Inspector costs can grow if not managed. GuardDuty charges per GB of logs analyzed; Inspector charges per instance per hour. To optimize, start by enabling GuardDuty only in regions where you have workloads. Use the 'free trial' period (30 days) to estimate costs. For Inspector, use 'exclusion rules' to skip scanning of non-critical instances (e.g., bastion hosts that are ephemeral). Also, consider using 'Inspector continuous scanning' only for production accounts; staging accounts can use 'on-demand' scans. Another tip: aggregate findings in a central account and disable GuardDuty in member accounts if you don't need local visibility. Finally, set up budgets and alerts to monitor spending. In one case, a team accidentally enabled GuardDuty in all 20 regions and saw a 10x cost spike.

#!/bin/bash
# Estimate GuardDuty cost based on CloudTrail volume
# Get CloudTrail management events per month (approximate)
TRAIL_EVENTS=$(aws cloudtrail get-trail-status --name default --query 'LatestCloudWatchLogsDeliveryTime' --output text)
# This is a placeholder; real estimation requires CloudWatch metrics
# Use AWS Cost Explorer or GuardDuty console for accurate numbers

echo "GuardDuty cost estimation requires monitoring CloudTrail volume."
echo "Typical cost: $0.10 per GB of logs analyzed."
echo "For 100 GB/month, expect ~$10/month per region."

Testing Your Detection and Response Pipeline

You cannot assume your GuardDuty and Inspector setup works without testing. AWS provides 'GuardDuty test findings' that simulate real threats. Use the create-sample-findings API to generate findings of various types. For Inspector, you can intentionally deploy a vulnerable AMI (e.g., from the 'AWS Vulnerable AMI' marketplace) and verify that Inspector detects the CVEs. Then, test your automated remediation pipeline: does the Lambda fire? Does it isolate the instance? Does it notify the right people? Run these tests in a non-production account first. Document the expected behavior and compare with actual results. We recommend a quarterly 'security drill' where the team simulates a breach and measures response time. This is the only way to ensure your defenses work when it matters.

#!/bin/bash
# Generate a sample GuardDuty finding
DETECTOR_ID=$(aws guardduty list-detectors --region us-east-1 --query 'DetectorIds[0]' --output text)

aws guardduty create-sample-findings \
  --detector-id $DETECTOR_ID \
  --finding-types "UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration" \
  --region us-east-1

echo "Sample finding created. Check GuardDuty console."

# Wait a minute and check if EventBridge triggered Lambda
sleep 60
aws logs filter-log-events --log-group-name /aws/lambda/remediate_guardduty --filter-pattern "Isolated" --region us-east-1

Advanced: Custom Threat Detection with GuardDuty and Lambda

GuardDuty's built-in threat intelligence covers common patterns, but you may need custom detection for your specific environment. For example, you might want to detect when an EC2 instance communicates with a known malicious IP that is not in GuardDuty's feed. You can do this by exporting VPC Flow Logs to S3 and running a custom Athena query or Lambda function. Alternatively, use GuardDuty's 'threat list' feature to add your own IP addresses or domains. For Inspector, you can write custom rules using 'Inspector custom assessments' (though limited). A more flexible approach is to use Amazon Detective to analyze GuardDuty findings and correlate with other data sources. However, beware of reinventing the wheel—only build custom detection if GuardDuty's coverage is insufficient. In most cases, the built-in rules are adequate.

import boto3
import json

def lambda_handler(event, context):
    # This Lambda is triggered by S3 events on VPC Flow Logs
    # Check for connections to known bad IPs
    BAD_IPS = ['203.0.113.50', '198.51.100.100']  # Example
    
    s3 = boto3.client('s3')
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = event['Records'][0]['s3']['object']['key']
    
    response = s3.get_object(Bucket=bucket, Key=key)
    log_data = response['Body'].read().decode('utf-8')
    
    for line in log_data.splitlines():
        fields = line.split(' ')
        if len(fields) >= 5:
            dst_ip = fields[4]
            if dst_ip in BAD_IPS:
                # Create a custom finding (e.g., send to SNS)
                sns = boto3.client('sns')
                sns.publish(
                    TopicArn='arn:aws:sns:us-east-1:123456789012:security-findings',
                    Message=json.dumps({'custom_finding': f'Connection to bad IP {dst_ip} from {fields[2]}'})
                )
                print(f"Alert: Connection to {dst_ip}")
    return {'statusCode': 200}

Compliance and Auditing with GuardDuty and Inspector

For compliance frameworks like PCI DSS, HIPAA, or SOC 2, you need to demonstrate that you are monitoring for threats and vulnerabilities. GuardDuty and Inspector provide built-in integrations with AWS Audit Manager and AWS Security Hub. Security Hub aggregates findings from both services and provides a compliance score. You can also export findings to S3 for long-term retention (required by many regulations). Ensure that findings are immutable and access-controlled. Additionally, set up CloudTrail to log all API calls to GuardDuty and Inspector—this creates an audit trail of configuration changes. In production, we recommend enabling 'AWS Foundational Security Best Practices' standard in Security Hub, which includes checks for GuardDuty and Inspector enablement. This ensures you don't accidentally disable them.

resource "aws_securityhub_account" "example" {}

resource "aws_securityhub_standards_subscription" "foundational" {
  depends_on    = [aws_securityhub_account.example]
  standards_arn = "arn:aws:securityhub:us-east-1::standards/aws-foundational-security-best-practices/v/1.0.0"
}

resource "aws_securityhub_standards_subscription" "pci" {
  depends_on    = [aws_securityhub_account.example]
  standards_arn = "arn:aws:securityhub:us-east-1::standards/pci-dss/v/3.2.1"
}

# Enable GuardDuty and Inspector checks
resource "aws_securityhub_action_target" "remediate" {
  name        = "Remediate"
  identifier  = "remediate"
  description = "Action to trigger remediation"
}

Common Pitfalls and How to Avoid Them

Even with GuardDuty and Inspector, teams make mistakes. The most common: (1) Not enabling GuardDuty in all accounts—attackers target the weakest link. (2) Ignoring Inspector findings because they are too numerous—use severity-based triage. (3) Over-relying on automation without testing—automation can break. (4) Not updating threat lists—GuardDuty's threat intelligence updates automatically, but custom lists need maintenance. (5) Forgetting to enable Inspector for container images—ECR scanning is not enabled by default. (6) Not setting up cross-region aggregation—findings are regional; you need a central view. (7) Skipping cost monitoring—bills can surprise. To avoid these, create a checklist during account setup. Use Infrastructure as Code to enforce GuardDuty and Inspector enablement. Regularly review findings and adjust suppression rules. Finally, conduct post-mortems on security incidents to identify gaps.

# Enforce GuardDuty enablement using AWS Config
resource "aws_config_config_rule" "guardduty_enabled" {
  name = "guardduty-enabled"

  source {
    owner             = "AWS"
    source_identifier = "GUARDDUTY_ENABLED_CENTRALIZED"
  }

  input_parameters = jsonencode({
    CentralMonitoringAccountId = "123456789012"
  })
}

resource "aws_config_config_rule" "inspector_enabled" {
  name = "inspector-enabled"

  source {
    owner             = "AWS"
    source_identifier = "INSPECTOR_ENABLED"
  }

  input_parameters = jsonencode({
    ResourceTypes = ["EC2", "ECR"]
  })
}

Conclusion: Building a Proactive Security Posture

GuardDuty and Inspector are not set-and-forget services. They require ongoing tuning, testing, and integration with your incident response process. The goal is to shift from reactive security (waiting for a breach) to proactive security (detecting and remediating before damage). Start by enabling both services in all accounts and regions where you have workloads. Centralize management via AWS Organizations. Automate remediation for critical findings. Integrate with your SIEM and ticketing systems. Test your pipeline regularly. And most importantly, foster a culture where security is everyone's responsibility—developers, operations, and security teams. The tools are powerful, but they are only as effective as the processes around them. Invest in training and runbooks. Your future self will thank you when a real incident occurs and you respond in minutes, not days.

#!/bin/bash
# Quick health check for GuardDuty and Inspector

echo "=== GuardDuty Status ==="
aws guardduty list-detectors --region us-east-1 --query 'DetectorIds[0]' --output text

echo "=== Inspector Status ==="
aws inspector2 list-findings --region us-east-1 --max-results 1 --query 'findings[0].severity' --output text

echo "=== Security Hub Status ==="
aws securityhub get-findings --region us-east-1 --max-results 1 --query 'Findings[0].Title' --output text

echo "All services operational."