AWS Config Rules, Conformance Packs, and Automated Compliance

AWS Config rules and conformance packs are the continuous-compliance machinery that turns "we follow PCI-DSS" from a slide deck into automatically-evaluated, automatically-remediated, audit-evidence-producing reality across an entire AWS Organization. On the DOP-C02 exam, AWS Config rules and conformance packs appear all over Domain 6 Tasks 6.2 and 6.3 whenever a scenario sets "ensure no S3 bucket is public," "auto-remediate any unencrypted EBS volume," "produce evidence for HIPAA across 50 accounts," or "non-compliant resource must trigger SNS alert and SSM Automation rollback." The right answer always combines Config rules (for detection), conformance packs (for grouping rules into compliance frameworks), Config aggregator (for multi-account roll-up), and remediation actions (for self-healing) into a closed-loop system.

This Pro-depth guide walks through every AWS Config rules and conformance packs primitive you will encounter on DOP-C02: configuration recorder and delivery channel mechanics, AWS managed rules vs custom Lambda rules vs Guard rules, conformance pack YAML templates with parameters, organizational rules vs StackSet-based deployment, multi-account multi-region aggregator, automatic remediation via Systems Manager Automation runbooks, the relationship to Security Hub, periodic vs configuration-change triggers, the cost model, and the canonical Pro scenario — landing-zone-wide continuous compliance with auto-remediation and audit evidence — dissected step by step.

What Are AWS Config Rules and Conformance Packs?

AWS Config is a fully-managed service that continuously records the configuration of supported AWS resources and evaluates those configurations against rules. Config rules are evaluation logic — managed rules ship with AWS, custom rules run as Lambda functions or Guard policies. A conformance pack is a collection of Config rules and remediation actions packaged as a single deployable unit, typically representing a compliance framework (PCI-DSS, HIPAA, NIST 800-53, CIS, FedRAMP).

Why AWS Config Rules and Conformance Packs Matter for DOP-C02

DOP-C02 Tasks 6.2 and 6.3 explicitly demand "AWS Config rules" as required knowledge and "automating the application of security controls in multi-account and multi-Region environments." Config is also referenced in Task 5.2 ("Implement configuration changes in response to events"). Pro-tier scenarios involve 50-account organizations where compliance must be evaluated across the fleet and noncompliant resources must self-heal without human intervention.

The Five Components

Understanding AWS Config rules and conformance packs requires knowing five components: configuration recorder (records resource state), delivery channel (writes snapshots to S3 and notifications to SNS), rules (evaluation logic), remediation actions (SSM runbooks invoked on non-compliance), and aggregator (multi-account roll-up). On DOP-C02, scenarios often hide which component is failing — recorder not enabled in a region, delivery channel S3 policy missing, rule evaluating but no remediation attached, aggregator not authorised by member account.

Plain-Language Explanation: AWS Config Rules and Conformance Packs

AWS Config rules and conformance packs sound like another acronym mountain, but three everyday analogies make their structure immediate.

Analogy 1 — The Restaurant Health Inspection System (Inspection / Health Department Analogy)

Picture a city with 50 restaurant branches (your AWS accounts) all owned by one chain. AWS Config is the chain's headquarters health-inspection program, and conformance packs are the inspection checklists.

The continuous-monitoring CCTV in every branch's kitchen recording fridge temperature, hand-washing, and food-storage practices is the Config recorder — it does not judge, it just records every state change. The inspection checklist with rules like "fridge must be below 4°C," "raw meat must be on the bottom shelf," "staff must wash hands every 30 minutes" is a Config rule. The comprehensive food-safety framework bundling 47 individual rules into one branded program (e.g., "ServSafe Certified") that every branch must comply with is a conformance pack — Config ships ready-made packs for "PCI-DSS," "HIPAA," "NIST 800-53." The regional health authority rolling up inspection results across all 50 branches into one regulatory dashboard is the Config aggregator. The automatic corrective response — when the system detects fridge above 4°C it auto-dispatches a refrigeration technician — is a remediation action invoked via Systems Manager Automation. The annual audit evidence package delivered to the city health department is Config's S3 snapshot stream plus the conformance-pack compliance report. The chain headquarters never visits each branch; the inspection runs continuously, automatically, with self-healing for known violations.

