AWS Config and Security Hub: Compliance Automation

Maintaining continuous compliance across dozens of AWS accounts is one of the hardest operational challenges in cloud engineering. Resources drift from their intended state constantly — an S3 bucket gets its public-access block removed, a security group opens port 22 to 0.0.0.0/0, an EBS volume gets created without encryption. AWS Config continuously monitors resource configurations and flags every deviation. AWS Security Hub aggregates those findings alongside GuardDuty threat intelligence, Inspector vulnerability data, and Macie sensitive-data alerts into a single prioritised dashboard — and can automatically remediate many issues through Systems Manager Automation documents.

This guide covers AWS Config rules in depth, conformance packs for CIS and PCI-DSS, Security Hub standards and aggregated findings, automated remediation workflows, custom Config rules backed by Lambda, multi-account aggregation, and integration between Security Hub and the major AWS security services.

AWS Config: How Continuous Compliance Works

AWS Config is a configuration history and change-tracking service. When you enable it in a region, Config deploys a configuration recorder that captures the full configuration snapshot of every supported AWS resource — EC2 instances, security groups, IAM policies, S3 buckets, RDS clusters, Lambda functions, and over 300 more resource types. Every time a resource changes, Config records a configuration item (CI) — a JSON document containing the resource's state, relationships, and metadata at that moment in time.

Configuration items are stored in an S3 bucket (your delivery channel) and optionally streamed to an SNS topic for real-time alerts. The historical CI record lets you answer questions like "What was the configuration of this security group three months ago?" and "Who changed this IAM role and when?" — critical for incident investigation and audit evidence.

Config Rules: Evaluating Compliance

Config rules are the compliance evaluation engine. Each rule is an AWS Lambda function (managed by AWS for built-in rules, or your own for custom rules) that receives configuration items and returns a compliance verdict: COMPLIANT, NON_COMPLIANT, NOT_APPLICABLE, or INSUFFICIENT_DATA.

Rules are evaluated in two modes:

• Configuration change — triggered whenever a relevant resource is created, modified, or deleted. Best for catching drift immediately.
• Periodic — runs on a schedule (1 hour, 3 hours, 6 hours, 12 hours, 24 hours). Required for rules that check account-level settings or aggregated conditions (e.g., "are CloudTrail trails enabled in all regions?").

Enabling Config with CloudFormation

The following CloudFormation snippet enables Config with an S3 delivery channel and SNS notification for all resource types:

AWSTemplateFormatVersion: '2010-09-09'
Description: Enable AWS Config with S3 delivery channel

Parameters:
  ConfigBucketName:
    Type: String
    Default: techoral-aws-config-logs

Resources:

  ConfigBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Ref ConfigBucketName
      VersioningConfiguration:
        Status: Enabled
      BucketEncryption:
        ServerSideEncryptionConfiguration:
          - ServerSideEncryptionByDefault:
              SSEAlgorithm: aws:kms
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        BlockPublicPolicy: true
        IgnorePublicAcls: true
        RestrictPublicBuckets: true
      LifecycleConfiguration:
        Rules:
          - Id: ArchiveOldConfigItems
            Status: Enabled
            Transitions:
              - TransitionInDays: 90
                StorageClass: GLACIER
            ExpirationInDays: 2557  # ~7 years for audit retention

  ConfigBucketPolicy:
    Type: AWS::S3::BucketPolicy
    Properties:
      Bucket: !Ref ConfigBucket
      PolicyDocument:
        Statement:
          - Sid: AWSConfigBucketPermissionsCheck
            Effect: Allow
            Principal:
              Service: config.amazonaws.com
            Action: s3:GetBucketAcl
            Resource: !Sub "arn:aws:s3:::${ConfigBucketName}"
          - Sid: AWSConfigBucketDelivery
            Effect: Allow
            Principal:
              Service: config.amazonaws.com
            Action: s3:PutObject
            Resource: !Sub "arn:aws:s3:::${ConfigBucketName}/AWSLogs/*"
            Condition:
              StringEquals:
                s3:x-amz-acl: bucket-owner-full-control

  ConfigSNSTopic:
    Type: AWS::SNS::Topic
    Properties:
      TopicName: aws-config-notifications
      Subscription:
        - Protocol: email
          Endpoint: security@techoral.com

  ConfigRole:
    Type: AWS::IAM::ServiceLinkedRole
    Properties:
      AWSServiceName: config.amazonaws.com

  ConfigRecorder:
    Type: AWS::Config::ConfigurationRecorder
    Properties:
      Name: default
      RecordingGroup:
        AllSupported: true
        IncludeGlobalResourceTypes: true
      RoleARN: !Sub "arn:aws:iam::${AWS::AccountId}:role/aws-service-role/config.amazonaws.com/AWSServiceRoleForConfig"

  ConfigDeliveryChannel:
    Type: AWS::Config::DeliveryChannel
    Properties:
      Name: default
      S3BucketName: !Ref ConfigBucketName
      SnsTopicARN: !Ref ConfigSNSTopic
      ConfigSnapshotDeliveryProperties:
        DeliveryFrequency: Six_Hours
    DependsOn: ConfigBucket

