Skip to main content
In this lesson you’ll learn how AWS Config enforces governance by continuously monitoring, recording, and evaluating resource configurations across your AWS environment. AWS Config provides a central, auditable source of truth for resource state, relationships, and configuration history—enabling drift detection, compliance reporting, and automated remediation. Think of AWS Config as a librarian for your cloud resources: it catalogs what exists, records changes over time, tracks relationships, and alerts you when things deviate from policy.
A slide titled "Before AWS Config" showing four blue circular icons and labels for common problems: Lack of visibility, Manual configuration auditing, Configuration drift, and Security and compliance risks.
Before AWS Config, teams often struggled with limited visibility, manual auditing, and configuration drift. AWS Config remediates these gaps by automatically tracking configuration items (CIs), relationships, and changes.

​
How AWS Config fits with other governance services

Each AWS service in the governance stack focuses on a distinct problem: While these services overlap in supporting compliance and multi-account visibility, AWS Config is the primary tool for continuous configuration monitoring and automatic remediation.
A comparison table of AWS Config, AWS Security Hub, and AWS Audit Manager showing features such as purpose, compliance detection, remediation, multi-account support, and best use cases. It notes AWS Config is for continuous resource monitoring and auto-remediation, Security Hub for security event aggregation, and Audit Manager for automating compliance reports.

​
Configuration Items and Recording

AWS Config represents each tracked resource as a configuration item (CI). A CI includes metadata, attributes, relationships to other resources, and timestamps for creation, updates, and deletions. You can choose the recording frequency:
  • On every change (recommended for near-real-time monitoring).
  • Periodic (for example, daily snapshots).
Configuration history stores versioned snapshots of a resource so you can answer questions like: When was the resource created? What changed last month? What changed at a specific timestamp?
A slide titled "Configuration Item" showing an AWS Config icon on the left and a Configuration Item document icon on the right. An arrow between them is labeled "Created, Updated, or Deleted" and "Recording Frequency."
A slide titled "Configuration History" showing a collection of three configuration item icons labeled v1, v2, and v3, with a stopwatch icon. To the right are three question boxes asking when the resource was created, how it was configured in the last month, and what changes were made yesterday at 9 AM.

​
Recorder and Delivery Channel

The AWS Config recorder captures create/update/delete events and produces configuration items. The delivery channel controls where snapshots, history files, and notifications are sent. Common delivery patterns:
  • Store snapshots and history in an S3 bucket (apply strict bucket policies, encryption, and lifecycle rules).
  • Route notifications to SNS or EventBridge to trigger downstream automation.
A diagram titled "Delivery Channel: S3" showing AWS Config sending configuration data to an S3 bucket. The bucket stores three types of configuration data labeled Items, Snapshots, and History.
You can forward SNS notifications to Lambda, EventBridge, or other systems. EventBridge provides flexible routing to many AWS services; Lambda can perform arbitrary remediation by calling AWS APIs.
A diagram titled "How Config Works" showing AWS resource icons feeding into an AWS Config service icon. Config stores configuration data to an S3 bucket and triggers downstream actions (for example a Lambda function) via rule/action icons.
Secure delivery targets: ensure S3 bucket IAM policies, encryption (SSE-KMS/SSE-S3), and cross-account access are correctly configured. Also confirm the remediation role has least-privilege permissions for any automated actions.

​
Rules: Managed and Custom

AWS Config evaluates resources using rules. There are two main types:
  • AWS Managed Rules: Pre-built, maintained by AWS. These cover common best practices (for example, EBS encryption, public snapshot checks, Auto Scaling settings). Quick to deploy—no custom code required.
  • Custom Rules: Implement your own evaluation logic (typically a Lambda function written in Python, Node.js, etc.). Use custom rules for organization-specific or application-level policy checks.
Rules produce standard compliance statuses:
  • COMPLIANT — resource conforms to the rule.
  • NON_COMPLIANT — resource violates the rule.
  • NOT_APPLICABLE — rule does not apply to this resource type.
  • INSUFFICIENT_DATA — AWS Config cannot determine compliance.
A slide titled "How AWS Config Rules Work" showing four status tiles. The tiles are labeled COMPLIANT (blue check), NON_COMPLIANT (orange X), ERROR (green warning triangle), and NOT_APPLICABLE (purple "NA").
Managed rules are excellent for broad, well-known checks. For fine-grained or bespoke policy enforcement, author custom rules as Lambda functions.
A slide titled "AWS Managed Config Rules" showing a screenshot of the AWS Managed Rules console with a list of EC2-related rules. To the right are three highlighted benefits: built-in logic (no code required), evaluates best practices and compliance frameworks, and quick to deploy.
A presentation slide titled "Custom Config Rules" showing an AWS Lambda icon (with Python and Node.js logos) inside a dashed box. To the right are two callouts: "Full control over compliance policies" and "Useful for custom security and business logic."

