Config

Record and evaluate AWS resource configurations over time for compliance auditing

AWS Config is a continuous auditing service that records the configuration state of your AWS resources over time, evaluates them against desired-state rules, and maintains a detailed history of all configuration changes. It is the primary tool for compliance auditing, security investigations, and change management in AWS environments.

How Config Records Resources and Configuration History

AWS Config uses a Configuration Recorder to capture resource configurations and changes. When you enable Config in a region, it periodically snapshots the state of all supported resource types and records every configuration change as a Configuration Item (CI).

Concept	Description
Configuration Item (CI)	Point-in-time snapshot of a single resource's configuration, relationships, and metadata
Configuration History	All CIs for a resource over time - lets you see exactly how it looked at any past point
Configuration Snapshot	Full point-in-time dump of all recorded resources in a region, delivered to S3
Configuration Stream	SNS stream of configuration changes as they occur in near real-time
Delivery Channel	S3 bucket + optional SNS topic where Config delivers snapshots and change notifications

Config tracks resource relationships as well as configurations. For example, a CI for a security group includes which EC2 instances are associated with it, and a CI for an EC2 instance includes the VPC, subnet, and attached security groups. This relationship graph is invaluable for blast-radius analysis.

bash

# Get configuration history for a specific resource
aws configservice get-resource-config-history \
  --resource-type AWS::EC2::SecurityGroup \
  --resource-id sg-0123456789abcdef0 \
  --limit 10

# List all resources of a type tracked by Config
aws configservice list-discovered-resources \
  --resource-type AWS::S3::Bucket

⚠️

AWS Config costs are primarily driven by the number of configuration items recorded. With recording set to "All resources", costs can grow quickly in large accounts. Use resource-specific recording to limit scope if cost is a concern, or use the newer per-resource-type controls.

Config Rules, Conformance Packs, and Remediation

Config Rules are the evaluation engine of AWS Config. A rule defines the desired configuration state of a resource type. Config evaluates resources against rules and marks them as COMPLIANT or NON_COMPLIANT.

Rule Type	Description	Examples
AWS Managed Rules	Pre-built rules maintained by AWS, configurable parameters	s3-bucket-public-read-prohibited, rds-storage-encrypted, mfa-enabled-for-iam-console-access
Custom Lambda Rules	You write a Lambda function that evaluates compliance	Check that EC2 instances have required tags, verify custom security policies
Custom Policy Rules (Guard)	Write compliance logic in cfn-guard policy language, no Lambda needed	Simpler custom rules without Lambda management overhead

Conformance Packs are collections of Config rules and remediation actions that can be deployed as a single unit. AWS provides conformance packs aligned with compliance standards like PCI-DSS, HIPAA, NIST, and CIS Benchmarks.

Remediation Actions let Config automatically fix non-compliant resources using SSM Automation documents. You can configure auto-remediation (fires immediately on non-compliance) or manual remediation (creates a finding that a human must approve).

bash

# Deploy a conformance pack (e.g., operational best practices for S3)
aws configservice put-conformance-pack \
  --conformance-pack-name "s3-operational-best-practices" \
  --template-s3-uri "s3://my-config-bucket/conformance-packs/s3-pack.yaml"

# Check compliance summary for a rule
aws configservice get-compliance-summary-by-config-rule

# List non-compliant resources for a specific rule
aws configservice get-compliance-details-by-config-rule \
  --config-rule-name "s3-bucket-public-read-prohibited" \
  --compliance-types NON_COMPLIANT

💡

Config rules evaluate on configuration change (triggered by the change) or periodically (every 1, 3, 6, 12, or 24 hours). Change-triggered rules are more responsive but only fire when the resource changes. Periodic rules catch compliance drift in resources that haven't changed recently.

Aggregators, Multi-Account Visibility, and Organizations Integration

A Config Aggregator collects Config data from multiple accounts and regions into a single aggregated view. This is the foundation of enterprise-wide compliance reporting.

Aggregation Type	How It Works	Use Case
Individual account aggregation	Explicitly list source accounts; each must authorize the aggregator	Small number of accounts, manual governance
Organization aggregation	Automatically includes all accounts in an AWS Organization; management account deploys aggregator	Large organizations with hundreds of accounts

When using Organizations integration, you can deploy Config rules organization-wide using Organization Config Rules. These automatically apply to all existing accounts and any new accounts added to the Organization, eliminating the need to manually configure each account.

The aggregated view lets you query across all accounts: "which S3 buckets in my entire organization have public access enabled?" or "which EC2 instances in us-east-1 are missing the required cost-center tag?"

bash

# Query aggregated compliance across organization
aws configservice get-aggregate-compliance-details-by-config-rule \
  --configuration-aggregator-name "org-aggregator" \
  --config-rule-name "s3-bucket-public-read-prohibited" \
  --compliance-type NON_COMPLIANT

# Advanced Config query across all accounts (SQL-like)
aws configservice select-aggregate-resource-config \
  --configuration-aggregator-name "org-aggregator" \
  --expression "SELECT accountId, resourceId, configuration.publicAccessBlockConfiguration WHERE resourceType='AWS::S3::Bucket' AND configuration.publicAccessBlockConfiguration.blockPublicAcls != true"

Config vs CloudTrail vs GuardDuty - Complementary Roles

A common interview question is distinguishing the roles of Config, CloudTrail, and GuardDuty. They address different questions and are complementary, not redundant:

Service	Answers the Question	Data Type	Primary Use
AWS Config	"What is the configuration of this resource now and how did it change over time?"	Resource configuration state	Compliance auditing, change history, drift detection
CloudTrail	"Who made this API call and when?"	API call audit log	Security audit, who changed what, forensics
GuardDuty	"Is there malicious or anomalous activity happening in my account?"	VPC Flow Logs, DNS logs, CloudTrail events (ML analysis)	Threat detection, anomaly detection

A complete security posture uses all three: CloudTrail answers "who did it", Config answers "what changed", and GuardDuty answers "was it malicious". For a security incident investigation, you'd use CloudTrail to find who made a change, Config to see what the resource looked like before and after, and GuardDuty to determine if the actor was behaving maliciously.

💡

Config can also use CloudTrail events to link a configuration change to the specific API call and IAM principal that caused it. This correlation is available in the Config timeline view and makes incident investigation much faster.

🎯

Interview Focus Points

1What is a Configuration Item in AWS Config and what information does it contain?
2How do Config rules differ from SCPs (Service Control Policies) - one detects, one prevents?
3Explain the difference between change-triggered and periodic Config rules.
4How would you achieve organization-wide compliance reporting across 200 AWS accounts using Config?
5Compare AWS Config, CloudTrail, and GuardDuty - what question does each answer?
6How does Config remediation work and what is the risk of auto-remediation vs manual remediation?
7What is a conformance pack and how does it help with framework-aligned compliance (PCI, HIPAA)?
8How does Config track resource relationships and why is that useful for security investigations?