Assuming you already know Config records resources and runs rules — here’s the model that matters once you’re operating it in production.

A Configuration Item (CI) is not a live snapshot — it’s an event record

Every time a tracked resource changes, Config’s recorder generates a Configuration Item: a point-in-time JSON representation of that resource’s attributes, relationships, and metadata, immutable once written. CIs are not deleted or overwritten — they accumulate into a full configuration history per resource, which is what powers the “configuration timeline” view. This is the architectural reason Config can answer “what did this security group look like three weeks ago” when CloudTrail alone can only tell you “someone called AuthorizeSecurityGroupIngress” without the resulting state.

Rules evaluate CIs, not live resources

A common misconception among engineers moving from ad-hoc scripts to Config is assuming rules query the live AWS API at evaluation time. They don’t — both managed and custom Config rules evaluate against the CI stream (for change-triggered rules) or against periodic snapshots (for periodic rules). A rule’s Lambda function receives the CI payload as its input event; it never calls DescribeSecurityGroups itself for the resource under evaluation. This matters because a resource can drift and revert within a single scheduling window in ways periodic rules may never observe, while change-triggered rules catch it because they fire per CI, not per clock tick.

Recorder scope, not rule scope, decides what’s even visible

Advanced teams learn to separate two independent configuration surfaces: the recorder decides which resource types generate CIs at all (configurable to “all supported types,” a specific list, or all-with-exclusions), while individual rules decide which of those recorded resource types they evaluate. A rule referencing a resource type the recorder isn’t tracking will simply never fire — silently, with no error — which is one of the most common “why isn’t this rule working” debugging dead ends in Config.

What happens between “someone modifies a security group” and “a rule marks it NON_COMPLIANT in your dashboard.”

The configuration recorder subscribes to change notifications for every resource type in its scope. When a supported resource changes, the recorder builds a new CI capturing the resource’s current configuration, tags, and relationships to other tracked resources (for example, an EC2 instance’s CI includes references to its attached security groups and subnet). This CI is written to the delivery channel, which persists it to an S3 bucket you designate and, if configured, publishes an SNS notification.

Separately, Config maintains a rule-evaluation queue. Change-triggered rules subscribe to CI delivery events for the resource types they care about; when a matching CI arrives, Config invokes the rule’s Lambda function (for custom rules) or its managed-rule equivalent, passing the CI as the evaluation event. The rule function returns a compliance verdict — COMPLIANT, NON_COMPLIANT, NOT_APPLICABLE, or INSUFFICIENT_DATA — which Config records against that resource and rule pair. Periodic rules instead run on a fixed schedule (as often as every 24 hours) regardless of change activity, evaluating the latest known CI at that time.

graph LR
    R[Tracked Resource Changes] --> REC[Configuration Recorder]
    REC --> CI[Configuration Item Generated]
    CI --> S3[(Delivery Channel - S3 Bucket)]
    CI --> SNS[SNS Notification]
    CI --> QUEUE[Rule Evaluation Trigger]
    QUEUE --> LAMBDA[Custom Rule Lambda / Managed Rule Logic]
    LAMBDA --> VERDICT[Compliance Verdict]
    VERDICT --> STORE[(Config Compliance Store)]
    STORE --> REMED[SSM Automation Remediation]
    STORE --> AGG[Aggregator]
        

A resource’s compliance history in Config isn’t a single value — it’s a timeline of verdicts, each tied to the CI that triggered it. Understanding this timeline model is essential for anyone building dashboards or audit reports on top of Config data.

Aggregators do not generate their own CIs or run their own evaluations — they pull already-computed compliance and configuration data from source accounts on a scheduled basis. This means an aggregator view can lag the source account’s true state by minutes, which matters when building near-real-time alerting on top of aggregated data versus per-account EventBridge triggers.

At organization scale, Config’s cost and performance profile is driven almost entirely by two variables: the number of configuration items recorded, and the number of rule evaluations run against them. Both scale with resource count and change frequency, not with account count directly — ten accounts with high resource churn can generate far more CIs than a hundred quiet accounts.

A frequent scaling mistake is recording “all supported resource types” by default across every account without considering churn-heavy resource types like Auto Scaling-managed EC2 instances or Lambda function versions, which can dominate CI volume without adding proportional compliance value. Mature deployments scope the recorder deliberately — often excluding high-churn, low-compliance-relevance resource types — while still capturing everything security- and cost-relevant.

Uber’s infrastructure engineering team, describing large-scale configuration governance in public talks, has highlighted the same generalizable lesson that applies directly to Config: at high resource counts, the practical bottleneck shifts from “can the evaluation engine keep up” to “can your remediation and alerting pipeline downstream keep up with the resulting verdict volume” — which is why scoping the recorder and batching remediation logic matters more than any single API quota.