​
Workflow and Automatic Remediation

A typical AWS Config workflow:
  1. Enable AWS Config and start the recorder.
  2. Define rules (managed or custom).
  3. Evaluate resources and check compliance status.
  4. Attach remediation actions to rules to automatically fix non-compliant resources.
By default, AWS Config only detects and reports non-compliance. To perform automatic remediation you must attach remediation actions (for example, Systems Manager Automation runbooks or Lambda functions) to rules.
A diagram titled "AWS Config Workflow" showing a four-step flow with icons and arrows. The steps are: Enable AWS Config, Define AWS Config rules, Check Compliance status, and Apply Automatic Remediation.
AWS Config detects non-compliance out of the box, but automated remediation requires explicitly configured remediation actions (Systems Manager Automation, Lambda, etc.). Ensure your remediation IAM role and target services have the necessary permissions before enabling automated fixes.

​
Evaluation Modes and Trigger Types

AWS Config supports different evaluation modes and triggers so you can balance latency and cost:
  • Evaluation modes:
    • Proactive evaluation: validates configuration before or during deployment when supported (helps prevent misconfigurations).
    • Detective evaluation: ongoing scans of existing resources to detect drift and non-compliance.
  • Trigger types:
    • Configuration change trigger: evaluate when a resource changes (event-driven).
    • Periodic trigger: evaluate on a schedule (for example, hourly or daily).
    • Hybrid: immediate evaluation on changes plus periodic full scans.
A slide titled "AWS Config Trigger Types" showing three colored boxes: Configuration Changes Trigger, Periodic Trigger, and Hybrid Trigger, each with a brief description of when evaluations occur (on resource changes, at regular intervals, or immediately on change).

​
Remediation Actions

When a rule flags a resource as NON_COMPLIANT, remediation actions can be invoked:
  • AWS Systems Manager Automation runbooks — ideal for standardized, auditable operational fixes.
  • AWS Lambda functions — use for custom or complex remediation logic (e.g., tagging, reconfiguration, resource replacement).
  • Notifications via SNS or EventBridge — alert operators or trigger external workflows.
Automated remediation reduces mean time to remediation (MTTR), makes infrastructure self-healing, and lowers the risk of long-lived non-compliance.
A simple flow diagram titled "Remediating Noncompliant Resources" showing AWS resource icons on the left being monitored and checked for noncompliance in the center, which then triggers remediation actions on the right. The remediation actions shown include AWS Systems Manager Automation runbooks and AWS Lambda functions.

​
Conformance Packs

Conformance Packs bundle multiple AWS Config rules and remediation actions into a single, reusable package defined in YAML. Apply a conformance pack to an account, region, or across an AWS Organization to ensure consistent policy enforcement. Use conformance packs when you want to:
  • Roll out a standard compliance baseline across multiple accounts.
  • Version-control and automate deployment of policy sets.
A presentation slide titled "Conformance Pack" showing an icon for a conformance pack and a formula: "AWS Config managed or custom rules = + Remediation actions." The slide also shows a small "© Copyright KodeKloud" at the bottom.

​
Aggregators for Multi-Account / Multi-Region

Config Aggregators collect AWS Config data from many accounts and regions into a single aggregated view. Aggregators enable centralized governance by simplifying enterprise-wide queries, dashboards, and reporting. Key benefits:
  • Centralized compliance dashboards across accounts and regions.
  • Aggregated metrics (total resources, compliant vs non-compliant counts).
  • Easier evidence collection for audits and executive reporting.
A diagram titled "AWS Config Aggregator" showing a flow from Accounts and Regions through AWS Config Data into an Aggregator and then to an Aggregated View, with icons representing users, global regions, data files, filters, and a dashboard. The image illustrates how configuration and compliance data are collected, aggregated, and presented.
Aggregators are essential when scaling governance across multiple accounts: they consolidate datasets and give governance teams a single place to monitor posture.

​
Best Practices

  • Enable AWS Config organization-wide (AWS Control Tower can bootstrap this).
  • Automate remediation where safe and auditable (Systems Manager Automation or Lambda).
  • Use Config Aggregators to centralize data across accounts and regions.
  • Store configuration history and snapshots in S3 (apply encryption, access controls, and lifecycle policies).
  • Integrate AWS Config findings with Security Hub and other security tools for centralized insights and alerting.
  • Use conformance packs to standardize and version policy bundles.
A presentation slide titled "AWS Config Architecture – Best Practices" showing a checklist of recommendations (enable AWS Config organization‑wide, automate remediation with SSM and Lambda, use Config aggregators, store history in S3, and integrate with Security Hub).
Summary: AWS Config provides continuous configuration monitoring, versioned configuration history, evaluation through managed or custom rules, and supports automated remediation and enterprise aggregation. Use AWS Config as the backbone of your configuration governance strategy to improve visibility, reduce drift, and automate compliance at scale. Further reading and references:

Watch Video

Practice Lab