Enable AWS Config Rules

Your AWS account may look healthy, but without continuous monitoring, a single misconfigured S3 bucket or an overly permissive IAM policy can go unnoticed for weeks — until it becomes a breach. That's the pain this lesson solves: how to enable AWS Config rules for compliance so you get automated, ongoing visibility into your resource configurations and can enforce security policies before attackers exploit them.

The problem this lesson solves

Cloud environments are dynamic. Resources are created, modified, and deleted constantly, and manual audits can't keep up. Without automated compliance checks, you're blind to drift from your security baseline. AWS Config rules close this gap by evaluating your resources against predefined or custom standards, flagging anything that violates your policies.

Consider a common scenario: a developer launches an EC2 instance with a public security group, or an S3 bucket gets created with public read access. These are classic misconfigurations that lead to data exposure. Without Config, you'd discover them during a security review — days or weeks later. With Config, you get near-real-time alerts and a full history of changes.

This lesson focuses on enable aws config rules for compliance — the practical steps to turn on AWS Config, deploy managed rules, and start acting on the results. You'll learn how to reduce your IAM blast radius and harden your cloud posture, which are core themes of this Cloud security essentials track.

Core concept / mental model

Think of AWS Config as a security camera for your infrastructure — but one that also reviews the footage and writes you a ticket when something's wrong. It continuously records the configuration of supported resources and evaluates them against rules you define.

AWS Config is the service that records configuration changes and delivers them as a stream of events. Config rules are the evaluators: each rule checks a specific condition. For example, a rule might check that every S3 bucket has encryption enabled, or that no security group allows inbound SSH from 0.0.0.0/0.

Here's a simple definition of the key terms:

• Configuration item (CI) — a snapshot of a resource's settings at a point in time.
• Rule — a set of conditions that a resource must satisfy.
• Compliance state — COMPLIANT, NON_COMPLIANT, or NOT_APPLICABLE.
• Managed rule — a rule AWS provides, covering common security best practices.
• Custom rule — a rule you write (often as a Lambda function) for unique requirements.

Analogy: Think of Config as a security guard who walks the same route every few minutes. The guard checks each door (resource) against a checklist (rules). If a door is unlocked, the guard reports it immediately and logs the time. You get the report via email, and you can even have the guard lock the door automatically.

How it works step by step

Enabling AWS Config rules for compliance involves six high-level steps:

1. Enable AWS Config in your account (or across an organization).
2. Choose recording scope — what resource types to record and where the data goes.
3. Select or create rules — start with managed rules for common compliance frameworks.
4. Remediate — attach automatic remediation actions to non-compliant resources.
5. Review compliance — use the dashboard, CLI, or API to see the state of your resources.
6. Integrate — send notifications to SNS or Security Hub for automated responses.

Let's break down a few details.

Enabling AWS Config

Start in the AWS Management Console: navigate to AWS Config, and click Get started. You'll be asked to set up:

• Resource types to record — you can record all supported resources, or select specific types like EC2 instances or IAM policies.
• S3 bucket — Config stores configuration history and snapshot files here.
• SNS topic — for notifications on configuration changes and compliance events.
• IAM role — Config uses this role to access resources and write to S3/SNS.

For a quick start, you can accept defaults — Config will create the S3 bucket and IAM role automatically.

Choosing rules

Once Config is running, go to the Rules section and Add rule. AWS offers over 100 managed rules, such as:

• s3-bucket-public-read-prohibited
• ec2-instance-no-public-ip
• iam-policy-no-statements-with-admin-access
• cloudtrail-enabled
• encrypted-volumes

You can also use the AWS Config conformance packs — a collection of rules that map to a compliance framework like CIS AWS Foundations or PCI DSS. This is a great shortcut for compliance-focused environments.

Evaluation cycle

Rules evaluate resources in two ways: - Periodic — every N minutes (e.g., every 24 hours). - Configuration changes — the rule runs whenever a relevant resource changes.

This dual mechanism ensures you catch both existing issues and new ones as they appear.

Hands-on walkthrough

Let's go through a hands-on exercise using the AWS CLI. We'll enable AWS Config, add a couple of rules, and check compliance from the command line.

Prerequisites

• AWS CLI installed and configured (with credentials that have config: and s3: permissions).
• An S3 bucket to store configuration snapshots (you can create one if needed).

Step 1: Enable AWS Config (example using CLI)

You can enable Config via the put-configuration-recorder and start-configuration-recorder commands after setting up a delivery channel.

# Create a role that AWS Config will assume
aws iam create-role --role-name aws-config-role --assume-role-policy-document file://trust-policy.json

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

# Create a delivery channel to an S3 bucket
aws configservice put-delivery-channel --delivery-channel "{\"name\":\"default\",\"s3BucketName\":\"my-config-bucket\"}"

