15.2 AWS Config, Conformance Packs & Automated Remediation

15.2 AWS Config, Conformance Packs & Automated Remediation

Maintaining continuous security compliance across distributed multi-account cloud environments requires continuous monitoring, auditing, and recording of resource configurations. Traditional periodic audits rely on point-in-time manual assessments that fail to detect transient misconfigurations, ephemeral resource exposures, or unauthorized infrastructure alterations. AWS Config addresses this challenge by providing a continuous, fully managed configuration recording and compliance auditing service.

AWS Config tracks the detailed inventory of supported AWS resources, logs configuration history, models inter-resource relationships, and evaluates whether resource configurations conform to internal security baselines and regulatory frameworks. When combined with Conformance Packs and AWS Systems Manager Automated Remediation, AWS Config transitions security governance from passive alerting to active, autonomous self-healing.

---

AWS Config Core Architecture

The AWS Config operational workflow comprises three fundamental components: the Configuration Recorder, Configuration Items (CIs), and the Delivery Channel.

[Resource State Change] ──> [Configuration Recorder] ──> [Configuration Item (CI)]
                                                                 │
                    ┌────────────────────────────────────────────┴─────────────────────────────┐
                    ▼                                                                          ▼
           [Delivery Channel]                                                          [Config Rules Engine]
        ├── S3: Configuration History & Snapshots                                      ├── Evaluate Compliance
        └── SNS: Real-time Configuration Streams                                      └── Trigger SSM Remediation

1. Configuration Recorder

The Configuration Recorder detects changes in resource states and creates corresponding configuration records. Security engineers configure the recorder to capture:

• All Supported Resources: Records every supported AWS resource in the target Region.
• Specific Resource Types: Selectively records high-risk services (e.g., AWS::IAM::*, AWS::S3::Bucket, AWS::EC2::SecurityGroup).
• Global Resources: IAM users, groups, roles, and customer-managed policies are global resources. To avoid duplicate Configuration Items and billing charges across multiple Regions, global resources should be recorded in only one Region per account (typically us-east-1).
• Recording Frequency: Organizations can select Continuous Recording (real-time recording of changes as they occur, essential for incident detection) or Daily Recording (aggregates changes every 24 hours, suitable for cost-sensitive, low-churn environments).

2. Configuration Items (CIs)

A Configuration Item (CI) is a point-in-time JSON document representing the state of an AWS resource. Each CI contains:

• Metadata: CI capture time, CI version, AWS account ID, Region, and resource type.
• Attributes: Resource ID, resource ARN, resource tags, and creation time.
• Configuration: The full serialized configuration payload of the resource (e.g., S3 bucket encryption algorithms, security group inbound/outbound rules).
• Relationships: Graph linkages to associated resources (e.g., an EC2 instance CI references its attached EBS volumes, ENIs, and security groups).

3. Delivery Channel

The Delivery Channel exports CIs for long-term retention and real-time processing:

• Amazon S3 Bucket: Stores configuration history files (delivered periodically throughout the day) and periodic Configuration Snapshots (complete point-in-time inventories of all recorded resources).
• Amazon SNS Topic: Streams configuration change notifications and compliance evaluation status transitions in real time, enabling downstream integration with SIEMs, ticketing systems, or event routers.

---

AWS Config Rules: Managed vs. Custom

AWS Config Rules represent desired configuration states for specific resource types or entire accounts. Config evaluates resources against these rules to determine whether resources are COMPLIANT, NON_COMPLIANT, or NOT_APPLICABLE.

Evaluation Triggers

Config rules are executed based on one of two trigger mechanisms:

1. Configuration Changes (Event-Driven): Evaluated immediately when AWS Config detects a change in the resource's configuration, tags, or deletion. Used for critical security controls requiring immediate detection (e.g., S3 public access, security group rule expansion).
2. Periodic (Schedule-Driven): Evaluated at a fixed time frequency (1 hour, 3 hours, 6 hours, 12 hours, or 24 hours). Required for rules that evaluate time-dependent criteria (e.g., checking whether IAM user access keys have remained unrotated for more than 90 days).

Rule Types: Managed vs. Custom Lambda vs. Custom Guard

Lambda Custom Rule Lifecycle & PutEvaluations API

When a configuration change occurs on a resource monitored by a Lambda-based custom rule:

1. AWS Config invokes the Lambda function asynchronously, passing an event payload containing invokingEvent (containing the Configuration Item) and ruleParameters.
2. The Lambda function inspects the CI's configuration properties.
3. The function determines compliance and constructs an evaluation result containing ComplianceResourceType, ComplianceResourceId, ComplianceType (COMPLIANT or NON_COMPLIANT), and OrderingTimestamp.
4. The Lambda function calls the AWS Config API config:PutEvaluations to record the finding in AWS Config. If the function fails to call PutEvaluations, the rule status transitions to EVALUATION_FAILURE.

Multi-Account Multi-Region Configuration Aggregators

In an enterprise environment spanning dozens or hundreds of AWS accounts and multiple active Regions, reviewing compliance on an account-by-account basis is unworkable. AWS Config provides Configuration Aggregators to centralize inventory tracking and compliance posture.

Aggregator Types