AWS Config Managed Rules and Conformance Packs

AWS provides over 190 managed Config rules covering the most common compliance requirements. These are pre-built, maintained by AWS, and require no Lambda code — you configure them with parameters and AWS handles the evaluation logic.

Commonly Used Managed Rules

• s3-bucket-public-read-prohibited — Flags any S3 bucket with a public ACL or bucket policy allowing public read access.
• s3-bucket-server-side-encryption-enabled — Checks that S3 buckets have default encryption enabled (SSE-S3 or SSE-KMS).
• ec2-security-group-attached-to-eni — Finds unattached security groups that accumulate and create attack surface over time.
• restricted-ssh — Flags security groups that allow unrestricted inbound SSH (port 22, source 0.0.0.0/0).
• restricted-common-ports — Same as above but covers a broader set of risky ports (3389 RDP, 3306 MySQL, 5432 Postgres, etc.).
• iam-password-policy — Validates your account's IAM password policy meets length, complexity, and rotation requirements.
• mfa-enabled-for-iam-console-access — Flags IAM users with console access but no MFA device.
• root-account-mfa-enabled — Checks whether the root account has MFA enabled.
• cloudtrail-enabled — Verifies that CloudTrail is active with at least one multi-region trail.
• encrypted-volumes — Flags EC2 EBS volumes that are not encrypted at rest.
• rds-storage-encrypted — Verifies RDS DB instances have storage encryption enabled.
• vpc-flow-logs-enabled — Checks that VPC flow logs are enabled for every VPC.
• guardduty-enabled-centralized — Verifies GuardDuty is enabled and reports to a designated master account.

Conformance Packs

A conformance pack is a collection of Config rules and remediation actions packaged as a YAML template. AWS provides ready-made packs for major compliance frameworks:

• Operational Best Practices for CIS AWS Foundations Benchmark — 43 rules covering the CIS Level 1 and Level 2 controls
• Operational Best Practices for PCI-DSS — 131 rules covering PCI-DSS requirements
• Operational Best Practices for HIPAA — 84 rules for HIPAA controls
• Operational Best Practices for NIST SP 800-53 — 180+ rules
• Operational Best Practices for SOC 2 — 80+ rules covering Trust Service Criteria

Deploy a CIS conformance pack via CLI:

# Deploy the CIS AWS Foundations Benchmark conformance pack
aws configservice put-conformance-pack \
  --conformance-pack-name "CIS-AWS-Foundations-Benchmark" \
  --template-s3-uri "s3://aws-configservice-us-east-1/conformance-packs/Operational-Best-Practices-for-CIS-AWS-v1.4-Level2.yaml" \
  --delivery-s3-bucket "techoral-aws-config-logs" \
  --region us-east-1

# Check deployment status
aws configservice describe-conformance-packs \
  --conformance-pack-names "CIS-AWS-Foundations-Benchmark" \
  --region us-east-1

# Get compliance summary for the pack
aws configservice get-conformance-pack-compliance-summary \
  --conformance-pack-names "CIS-AWS-Foundations-Benchmark" \
  --region us-east-1

