AWS Config Rules and Compliance

AWS Config is a fully managed service that provides you with an AWS resource inventory, configuration history, and configuration change notifications to enable security and governance. It continuously monitors and records your AWS resource configurations and allows you to automate the evaluation of recorded configurations against desired configurations.

Without AWS Config, tracking resource configurations across hundreds or thousands of resources is nearly impossible. Teams manually check settings, rely on scripts that run periodically, or discover misconfigurations only after a security incident. AWS Config solves this by providing a continuous, auditable record of resource configuration changes and automated compliance checks.

AWS Config works by first discovering all supported AWS resources in your account and region. It then records a configuration item (CI) for each resource every time a change occurs. A configuration item includes metadata about the resource (ARN, type, ID), its current configuration (JSON), and relationships to other resources. These CIs are stored in a configuration history file that is delivered to an Amazon S3 bucket you specify.

Config rules are the core of compliance evaluation. A Config rule is essentially a function that evaluates your resource configurations against desired settings. You can choose from over 100 AWS managed rules (pre-defined) or create custom rules using AWS Lambda. Each rule is associated with one or more resource types and a trigger type (see below). When a resource change triggers a rule evaluation, the rule returns one of these compliance states: COMPLIANT, NON_COMPLIANT, NOT_APPLICABLE, or INSUFFICIENT_DATA.

Trigger Types: - Configuration changes: The rule is triggered when a resource that matches the rule's scope changes. For example, a rule that checks if S3 buckets have versioning enabled triggers when any S3 bucket is created or updated. - Periodic: The rule runs at a frequency you specify (every 1, 3, 6, 12, or 24 hours). Useful for rules that check external factors, like whether an IAM user has logged in within the last 90 days. - Hybrid: Some rules can be triggered by both configuration changes and periodically.

AWS Config has two main components: Configuration Recording and Config Rules.

Configuration Recording: - Records configuration changes for all supported resources in a region. - Stores configuration history and configuration snapshots in an S3 bucket. - Provides a configuration timeline for each resource, viewable in the AWS Config console. - Pricing: $0.003 per configuration item recorded per region (as of 2025). The first 100,000 configuration items per month are free.

Config Rules: - Managed rules: No additional cost for the rule itself, but you pay for evaluations. $0.001 per rule evaluation per region. - Custom rules: You pay for Lambda invocations in addition to the evaluation fee. - Pricing example: If you have 10 managed rules evaluating 1,000 resources each, that's 10,000 evaluations. At $0.001 per evaluation, that's $10 per month plus S3 storage costs.

Multi-Account and Multi-Region Aggregation: - AWS Config Aggregators allow you to aggregate compliance data from multiple accounts and regions into a single view. This is essential for enterprises with many accounts. - An aggregator collects configuration and compliance data from source accounts and regions, giving you a centralized dashboard.

In on-premises environments, configuration management is often done with tools like Chef, Puppet, Ansible, or manual spreadsheets. These tools are typically used for provisioning and enforcing configurations, but they lack continuous auditing and historical tracking. AWS Config is different because it is not an enforcement tool (it does not prevent changes) but an auditing and monitoring tool. It records what changed, when, and by whom (via CloudTrail integration), providing a complete audit trail.

Competing AWS services include: - AWS CloudTrail: Records API calls, not resource configurations. CloudTrail tells you who made a change; Config tells you what the resource looks like after the change. - AWS Systems Manager: Can enforce configurations via State Manager, but does not provide the same historical record or compliance dashboard. - AWS Security Hub: Consumes findings from Config and other services, but does not perform the underlying configuration evaluations.

Use AWS Config when you need:

Do not use AWS Config when:

AWS provides over 100 managed rules that cover common security and compliance checks. Examples relevant to CLF-C02: - s3-bucket-public-read-prohibited: Checks if S3 buckets allow public read access. - iam-user-no-policies-check: Checks that IAM users do not have inline or attached policies (best practice is to use groups or roles). - restricted-common-ports: Checks if security groups allow unrestricted access to common ports (e.g., SSH port 22 from 0.0.0.0/0). - cloudtrail-enabled: Checks that CloudTrail is enabled in the region. - ec2-volume-inuse-check: Checks if EBS volumes are attached to instances (prevents orphaned volumes).

Each managed rule has a defined resource type, trigger type, and parameters you can customize. For example, the restricted-common-ports rule allows you to specify which ports to check and what CIDR range is considered 'restricted'.

If a managed rule does not meet your needs, you can create a custom rule using a Lambda function. The Lambda function receives an event with the configuration item and must return a compliance result. For example, you might create a custom rule that checks if RDS instances have automated backups enabled with a retention period of at least 7 days. The Lambda function would parse the RDS configuration, check the backup retention period, and return COMPLIANT or NON_COMPLIANT.

AWS Config can automatically remediate non-compliant resources using AWS Systems Manager Automation documents. For example, if an S3 bucket becomes publicly readable, Config can trigger a Systems Manager Automation document that modifies the bucket policy to block public access. This is set up in the Config rule's remediation action section. You can also manually remediate by clicking a button in the Config console.

A fintech startup needs to comply with PCI DSS, which requires monitoring of security configurations. They enable AWS Config across all accounts and enable managed rules like 'ec2-ebs-encryption-by-default' (checks that EBS volumes are encrypted), 'cloudtrail-enabled', and 's3-bucket-logging-enabled'. They set up a custom rule to check that RDS instances have encryption at rest. The Config dashboard gives them a real-time compliance score. When a developer accidentally launches an unencrypted EBS volume, Config flags it as non-compliant and sends an alert via SNS. The security team then uses the configuration timeline to see who created the volume and when. They also set up auto-remediation using Systems Manager to automatically encrypt the volume. Cost: ~$50/month for 500 resources and 20 rules. Without Config, they would need manual audits and risk non-compliance fines.

A large enterprise with 200 AWS accounts uses AWS Organizations. They enable Config in every account and region, and create an aggregator in a central security account. They enable managed rules for all accounts, such as 'iam-user-no-policies-check' (enforces IAM best practices) and 'restricted-common-ports' (prevents open SSH). The central security team views compliance across all accounts from one dashboard. When a new account is created via Organizations, Config automatically starts recording and evaluating rules. They discover that several accounts have security groups allowing SSH from 0.0.0.0/0. The team uses the aggregator to identify all affected accounts and resources, then sends a notification to account owners. They also create a remediation action that automatically removes the offending rule. This central visibility is impossible without Config and the aggregator.

Common mistakes include: (1) Not enabling Config in all regions—attackers can use an unmonitored region. (2) Not setting up an SNS topic for alerts—violations go unnoticed. (3) Over-customizing rules with wrong parameters—causing false positives or missing violations. (4) Forgetting to set up remediation—non-compliant resources remain for days. (5) Not aggregating across accounts—compliance blind spots in subsidiary accounts. In one case, a company failed a PCI audit because they only monitored US East (N. Virginia) but had resources in EU (Ireland) that were not recorded.