AWS Config: Resource Compliance and Configuration History

You’ve got 10,000 EC2 instances, and one of them just had its security group opened to 0.0.0.0/0. By the time you find out, your data is already exfiltrated. This isn’t a hypothetical—it’s a Tuesday. AWS Config exists to prevent this exact scenario by giving you a continuous audit trail and automated compliance checks. It’s not just a logging tool; it’s your first line of defense against configuration drift and security misconfigurations. In production, Config is the difference between catching a rogue change in minutes and discovering it during a post-mortem. This article covers how to set up Config rules, interpret compliance data, and use configuration history to debug incidents—without the fluff.

Why AWS Config Matters in Production

AWS Config is not just an audit tool; it's your first line of defense against configuration drift. In production, a single misconfigured security group or an S3 bucket with public access can lead to data breaches or outages. AWS Config continuously monitors your resource configurations, evaluates them against desired rules, and provides a historical record of changes. This enables you to detect non-compliant resources in real-time, troubleshoot incidents by reviewing configuration timelines, and enforce compliance with internal policies or regulatory standards like PCI-DSS or HIPAA. Without AWS Config, you're flying blind — changes happen silently, and you only discover issues after an incident. In my experience, teams that skip Config often face painful post-mortems where the root cause is a configuration change that no one logged.

aws configservice put-configuration-recorder --configuration-recorder name=default,roleARN=arn:aws:iam::123456789012:role/aws-service-role/config.amazonaws.com/AWSServiceRoleForConfig
aws configservice put-delivery-channel --delivery-channel name=default,s3BucketName=my-config-bucket,snsTopicARN=arn:aws:sns:us-east-1:123456789012:config-topic
aws configservice start-configuration-recorder --configuration-recorder-name default

Setting Up AWS Config Recorder and Delivery Channel

The AWS Config service relies on two core components: the configuration recorder and the delivery channel. The recorder captures configuration changes for supported resource types, while the delivery channel specifies where to store configuration snapshots and configuration history (S3 bucket) and where to send notifications (SNS topic). When setting up, choose an S3 bucket with versioning enabled to prevent accidental deletion or overwrite of historical data. Use a separate bucket per account or a centralized bucket with proper prefixes. The SNS topic is optional but recommended for real-time alerts on configuration changes or compliance state transitions. For production, configure the recorder to capture all resource types, not just a subset, because you never know which resource will cause the next incident. Also, set the delivery frequency to 1 hour for snapshots to balance cost and granularity.

resource "aws_config_configuration_recorder" "main" {
  name     = "default"
  role_arn = aws_iam_role.config.arn

  recording_group {
    all_supported                 = true
    include_global_resource_types = true
  }
}

resource "aws_config_delivery_channel" "main" {
  name           = "default"
  s3_bucket_name = aws_s3_bucket.config.id
  s3_key_prefix  = "config"
  sns_topic_arn  = aws_sns_topic.config.arn

  snapshot_delivery_properties {
    delivery_frequency = "One_Hour"
  }
}

resource "aws_s3_bucket" "config" {
  bucket = "my-config-bucket-${data.aws_caller_identity.current.account_id}"
  versioning {
    enabled = true
  }
}

Writing Custom Config Rules for Compliance

AWS Config provides managed rules (e.g., s3-bucket-public-read-prohibited, restricted-ssh) but custom rules are where you get real value. Custom rules are AWS Lambda functions that evaluate resource configurations against your specific policies. For example, you might require that all EC2 instances have a specific tag (e.g., Environment) or that RDS instances are encrypted at rest. The Lambda function receives an evaluation event containing the resource configuration and must return a compliance state (COMPLIANT, NON_COMPLIANT, or NOT_APPLICABLE). Write idempotent functions that handle missing fields gracefully. Use the AWS Config API to put evaluations. For production, ensure your Lambda function has a timeout of at least 60 seconds and sufficient memory to process complex evaluations. Also, enable error handling and logging to CloudWatch for debugging.

import boto3
import json

def lambda_handler(event, context):
    invoking_event = json.loads(event['invokingEvent'])
    configuration_item = invoking_event['configurationItem']
    rule_parameters = json.loads(event['ruleParameters'])
    
    compliance_type = 'COMPLIANT'
    annotation = 'Resource is compliant.'
    
    if configuration_item['resourceType'] == 'AWS::EC2::Instance':
        tags = {tag['key']: tag['value'] for tag in configuration_item.get('tags', [])}
        required_tag = rule_parameters.get('requiredTag')
        if required_tag not in tags:
            compliance_type = 'NON_COMPLIANT'
            annotation = f'Missing required tag: {required_tag}'
    
    config = boto3.client('config')
    config.put_evaluations(
        Evaluations=[
            {
                'ComplianceResourceType': configuration_item['resourceType'],
                'ComplianceResourceId': configuration_item['resourceId'],
                'ComplianceType': compliance_type,
                'Annotation': annotation,
                'OrderingTimestamp': configuration_item['configurationItemCaptureTime']
            }
        ],
        ResultToken=event['resultToken']
    )
    return compliance_type