# List NON_COMPLIANT rules within the pack
aws configservice get-conformance-pack-compliance-details \
  --conformance-pack-name "CIS-AWS-Foundations-Benchmark" \
  --filters '{"ComplianceType": "NON_COMPLIANT"}' \
  --region us-east-1

# Deploy PCI-DSS pack
aws configservice put-conformance-pack \
  --conformance-pack-name "PCI-DSS-v3-2-1" \
  --template-s3-uri "s3://aws-configservice-us-east-1/conformance-packs/Operational-Best-Practices-for-PCI-DSS.yaml" \
  --delivery-s3-bucket "techoral-aws-config-logs" \
  --region us-east-1

# Export compliance report to S3 (useful for auditors)
aws configservice start-config-rules-evaluation \
  --config-rule-names "s3-bucket-public-read-prohibited" \
                      "encrypted-volumes" \
                      "mfa-enabled-for-iam-console-access" \
  --region us-east-1

Custom Config Rules with Lambda

When the 190+ managed rules don't cover your specific compliance requirement, you write a custom rule backed by a Lambda function. Custom rules receive the configuration item (or an oversized-item notification) and return an evaluation result. Common use cases: enforce a custom tagging strategy, validate approved AMI IDs, check that EC2 instances use approved instance types, or verify that KMS key rotation is enabled on keys created in specific regions.

Custom Rule Structure

The Lambda function receives an event with two keys: configRuleArn and either a configurationItem (for change-triggered rules) or an invokingEvent containing a configurationItemSummary (for periodic rules). The function calls config.put_evaluations() to report results.

import json
import boto3

config_client = boto3.client('config')

# Required tags that every EC2 instance must have
REQUIRED_TAGS = {'Environment', 'Owner', 'CostCenter', 'Project'}

def lambda_handler(event, context):
    """
    Custom Config rule: EC2 instances must have required tags.
    Trigger type: ConfigurationItemChangeNotification
    Scope: AWS::EC2::Instance
    """
    invoking_event = json.loads(event['invokingEvent'])
    configuration_item = invoking_event.get('configurationItem')

    # Skip deleted resources
    if configuration_item['configurationItemStatus'] in ('ResourceDeletedNotRecorded', 'ResourceDeleted'):
        return

    resource_id = configuration_item['resourceId']
    resource_type = configuration_item['resourceType']

    compliance = evaluate_tags(configuration_item)

    evaluation = {
        'ComplianceResourceType': resource_type,
        'ComplianceResourceId': resource_id,
        'ComplianceType': compliance['status'],
        'Annotation': compliance['annotation'],
        'OrderingTimestamp': configuration_item['configurationItemCaptureTime']
    }

    config_client.put_evaluations(
        Evaluations=[evaluation],
        ResultToken=event['resultToken']
    )


def evaluate_tags(configuration_item):
    """Check that all required tags are present and non-empty."""
    tags = configuration_item.get('tags', {})
    present_tags = {k for k, v in tags.items() if v and v.strip()}
    missing_tags = REQUIRED_TAGS - present_tags

    if not missing_tags:
        return {
            'status': 'COMPLIANT',
            'annotation': 'All required tags present'
        }
    else:
        return {
            'status': 'NON_COMPLIANT',
            'annotation': f"Missing required tags: {', '.join(sorted(missing_tags))}"
        }


# ---- CloudFormation snippet to deploy the rule ----
# CustomTagComplianceRule:
#   Type: AWS::Config::ConfigRule
#   Properties:
#     ConfigRuleName: ec2-required-tags
#     Description: "EC2 instances must have Environment, Owner, CostCenter, Project tags"
#     Source:
#       Owner: CUSTOM_LAMBDA
#       SourceIdentifier: !GetAtt TagComplianceLambda.Arn
#       SourceDetails:
#         - EventSource: aws.config
#           MessageType: ConfigurationItemChangeNotification
#         - EventSource: aws.config
#           MessageType: OversizedConfigurationItemChangeNotification
#     Scope:
#       ComplianceResourceTypes:
#         - AWS::EC2::Instance
#   DependsOn: TagComplianceLambdaPermission

Automated Remediation with SSM Automation

