AWS Config Explained: Resource Inventory, Compliance Rules, and Configuration Tracking

AWS Config gives you a searchable inventory of AWS resources, records how their configurations change, and evaluates them against compliance rules. If you run more than a handful of AWS accounts, this is not optional hygiene. It is one of the main ways you prove what existed, how it was configured, and when it drifted from policy.

AWS describes Config as a fully managed service for resource inventory, configuration history, and continuous compliance evaluation. In practice, security teams use it beside AWS CloudTrail, AWS Security Hub, Amazon GuardDuty, and centralized logging to answer hard audit and incident response questions without scraping every account by hand.

What AWS Config does

AWS Config has three jobs that matter most:

• Resource inventory: Discover supported AWS resources across accounts and Regions, including current and deleted resources.
• Configuration tracking: Record point-in-time resource states as ConfigurationItems.
• Compliance evaluation: Use AWS Config rules to decide whether resources match your required baseline.

That sounds simple until you need to answer a question like, Who opened port 22 to 0.0.0.0/0 on that security group last Tuesday? Config shows the resource timeline. CloudTrail helps connect the change to the API call and principal. Together, they give you a defensible trail.

Resource inventory in AWS Config

The inventory feature discovers supported AWS resource types and makes them searchable through the AWS Management Console, AWS CLI, and AWS Config API. Common recorded resources include EC2 instances, VPC components, S3 buckets, IAM resources, RDS databases, Lambda functions, CloudFormation stacks, and EBS volumes. AWS maintains the supported resource type list in its Config documentation. Check it before you assume a newer service is covered.

What the inventory contains

For each supported resource, AWS Config can store details such as:

• Resource type and identifier
• Current configuration
• Relationships to other resources
• Tags and metadata
• Configuration change count
• Deleted resource history, where available

That last point is useful. A deleted EC2 instance or removed security group may still matter during an investigation. Config can preserve historical evidence after the resource has disappeared from the normal service console.

Advanced queries for inventory reporting

AWS Config advanced queries use a SQL-like syntax. You can query one account and Region, or use a configuration aggregator to query across AWS Organizations. A platform team can search for all EC2 instances by instance type, all unencrypted volumes, or all resources missing required tags.

A common query pattern is to filter by resource type, such as AWS::EC2::Instance. For compliance reporting, teams often query AWS::Config::ResourceCompliance, which stores compliance status history. This is much cleaner than running ad hoc scripts against every AWS account.

Inventory and compliance dashboards

In November 2023, AWS launched inventory and compliance dashboards for AWS Config aggregators. These dashboards give central teams prebuilt views across multiple accounts, Regions, and AWS Organizations. Examples include the top 10 accounts with noncompliant resources, compliance summaries by resource, EC2 instances by running or stopped state, and EBS volumes by type and size.

The practical detail I like: each widget is backed by an AWS Config advanced query that you can inspect and reuse. That makes the dashboard more than a pretty chart. Take the query, adjust it for your control, and turn it into a repeatable report.

AWS Config rules and compliance governance

AWS Config rules compare resource configurations against a desired state. The result is usually COMPLIANT, NON_COMPLIANT, NOT_APPLICABLE, or INSUFFICIENT_DATA, depending on the rule and resource.

A rule might check that:

• S3 buckets are not publicly readable
• EBS volumes are encrypted
• Security groups do not allow unrestricted inbound SSH
• CloudTrail is enabled
• EC2 instances use approved AMIs
• Required tags exist on resources

Managed rules versus custom rules

AWS provides managed rules for common controls. Start there. Custom Lambda-backed rules are useful, but they add code maintenance, IAM permissions, error handling, and deployment overhead. If a managed rule covers the policy, use it.

Recent managed rule improvements make this easier. AWS added options for checking whether EC2 instances use approved AMIs, either by explicit AMI IDs or tags. The required-tag managed rule can require up to 6 tags in a single rule, with optional accepted values. That small number matters. If your governance model needs 12 mandatory tags, you will split the policy across multiple rules or rethink the tagging standard.

Conformance packs

Conformance packs bundle AWS Config rules and remediation actions into deployable compliance packages. AWS provides packs aligned to frameworks such as PCI DSS, HIPAA, NIST, and operational best practices. They are useful when you need a fast baseline across many accounts.

