13.1 AWS Config Managed Rules & Automated Remediation with SSM

AWS Config Architecture: Configuration Items, Recorders & Rule Types

AWS Config is a fully managed service that provides resource inventory, configuration history, and compliance monitoring across AWS environments. For the AWS Certified DevOps Engineer - Professional (DOP-C02) exam, candidates must master how AWS Config continuously evaluates resource state, detects configuration drift, and executes automated self-healing workflows via AWS Systems Manager (SSM) Automation.

Core Components of AWS Config

1. Configuration Item (CI): A standardized JSON document representing the state of an AWS resource at a specific point in time. A CI encapsulates resource metadata, configuration attributes, relationship mappings to other resources, and CloudTrail event IDs associated with the state change.
2. Configuration Recorder: Captures changes for specified resource types in each AWS Region. It must be explicitly enabled and assigned an IAM service-linked role with permissions to read resource configurations.
3. Configuration Stream & History: Delivers real-time CI updates to an Amazon Kinesis Data Stream and writes scheduled configuration history snapshots (hourly/daily) to an Amazon S3 bucket, accompanied by Amazon SNS state-change notifications.

Resource Mutation (API Call)
          │
          ▼
[ Configuration Recorder ] ──> Generates Configuration Item (CI)
          │
          ├──> Amazon S3 Bucket (Configuration History Snapshot)
          ├──> Amazon SNS Topic (Configuration State Changes)
          ▼
[ AWS Config Rules Engine ] ──> Evaluates Compliance (Compliant / Non-Compliant)
          │
          ▼ (If Non-Compliant & Auto-Remediation Configured)
[ AWS Systems Manager Automation Document ] ──> Self-Healing Action Executed

Managed Rules vs. Custom Lambda Rules

AWS Config provides two primary mechanisms for evaluating resource compliance:

For custom Lambda rules, AWS Config invokes the function with an event payload containing the CI and an evaluation token. The Lambda function inspects the CI attributes and must invoke config:PutEvaluations before its own function timeout expires, supplying the ComplianceType (COMPLIANT, NON_COMPLIANT, or NOT_APPLICABLE), the EvaluationToken, and the resource identity (OrderingTimestamp, ComplianceResourceId, ComplianceResourceType).

---

Trigger Types: Configuration Changes vs. Periodic Schedules

Config rules are triggered according to two distinct evaluation models based on the nature of the check:

1. Configuration Change Triggered Rules

Change-triggered rules evaluate resources in near-real-time whenever an affected resource is created, updated, or deleted. When the Configuration Recorder detects an API mutation, it generates a CI and immediately passes it to the associated rule.

• Best Suited For: Security boundaries and resource configuration properties that can be immediately evaluated from the CI payload (e.g., verifying if an S3 bucket has public access blocked, if an EBS volume is encrypted upon creation, or if a Security Group allows port 22 to 0.0.0.0/0).
• Scope of Changes: Can be restricted to specific resource types (e.g., AWS::EC2::SecurityGroup), specific resource IDs, or specific resource tags.

2. Periodic Triggered Rules

Periodic rules evaluate compliance at recurring time intervals regardless of whether a configuration mutation occurred.

• Supported Frequencies: 1 hour, 3 hours, 6 hours, 12 hours, or 24 hours.
• Best Suited For: Rules that evaluate dynamic, external, or time-decay attributes that do not emit CI change notifications. Classic examples include:
  • access-keys-rotated: Evaluates whether active IAM access keys have exceeded a maximum age (e.g., 90 days).
  • iam-user-unused-credentials-check: Identifies passwords or access keys inactive for more than 45 days.
  • ebs-snapshot-public-restorable-check: Queries external snapshot permissions.

---

Evaluation Modes: Detective vs. Proactive

A critical DOP-C02 concept is the distinction between Detective and Proactive evaluation modes:

Developer / CI/CD Pipeline
          │
          ├──> [ Proactive Mode ] ──> StartResourceEvaluation API / CloudFormation Hooks
          │                               │ (Pre-deployment check: Passes or Fails Build)
          │                               ▼
          └──> [ Resource Provisioned ] ──> Detective Mode (AWS Config Recorder captures CI)
                                                  │ (Post-deployment continuous audit)
                                                  ▼
                                            Compliance Dashboard / Remediation

Detective Mode

• Operates after resources are provisioned.
• Continuously audits live infrastructure recorded by the Configuration Recorder.
• When a violation is identified, the resource is flagged as NON_COMPLIANT in the AWS Config dashboard, an SNS event is emitted, and automated SSM remediation is triggered if configured.
• Limitation: The non-compliant resource exists in the production environment for a transient period until remediation completes.

Proactive Mode

