3.2.3.7. Configuring S3 Events to Process Log Files (Lambda) and Deliver Log Files to Another Destination (OpenSearch Service, CloudWatch Logs)

3.2.3.7. AWS Config Rules Automated Remediation

Detecting non-compliance is useful; automatically fixing it is transformational. Config rules with automated remediation create a self-healing compliance posture.

Remediation architecture:

1. AWS Config detects a non-compliant resource
2. Remediation configuration triggers an SSM Automation document
3. SSM Automation executes the fix (e.g., enable encryption, restrict security group)
4. Config re-evaluates the resource
5. Resource marked as COMPLIANT

Common remediation examples:

# Custom SSM Automation: Remove unrestricted SSH from security group
schemaVersion: '0.3'
parameters:
  SecurityGroupId:
    type: String
mainSteps:
  - name: RevokeSSH
    action: aws:executeAwsApi
    inputs:
      Service: ec2
      Api: RevokeSecurityGroupIngress
      GroupId: "{{ SecurityGroupId }}"
      IpPermissions:
        - IpProtocol: tcp
          FromPort: 22
          ToPort: 22
          IpRanges:
            - CidrIp: "0.0.0.0/0"

Config remediation settings:

• Automatic: true — remediation runs without approval
• MaximumAutomaticAttempts: How many times to retry (1-25)
• RetryAttemptSeconds: Wait between retries
• ResourceId parameter mapping: Config passes the non-compliant resource ID to the SSM document

Exam Trap: Automatic remediation can cause unintended disruptions. Removing an SSH rule or enabling encryption on a running instance may break active connections. Use Automatic: false (manual) for production-critical resources and Automatic: true for development/sandbox environments. The exam tests whether you understand the risk of fully automated remediation in production.