AWS Config Rules and Conformance Packs

AWS Config is a fully managed service that provides a detailed inventory of your AWS resources and continuously records configuration changes. It enables you to evaluate resource configurations against desired policies using Config rules. The primary purpose is to achieve compliance auditing, security analysis, and operational troubleshooting. Without Config, you would need to manually audit resources using scripts or third-party tools, which is error-prone and does not scale.

A Config rule is essentially a Lambda function (or a built-in function) that evaluates whether a resource configuration complies with a policy. When you enable a Config rule, AWS Config triggers evaluations based on: - Configuration changes: Whenever a supported resource is created, updated, or deleted, Config records the change and invokes the rule's evaluation function. - Periodic evaluations: You can set a frequency (e.g., every 1, 3, 6, 12, or 24 hours) for rules that need to check resources regardless of changes.

The evaluation function receives a JSON payload containing the resource's configuration and metadata. It returns a compliance status: COMPLIANT, NON_COMPLIANT, NOT_APPLICABLE, or INSUFFICIENT_DATA. The rule can also include remediation actions using AWS Systems Manager Automation documents.

- Managed Rules: Pre-built rules provided by AWS (e.g., s3-bucket-public-read-prohibited). They cover common compliance frameworks like PCI DSS, HIPAA, and CIS Benchmarks. - Custom Rules: You write your own evaluation logic in a Lambda function. You define the rule in JSON or YAML and associate it with the Lambda ARN. - Trigger Types: - Configuration changes: Evaluates when a resource changes. Supported for resources listed in the Config resource schema. - Periodic: Evaluates at a fixed interval (e.g., TwentyFour_Hours). - Evaluation Results: Config stores the latest compliance status for each resource-rule pair. You can view results in the console or via API. - Remediation: You can associate a Systems Manager Automation document (SSM doc) with a rule. When a resource is noncompliant, you can automatically run remediation (e.g., attach a policy, stop an instance). Manual or automatic remediation can be triggered. - Aggregators: For multi-account/region compliance, use an aggregator to collect compliance data from multiple accounts and regions into a single view.

To create a managed rule using AWS CLI:

aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "s3-bucket-public-read-prohibited",
  "Source": {
    "Owner": "AWS",
    "SourceIdentifier": "S3_BUCKET_PUBLIC_READ_PROHIBITED"
  }
}'

To create a custom rule:

aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "check-ec2-tags",
  "Source": {
    "Owner": "CUSTOM_LAMBDA",
    "SourceIdentifier": "arn:aws:lambda:us-east-1:123456789012:function:my-tag-check",
    "SourceDetails": [
      {
        "EventSource": "aws.config",
        "MessageType": "ConfigurationItemChangeNotification"
      }
    ]
  },
  "Scope": {
    "ComplianceResourceTypes": ["AWS::EC2::Instance"]
  }
}'

To list compliance status:

aws configservice get-compliance-details-by-config-rule --config-rule-name s3-bucket-public-read-prohibited

A conformance pack is a collection of AWS Config rules and remediation actions that can be deployed together as a single entity. It uses a YAML or JSON template to define the rules, parameters, and remediation. Conformance packs are especially useful for implementing standardized compliance across multiple accounts using AWS Organizations. You can deploy a conformance pack to an entire organization, specific OUs, or individual accounts.

Key points:

A company processing credit card transactions must comply with PCI DSS. They use hundreds of EC2 instances, S3 buckets, and RDS databases across multiple accounts. The security team needs to ensure that:

They deploy AWS Config with managed rules such as s3-bucket-public-read-prohibited, ec2-instance-no-public-ip, rds-storage-encrypted, and restricted-ssh. They create a conformance pack template that includes these rules and deploy it to all accounts using AWS Organizations. For any noncompliant resources, they set up automatic remediation via SSM Automation: for example, automatically attaching a policy to block public access on S3 buckets. They also configure Config aggregators in a central audit account to view compliance across all accounts. Common issues: forgetting to enable Config recording in all regions, or not granting the Config recorder role sufficient permissions to describe resources.

A multinational corporation requires all resources to have specific tags (e.g., CostCenter, Environment, Owner) for cost allocation and governance. They have thousands of resources across hundreds of accounts. They create a custom Config rule that checks for the presence and value of required tags on EC2 instances, volumes, and S3 buckets. The rule triggers on configuration changes and runs periodically every 6 hours. They deploy this rule via a conformance pack to all accounts. When a resource is missing a tag, an automatic remediation runs a Lambda function that adds the missing tag with a default value. However, they must ensure the remediation Lambda has permissions to tag resources across accounts. Performance: with thousands of resources, the evaluation time is manageable but they need to monitor Lambda concurrency limits. Misconfiguration: if the rule's scope is not set correctly, it may evaluate unsupported resources and return NOT_APPLICABLE, causing confusion.

A bank must adhere to the CIS AWS Foundations Benchmark. They use the AWS-provided conformance pack template Operational-Best-Practices-for-CIS-AWS-Foundations-Benchmark. This template includes over 40 rules covering IAM, logging, monitoring, and networking. They deploy it to their production and non-production accounts. They customize parameters such as the SNS topic ARN for alerts. They also enable automatic remediation for critical rules, like enabling CloudTrail in all regions. However, they discover that some rules conflict with existing configurations (e.g., the CIS rule requiring VPC flow logs enabled on all VPCs causes noncompliance for VPCs that intentionally disable flow logs due to cost). They create exemptions by using Config rule parameters to exclude certain resources. They also use Config advanced queries to generate custom reports for auditors.