Enable AWS Config

Your AWS account is a sprawling, living system — security groups get modified, S3 buckets change policies, IAM roles rotate. If you only find out about a non-compliant configuration when an auditor asks for evidence, you’ve already lost. That’s the pain this lesson solves: enabling AWS Config so you can record every configuration change, detect drift from your compliance baseline, and answer audit questions in minutes instead of weeks. Let’s get you from reactive panic to proactive, automated compliance.

The problem this lesson solves

Without AWS Config, your AWS environment is a black box. A developer temporarily opens port 22 to the world, an S3 bucket loses its encryption setting, or a security group rule quietly disappears — and you have no idea. By the time a compliance audit rolls around (or worse, a breach), you’re scrambling through CloudTrail logs and hoping you can piece together what happened.

Manual monitoring doesn’t scale — AWS accounts are dynamic, and humans can’t watch every resource 24/7. The result is configuration drift: the gap between your intended security baseline and what actually exists in production. Drift is the root cause of most cloud security incidents, and it’s silent until it’s too late.

Here’s the story worse than drift: audits. You get asked, “Show me that all S3 buckets are encrypted, and have been for the past six months.” Without a continuous record, you’ll spend days generating reports, chasing ticket history, and praying your evidence holds up. AWS Config solves both drift and audit nightmares by giving you a living history of your resource configurations.

Pro tip: If you’re working in a regulated environment (HIPAA, SOC 2, PCI-DSS), AWS Config isn’t optional — it’s often a hard requirement for demonstrating continuous compliance.

Core concept / mental model

Think of AWS Config as a surveillance camera for your AWS resources. It doesn’t block or fix anything on its own; it records what changed, when it changed, and who changed it. You get:

• Configuration history — a timeline of every resource’s state
• Configuration snapshots — point-in-time overviews of your entire account
• Compliance rules — custom or managed rules that check resources against best practices
• Notifications — when a rule fails, you get alerted (via SNS)

The core loop

1. AWS Config records a resource’s configuration (and changes) in an S3 bucket and a DynamoDB table (both behind the scenes, but you control the S3 bucket).
2. You define rules — each rule is a function that evaluates a resource and returns compliant, non-compliant, or not applicable.
3. When a change occurs, AWS Config re-evaluates the affected resources against all rules.
4. Results are logged, and you can trigger notifications.

This is event-driven, not periodic polling — AWS Config reacts to changes in near-real-time.

Key definitions

• Resource type: e.g., AWS::S3::Bucket, AWS::EC2::SecurityGroup
• Managed rule: AWS-provided, fully maintained rule (e.g., s3-bucket-ssl-requests-only)
• Custom rule: your own AWS Lambda function that returns compliance judgments
• Aggregator: lets you view compliance across multiple accounts/regions

How it works step by step

Step 1: Turn on AWS Config

You can enable it via the console, CLI, or Infrastructure as Code (CloudFormation/Terraform). Under the hood, AWS Config needs: - An S3 bucket to store configuration snapshots and history - An SNS topic to send notifications (optional but recommended) - An IAM role that grants AWS Config access to record resources and write to S3

Step 2: Choose what to record

Record all resources in the region, or limit to specific types. Start with all supported resources to get maximum visibility.

Step 3: Add rules

Start with managed rules that cover your compliance baseline. For example, s3-bucket-encryption-enabled or iam-user-mfa-enabled. You can also create custom rules for your own policies.

Step 4: Review and act

When a rule flags a resource as non-compliant, you investigate the configuration history to see what changed. You can then remediate manually or automate with AWS Systems Manager remediation actions.

Hands-on walkthrough

Let’s enable AWS Config using the AWS CLI, because it’s repeatable and scriptable — perfect for a DevOps workflow. We’ll assume you have aws configured with sufficient permissions (Config and IAM).

1. Create the S3 bucket (if you don’t have one)

aws s3api create-bucket --bucket my-config-bucket-$RANDOM --region us-east-1

Note: S3 bucket names are globally unique, so the $RANDOM suffix helps avoid collisions.

2. Create an IAM role for AWS Config

Create a trust policy that allows AWS Config to assume the role:

cat > config-trust.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "config.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}
EOF

aws iam create-role --role-name config-role --assume-role-policy-document file://config-trust.json

Attach the AWS-managed policy AWSConfigRole and a policy that allows writing to S3:

aws iam attach-role-policy --role-name config-role --policy-arn arn:aws:iam::aws:policy/service-role/AWSConfigRole

