AWS Config: Configuration History, Rules, and Compliance

AWS Config records the configuration of supported AWS resources, tracks configuration changes over time, evaluates resources against compliance rules, and helps organisations investigate and remediate configuration problems.

This is Part 52 of the AWS Cloud Practitioner Study Notes. The easiest comparison is:

CloudWatch → Is my workload performing well?
CloudTrail  → Who called an AWS API?
AWS Config  → Is my resource configured correctly?

AWS Config is the configuration auditor and compliance engine for AWS resources. It is not primarily a CPU, memory, log, or application-latency monitoring service.

What AWS Config records

AWS Config creates configuration items for resource types in scope. Depending on the resource and recording configuration, an item can describe attributes such as:

• Resource type and identifier
• Relationships to other AWS resources
• Configuration state at a point in time
• Creation, update, or deletion information
• Previous and current configuration values
• Compliance evaluation results

Example questions AWS Config can help answer:

• Is this S3 bucket configured for public access?
• Are EBS volumes encrypted?
• Does every EC2 instance have the required tags?
• Was a security group changed from a corporate CIDR range to 0.0.0.0/0?
• Which resources are non-compliant with the organisation’s policy?

How AWS Config works

The main flow is:

AWS resource changes
        ↓
Configuration recorder
        ↓
Configuration items and history
        ↓
AWS Config rules evaluate resources
        ↓
COMPLIANT or NON_COMPLIANT
        ↓
EventBridge, notification, or remediation

AWS Config is Regional. Set up the configuration recorder and rules in each relevant Region, or use organisation-level features and aggregators when a central view is required.

Configuration recorder

The configuration recorder records configuration changes for the resource types you select. A customer-managed configuration recorder is controlled by you, including its resource scope and recording behavior. AWS also supports service-linked configuration recorders for specific AWS services.

Do not assume that AWS Config automatically records every supported resource in every Region. You must configure and enable the recorder, choose the resource types in scope, and provide the required IAM permissions.

Choose Region and resource types
        ↓
Configure recorder
        ↓
Start recording
        ↓
AWS Config captures configuration state

The recorder is the collection component. It does not by itself decide whether a resource follows your security or governance policy; Config rules perform that evaluation.

Delivery channel and configuration history

AWS Config uses a delivery channel to deliver configuration data and notifications. Configuration history files and snapshots can be delivered to an Amazon S3 bucket, and notifications can be sent through supported integrations such as Amazon SNS.

Configuration recorder
        ↓
Configuration item
        ↓
Delivery channel
        ├── Configuration history in S3
        ├── Snapshots
        └── Notifications and integrations

Configuration history provides a timeline of recorded resource states. A snapshot provides a point-in-time view of the resources and configurations being recorded.

Configuration timeline example

Imagine an EC2 instance:

Day 1  → instance type: t3.micro
Day 3  → instance type changed to t3.large
Day 5  → IAM role attached
Day 10 → security group association changed

AWS Config helps answer what the resource configuration was before and after the changes. If you need to identify the human or workload that called the API, use CloudTrail alongside the Config timeline.

Config rules

Config rules evaluate resources against a desired condition and produce a compliance result such as COMPLIANT, NON_COMPLIANT, or INSUFFICIENT_DATA.

Examples:

Rule: EBS volumes must be encrypted
Resource: unencrypted EBS volume
Result: NON_COMPLIANT

Rule: EC2 instances must have Environment tags
Resource: tag is missing
Result: NON_COMPLIANT

Rules can evaluate resources when configuration changes occur, periodically, or according to the rule’s evaluation behavior.

AWS Config managed rules

AWS provides managed rules for common governance and security requirements. Examples include rules that check:

• S3 public-access configuration
• Root-user MFA
• EBS encryption
• IAM password policy
• Required tags
• Security groups open to the world
• RDS encryption
• CloudTrail configuration

Managed rules require configuration rather than custom code, although parameters and supported resource types still need to be reviewed for the target Region.

Custom Config rules

Custom rules are useful when the organisation has a policy that is not covered by a managed rule. A custom rule can evaluate a resource against a company-specific requirement, such as:

• Only approved EC2 instance families may be used.
• Every production resource must have an owner and cost-center tag.
• A particular network configuration must exist.
• A resource must use an approved encryption key.

Custom rules can be written with AWS Lambda or created using the supported Config rule models. The evaluation code must return a compliance result based on the resource configuration.

Conformance packs

A conformance pack is a collection of AWS Config rules and remediation actions deployed as one package. It can represent a security baseline, operational standard, cost-governance policy, or a selected compliance framework.

Conformance pack
├── Rule: encrypted EBS volumes
├── Rule: required resource tags
├── Rule: restricted security groups
└── Remediation actions

Conformance packs use a YAML template and can be deployed in an account and Region or across an AWS organisation. They make it easier to apply a consistent set of controls rather than creating and managing every rule separately.

Sample conformance packs are starting points, not automatic proof of compliance with a specific legal or industry standard. Review the rules, parameters, resource coverage, and remediation behavior for your environment.

Remediation

AWS Config identifies non-compliance. Remediation is the corrective action that changes the resource or starts an operational response.