AWS Config integrates directly with AWS Systems Manager (SSM) Automation documents to auto-remediate NON_COMPLIANT findings. When a resource fails a Config rule evaluation, Config can immediately invoke an SSM Automation document that fixes the configuration drift. This creates a fully automated compliance loop: drift detected → Config marks NON_COMPLIANT → SSM remediates → Config re-evaluates → COMPLIANT.

Remediation Execution Modes

• Automatic remediation — Triggered immediately when a resource is marked NON_COMPLIANT. Use carefully; automatic remediation of production IAM policies or security groups without human review can cause outages.
• Manual remediation — Listed in the Config console and API as available actions. An operator clicks "Remediate" to trigger the SSM document. Best for high-risk resources.

AWSTemplateFormatVersion: '2010-09-09'
Description: Config rule with automatic remediation for unencrypted EBS volumes

Resources:

  # IAM role that Config uses to invoke SSM
  ConfigRemediationRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: ConfigSSMRemediationRole
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: ssm.amazonaws.com
            Action: sts:AssumeRole
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AmazonSSMAutomationRole
      Policies:
        - PolicyName: EC2EncryptionRemediation
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Effect: Allow
                Action:
                  - ec2:CreateSnapshot
                  - ec2:CreateVolume
                  - ec2:ModifyInstanceAttribute
                  - ec2:StopInstances
                  - ec2:StartInstances
                  - ec2:DescribeVolumes
                  - ec2:DescribeSnapshots
                  - kms:CreateGrant
                  - kms:Decrypt
                  - kms:DescribeKey
                  - kms:GenerateDataKey
                Resource: "*"

  # Config rule: check EBS volume encryption
  EncryptedVolumesRule:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: encrypted-volumes
      Source:
        Owner: AWS
        SourceIdentifier: ENCRYPTED_VOLUMES
      Scope:
        ComplianceResourceTypes:
          - AWS::EC2::Volume

  # Remediation configuration — auto-remediate after 5 minutes (300s)
  EncryptedVolumesRemediation:
    Type: AWS::Config::RemediationConfiguration
    Properties:
      ConfigRuleName: !Ref EncryptedVolumesRule
      TargetType: SSM_DOCUMENT
      TargetId: AWSConfigRemediation-EncryptUnencryptedVolume
      Automatic: true
      MaximumAutomaticAttempts: 3
      RetryAttemptSeconds: 300
      Parameters:
        VolumeId:
          ResourceValue:
            Value: RESOURCE_ID
        KMSKeyId:
          StaticValue:
            Values:
              - "arn:aws:kms:us-east-1:123456789012:key/your-kms-key-id"
        AutomationAssumeRole:
          StaticValue:
            Values:
              - !GetAtt ConfigRemediationRole.Arn
    DependsOn: EncryptedVolumesRule

  # Remediation for public S3 buckets — block public access
  S3PublicBucketRule:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: s3-bucket-public-read-prohibited
      Source:
        Owner: AWS
        SourceIdentifier: S3_BUCKET_PUBLIC_READ_PROHIBITED

  S3PublicBucketRemediation:
    Type: AWS::Config::RemediationConfiguration
    Properties:
      ConfigRuleName: !Ref S3PublicBucketRule
      TargetType: SSM_DOCUMENT
      TargetId: AWSConfigRemediation-ConfigureS3BucketPublicAccessBlock
      Automatic: true
      MaximumAutomaticAttempts: 5
      RetryAttemptSeconds: 60
      Parameters:
        BucketName:
          ResourceValue:
            Value: RESOURCE_ID
        AutomationAssumeRole:
          StaticValue:
            Values:
              - !GetAtt ConfigRemediationRole.Arn
    DependsOn: S3PublicBucketRule

AWS Security Hub: Aggregated Security Findings

AWS Security Hub is the centralised security posture management service for AWS. It ingests findings from AWS-native security services (GuardDuty, Inspector, Macie, IAM Access Analyzer, Firewall Manager, Config), AWS Partner security tools (CrowdStrike, Palo Alto, Splunk, Rapid7, etc.), and custom integrations. All findings are normalised to the AWS Security Finding Format (ASFF) — a standard JSON schema that makes findings comparable across sources.

Key Concepts

