7.3.1. Compliance Detection and Remediation

First Principle: Compliance is not a state — it's a continuous process. Resources become non-compliant constantly (new deployments, configuration changes, new rules). Automated detection and remediation maintain compliance without manual intervention.

AWS Config for Compliance:

• Config Rules: Evaluate resource configurations against desired baselines
  • Managed rules: 300+ pre-built rules (e.g., s3-bucket-ssl-requests-only, ec2-imdsv2-check)
  • Custom rules: Lambda-backed rules for organization-specific requirements
• Remediation Actions: Automatically fix non-compliant resources using SSM Automation
• Conformance Packs: Collections of Config rules deployed as a unit (CIS, PCI DSS, NIST)
• Aggregators: Cross-account, cross-Region compliance dashboard

Security Hub Standards:

• AWS Foundational Security Best Practices: AWS-recommended security controls
• CIS AWS Foundations Benchmark: CIS-recommended controls
• PCI DSS: Payment card industry controls
• Automated scoring: percentage of checks passing per standard
• Integrates with EventBridge for automated response to failed checks

Compliance Automation Pipeline:

1. Config rule detects non-compliance
2. EventBridge routes finding to remediation Lambda
3. Lambda executes SSM Automation to fix the resource
4. Config re-evaluates to confirm compliance
5. Security Hub updates the compliance score

⚠️ Exam Trap: Config rules evaluate configuration. Security Hub standards evaluate security posture against frameworks. They overlap but serve different purposes — Config for resource-level compliance, Security Hub for framework-level scoring.

Scenario: A PCI DSS conformance pack detects that 5 S3 buckets lack encryption. Auto-remediation enables SSE-KMS on each bucket. Config re-evaluates and confirms compliance. Security Hub PCI DSS score improves from 87% to 94%.

Reflection Question: Why does the auto-remediation model (detect → fix → verify) provide stronger compliance assurance than periodic manual audits?