# Start the recorder
aws configservice start-configuration-recorder --configuration-recorder-name default

Note: You'll need to create the trust policy file first. For simplicity, you can also do this in the console — the CLI commands are for automation.

Step 2: Add a managed rule

Now let's add a rule that checks that S3 buckets are not publicly readable.

aws configservice put-config-rule --config-rule "{\"ConfigRuleName\":\"s3-bucket-public-read-prohibited\",\"Source\":{\"Owner\":\"AWS\",\"SourceIdentifier\":\"S3_BUCKET_PUBLIC_READ_PROHIBITED\"}}"

You can also do this via the console: go to Rules → Add rule → search for s3-bucket-public-read-prohibited → Add rule.

Step 3: Check compliance status

After the rule runs (the first evaluation may take a few minutes), check compliance:

aws configservice get-compliance-details-by-config-rule --config-rule-name s3-bucket-public-read-prohibited

Expected output (truncated):

{
    "EvaluationResults": [
        {
            "EvaluationResultIdentifier": {
                "EvaluationResultQualifier": {
                    "ConfigRuleName": "s3-bucket-public-read-prohibited",
                    "ResourceType": "AWS::S3::Bucket"
                }
            },
            "ComplianceType": "NON_COMPLIANT",
            "ConfigRuleInvokedTime": "2025-01-01T00:00:00Z",
            "ResultRecordedTime": "2025-01-01T00:00:00Z"
        }
    ]
}

If you see NON_COMPLIANT, that bucket is publicly readable. You can fix it by applying a bucket policy or enabling Block Public Access.

Step 4: Remediate a non-compliant resource

To automate fixing, attach a remediation action to the rule. For the S3 rule, you can use AWS Systems Manager automation document AWS-RemovePublicReadS3Bucket:

aws configservice put-remediation-configurations \
  --remediation-configurations "[{\"ConfigRuleName\":\"s3-bucket-public-read-prohibited\",\"TargetId\":\"AWS-RemovePublicReadS3Bucket\",\"TargetType\":\"SSM_DOCUMENT\",\"Automatic\":true}]"

Now the rule will automatically attempt to make non-compliant buckets private.

Step 5: Aggregate across accounts (optional)

For organizations, set up an aggregator to see compliance across all accounts:

aws configservice put-aggregation-authorization --authorized-account-id 123456789012 --authorized-account-region us-east-1

Compare options / when to choose what

When enabling AWS Config rules, you have several choices—each fits different needs.

For most users, start with managed rules and add conformance packs if you're targeting a specific standard. Custom rules become necessary when your policies are nuanced.

Pro tip: The AWS::Config::ResourceCompliance custom rule type lets you run your own logic (e.g., in Python) beyond simple managed rules.

Troubleshooting & edge cases

AWS Config can be tricky. Here are common issues and fixes:

• Rule shows NOT_APPLICABLE — The rule's scope doesn't match any resources. For example, an S3 rule won't apply if you have no S3 buckets. Check the rule's Scope and your resource inventory.
• No evaluation results — The rule may have just been created. Wait a few minutes (up to 15) for the first evaluation. If it's a periodic rule, it may take up to the specified interval.
• Permission errors — AWS Config needs an IAM role with permissions. Ensure the role has config:Put* and s3:PutObject permissions for the delivery channel.
• Bucket is public but rule says COMPLIANT — Make sure you're using a managed rule that checks public access (e.g., S3_BUCKET_PUBLIC_READ_PROHIBITED). Also, the rule may evaluate only certain resources; verify the rule's scope.
• Cost concerns — AWS Config is cheap, but heavy resource recording can add up. Limit recording to critical resource types (e.g., EC2, S3, IAM) to reduce costs.
• Conflicting rules — If two rules have overlapping scope and different outcomes, the compliance state of a resource might be unclear. Design rules to avoid conflicting triggers.

What you learned & what's next

You've learned how to enable AWS Config rules for compliance — from enabling the service, to deploying managed rules, to checking compliance and automating remediation. These skills directly support your track's focus on reducing IAM blast radius and hardening your cloud perimeter.

Key takeaways from this lesson:

• AWS Config continuously records resource configurations and evaluates them against rules.
• Managed rules cover most common security best practices; use conformance packs for compliance frameworks.
• You can automate fixes with SSM remediation, turning detection into action.
• Check compliance via the console or CLI/API for scripting and audits.

Next in this track — you'll explore how to centralize security findings with AWS Security Hub, and how to respond to compliance alerts automatically. Building on Config rules, Security Hub aggregates findings across multiple AWS services, giving you a single pane of glass for your security posture.

Now go ahead and add a few Config rules to your practice account — you'll be surprised how many misconfigurations you already have.