Lesson 209 · AWS Learning Path

AWS 209: AWS Config and compliance rules

Anil Jalela · Published Jan 20, 2026 · 7 min read

Why this lesson matters

AWS Config answers “what configuration did this supported resource have, how was it related, and did that state satisfy this rule?” It does not record application transactions and does not automatically prevent a change. Reliable compliance evidence requires a healthy recorder, intentional resource scope, understood evaluation mode, delivery, aggregation and a remediation path that cannot damage unknown resources.

What you will be able to do

By the end, you can:

• distinguish configuration recorder, configuration item, delivery channel, rule, conformance pack and aggregator;
• identify recording scope, strategy, service-linked recorder and excluded resource boundaries;
• read resource configuration, relationships, capture time and status chronologically;
• compare change-triggered, periodic and hybrid rule triggers;
• distinguish detective evaluation from proactive pre-deployment evaluation and enforcement;
• trace noncompliance through evaluation, approved remediation and changed retest;
• explain multi-account/Region aggregation without assuming telemetry is recorded centrally.

Before you start

• Use a personal AWS account only when its owner has approved the lesson. Do not use the root user for daily work.
• CloudShell is the default command environment. AWS028 explains CloudShell; AWS029 and AWS030 explain local AWS CLI installation and profiles.
• The course example Region is ap-south-1. Global services and services with a required control Region are called out in their commands.
• Run aws sts get-caller-identity privately. Redact the account number before sharing evidence.
• Never paste access keys, passwords, secret values, private object data, presigned URLs, or full account-specific ARNs into a submission.
• This is a no-create lesson. Every Console action and AWS CLI command is read-only. Create the practical artifact locally.
• Console wording can change. Use the Console service search if a menu label has moved, then confirm the current field in the official documentation.

The core model

How the request flows

+-----------------------------+
|  Supported resource change  |
+-----------------------------+
              |
              v
+-----------------------------------+
|  Configuration recorder and item  |
+-----------------------------------+
                 |
                 v
+----------------------+
|   Rule evaluation    |
+----------------------+
           |
           v
+-------------------------------------------------+
|  History, compliance, and remediation evidence  |
+-------------------------------------------------+

Recorder-to-remediation model, deeply

The configuration recorder discovers supported resources in its Region and produces configuration items (CIs) containing resource identity, capture time, configuration, tags, relationships and status. Recording can target supported resource types according to its strategy; exclusions and global-resource behavior must be reviewed explicitly. A delivery channel sends snapshots/history/notifications to configured destinations. Recorder existence is not recorder health: inspect status and last errors.

A Config rule expresses desired configuration. AWS managed rules implement published logic; custom policy/Lambda rules carry code and runtime ownership; service-linked or organization rules have separate owners. Trigger type determines when detective evaluation runs: configuration change, periodic schedule or both. Results are COMPLIANT, NON_COMPLIANT, NOT_APPLICABLE or insufficient/no-result states depending on context; compliance is evidence at an evaluation time, not proof that a resource can serve traffic safely.

Detective mode evaluates deployed resources. Proactive mode evaluates supplied resource properties before deployment for rules/resource types that support it. Proactive NON_COMPLIANT does not itself remediate or block deployment; enforcement requires a pipeline/admission/control layer to act on the result. A rule can support one or both modes.

A conformance pack bundles rules and optional remediation configuration as a deployable compliance unit. An aggregator provides cross-account/Region views of configuration/compliance data authorized from source accounts; it does not replace source recorders or retroactively create missing history. Automatic remediation commonly invokes a Systems Manager Automation document with an IAM role. Guard it with exact resource type/tag/ownership, concurrency/error limits, approval for risky changes and a post-remediation evaluation.

Use CloudTrail to answer who changed it; Config to answer what state/relationship changed and whether it complied; CloudFormation drift to compare stack actual state with template desired state. These sources complement rather than replace one another.

Architecture decision table

AWS Management Console, step by step