Analogy 2 — The Aircraft Pre-Flight and In-Flight Monitoring System (Aviation Analogy)

Imagine an airline operating 50 aircraft (your AWS accounts) where every flight must comply with regulations and self-correct deviations.

The black box flight data recorder capturing every parameter — altitude, fuel pressure, control surface positions — every second is Config's recorder, capturing every configuration change to every resource. The pre-flight checklist that the captain runs through before pushback ("doors closed, fuel sufficient, transponder set") corresponds to Config rules evaluated on configuration change — every new resource is "evaluated" before going live. The continuous in-flight monitoring alerting cockpit if cabin pressure drops or engine vibration exceeds threshold is Config's periodic-trigger rules running every 1, 3, 6, 12, or 24 hours. The regulatory framework bundle — FAA Part 121 operations specifications, EASA compliance, ICAO standards — bundling hundreds of individual checks into one certification is a conformance pack. The fleet operations centre monitoring all 50 aircraft on one screen, identifying any flight in non-compliance state, is the Config aggregator. The autopilot self-correction that adjusts trim when sensors detect deviation is a Config remediation action invoking an SSM Automation runbook. The maintenance log kept for 7 years for regulatory inspection is the Config snapshot stream in S3. Just like aviation, AWS Config rules and conformance packs make compliance continuous, fleet-wide, and self-healing.

Analogy 3 — The Car Manufacturing Assembly Line Quality Gates (Manufacturing Analogy)

Picture a car factory with 50 assembly lines (your AWS accounts) producing thousands of cars. AWS Config rules and conformance packs are the quality-gate system.

The station-level cameras and sensors on every assembly station recording every torque setting, paint thickness, weld parameter is the Config recorder for resource state. The inspection gate at the end of each station checking "torque within 35-40 Nm," "paint thickness 80-100 microns" against a master spec is a Config rule. The complete vehicle homologation framework — Euro NCAP 5-star, IIHS Top Safety Pick — bundling hundreds of individual quality criteria into one customer-facing certification is a conformance pack. The plant-wide MES dashboard showing real-time compliance across all 50 lines is the Config aggregator. The rework station where any car failing a gate is automatically routed for correction is a Config remediation action via SSM Automation. The production records retained for 15-year liability is Config's S3 snapshot retention. When a line drifts out of spec, the system catches it on the next car, not after 1,000 defects ship. AWS Config rules and conformance packs are the same idea applied to cloud configurations: every change is inspected, multi-criteria certifications are pre-packaged, and self-healing keeps the fleet compliant.

The Configuration Recorder — Foundation of Continuous Compliance

The Config recorder is the first thing to enable in every account, every region. Without it, no rule evaluates anything.

Recorder Mechanics

The configuration recorder is a per-region, per-account agent (managed by AWS, not installed by you) that captures the configuration of supported resources whenever they change. Each captured state is a Configuration Item (CI) — a JSON document with the resource's metadata, configuration, relationships, and state. The recorder writes CIs to the delivery channel and emits change events to EventBridge.

Resource Type Coverage

The recorder can record all supported resource types or a specific subset. Pro-tier compliance requires recording all resources — narrow recording leaves blind spots. AWS Config supports 200+ resource types covering most AWS services. Recently added services may take a few weeks to appear; check the supported-resources page.

Delivery Channel — S3 and SNS

The delivery channel writes configuration history files (every change for a 6-hour window) and configuration snapshots (point-in-time inventory) to an S3 bucket, plus configuration change notifications and compliance change notifications to an SNS topic. Convention: write to a Log Archive account bucket via cross-account bucket policy. The bucket must allow config.amazonaws.com to PutObject with the appropriate key prefix.

Configuration History vs Configuration Snapshot

History is the stream of every change as it happens. Snapshot is a periodic full inventory (default daily). For audit evidence, both are useful — history shows what changed and when, snapshot proves the state of the world at a known checkpoint. Both land in S3 as JSON.

Recorder Cost Model

Config charges per Configuration Item recorded ($0.003 per CI in most regions) plus per rule evaluation ($0.001 per evaluation). High-churn environments (CI/CD pipelines spinning EC2 fleets up and down) can produce thousands of CIs per hour. Cost control: limit recording to compliance-relevant resource types or use the "Continuous Recording with Daily Recording" mode (newer feature) for low-volume resources.