Do not treat a conformance pack as a finished compliance program. It maps technical checks to controls, but it does not prove process maturity, access reviews, data classification, or incident response readiness. Use it as evidence support, not as the whole audit story.

Automatic remediation

AWS Config can trigger remediation when a resource becomes noncompliant, often through AWS Systems Manager Automation or Lambda. For example, you can automatically enable S3 bucket public access blocks or apply required encryption settings where supported.

Be careful with destructive remediation. Auto-closing a security group rule is usually safe if the policy is clear. Auto-modifying production networking without change review can break an application at 2 a.m. My rule: auto-remediate low-risk misconfigurations, alert and ticket the ambiguous ones.

Configuration tracking and resource timelines

The configuration recorder is the component that captures resource state. It records ConfigurationItems, which are point-in-time snapshots of supported resources. These include configuration data, relationships, and metadata.

You can set recording scope by choosing all supported resource types, selected resource types, or exclusion strategies such as EXCLUSION_BY_RESOURCE_TYPES. The includeGlobalResourceTypes setting also matters for global resources such as IAM. Beginners often miss this, then wonder why IAM-related findings appear incomplete or duplicated across Regions depending on the setup.

A real setup mistake to avoid

If you script AWS Config setup and call start-configuration-recorder before creating the recorder, the AWS CLI can return NoAvailableConfigurationRecorderException. The fix is boring but necessary: create or update the recorder first with put-configuration-recorder, configure the delivery channel, then start recording. Order matters.

Resource timeline

The resource timeline in the AWS Config console shows configuration events, compliance events, and related CloudTrail events for a resource. This is where Config becomes valuable during incident response.

Say an S3 bucket became public. The timeline can show when the bucket policy changed, when the Config rule marked it noncompliant, and which CloudTrail event occurred around that change. You still need to verify the actor in CloudTrail, but Config narrows the search quickly.

Programmatic history access

You can retrieve history with the AWS CLI using get-resource-config-history. This is useful for exporting evidence, building internal dashboards, or feeding data into a governance data lake. Enterprises also connect Config to CMDB and ITSM platforms such as ServiceNow through the AWS Service Management Connector.

Multi-account AWS Config design

For a single sandbox account, the console may be enough. For an enterprise, use AWS Config aggregators. Aggregators collect configuration and compliance data from multiple accounts and Regions, including AWS Organizations setups.

A sensible operating model looks like this:

1. Enable AWS Config in every active Region where workloads run.
2. Standardize recording settings with infrastructure as code.
3. Deploy baseline managed rules and conformance packs centrally.
4. Create an aggregator in a security or audit account.
5. Use dashboards and advanced queries for reporting.
6. Send high-risk findings to Security Hub or your ticketing workflow.

Do not only enable Config in the home Region. Attackers and hurried developers both know how to create resources elsewhere. Regional blind spots are common in young AWS environments.

Where AWS Config fits with other AWS security services

AWS Config is not a threat detection service. GuardDuty detects suspicious activity. Security Hub aggregates findings. CloudTrail records API calls. Config records resource state and policy compliance. They overlap, but they are not substitutes.

Use AWS Config when you need to know:

• What resources existed at a point in time
• How a resource was configured before and after a change
• Whether resources match security or compliance rules
• Which accounts have the most noncompliant resources
• Whether tagging, encryption, logging, or network policies are drifting

Use other tools when you need runtime detection, vulnerability scanning, endpoint telemetry, or application security testing.

Cost and operational considerations

AWS Config is charged based on usage, including configuration items recorded and rule evaluations. The inventory and compliance dashboards are available in AWS Config supported Regions at no extra Config-specific charge, but normal Config usage pricing still applies.

High-change environments can generate many ConfigurationItems. Kubernetes-heavy accounts, CI test accounts, and ephemeral infrastructure can become noisy. Tune recording scope, exclude resource types where justified, and avoid rules that evaluate constantly without business value.

Skills to build next

If you are preparing for cloud governance, security engineering, or platform engineering work, learn AWS Config alongside IAM, CloudTrail, Security Hub, AWS Organizations, and infrastructure as code. For structured learning, Global Tech Council training paths in cloud computing, cybersecurity, DevOps, and data governance are useful next steps.

Build a small lab this week: enable AWS Config in one test account, add three managed rules, create one noncompliant security group, and inspect the resource timeline. Then query the result through advanced queries. That hands-on loop teaches more than any diagram.