• Finding — A single security observation (e.g., "GuardDuty detected port scanning from 1.2.3.4 against your EC2 instance i-abc123"). Every finding has a severity (CRITICAL, HIGH, MEDIUM, LOW, INFORMATIONAL), a workflow status (NEW, NOTIFIED, RESOLVED, SUPPRESSED), and a compliance status.
• Insight — A saved filter + grouping query that surfaces patterns across findings (e.g., "top EC2 instances by CRITICAL finding count").
• Standard — A built-in compliance benchmark (CIS, PCI-DSS, FSBP) that Security Hub evaluates across your account and reports as a compliance score.
• Control — An individual check within a Standard (e.g., CIS 2.1 "Ensure CloudTrail is enabled in all regions"). Controls map to Config rules or direct API checks.

Enabling Security Hub via CLI

# Enable Security Hub in a region
aws securityhub enable-security-hub \
  --enable-default-standards \
  --region us-east-1

# List available standards
aws securityhub describe-standards \
  --region us-east-1

# Enable a specific standard (PCI-DSS)
aws securityhub batch-enable-standards \
  --standards-subscription-requests \
    StandardsArn=arn:aws:securityhub:us-east-1::standards/pci-dss/v/3.2.1 \
  --region us-east-1

# Get current standards subscriptions
aws securityhub get-enabled-standards \
  --region us-east-1

# Get findings — filter to CRITICAL severity, active status
aws securityhub get-findings \
  --filters '{
    "SeverityLabel": [{"Value": "CRITICAL", "Comparison": "EQUALS"}],
    "WorkflowStatus": [{"Value": "NEW", "Comparison": "EQUALS"}],
    "RecordState": [{"Value": "ACTIVE", "Comparison": "EQUALS"}]
  }' \
  --sort-criteria '[{"Field": "UpdatedAt", "SortOrder": "desc"}]' \
  --max-items 20 \
  --region us-east-1

# Update finding workflow status (mark as resolved)
aws securityhub batch-update-findings \
  --finding-identifiers '[{
    "Id": "arn:aws:securityhub:us-east-1:123456789012:subscription/pci-dss/v/3.2.1/PCI.S3.1/finding/abc123",
    "ProductArn": "arn:aws:securityhub:us-east-1::product/aws/securityhub"
  }]' \
  --workflow '{"Status": "RESOLVED"}' \
  --note '{"Text": "Remediated by SSM automation on 2026-06-06", "UpdatedBy": "security-team"}' \
  --region us-east-1

Security Hub Standards: CIS, PCI-DSS, AWS Foundational

AWS Foundational Security Best Practices (FSBP)

FSBP is AWS's own security standard — 271 controls spanning IAM, EC2, S3, RDS, Lambda, CloudTrail, KMS, API Gateway, and more. It's the most comprehensive and AWS-specific standard. FSBP controls are evaluated by Security Hub directly (some use Config, others call AWS APIs directly). This is the recommended starting point for any AWS account because it's tailored specifically to AWS services and updated as new services launch.

CIS AWS Foundations Benchmark

The Center for Internet Security (CIS) AWS Foundations Benchmark is an industry-standard hardening guide. Security Hub supports v1.2.0 (58 controls) and v1.4.0 (88 controls). Key control categories:

• Identity and Access Management — No root account API keys, MFA on root and IAM console users, password policy requirements, no inline IAM policies, access key rotation
• Storage — S3 no public access, S3 logging enabled, S3 versioning enabled
• Logging — CloudTrail enabled multi-region, CloudTrail log validation, CloudTrail S3 encryption, Config enabled, VPC flow logs enabled
• Monitoring — CloudWatch alarms for root account usage, unauthorized API calls, IAM policy changes, security group changes, CloudTrail configuration changes
• Networking — No unrestricted security group rules, VPC default security group blocks all traffic, VPC peering routing tables limit

PCI-DSS Standard

The PCI-DSS standard in Security Hub covers Payment Card Industry Data Security Standard requirements. The 225 controls map PCI requirements to specific AWS configurations. Key controls:

• PCI.AutoScaling.1 — Auto Scaling groups must have health checks
• PCI.CloudTrail.1–4 — CloudTrail enabled, encrypted, log file validation, integrated with CloudWatch
• PCI.EC2.2 — VPC default security group blocks all traffic
• PCI.IAM.1–5 — Root account MFA, IAM password complexity, access key rotation, no root access keys, user account MFA
• PCI.KMS.4 — KMS keys must have rotation enabled
• PCI.RDS.1–2 — RDS snapshots not public, RDS encryption enabled
• PCI.S3.1–6 — S3 public access blocked, S3 logging, S3 versioning, S3 default encryption

Suppressing and Customising Controls

Not every control is relevant to every account. You can disable specific controls within a standard without disabling the entire standard. For example, if you intentionally allow GuardDuty findings in a sandbox account without a master, suppress that control organisation-wide. Use update-standards-control or the Security Hub console. Suppressed controls don't affect your compliance score.

Security Hub Integrations: GuardDuty, Inspector, Macie

Security Hub's real power comes from aggregating findings from every AWS security service. Each integration sends findings in ASFF format, so you see one normalised view across all threat and vulnerability data.

Amazon GuardDuty Integration

GuardDuty detects threats using machine learning and threat intelligence: compromised credentials (impossible travel, unusual API calls), cryptomining (unusual compute usage, mining pool connections), reconnaissance (port scanning, unusual API enumeration), and malware (suspicious process execution, known C2 beacon patterns).

When GuardDuty finds a threat, it sends the finding to Security Hub automatically (enable in GuardDuty settings). The finding appears in Security Hub with ProductName: GuardDuty and severity mapped from GuardDuty's own 0.1–10.0 scale to Security Hub's CRITICAL/HIGH/MEDIUM/LOW labels. You can then trigger Security Hub automation rules to route HIGH/CRITICAL GuardDuty findings to a PagerDuty incident or a Slack alert.

Amazon Inspector Integration

Inspector v2 continuously scans EC2 instances and Lambda functions for known CVEs, and ECR container images for vulnerabilities in OS packages and application dependencies. It sends every vulnerability finding to Security Hub with:

• CVE ID and CVSS score
• Affected package name, version, and fix version
• Resource details (instance ID, Lambda ARN, ECR image digest)
• Exploit availability indicator (is there a known exploit in the wild?)

Inspector findings in Security Hub enable cross-correlation: if GuardDuty detects suspicious outbound traffic from an instance AND Inspector shows that instance has a CRITICAL unpatched CVE — the combination is a strong incident signal warranting immediate response.

Amazon Macie Integration

Macie discovers and protects sensitive data (PII, financial records, credentials) in S3. When Macie finds sensitive data in a bucket, it sends a finding to Security Hub. This enables compliance workflows: an S3 bucket that Macie identifies as containing credit card numbers, that Config identifies as having public access enabled, appears as multiple correlated findings in Security Hub — surfacing the maximum-risk scenario clearly.

Automation Rules and EventBridge

Security Hub Automation Rules (launched 2023) let you automatically update finding fields when findings match filter criteria — without writing Lambda functions. For example, automatically suppress LOW-severity findings from specific accounts, or automatically set HIGH-severity Inspector findings with known exploits to CRITICAL.

# Create a Security Hub automation rule:
# Auto-suppress low-severity findings from sandbox account
aws securityhub create-automation-rule \
  --rule-name "suppress-low-sev-sandbox" \
  --rule-order 1 \
  --description "Suppress LOW findings in sandbox account 111122223333" \
  --is-terminal false \
  --criteria '{
    "SeverityLabel": [{"Value": "LOW", "Comparison": "EQUALS"}],
    "AwsAccountId": [{"Value": "111122223333", "Comparison": "EQUALS"}]
  }' \
  --actions '[{
    "Type": "FINDING_FIELDS_UPDATE",
    "FindingFieldsUpdate": {
      "Workflow": {"Status": "SUPPRESSED"},
      "Note": {
        "Text": "Auto-suppressed: low severity in sandbox account",
        "UpdatedBy": "automation-rule"
      }
    }
  }]' \
  --region us-east-1