1. Organization Aggregators: When configured from the AWS Organizations management account or an AWS Config Delegated Administrator account, the aggregator automatically discovers and aggregates configuration and compliance data from all member accounts in the organization across all active Regions. As new accounts join the organization, they are automatically enrolled into the aggregator without configuration changes.
2. Individual Account Aggregators: Manually configured to aggregate specific account IDs. Requires target accounts to grant authorization via PutConfigurationAggregatorAuthorization.

Organization-Wide Config Rules

Security teams can deploy rules enterprise-wide using Organization Config Rules (PutOrganizationConfigRule).

• Managed or custom rules are defined once in the management or delegated administrator account.
• AWS Config deploys the rule to all current and future member accounts in the Region where you create it (repeat per Region), except accounts you exclude.
• Immutability in Member Accounts: Member accounts cannot modify, disable, or delete Organization Config rules. Local administrators attempting to delete the rule receive an AccessDeniedException.

---

AWS Config Conformance Packs

A Conformance Pack is a packaged collection of AWS Config rules and automated remediation actions authored as a single YAML template. Conformance packs simplify compliance management by providing version-controlled governance blueprints mapped to specific industry standards and regulatory frameworks.

Supported Regulatory Frameworks

AWS provides pre-architected, managed conformance pack templates for major regulatory standards:

• NIST SP 800-53 (Rev 4 and Rev 5): Comprehensive security and privacy controls for federal and enterprise systems.
• PCI DSS v4.0: Controls covering network segmentation, encryption of cardholder data, vulnerability management, and access control.
• HIPAA Security Rule: Standards for safeguarding electronic protected health information (ePHI).
• CIS AWS Foundations Benchmark: Industry-consensus best practices for identity, logging, monitoring, and networking.
• FedRAMP Moderate & High: Federal Risk and Authorization Management Program security baselines.

Organization Conformance Packs

Similar to organization rules, Organization Conformance Packs (PutOrganizationConformancePack) deploy entire suites of rules and remediation documents across an AWS Organization:

• Deployed centrally from the management account or a delegated administrator account.
• Automatically provisioned into new member accounts when they are added to the organization.
• Cannot be deleted, modified, or bypassed by IAM principals in member accounts, ensuring an immutable compliance baseline.
• Support parameterized templates, allowing organizations to override specific rule parameters (e.g., passing custom KMS key ARNs or retention day thresholds) across different OUs.

---

Automated Remediation with Systems Manager Automation

Detecting a non-compliant resource satisfies audit visibility, but security defense requires minimizing the window of vulnerability. AWS Config integrates natively with AWS Systems Manager (SSM) Automation Documents to execute automated remedial actions.

Remediation Architecture & Configuration

Security engineers attach a Remediation Configuration to an AWS Config rule using the PutRemediationConfigurations API. The configuration specifies:

• Target Document: The SSM Automation document to execute (AWS-managed or custom).
• Execution Mode: Automatic Execution (triggers immediately upon non-compliant evaluation) or Manual Execution (operator must review finding and click "Remediate" in the console or CLI).
• Parameters: Input parameters passed to the SSM document. Config supports Dynamic Parameters (binding the non-compliant resource's identifier using the RESOURCE_ID token) and Static Parameters (fixed values such as notification ARNs or IAM roles).
• Retry Controls: Governs remediation resilience via MaximumAutomaticAttempts (1 to 25 attempts, default 5) and RetryAttemptSeconds (1 to 2,678,000 seconds, default 60 seconds).

Common AWS-Managed Remediation Documents

Remediation Execution Role Permissions

For automated remediation to succeed, the remediation configuration must specify an IAM service role (AutomationAssumeRole) that Systems Manager assumes to perform the action:

• The role must trust the Systems Manager service principal (ssm.amazonaws.com).
• The role's policy must grant the exact least-privilege actions executed by the SSM document (e.g., s3:PutBucketPublicAccessBlock for S3 remediation, or ec2:RevokeSecurityGroupIngress for security group remediation).
• If remediating across accounts in an Organization Conformance Pack, the execution role must be pre-provisioned in member accounts with identical names and trust relationships.

---

Specialty Exam Pitfalls & Architectural Traps

1. Detective Nature of Config vs. Preventive Controls: Believing that AWS Config rules can block a developer from deploying an unencrypted resource. Config is strictly detective; the resource is created first, a CI is recorded, and Config marks it NON_COMPLIANT. To block creation proactively, use Service Control Policies (SCPs), CloudFormation Hooks, or cfn-guard in CI/CD.
2. Global Resource Duplication Across Regions: Enabling global resource recording (IAM) in all active Regions. This creates duplicate Configuration Items for the exact same IAM changes, clutters S3 delivery buckets, and inflates AWS Config recording costs. Always record global resources in only one Region per account.
3. SSM Remediation Role Missing in Spoke Accounts: Deploying an Organization Conformance Pack with automated remediation, but failing to deploy the corresponding SSM Automation execution IAM role into all member accounts. The Config rule will evaluate resources as NON_COMPLIANT, but remediation will fail with ActionExecutionFailed because Systems Manager cannot assume the specified role ARN.
4. Event-Driven vs. Scheduled Rule Mismatches: Configuring an event-driven trigger for a rule that requires periodic time calculations (e.g., checking for unrotated IAM credentials older than 90 days). Because an inactive IAM user's configuration never changes, no CI is emitted, and the rule will never trigger unless configured with a Periodic schedule.