# Create a custom policy for S3 and SNS (simplified)
aws iam put-role-policy --role-name config-role --policy-name s3-write --policy-document '{
  "Version": "2012-10-17",
  "Statement": [
    {"Effect": "Allow", "Action": ["s3:PutObject", "s3:GetBucketAcl"], "Resource": "*"},
    {"Effect": "Allow", "Action": ["sns:Publish"], "Resource": "*"}
  ]
}'

3. Enable AWS Config in your region

aws configservice subscribe \
  --s3-bucket-name my-config-bucket-12345 \
  --sns-topic-arn arn:aws:sns:us-east-1:123456789012:config-topic \
  --iam-role-arn arn:aws:iam::123456789012:role/config-role

Replace the bucket name, topic ARN, and role ARN with your actual values. If you don’t have an SNS topic, you can omit --sns-topic-arn for now.

4. Add a managed rule

Let’s add the s3-bucket-ssl-requests-only rule to enforce SSL on all S3 buckets:

aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "s3-bucket-ssl-requests-only",
  "Source": { "Owner": "AWS", "SourceIdentifier": "S3_BUCKET_SSL_REQUESTS_ONLY" }
}'

5. Check compliance status

aws configservice get-compliance-details-by-config-rule --config-rule-name s3-bucket-ssl-requests-only

This returns a list of resources and their compliance state. If a bucket is non-compliant, you’ll see it in the output.

Expected output snippet:

{
  "EvaluationResults": [
    {
      "EvaluationResultIdentifier": {
        "EvaluationResultQualifier": {
          "ConfigRuleName": "s3-bucket-ssl-requests-only",
          "ResourceType": "AWS::S3::Bucket",
          "ResourceId": "my-bucket"
        }
      },
      "ComplianceType": "NON_COMPLIANT",
      "ResultRecordedTime": "2025-01-15T10:30:00Z"
    }
  ]
}

You now have a working compliance baseline. Next, let’s compare options for scaling this setup.

Compare options / when to choose what

When to choose what: - Start with AWS Config alone for small-to-medium accounts — it’s the foundation. - Add Security Hub when you need to consolidate findings from Config, GuardDuty, and other services. - Go third-party only if you have multi-cloud strategies or niche compliance frameworks (e.g., FedRAMP) that Config’s managed rules don’t cover.

Variation — use Terraform: If you’re infrastructure-as-code, you can enable Config declaratively. Here’s a snippet:

resource "aws_config_configuration_recorder" "example" {
  name     = "example"
  role_arn = aws_iam_role.config.arn
}

resource "aws_config_configuration_recorder_status" "example" {
  is_enabled = true
  depends_on = [aws_config_configuration_recorder.example]
}

Both CLI and Terraform achieve the same result; pick based on your team’s workflow.

Troubleshooting & edge cases

“The role is not authorized to perform this action”

When enabling Config, you get an error like: 'config.amazonaws.com' failed to call sts:AssumeRole.

• Fix: Double-check the trust policy — the Principal must be exactly config.amazonaws.com. Also verify the role ARN you passed is correct.

“No configuration recorder found in this region”

AWS Config records per-region. If you switch regions in the console, you might see nothing.

• Fix: Enable Config in each region where you run workloads. Use the aggregator in a central region to view all compliance across regions/accounts.

Rules remain “No results recorded”

• Cause: You added a rule but AWS Config hasn’t re-evaluated resources yet, or the rule isn’t being triggered.
• Fix: Wait a few minutes, or trigger a manual evaluation: aws configservice start-config-rules-evaluation --config-rule-names "my-rule".

Every resource is non-compliant

• Cause: You added a rule that conflicts with your existing setup (e.g., requiring encryption on buckets that aren’t encrypted yet).
• Fix: Review the rule’s parameters, and use --input-parameters to scope it (e.g., only apply to production tags). Also check if the rule is meant for a different resource type.

Edge case — AWS Config costs: Recording all resources can get pricey. Use the recording strategy (e.g., record only changed resources) and scope rules to high-value resource types to keep costs predictable.

What you learned & what's next

You’ve now enabled AWS Config, added a compliance rule, and know how to troubleshoot common setup issues. You can explain the core idea behind AWS Config for compliance, and you’ve completed a hands-on exercise — both learning objectives achieved. You’ll carry this knowledge forward: every cloud security audit starts with having reliable configuration history, and you now have it.

Next in the track: AWS Config + CloudTrail integration — you’ll combine Config’s resource state with CloudTrail’s API activity to build a full forensic timeline for incident response and advanced compliance reporting. You’re not just tracking what changed, but who changed it and why.