Config is a Regional, managed service with standard multi-AZ resilience for its control plane — you don’t manage recorder or evaluation-engine redundancy directly. The reliability considerations that require actual design decisions sit at the delivery-channel and aggregator layers.

The delivery channel’s S3 bucket is a single point of dependency for historical CI storage: if that bucket’s lifecycle policy deletes objects prematurely, or cross-account bucket permissions break silently, you lose historical configuration data even though the recorder continues operating normally going forward — Config does not retroactively repair or re-deliver missing history. Similarly, if an aggregator’s source-account authorization is revoked (for example, during an account offboarding that isn’t fully cleaned up), that account’s data silently stops appearing in the aggregated view without an obvious error surfaced to the aggregator owner.

Because Config’s CI history can include sensitive metadata about your infrastructure’s exact configuration — security group rules, IAM policy documents attached to roles, KMS key policies — the delivery-channel S3 bucket and the aggregator account both become high-value targets in their own right, deserving the same access-control rigor as the workloads they’re monitoring.

A frequently under-scoped permission is config:PutRemediationConfigurations combined with broad ssm:StartAutomationExecution rights — together, these let a principal define what “auto-fix” means for any non-compliant resource across the account, which is effectively a general-purpose remediation execution capability if the underlying SSM Automation document itself has broad permissions. Scoping the automation role’s own IAM permissions to only the specific actions each remediation document needs (rather than broad service-level access) limits the blast radius if the remediation configuration itself is ever manipulated by a compromised principal.

Config’s own control-plane calls — stopping the recorder, deleting a delivery channel, removing rules — are logged to CloudTrail, and monitoring for config:StopConfigurationRecorder or config:DeleteDeliveryChannel specifically is a well-known detection pattern, since disabling Config is a known technique used to blind an environment before making unauthorized changes.

For compliance-state observability, SNS notifications from the delivery channel (configuration item deliveries) and a separate optional notification stream for compliance-state changes are the standard integration points for near-real-time alerting, typically consumed by a Lambda function that fans out into a SIEM or ticketing system. Config also natively integrates with Security Hub — compliance findings can be forwarded automatically, letting teams standardize on Security Hub’s EventBridge pipeline rather than building a second bespoke Config-specific alerting path.

The production deployment pattern for Config across an organization mirrors other AWS governance services: designate a delegated administrator account (often the same security-tooling account used for Security Hub and GuardDuty), enable an organization-wide aggregator there, and deploy conformance packs and recorder configuration consistently to every member account via AWS CloudFormation StackSets rather than manual per-account setup.

graph TD
    subgraph Org["AWS Organization"]
        MEM1[Member Account 1 - Recorder + Rules]
        MEM2[Member Account 2 - Recorder + Rules]
        MEM3[Member Account N - Recorder + Rules]
    end
    MEM1 -->|compliance data pulled| AGG[Delegated Admin - Org Aggregator]
    MEM2 -->|compliance data pulled| AGG
    MEM3 -->|compliance data pulled| AGG
    AGG --> DASH[Aggregated Compliance Dashboard]
    AGG --> SECHUB[AWS Security Hub Forwarding]
    STACKSETS[CloudFormation StackSets] -->|deploys conformance packs| MEM1
    STACKSETS -->|deploys conformance packs| MEM2
    STACKSETS -->|deploys conformance packs| MEM3
        

AWS Control Tower provisions much of this scaffolding automatically for accounts vended through its Account Factory, including a baseline set of mandatory and strongly recommended Config rules. Teams building beyond Control Tower’s defaults typically layer their own conformance packs for industry-specific baselines (PCI DSS, HIPAA-aligned controls) on top of that foundation rather than replacing it.

Financial services firms operating under PCI DSS commonly point to Config’s historical CI timeline as the mechanism that turns “prove this control was in place for the entire audit period” from a manual evidence-gathering exercise into a queryable API call — auditors can be shown the exact compliance status of a resource on any past date, not just its current state.

Capital One has publicly discussed using AWS Config as a foundational piece of their cloud governance model, layering custom rules and conformance packs on top of Config’s managed rule library to encode organization-specific security baselines beyond AWS’s defaults — a pattern that generalizes to any regulated enterprise needing baselines stricter than the generic AWS Foundational Security Best Practices standard.

Large SaaS companies running Control Tower-vended multi-account environments typically extend the Control Tower default rule set with their own conformance packs targeting product-specific risks (for example, custom rules ensuring specific encryption settings on data stores unique to their architecture), illustrating how Config’s managed-rule library is treated as a floor, not a ceiling, in mature environments.