• Operates before resources are provisioned into the live environment.
• Evaluates CloudFormation template resource definitions or Terraform configurations prior to deployment using the config:StartResourceEvaluation API or AWS CloudFormation Guard Hooks.
• If a template resource violates a proactive Config rule (e.g., an S3 bucket lacking encryption), the deployment pipeline blocks the deployment entirely, preventing security regressions from entering production.
• Can evaluate both AWS Managed Rules and Custom Guard Rules that support proactive evaluation.

Automated Remediation with Systems Manager Automation Documents

AWS Config allows engineers to attach automated remediation actions to any managed or custom rule using AWS Systems Manager (SSM) Automation documents. When a resource is flagged as NON_COMPLIANT, Config automatically initiates the configured SSM Automation document without requiring manual operator intervention.

Remediation Configuration Specification (AWS::Config::RemediationConfiguration)

A remediation configuration specifies how Config invokes SSM Automation:

Type: AWS::Config::RemediationConfiguration
Properties:
  ConfigRuleName: restricted-ssh
  TargetType: SSM_DOCUMENT
  TargetId: AWS-DisablePublicAccessForSecurityGroup
  TargetVersion: '1'
  Automatic: true
  MaximumAutomaticAttempts: 5
  RetryAttemptSeconds: 60
  Parameters:
    GroupId:
      ResourceValue:
        Value: RESOURCE_ID
    AutomationAssumeRole:
      StaticValue:
        Values:
          - !GetAtt RemediationExecutionRole.Arn

Key Remediation Execution Parameters

1. Automatic: Boolean (true or false). When set to true, remediation executes immediately upon non-compliance detection. When set to false, an operator must manually trigger remediation via the console or CLI (aws configservice start-remediation-execution).
2. MaximumAutomaticAttempts: Specifies how many times AWS Config attempts automatic remediation before marking the remediation as failed. Valid range is 1 to 25 attempts.
3. RetryAttemptSeconds: The backoff time in seconds that AWS Config waits before retrying a failed remediation execution. Valid range is 1 to 2,678,400 seconds (31 days).
4. Parameters: Mappings passed into the SSM Automation document:
   • ResourceValue (RESOURCE_ID): Dynamically extracts the non-compliant resource identifier (e.g., GroupId, BucketName, InstanceId) directly from the evaluation finding.
   • StaticValue: Hardcoded parameters, such as the AutomationAssumeRole ARN or default encryption keys.

Widely Tested AWS-Managed Remediation Documents

Remediation Execution Role: Trust Policy & Least Privilege

A frequent source of exam errors involves confusing the AWS Config service role with the Remediation Execution Role:

• The AWS Config Service Role allows Config to describe resources, record CIs, and publish to S3/SNS. Its trust principal is config.amazonaws.com.
• The Remediation Execution Role (AutomationAssumeRole) is assumed by AWS Systems Manager, NOT AWS Config directly. Therefore, its IAM trust policy MUST allow ssm.amazonaws.com:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ssm.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

The permissions policy attached to this role must grant least-privilege access for the specific actions performed by the SSM document (e.g., ec2:RevokeSecurityGroupIngress, s3:PutEncryptionConfiguration, iam:UpdateAccessKey).

---

AWS Config Conformance Packs & Multi-Account Governance

A Conformance Pack is a collection of AWS Config rules and associated remediation actions packaged into a single, version-controlled YAML template. Conformance packs simplify compliance tracking against industry frameworks (e.g., CIS AWS Foundations Benchmark, NIST 800-53, PCI-DSS, HIPAA).

Multi-Account Deployment via AWS Organizations

In enterprise environments, managing Config rules account-by-account is unsustainable. Organization Conformance Packs solve this:

1. Delegated Administration: The organization management account delegates Config administration to a dedicated audit or security tooling account using AWS Organizations:

aws organizations register-delegated-administrator \
    --account-id 111122223333 \
    --service-principal config-multiaccountsetup.amazonaws.com

1. Template Authoring: The DevOps team writes a conformance pack YAML template defining rules, parameters, and AWS::Config::RemediationConfiguration resources.
2. Centralized Deployment: The delegated administrator deploys the pack across the entire AWS Organization using PutOrganizationConformancePack:

aws configservice put-organization-conformance-pack \
    --organization-conformance-pack-name CIS-Benchmark-Pack \
    --template-s3-uri "s3://central-sec-compliance/conformance-packs/cis-v3.yaml" \
    --delivery-s3-bucket central-sec-compliance

1. Immutability & Tamper Resistance: Once deployed across the organization, member accounts cannot modify, disable, or delete the organizational conformance pack or its constituent rules. Even member account root credentials cannot alter organization-managed Config rules.
2. Multi-Account Aggregators: A centralized AWS Config Aggregator deployed in the security account aggregates compliance data and inventory from all member accounts across all AWS Regions, providing a unified compliance posture.