AWS Config Rules — Managed, Custom Lambda, and Guard

Rules are the evaluation logic that produces compliance findings.

AWS Managed Rules

AWS ships 200+ managed rules covering common compliance checks. Examples DOP-C02 frequently references:

• s3-bucket-public-read-prohibited — fails if any S3 bucket allows public read.
• ec2-instance-no-public-ip — fails if EC2 instance has a public IP outside the allow list.
• iam-password-policy — checks password policy meets complexity requirements.
• encrypted-volumes — fails if EBS volumes are unencrypted.
• rds-storage-encrypted — fails if RDS storage is unencrypted.
• cloudtrail-enabled — fails if CloudTrail is not enabled.
• restricted-ssh — fails if any security group allows 0.0.0.0/0 on port 22.
• root-account-mfa-enabled — fails if root user lacks MFA.

Managed rules are zero-code; just enable and parameterize.

Custom Lambda Rules

When managed rules do not cover the check, write a Lambda function that receives a ConfigurationItem event, performs evaluation logic, and reports COMPLIANT / NON_COMPLIANT / NOT_APPLICABLE via the Config API. Common use cases: tag-policy enforcement (every resource must have costCenter tag), naming-convention enforcement, custom encryption-key requirements (must use specific KMS CMK).

Custom Guard Rules

AWS CloudFormation Guard is a policy-as-code language for evaluating JSON/YAML against rules. Config supports Guard rules as a no-Lambda alternative — author the rule in Guard syntax, deploy as a Config rule, no Lambda function to maintain. Cheaper and simpler than Lambda rules for declarative checks.

Trigger Type — Configuration Changes vs Periodic

Rules trigger either:

• Configuration changes: evaluates the resource immediately when its CI changes. Best for "any new resource must comply" scenarios. Sub-minute latency.
• Periodic: evaluates all in-scope resources every 1, 3, 6, 12, or 24 hours. Best for cross-resource checks (e.g., does any IAM user have unused access keys? — needs to scan all users together).

Rule Scope and Parameters

Rules can be scoped to specific resource types, tags, or resource IDs. Parameters customize the check (e.g., s3-bucket-public-read-prohibited has no parameters; iam-password-policy parameters set MinimumPasswordLength, RequireSymbols, MaxPasswordAge). Same rule, different parameter sets — different conformance pack flavours.

Conformance Packs — Compliance Frameworks as Code

Conformance packs bundle rules + remediation actions + parameters into a single deployable unit.

Conformance Pack Structure

A conformance pack is a YAML CloudFormation-syntax template containing:

• A list of AWS::Config::ConfigRule resources
• Optional AWS::Config::RemediationConfiguration resources
• Optional Parameters for tuning per environment
• Optional InputParameters for individual rules

Deploy as a single API call (PutConformancePack); all rules and remediations apply atomically.

AWS Sample Conformance Packs

AWS publishes ready-made conformance packs mapping to popular frameworks: PCI-DSS, HIPAA, NIST 800-53 Rev 5, CIS AWS Foundations Benchmark, FedRAMP Moderate/High, AWS Foundational Security Best Practices, ISO 27001, ENISA, ACSC Essential Eight, K-ISMS, MAS, BNM, RBI, and more. Browse and clone from the conformance-packs GitHub repo.

Custom Conformance Packs

Author your own pack by combining managed rules and custom rules into a YAML template. Common pattern: clone the AWS PCI-DSS pack, add 5-10 organization-specific tag/encryption rules, deploy as the company's "Acme Production Baseline" pack.

Conformance Pack Compliance Score

Each pack reports an overall compliance score (percentage of rules and resources compliant). The pack-level dashboard in the Config console shows pass/fail per rule and per resource. Stakeholders read pack-level scores; auditors read per-resource evidence.

Multi-Account Deployment — Organizational Rules and Conformance Packs

Pro-tier compliance requires fleet-wide deployment. AWS Config offers two paths.

Organizational Config Rules