Remediation can integrate with Systems Manager Automation:

S3 bucket violates public-access rule
        ↓
AWS Config → NON_COMPLIANT
        ↓
Systems Manager Automation runbook
        ↓
Apply approved corrective action
        ↓
AWS Config evaluates again

Possible responses include:

• Automatically apply a safe configuration change
• Start an Automation runbook
• Notify a security or operations team
• Create a ticket for manual remediation
• Quarantine or replace a resource under an approved process

Automatic remediation should be designed carefully. A rule can identify a valid exception incorrectly, and an automated change can affect production availability. Use approvals, exclusions, change controls, and rollback plans for high-impact actions.

AWS Config and EventBridge

EventBridge can monitor AWS Config events and react to configuration or compliance state changes:

Resource becomes NON_COMPLIANT
        ↓
EventBridge rule
        ├── SNS notification
        ├── Lambda ticket integration
        ├── Systems Manager Automation
        └── Security workflow

EventBridge is useful for near-real-time reactions and central event routing. It does not replace the Config recorder or rules; it reacts to events generated by the Config workflow.

AWS Config and CloudTrail

AWS Config and CloudTrail answer different parts of a change investigation:

AWS Config	AWS CloudTrail
What changed in the resource configuration?	Who called the API?
Previous and current resource state	API operation, identity, time, and request context
Compliance state	User and workload activity audit
Resource relationships and history	Management and data-event audit where configured

Example:

Security group port 22 changes from corporate CIDR to 0.0.0.0/0

AWS Config
→ Shows the before-and-after configuration

CloudTrail
→ Shows who called AuthorizeSecurityGroupIngress and when

CloudTrail can also record API calls made to AWS Config itself. That is a separate use case from Config recording changes to other AWS resources.

AWS Config and CloudWatch

CloudWatch focuses on performance and operational telemetry. AWS Config focuses on configuration state and compliance.

AWS Config	CloudWatch
Configuration history	Metrics and logs
Compliance rules	Threshold alarms
Resource relationships	CPU, memory, latency, and request count
Configuration drift	Workload performance
“Is it configured correctly?”	“Is it performing normally?”

For example, CloudWatch can alert when EC2 CPU reaches 90%. AWS Config can report that the instance is missing the required Environment tag. Both services may be used for the same workload, but they observe different dimensions of health.

AWS Config and Systems Manager

The relationship can be remembered as:

AWS Config
→ Find configuration problems and compliance drift

Systems Manager
→ Manage, patch, automate, or remediate resources

Config rules can identify a non-compliant resource, while Systems Manager Automation can apply the approved fix. Systems Manager can also manage nodes independently through Session Manager, Run Command, Patch Manager, and other capabilities.

Supported resources and aggregators

AWS Config supports many AWS resource types, including EC2, VPC, security groups, IAM resources, S3, RDS, Lambda, EBS, CloudTrail, CloudFront, load balancers, and API Gateway. Support varies by resource type and Region.

For multi-account or multi-Region environments, AWS Config aggregators provide a central view of configuration and compliance data from multiple source accounts and Regions. An aggregator improves visibility; it does not remove the need to configure recording and rules in the source environments.

Production example: encrypted EBS policy

Company policy: every EBS volume must be encrypted.

Developer launches an unencrypted EBS volume
        ↓
AWS Config recorder captures the resource
        ↓
Encrypted-volume rule evaluates it
        ↓
NON_COMPLIANT
        ↓
EventBridge notification or Systems Manager remediation
        ↓
Security team investigates or approved automation responds

Depending on the policy, the response might be a notification, an approved encryption-and-replacement workflow, or a deployment-blocking control. AWS Config identifies the violation; the organisation decides how disruptive the correction may be.

Common exam questions

You need to know whether an S3 bucket is configured for public access.

Use an AWS Config rule that evaluates S3 access configuration.

You need to know who made the bucket public.

Use CloudTrail to identify the API call and principal.

You need to enforce that EBS volumes are encrypted.

Use AWS Config rules, often combined with notification or remediation.

You need automatic remediation for a non-compliant resource.

Use AWS Config with Systems Manager Automation or another approved remediation target.

You need to monitor EC2 CPU utilization.

Use CloudWatch, not AWS Config.

You need one package of related compliance controls.

Use a conformance pack.

You need a central compliance view across multiple accounts and Regions.

Use an AWS Config aggregator after configuring the source accounts and Regions.

Final memory trick

CloudWatch
→ How is it performing?
→ CPU, memory, logs, latency, metrics

CloudTrail
→ Who changed it?
→ API calls and audit history

AWS Config
→ Is it configured correctly?
→ Configuration history, rules, compliance

Systems Manager
→ How do I manage or fix it?
→ Session, patching, commands, automation

The one-sentence takeaway is: AWS Config records resource configuration, evaluates it against rules, reports compliance, and connects detection to notification or remediation workflows.

Sources

• AWS Config terminology and concepts
• How AWS Config works
• Monitoring AWS Config with EventBridge
• Setting up automatic remediation
• Logging AWS Config API calls with CloudTrail