Skip to main content
In this lesson, we’ll explore AWS Config — a managed service for continuous resource configuration monitoring, auditing, and compliance. You’ll learn what AWS Config does, where it fits in your cloud environment, how rules work, and a common example for enforcing HTTPS on Application Load Balancers. What is AWS Config? AWS Config continuously records and evaluates the configuration state of supported AWS resources. It provides a time-ordered history of configuration changes, captures relationships between resources, and can notify or trigger automated remediation when deviations occur. Use cases include auditing, security posture management, compliance reporting, and troubleshooting configuration drift. Think of AWS Config like a librarian who tracks which books were checked out, when, and which books are related — Config tracks what changed, when it changed, and how resources relate to one another. Before AWS Config, teams often relied on manual checks or custom scripts to examine resource settings. That approach made it easy for configuration drift and undocumented dependencies to slip by, creating security and compliance gaps. AWS Config solves this by continuously recording configuration items and exposing tools to detect and respond to changes.
A slide titled "Before AWS Config" showing five numbered issues: Lack of Visibility, Manual Configuration Auditing, Configuration Drift, Security and Compliance Risks, and Resource Relationship Mapping. Each issue is displayed in a column with a colorful circular icon.

​
Key capabilities

You configure rules to define the desired configuration state or compliance checks. Rules can be AWS-managed or custom (Lambda-backed). When a rule detects a noncompliant resource, AWS Config generates findings, sends notifications, and can kick off automated remediation.
A presentation slide titled "AWS Config Use Cases" with a turquoise gradient panel on the left. The right side lists five numbered use cases (inventory, continuous monitoring, detecting changes, reporting non-compliance, and sending notifications).

​
How AWS Config fits into your environment

When enabled for a region, AWS Config starts recording configuration items (CIs) for supported resource types. Each CI includes:
  • Resource configuration and metadata
  • Relationships and dependencies to other resources
  • A timestamped change history
Common integrations and flows:
  • Store snapshots and historical CI data in an S3 bucket for long-term retention and auditing.
  • Route change notifications to Amazon EventBridge or Amazon SNS to build alerting streams.
  • Invoke AWS Lambda functions or Systems Manager Automation to filter, analyze, or remediate changes programmatically.
Example workflow: An administrator replaces a security group attached to an EC2 instance. AWS Config records the change, stores the CI in S3, evaluates any applicable rules, and emits events. Those events can alert teams or invoke Lambda to perform automated remediation or additional auditing.
A simple AWS architecture diagram titled "Config" showing a group of AWS resource icons feeding into AWS Config (pink icon), which then connects to an S3 bucket and downstream processing components including a filter/processor and AWS Lambda. The left box is labeled "AWS Resources" and contains common service icons.

​
AWS Config rules

Rules evaluate whether resources meet your desired configuration or organizational policies. There are two primary rule types: Rules support two evaluation modes:
  • Configuration change-triggered: Evaluates when a relevant resource changes.
  • Periodic (scheduled) evaluation: Runs on a schedule to catch drift or non-event-based issues.
When a resource violates a rule, AWS Config marks it as noncompliant and can generate findings, notifications, and optionally trigger remediation actions.
Screenshot of the AWS Config Rules console showing AWS Managed Rules filtered by "EC2". The table lists rule names, labels, supported evaluation modes and descriptions (e.g., ALB HTTP→HTTPS redirection, Auto Scaling health checks).

​
Example: ALB HTTP → HTTPS redirection rule

A common managed rule verifies that Application Load Balancer (ALB) HTTP listeners redirect traffic to HTTPS. If any HTTP listener lacks a redirect action to HTTPS, the rule reports the ALB as noncompliant. Enforcing this rule helps eliminate unencrypted HTTP traffic and enforce secure-by-default configurations.
Use AWS managed rules to cover common security and best-practice checks quickly. For organization-specific or more complex checks, author custom rules (Lambda-backed). Combine Config rules with EventBridge, SNS, Lambda, or Systems Manager Automation to implement scalable alerting and automated remediation.

Watch Video