Use PutOrganizationConfigRule from the Organizations management account or Config delegated admin to deploy a rule to every member account in every Organization-included region. The rule is automatically deployed to new accounts as they join. Limit: the management account does not evaluate organizational rules — only member accounts. This requires the central account itself to use a separate, identical rule deployed normally.

Organizational Conformance Packs

PutOrganizationConformancePack deploys an entire pack to all member accounts. Same auto-onboarding for new accounts. Same management-account-exempt limitation.

CloudFormation StackSets Alternative

Before organizational rules existed, the only way was CloudFormation StackSets — author a stack with AWS::Config::ConfigRule resources, deploy via StackSet to the OU. StackSets are still useful for hybrid deployments (rules + non-Config resources in one stack) but pure Config rules are simpler with organizational rules.

Delegated Admin

Designate a member account (typically the Audit/Security account) as Config delegated admin. The delegated admin can manage organizational rules and conformance packs without using the management account. The management account is exempt from SCPs and best kept minimal — DOP-C02 best practice is operating Config from the delegated admin.

Multi-Account Aggregator — Single-Pane Compliance View

The Config aggregator collects data from multiple accounts and regions into one account for unified querying.

Aggregator Setup

Create an aggregator in the Audit/Security account. Authorize the aggregator from each member account (one-time per account/region) or use Organizations-based authorization (auto-authorizes every member). Aggregator pulls compliance findings, configuration items, and resource inventories from all sources.

What Aggregator Does NOT Do

Aggregator does not enforce rules — it only aggregates findings from rules already deployed elsewhere. To deploy rules, use organizational rules or StackSets. Aggregator is read-only roll-up.

Advanced Queries Across Accounts

Config Advanced Queries (SQL-syntax) run against aggregated data: "list every EC2 instance across all accounts where KeyName is null," "list every S3 bucket without versioning," "list every RDS instance without encryption." Replaces ad-hoc per-account audits.

Aggregator vs CloudTrail Lake

Aggregator answers "what configuration state exists right now?" CloudTrail Lake answers "what API actions happened across history?" Both are queryable, multi-account, multi-region. Aggregator is for state; CloudTrail Lake is for events. Use both.

Auto-Remediation — Closing the Loop with SSM Automation

Detection without remediation is a half-built system. DOP-C02 expects you to close the loop.

Remediation Mechanics

Attach a remediation configuration to a Config rule. When the rule reports NON_COMPLIANT for a resource, Config invokes a Systems Manager Automation runbook with the resource ID as parameter. The runbook performs the corrective action — disable public S3 access, enable EBS encryption (where possible), terminate non-compliant EC2, attach a missing tag, restart a service.

Automatic vs Manual Remediation

Remediation can be automatic (Config invokes immediately on non-compliance) or manual (compliance team reviews, clicks "remediate" in console). Automatic is the goal for low-risk fixes (enable encryption, add tag); manual is wiser for high-impact (terminate instance, change security group on production VPC).

SSM Automation Runbooks

AWS publishes 200+ runbooks for common remediations. Examples:

• AWS-DisableS3BucketPublicReadWrite — removes public ACLs from a bucket.
• AWS-EnableS3BucketEncryption — applies default encryption.
• AWS-EnableCloudTrail — re-enables disabled trails.
• AWSConfigRemediation-RemoveUnrestrictedSourceIngressRules — strips 0.0.0.0/0 ingress from security groups.

Custom runbooks are JSON/YAML documents with steps invoking AWS APIs, Lambda, scripts. Author per organization-specific remediation logic.

Retry and Failure Behaviour

Remediation has a configurable retry count (default 5) and rate limit (operations per minute). Failed remediations stay non-compliant; a retry can be triggered by re-evaluating the rule. Always deliver remediation invocations to CloudWatch Logs for audit.

Config Rules and Security Hub — Avoid Double Coverage

Security Hub also maintains compliance standards. Understand the relationship.

Security Hub Standards Use Config Rules

Security Hub's standards (AWS Foundational Security Best Practices, CIS, PCI-DSS, NIST) deploy underlying Config rules in each enabled account. When you enable a Security Hub standard, Config rules appear in the account automatically. Security Hub aggregates findings from those rules into the cross-account dashboard.

When to Use Each