Aggregating Compliance Across Multiple Accounts

In multi-account environments, managing compliance per account is inefficient. AWS Config Aggregator collects configuration and compliance data from multiple accounts and regions into a single view. You can create an aggregator in a central account (e.g., Security or Audit account) and authorize source accounts to share data. Use AWS Organizations to automatically add all accounts in the organization. The aggregator provides a unified dashboard showing compliance status across accounts, enabling you to identify trends and non-compliant resources quickly. For production, set up the aggregator with a comprehensive query scope to include all resources. Also, use the aggregator's advanced queries to run SQL-like queries across aggregated data for custom reports. Remember that aggregator data is eventually consistent; there can be a delay of up to 15 minutes.

resource "aws_config_configuration_aggregator" "org" {
  name = "org-aggregator"

  organization_aggregation_source {
    role_arn    = aws_iam_role.aggregator.arn
    all_regions = true
  }

  depends_on = [aws_iam_role_policy_attachment.aggregator]
}

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

resource "aws_iam_role_policy_attachment" "aggregator" {
  role       = aws_iam_role.aggregator.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSConfigRoleForOrganizations"
}

Automating Remediation with AWS Config Rules

Detection without remediation is just noise. AWS Config allows you to associate automatic remediation actions with rules using AWS Systems Manager Automation documents or custom Lambda functions. For example, if an S3 bucket becomes publicly accessible, you can automatically apply a bucket policy to block public access. To set up remediation, create an SSM Automation document that performs the corrective action, then associate it with the Config rule. The remediation can be triggered automatically when a resource is evaluated as NON_COMPLIANT. For production, be cautious with auto-remediation: test thoroughly to avoid unintended consequences (e.g., breaking legitimate access). Use a manual approval step for critical resources. Also, set a retry count and timeout to handle transient failures. Monitor remediation actions in CloudTrail.

schemaVersion: '0.3'
description: 'Remediate S3 bucket public access'
assumeRole: '{{ AutomationAssumeRole }}'
parameters:
  BucketName:
    type: String
    description: 'Name of the S3 bucket'
  AutomationAssumeRole:
    type: String
    description: 'IAM role for automation'
mainSteps:
  - name: BlockPublicAccess
    action: 'aws:executeAwsApi'
    inputs:
      Service: s3
      Api: PutPublicAccessBlock
      Bucket: '{{ BucketName }}'
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        IgnorePublicAcls: true
        BlockPublicPolicy: true
        RestrictPublicBuckets: true
    isEnd: true

Querying Configuration History with Advanced Queries

AWS Config Advanced Queries allow you to run SQL-like queries across your configuration data. This is invaluable for ad-hoc investigations, such as finding all EC2 instances with a specific AMI or listing all S3 buckets without encryption. You can query across accounts and regions using the aggregator. The query syntax is similar to SQL but with limitations (no JOINs, subqueries). Use the AWS Config console or API to execute queries. For production, save frequently used queries as query definitions for reuse. Also, use queries to generate compliance reports for auditors. Remember that queries are eventually consistent and may not reflect the latest changes. For real-time data, use the configuration stream via EventBridge.

SELECT
  resourceId,
  resourceType,
  configuration.instanceType,
  configuration.imageId
WHERE
  resourceType = 'AWS::EC2::Instance'
  AND configuration.instanceType LIKE 't2.%'
  AND configuration.imageId NOT IN ('ami-12345678', 'ami-87654321')

Monitoring Configuration Changes with EventBridge

AWS Config sends configuration change notifications to Amazon EventBridge (formerly CloudWatch Events). You can create rules to trigger actions on specific events, such as when a security group ingress rule is modified or when an IAM role is created. This enables real-time response to changes. For example, you can send a notification to a Slack channel or invoke a Lambda function to validate the change. EventBridge events from Config include the full configuration item, so you can evaluate the change context. For production, use event patterns to filter only relevant changes to avoid noise. Also, consider using EventBridge Pipes to stream events to other services like SQS or Kinesis for further processing. Be mindful of event delivery guarantees: EventBridge offers at-least-once delivery, so your handler must be idempotent.

{
  "source": ["aws.config"],
  "detail-type": ["Config Configuration Item Change"],
  "detail": {
    "resourceType": ["AWS::EC2::SecurityGroup"],
    "messageType": ["ConfigurationItemChangeNotification"]
  }
}

Cost Optimization and Governance with AWS Config

AWS Config costs are based on the number of configuration items recorded and rules evaluated. In large environments, costs can escalate quickly. To optimize, selectively record only critical resource types if you don't need full coverage. However, I recommend recording all supported types because the cost is usually worth the visibility. Use the Config console's cost explorer to monitor usage. For governance, enforce that all accounts have Config enabled via Service Control Policies (SCPs). Also, use Config rules to detect unused resources (e.g., untagged resources, idle load balancers) and trigger cost-saving actions. For production, set budgets and alerts on Config costs. Consider using the Config API to programmatically manage rules and avoid manual errors.