Sign in with the normal non-root learning identity. Write the expected starting state before opening the service.

1. Open AWS Config > Settings in the correct Region. Record recorder name/type, role, recording frequency/strategy, included/excluded types and delivery destination.
2. Check recorder and delivery status, last successful recording/delivery and error fields. Stop if evidence has a collection gap.
3. Open Resources, select the supplied security group and inspect its timeline. Compare two CIs: capture time, configuration diff, tags and relationships.
4. Open the associated rule. Record owner/source, scope, parameters, trigger and evaluation mode; open the exact evaluation timestamp and annotation.
5. Inspect remediation configuration without executing it: automatic/manual setting, SSM document, role, parameters, retries, concurrency/error controls and ownership check.
6. If an aggregator exists, switch source account and Region and prove authorization/collection time. Do not treat aggregator absence as source noncompliance.

CloudShell and AWS CLI, step by step

Start with a known caller and Region:

export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws configure list

Redact the account part of the ARN in shared evidence. Now run the topic queries:

aws configservice describe-configuration-recorders --output json
aws configservice describe-delivery-channels --output json
aws configservice describe-config-rules --query 'ConfigRules[].{Name:ConfigRuleName,State:ConfigRuleState,Source:Source.Owner}' --output table
aws configservice get-compliance-summary-by-resource-type --output table
aws configservice describe-configuration-recorder-status --output json
aws configservice describe-config-rule-evaluation-status --output json
aws configservice get-resource-config-history --resource-type AWS::EC2::SecurityGroup \
  --resource-id replace-with-approved-security-group-id --limit 10 --output json

Expected interpretation

Definitions show intent; recorder/evaluation status shows whether collection and rule execution are current; resource history supplies actual CIs. A compliance summary can be stale, aggregated or omit unrecorded/unsupported resources. Always record source account, Region, recorder coverage, capture/evaluation time and rule parameters before interpreting the status.

Practical work

Trace a security group from one configuration item to a later noncompliant rule evaluation. Record relationships, capture time, rule scope, evaluation result, remediation owner, and limitation.

Diagnose this topic from its own evidence

Positive test: a supplied SG CI matches the rule scope and evaluates as predicted. Negative test: an out-of-scope resource is NOT_APPLICABLE or absent for the documented reason. Dependency-failure test: recorder/delivery loses permission; distinguish collection failure from actual resource compliance.

Cost and cleanup

Configuration items, rule evaluations, conformance packs, aggregators, remediation dependencies, and delivery storage can charge.

Knowledge check

1. What operational purpose is this lesson solving?

Expected direction: Record supported resource configuration history, relationships, rules, conformance, remediation, aggregators, and delivery without calling it a general log service.

1. Which scope or ownership boundary must be proved first?

Expected direction: For AWS Config, separate account and Region scope, identity, configuration, data or network behavior, failure ownership, evidence retention, and cleanup.

1. What evidence is strong enough to accept the result?

Expected direction: Success requires matching Console, command-line, behavior, monitoring, and owner evidence for AWS Config. One green status is not enough.

1. Which tempting design or shortcut must be rejected?

Expected direction: Avoid assuming Config records application data, every service resource, or historical state from before the recorder was enabled.

1. Which cost dimensions and retained resources need an owner?

Expected direction: Configuration items, rule evaluations, conformance packs, aggregators, remediation dependencies, and delivery storage can charge.

Lesson acceptance

• Recorder scope/status, delivery channel and a configuration history are proved for one account/Region.
• Two CIs show an exact property/relationship change with capture times.
• Rule owner, parameters, scope, trigger and detective/proactive modes are correctly interpreted.
• Positive, out-of-scope and recorder-dependency cases have expected and observed results.
• Remediation design includes ownership guard, least-privilege role, bounded concurrency/errors, rollback and changed reevaluation.

Official sources

• AWS Config
• Configuration items
• AWS Config rule components and evaluation modes
• Proactive evaluation boundaries