• Security Hub standards: easiest path for popular frameworks. One-click enable, automatic rule deployment, automatic finding aggregation.
• Config conformance packs: more flexibility (custom packs, custom rules, custom remediation). Use when Security Hub standards do not match the desired baseline or when remediation actions are needed.

Both can coexist; just avoid duplicate rule deployment (which doubles Config evaluation cost). DOP-C02 questions sometimes test knowing both paths exist; the right answer depends on the scenario's emphasis (one-click compliance vs custom remediation).

Cost Control for AWS Config Rules and Conformance Packs

Config can become expensive in high-churn environments. DOP-C02 expects awareness.

Cost Drivers

• Configuration items recorded ($0.003 per CI typical)
• Active rule evaluations ($0.001 per evaluation typical)
• Conformance pack evaluations (same per-evaluation rate)
• S3 storage of configuration history and snapshots
• Lambda invocations for custom rules

A 50-account org recording all resource types with 200 active rules can produce $5K-$20K monthly Config spend.

Cost Reduction Patterns

• Limit recording to compliance-relevant resource types where possible.
• Disable Config in regions you do not use.
• Use periodic-trigger rules for bulk checks instead of change-trigger rules where sub-minute detection is unnecessary.
• Use Guard rules instead of Lambda rules to eliminate Lambda invocation cost.
• Aggregate findings to one Audit account; do not run conformance packs in every account if Security Hub aggregation suffices.

Configuration History and Drift Detection — Beyond Compliance

Config doubles as drift detection and forensics.

Drift From CloudFormation Stacks

CloudFormation drift detection compares stack template against actual resource state and flags differences. Config recorder is the underlying source of truth. Combining stack drift detection with Config rules catches both "this resource was created outside CFN" and "this CFN-managed resource was modified outside CFN."

Forensic Time-Travel

Config's resource timeline shows every state of a resource and every relationship change. When investigating "who changed this security group's ingress rule on Tuesday?," Config + CloudTrail tell the full story — Config shows what changed, CloudTrail shows who changed it.

Resource Relationships

Config tracks relationships (this EC2 instance uses this security group, this VPC, this IAM role). Useful for impact analysis ("if I delete this IAM role, which Lambda functions break?"). Config Advanced Queries can traverse relationships.

常考陷阱 (Common Exam Traps)

DOP-C02 has predictable AWS Config rules and conformance packs gotchas:

1. Forgetting the recorder must be enabled per region — rules in regions without recorder simply do not evaluate. Onboarding a new region requires recorder + delivery channel + rule deployment.
2. Management account exempt from organizational rules — rules deployed via PutOrganizationConfigRule apply only to member accounts. Management account compliance requires a separate normal rule deployed in management.
3. Confusing aggregator with rule deployment — aggregator only collects findings from rules already deployed; it does not deploy rules. Use organizational rules or StackSets to deploy.
4. Auto-remediation breaking production — automatic remediation on a destructive runbook (e.g., terminate non-compliant EC2) will trigger fleet-wide on rule deploy. Pilot first, gate via EventBridge if needed.
5. Custom Lambda rule when managed rule exists — operational waste. Always check the managed-rules list first.
6. Periodic trigger when configuration-change is needed — periodic rules evaluate every 1-24 hours; new non-compliant resources can exist for hours. Use change-trigger for "every new resource must comply on creation" requirements.
7. Conformance pack vs Security Hub standard duplication — enabling both for the same framework deploys two copies of every rule, doubling Config evaluation cost. Pick one path per framework.
8. Delivery channel S3 bucket missing Config service principal permissions — recorder cannot write, history disappears. The bucket policy must allow config.amazonaws.com PutObject.
9. CI cost explosion in CI/CD environments — high-churn EC2 fleets create CIs constantly. Limit recorded resource types or use Daily Recording mode.
10. Forgetting parameters on parameterised rules — iam-password-policy evaluates against default parameters unless overridden. Conformance packs supply parameters per framework requirement.

FAQ

Q1: When should I use a Config rule vs a Security Hub control? Both produce compliance findings. Security Hub controls are easier for popular frameworks (one-click enable). Config rules and conformance packs allow custom packs, custom rules, and remediation actions. For PCI-DSS / HIPAA / CIS where AWS publishes standards in both places, pick one to avoid duplicate evaluation cost. For organization-specific baselines, conformance packs are the path.