data "aws_iam_policy_document" "scp_config" {
  statement {
    effect = "Deny"
    actions = [
      "config:StopConfigurationRecorder",
      "config:DeleteConfigurationRecorder",
      "config:DeleteDeliveryChannel"
    ]
    resources = ["*"]
    condition {
      test     = "ArnNotLike"
      variable = "aws:PrincipalArn"
      values   = ["arn:aws:iam::*:role/AdminRole"]
    }
  }
}

resource "aws_organizations_policy" "config_scp" {
  name    = "Config-Enforcement"
  content = data.aws_iam_policy_document.scp_config.json
}

Troubleshooting Common AWS Config Issues

Even with proper setup, AWS Config can fail silently. Common issues include: the configuration recorder not starting due to missing IAM permissions, delivery channel failing because the S3 bucket policy is incorrect, or custom rules timing out. Always check CloudWatch Logs for Lambda errors. Use the AWS Config console's 'Resources' tab to verify that resources are being recorded. If you see 'No results', check the recorder status. For delivery issues, verify S3 bucket permissions and that the bucket exists in the same region. Another common issue is that Config does not support all resource types; check the supported resource list. For production, set up CloudWatch alarms on Config metrics like 'ConfigRulesEvaluation' and 'ConfigurationRecorderStatus' to detect failures early.

aws configservice describe-configuration-recorder-status --configuration-recorder-name default
aws configservice describe-delivery-channel-status --delivery-channel-name default
aws configservice get-compliance-details-by-config-rule --config-rule-name s3-bucket-public-read-prohibited --compliance-types NON_COMPLIANT

Integrating AWS Config with CI/CD Pipelines

Shift left by integrating AWS Config into your CI/CD pipeline. Before deploying infrastructure changes, you can run Config rules against the proposed configuration to catch non-compliance early. Use tools like AWS CloudFormation Hooks or Terraform's sentinel policies to evaluate configurations. Alternatively, after deployment, trigger a Config evaluation and fail the pipeline if resources are non-compliant. For example, in a CodePipeline, add a step that invokes a Lambda function to run a Config query and check for non-compliant resources. This prevents non-compliant resources from reaching production. For production, ensure your pipeline has proper IAM permissions to call Config APIs. Also, consider using Config conformance packs to deploy a set of rules and remediation actions as part of your infrastructure-as-code.

version: 0.2
phases:
  post_build:
    commands:
      - aws configservice get-compliance-details-by-config-rule --config-rule-name required-tags --compliance-types NON_COMPLIANT --query 'EvaluationResults[?ComplianceType==`NON_COMPLIANT`]' --output text
      - if [ -n "$NON_COMPLIANT" ]; then echo "Non-compliant resources found. Failing pipeline."; exit 1; fi

Using Conformance Packs for Standardized Compliance

Conformance packs are collections of AWS Config rules and remediation actions that can be deployed together across accounts and regions. They are defined as YAML templates and can be version-controlled. AWS provides sample conformance packs for standards like PCI-DSS, HIPAA, and CIS Benchmarks. You can also create custom packs for your organization's policies. Deploy conformance packs using AWS CloudFormation StackSets to multiple accounts. This ensures consistent compliance posture across your entire organization. For production, start with a small set of rules and gradually expand. Monitor the conformance pack compliance status in the Config console. Be aware that conformance packs have limits on the number of rules per pack (currently 50).

Resources:
  S3BucketPublicReadProhibited:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: s3-bucket-public-read-prohibited
      Source:
        Owner: AWS
        SourceIdentifier: S3_BUCKET_PUBLIC_READ_PROHIBITED
      Scope:
        ComplianceResourceTypes:
          - AWS::S3::Bucket
  IAMUserNoPoliciesCheck:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: iam-user-no-policies-check
      Source:
        Owner: AWS
        SourceIdentifier: IAM_USER_NO_POLICIES_CHECK
      Scope:
        ComplianceResourceTypes:
          - AWS::IAM::User

Best Practices for AWS Config in Production

After years of using AWS Config in production, here are my top recommendations: 1) Enable Config in all regions and accounts, including future accounts via Organizations. 2) Use a centralized S3 bucket with versioning and lifecycle policies. 3) Write custom rules for your specific policies, not just managed rules. 4) Set up automated remediation with caution and testing. 5) Use the aggregator for cross-account visibility. 6) Monitor Config health with CloudWatch alarms. 7) Integrate Config into your CI/CD pipeline. 8) Use conformance packs for standardized compliance. 9) Regularly review Config costs and optimize recording scope. 10) Train your team on Config's capabilities and limitations. Remember, Config is a tool, not a silver bullet. Combine it with other services like Security Hub, GuardDuty, and IAM Access Analyzer for comprehensive security.

for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  aws configservice put-configuration-recorder --configuration-recorder name=default,roleARN=arn:aws:iam::123456789012:role/aws-service-role/config.amazonaws.com/AWSServiceRoleForConfig --region $region
  aws configservice put-delivery-channel --delivery-channel name=default,s3BucketName=my-config-bucket,s3KeyPrefix=$region --region $region
  aws configservice start-configuration-recorder --configuration-recorder-name default --region $region
done