Skip to content
AWS aws monitoring 5 min read

AWS Config

AWS Config is a service that records the settings (the “configuration”) of your AWS resources and tracks how those settings change over time. Think of it as a continuous audit camera pointed at your account: every time a security group rule, an S3 bucket policy, or an EC2 instance type changes, Config captures a snapshot. On top of that history, it can automatically check whether each resource follows your rules — for example, “every S3 bucket must block public access” — and flag the ones that don’t. This matters because security drift is slow and silent: a single relaxed rule can stay unnoticed for months until something goes wrong.

What AWS Config actually records

The core unit in Config is a configuration item (CI): a point-in-time record of a resource’s attributes, its relationships to other resources, and the AWS CloudTrail (the service that logs API calls) events that caused the change. Config writes these CIs into an Amazon S3 (Simple Storage Service, AWS object storage) bucket and keeps a timeline you can browse.

A rule is a check that Config runs against your resources. There are two kinds:

TypeWhat it isWhen to use
AWS managed rulePre-built check maintained by AWS (e.g. s3-bucket-public-read-prohibited)Common compliance needs — start here
Custom ruleYour own logic, run as an AWS Lambda function or a Guard policyWhen no managed rule fits your specific policy

Rules can run on a change trigger (re-evaluate the instant a resource changes) or on a periodic trigger (re-evaluate every hour, 6 hours, etc.).

When to use AWS Config (and when not to)

Use Config when you need to answer questions like “what did this resource look like last Tuesday?”, “which resources are non-compliant right now?”, or “prove to an auditor that encryption was always on.” It is the backbone of governance, compliance reporting (PCI, HIPAA, SOC 2), and security drift detection.

Do not reach for Config to log who called which API — that is AWS CloudTrail’s job. Config tells you the state of a resource; CloudTrail tells you the action that changed it. They complement each other, and Config links to the CloudTrail event behind every change.

Turning on the configuration recorder

Recording is off by default. You enable a configuration recorder and a delivery channel (the S3 bucket destination), then choose which resource types to watch.

Console steps:

  1. Open the AWS Config console and choose Set up AWS Config (or Settings).
  2. Under Resource types to record, choose Specific resource types rather than All resource types (see the cost gotcha below).
  3. Pick a delivery S3 bucket (Config can create one named like config-bucket-123456789012).
  4. Optionally set an Amazon SNS (Simple Notification Service) topic for change notifications.
  5. Choose an IAM (Identity and Access Management) service role so Config can read your resources.
  6. Choose Confirm to start recording.

CLI equivalent (AWS CLI v2):

aws configservice put-configuration-recorder \
  --configuration-recorder name=default,roleARN=arn:aws:iam::123456789012:role/aws-config-role \
  --recording-group '{"allSupported":false,"resourceTypes":["AWS::S3::Bucket","AWS::EC2::SecurityGroup"]}'

aws configservice put-delivery-channel \
  --delivery-channel name=default,s3BucketName=config-bucket-123456789012

aws configservice start-configuration-recorder --configuration-recorder-name default

Verify it is running:

aws configservice describe-configuration-recorder-status --configuration-recorder-names default

Output:

{
    "ConfigurationRecordersStatus": [
        {
            "name": "default",
            "lastStartTime": "2026-06-15T09:12:44.120000+00:00",
            "recording": true,
            "lastStatus": "SUCCESS"
        }
    ]
}

Cost gotcha: Config bills per configuration item recorded and per rule evaluation. Blanket-enabling all resource types in all Regions in a busy account can produce hundreds of thousands of CIs per month and silently run into hundreds of dollars. Scope recording to the resource types and Regions you actually need to govern. A single configuration item is roughly $0.003, and each rule evaluation is roughly $0.001 — small individually, huge in aggregate.

Adding a rule and seeing compliance

Once recording is on, attach a rule. Here we use the managed rule that flags S3 buckets without server-side encryption.

Console steps:

  1. In the AWS Config console, go to Rules and choose Add rule.
  2. Search the AWS Managed Rules list for s3-bucket-server-side-encryption-enabled.
  3. Choose it, leave the default trigger (on configuration change), and choose Save.
  4. Within a minute the Compliance column shows Compliant or Noncompliant per bucket.

CLI equivalent:

aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "s3-encryption-enabled",
  "Source": {"Owner": "AWS", "SourceIdentifier": "S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED"}
}'

aws configservice get-compliance-details-by-config-rule \
  --config-rule-name s3-encryption-enabled

Output:

{
    "EvaluationResults": [
        {
            "EvaluationResultIdentifier": {
                "EvaluationResultQualifier": {
                    "ConfigRuleName": "s3-encryption-enabled",
                    "ResourceType": "AWS::S3::Bucket",
                    "ResourceId": "app-logs-prod-0a1b2c3d"
                }
            },
            "ComplianceType": "NON_COMPLIANT",
            "ResultRecordedTime": "2026-06-15T09:20:01.553000+00:00"
        }
    ]
}

Remediation actions

A rule that only reports problems still leaves you to fix them by hand. Remediation actions let Config fix a non-compliant resource automatically (or on one click) by running an AWS Systems Manager (SSM) Automation document. For the encryption example, you can attach the AWS-EnableS3BucketEncryption document so any flagged bucket gets encryption turned on.

When to use automatic vs manual remediation: use automatic for low-risk, well-understood fixes (enabling encryption, blocking public access). Use manual (a button an engineer clicks) when the fix could cause an outage — for example, removing a security group rule that might be in legitimate use.

Conformance packs

A conformance pack is a bundle of rules and remediation actions packaged as a single CloudFormation-style template, so you can deploy a whole compliance framework at once and across many accounts via AWS Organizations.

# conformance-pack-s3.yaml  (deploy with put-conformance-pack)
Resources:
  S3PublicReadProhibited:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: s3-bucket-public-read-prohibited
      Source:
        Owner: AWS
        SourceIdentifier: S3_BUCKET_PUBLIC_READ_PROHIBITED
aws configservice put-conformance-pack \
  --conformance-pack-name s3-baseline \
  --template-body file://conformance-pack-s3.yaml

AWS also publishes sample packs for PCI DSS, HIPAA, CIS Benchmarks, and more — a fast way to adopt a recognized standard without writing rules by hand.

Best Practices

  • Record only the resource types and Regions you must govern — the single biggest lever on Config cost.
  • Start with AWS managed rules and conformance packs before writing custom Lambda rules; reserve custom rules for policies AWS does not cover.
  • Attach remediation actions so compliance is self-healing, but keep risky fixes on manual approval.
  • Use an aggregator to roll up compliance from many accounts and Regions into one dashboard for organization-wide visibility.
  • Send the delivery S3 bucket and Config data to a dedicated, locked-down logging account and enable lifecycle rules to expire old configuration snapshots and control storage cost.
  • Pair Config with CloudTrail so every flagged change links to the API call (and caller) that caused it.
Last updated June 15, 2026
Was this helpful?