# EventBridge rule: send CRITICAL findings to SNS
# (define in CloudFormation or console)
# EventPattern:
# {
#   "source": ["aws.securityhub"],
#   "detail-type": ["Security Hub Findings - Imported"],
#   "detail": {
#     "findings": {
#       "Severity": {"Label": ["CRITICAL"]},
#       "RecordState": ["ACTIVE"],
#       "WorkflowState": ["NEW"]
#     }
#   }
# }

# Export all findings to S3 via Findings Export
aws securityhub create-finding-aggregator \
  --region-linking-mode ALL_REGIONS \
  --region us-east-1

Multi-Account Aggregation and Delegated Admin

In an AWS Organization, you designate a delegated administrator account for both Config and Security Hub. The delegated admin sees aggregated compliance and findings across all member accounts from a single pane of glass. This is essential for enterprises with dozens or hundreds of AWS accounts.

Config Aggregator

A Config Aggregator collects configuration and compliance data from multiple accounts and regions into one account. The aggregator account can query compliance across all member accounts using the Config advanced query (SQL-like) interface.

# Create an organization-wide Config aggregator
aws configservice put-configuration-aggregator \
  --configuration-aggregator-name "org-aggregator" \
  --organization-aggregation-source '{
    "RoleArn": "arn:aws:iam::MGMT-ACCOUNT-ID:role/ConfigAggregatorRole",
    "AllAwsRegions": true
  }' \
  --region us-east-1

# Query: find all NON_COMPLIANT S3 buckets across the organisation
aws configservice select-aggregate-resource-config \
  --configuration-aggregator-name "org-aggregator" \
  --expression "
    SELECT
      accountId,
      awsRegion,
      resourceId,
      configuration
    WHERE
      resourceType = 'AWS::S3::Bucket'
      AND configuration.publicAccessBlockConfiguration.blockPublicAcls = false
  " \
  --region us-east-1

# Organization conformance pack (applies to all accounts automatically)
aws configservice put-organization-conformance-pack \
  --organization-conformance-pack-name "org-cis-benchmark" \
  --template-s3-uri "s3://techoral-aws-config-logs/conformance-packs/cis-level2.yaml" \
  --delivery-s3-bucket "techoral-aws-config-logs" \
  --region us-east-1

# Check conformance pack deployment status across member accounts
aws configservice describe-organization-conformance-pack-statuses \
  --organization-conformance-pack-names "org-cis-benchmark" \
  --region us-east-1

# Security Hub: designate delegated admin from management account
aws securityhub enable-organization-admin-account \
  --admin-account-id "SECURITY-ACCOUNT-ID" \
  --region us-east-1

# From the delegated admin account: auto-enable Security Hub in new member accounts
aws securityhub update-organization-configuration \
  --auto-enable \
  --auto-enable-standards DEFAULT \
  --region us-east-1

# Finding aggregation — aggregate findings from all regions to us-east-1
aws securityhub create-finding-aggregator \
  --region-linking-mode ALL_REGIONS \
  --region us-east-1

# Get cross-account compliance score breakdown
aws securityhub list-standards-control-associations \
  --security-control-id "S3.1" \
  --region us-east-1

Bringing It All Together: Compliance Automation Pipeline

The complete compliance automation architecture for a production AWS Organization looks like this:

1. Config Recorder captures every resource configuration change across all member accounts.
2. Organization Conformance Packs (CIS, PCI-DSS, custom) evaluate compliance continuously in every account and region.
3. Config Aggregator in the Security account collects all compliance data for cross-account dashboards.
4. Automated Remediation (SSM Automation) fixes low-risk drift immediately — unencrypted volumes, public S3 buckets, open security group rules — within minutes of detection.
5. Security Hub (delegated admin) aggregates Config findings alongside GuardDuty threats, Inspector CVEs, and Macie sensitive-data alerts into a single prioritised findings stream.
6. Automation Rules suppress noise (sandbox findings, known exceptions) and escalate critical signals.
7. EventBridge → SNS/PagerDuty routes CRITICAL findings to on-call engineers for immediate investigation.
8. Weekly compliance report (Lambda → SES) sends per-standard compliance scores to security leadership.

This pipeline achieves what manual compliance audits cannot: continuous, real-time compliance monitoring with automated remediation that keeps your security posture tight without burdening engineers with repetitive manual fixes.