Q2: How do I deploy a conformance pack to all 50 accounts in my Organization? Designate a Config delegated admin (typically the Audit account) via register-delegated-administrator. From the delegated admin, call PutOrganizationConformancePack with the pack template. AWS deploys to every member account in every included region and auto-deploys to new accounts. The management account is exempt and needs a separate deployment if it should be evaluated.

Q3: What's the difference between a custom Lambda rule and a Guard rule? Lambda rules execute custom code in your AWS Lambda function — pay per invocation, maintain runtime, manage IAM. Guard rules are written in CloudFormation Guard policy-as-code syntax — declarative, no Lambda, AWS executes the evaluation. Guard is preferred for declarative checks; Lambda is needed for stateful logic (consulting an external API, complex multi-resource correlation).

Q4: How do I auto-remediate a non-compliant S3 bucket? Attach a remediation configuration to the relevant rule (e.g., s3-bucket-public-read-prohibited) referencing a Systems Manager Automation runbook (e.g., AWS-DisableS3BucketPublicReadWrite). Set automatic execution. When the rule reports non-compliance, Config invokes the runbook with the bucket as parameter, and the runbook removes public access. CloudTrail records the remediation action.

Q5: Can I write Config rules that reference data from outside AWS? Yes, via custom Lambda rules. The Lambda can call out to external APIs (e.g., a CMDB) to determine compliance. This is operationally heavier than self-contained rules; common use is comparing resource tags against an external source-of-truth.

Q6: How does Config aggregator differ from Security Hub aggregation? Config aggregator collects Config-specific data (configuration items, rule evaluations, advanced queries). Security Hub aggregates findings (Config findings, GuardDuty, Inspector, Macie, Access Analyzer, third-party). For unified compliance posture, aggregate Security Hub. For deep configuration query (SQL across all resources), use Config aggregator. Most organizations enable both.

Q7: What's the cost difference between change-triggered and periodic rules? Both cost the same per evaluation. Difference is volume: change-triggered fires once per CI per resource, periodic fires every N hours for every in-scope resource. In high-churn accounts, change-triggered is cheaper; in stable accounts, periodic is cheaper. Match trigger type to the use case rather than to cost.

Q8: How do I exclude specific resources from a rule? Either set the rule's scope to specific tag/resource ID inclusion, or write the rule logic to return NOT_APPLICABLE for excluded resources. For managed rules without exclusion parameters, custom Lambda is the workaround. For conformance pack rules, override via pack parameters where supported.

Q9: Can Config detect drift on CloudFormation stacks? Indirectly. CloudFormation has its own DetectStackDrift API that uses Config-recorded state under the hood. Config rule cloudformation-stack-drift-detection-check reports stacks in DRIFTED state. Combine with EventBridge to alert on drift detection.

Q10: How do I handle Config in a sandbox/non-production account where compliance rules would be too noisy? Skip Config altogether in pure-sandbox accounts (cost saving, low security risk). For accounts that should run rules but with relaxed enforcement, deploy a custom conformance pack with relaxed parameters (e.g., longer password rotation, broader allowed IP ranges) instead of the production pack. Tag the OU and use Filter on PutOrganizationConfigRule to scope to specific OUs.

Summary — AWS Config Rules and Conformance Packs Mental Model

AWS Config rules and conformance packs turn compliance from a periodic audit into a continuous, automated, self-healing system. On DOP-C02 Tasks 6.2 and 6.3, the right answer always combines: configuration recorder enabled in every account every region, organizational conformance packs deployed from the delegated Audit account, automatic remediation via SSM Automation for low-risk fixes, manual remediation for high-impact actions, multi-account aggregator for unified queries, and Security Hub for finding-level dashboards. Every Pro-tier compliance scenario blends three or more of these.

The mature DOP-C02 answer pattern is layered detection: managed rules cover 80% of common checks, custom Guard or Lambda rules cover organization-specific policies, conformance packs bundle them into framework-aligned releases, organizational deployment ensures fleet-wide coverage, aggregator delivers a single pane of glass, and SSM Automation closes the loop with self-healing. Single-rule answers are distractors at Pro tier.