AWS Config Rules

Definition

AWS Config Rules are automated compliance checks that evaluate AWS resources against configuration rules. Rules continuously monitor your infrastructure and alert when resources drift from desired configuration. This enables compliance-as-code: define standards once, enforce organization-wide.

How Config Rules Work

Evaluation Cycle:

1. Config monitors all resource changes in real-time
2. Triggers evaluation of relevant rules
3. Rule evaluates: resource compliant or non-compliant
4. Sends notification via SNS if non-compliant
5. Logs compliance status in Config dashboard

Example Rule: S3 Encryption

• Rule: “All S3 buckets must have encryption enabled”
• Resource: New S3 bucket created
• Config evaluates: Is encryption enabled?
• Result: Compliant or Non-compliant
• Action: Alert if non-compliant

AWS Managed Rules vs Custom Rules

AWS Managed Rules (pre-built)

• S3 bucket encryption, versioning, logging
• EC2 security groups, EBS encryption
• RDS encryption, backup enabled
• IAM password policy, MFA enabled
• VPC flow logs enabled
• CloudTrail logging enabled
• 300+ rules available

Custom Rules (you define)

• Define compliance logic in Lambda
• Evaluate based on custom requirements
• Example: “All production resources must have cost-center tag”
• Example: “No instances larger than m5.xlarge in dev”

Remediation Actions

Automatic Remediation (AWS-managed)

• Modify non-compliant resource automatically
• Examples: Enable encryption, add security group rule, tag resource
• Reduces manual remediation effort
• Can be dangerous; test first

Manual Remediation

• Config alerts on non-compliance
• Team manually fixes resource
• Better for critical changes
• Requires response process

Config + Other Services

Config + CloudTrail

• Config shows compliance status (what)
• CloudTrail shows who changed it (why)
• Together: full audit trail

Config + Remediation Actions

• Automated self-healing infrastructure
• Example: Non-compliant SG auto-reverts
• Reduces compliance violations

Config + SNS/EventBridge

• Notify teams of non-compliance
• Trigger workflows (Slack, email, Jira)
• Escalate critical violations

Common Compliance Rule Patterns

Security Rules:

• Encryption at rest (S3, EBS, RDS)
• TLS in transit (ALB HTTPS, RDS)
• Network isolation (security groups, NACLs)
• IAM least privilege

Data Protection Rules:

• Backup enabled (RDS, EBS, snapshots)
• Versioning enabled (S3)
• Replication enabled (multi-region)
• Retention policies enforced

Operational Rules:

• Logging enabled (CloudTrail, VPC Flow Logs, ALB)
• Monitoring enabled (CloudWatch alarms)
• Tags present and correct
• No public resources

Common Mistakes

Mistake 1: Creating rules without remediation plan. Non-compliance means something is broken; have a way to fix it.

Mistake 2: Enabling automatic remediation without testing. A rule that auto-changes production config can break systems.

Mistake 3: Too many rules creating alert fatigue. Prioritize rules; not all violations need immediate response.

Implementation Timeline

Week 1: Setup

• Enable AWS Config
• Deploy 5-10 high-priority managed rules
• Configure SNS notifications

Week 2-4: Tuning

• Review false positives
• Adjust rule logic or exclusions
• Build remediation processes

Month 2: Expansion

• Add custom rules for org-specific compliance
• Implement automated remediation
• Integrate with ticketing system

Related AWS Services

• AWS CloudTrail (audit logging what changed)
• AWS Systems Manager Automation (remediation workflows)
• AWS Security Hub (centralized compliance dashboard)
• AWS Organizations (multi-account config aggregation)

Related FactualMinds Content

• AWS Config Rules: Compliance Automation Guide
• Cloud Compliance Services
• Cloud Security