TECH **AWS Config Rules & Conformance Packs: Zero-Fluff, Hands-On Study Guide**

AWS Config Rules & Conformance Packs: Zero-Fluff, Hands-On Study Guide

(AWS Solutions Architect – Associate)

1. What This Is & Why It Matters

You’re a cloud engineer at a fintech startup. Your CISO just dropped a bombshell: "We need to prove to auditors that every S3 bucket has encryption enabled, every EC2 instance has a specific tag, and no security group allows unrestricted SSH access. And we need it in writing by Friday."

AWS Config Rules are your compliance autopilot. They continuously evaluate your AWS resources against custom or AWS-managed rules (e.g., "Is S3 bucket versioning enabled?"). Conformance Packs bundle multiple rules into a single deployable unit—like a compliance "playbook" for standards like CIS, PCI-DSS, or your internal policies.

Why this matters in production:
- Avoid audit failures: If you can’t prove compliance, you risk fines, lost contracts, or worse—data breaches.
- Automate remediation: Instead of manually checking 500 EC2 instances, Config Rules can flag (or even fix) non-compliant resources.
- Shift-left security: Catch misconfigurations before they hit production (e.g., a developer accidentally opens port 22 to the world).

Real-world scenario:
You inherit a legacy AWS account with 200+ resources. Your boss says, "We need to enforce encryption on all S3 buckets and ensure no RDS instances are publicly accessible." Without Config Rules, you’d spend days writing scripts or manually checking each resource. With them, you deploy a rule in 5 minutes and get a compliance report in 10.

2. Core Concepts & Components

1. AWS Config

• Definition: A service that records configuration changes to your AWS resources (e.g., "EC2 instance i-123456 was stopped at 2:03 PM").
• Production insight: Without Config, you’re flying blind—no audit trail for who changed what, when. Critical for troubleshooting ("Why did our bill spike?") and compliance.

2. Config Recorder

• Definition: The "camera" that tracks changes to your resources. You enable it per region.
• Production insight: If the recorder isn’t running, Config Rules won’t work. ⚠️ Default: Disabled in new accounts.

3. Config Rule

• Definition: A "check" that evaluates whether a resource complies with a desired configuration (e.g., "Is S3 bucket logging enabled?").
• Types:
• Managed rules: Pre-built by AWS (e.g., s3-bucket-ssl-requests-only).
• Custom rules: Written in Lambda (e.g., "Check if EC2 instances have a CostCenter tag").
• Production insight: Managed rules cover 80% of common compliance needs. Custom rules fill gaps (e.g., "All Lambda functions must have a Project tag").

4. Conformance Pack

• Definition: A YAML template that deploys multiple Config Rules at once (e.g., "CIS AWS Foundations Benchmark v1.4.0").
• Production insight: Instead of deploying 50 rules one-by-one, you deploy a pack in one command. ⚠️ Packs are region-specific.

5. Remediation Action

• Definition: Automatically fixes non-compliant resources (e.g., "Enable encryption on an S3 bucket").
• Production insight: Use sparingly—automated remediation can break things (e.g., disabling a misconfigured security group might cut off production traffic).

6. Aggregator

• Definition: Collects Config data from multiple accounts/regions into a single view.
• Production insight: Critical for multi-account setups (e.g., "Show me all non-compliant S3 buckets across 10 accounts").

7. Compliance Timeline

• Definition: A historical view of when a resource was compliant/non-compliant.
• Production insight: Auditors love this. "Prove that your S3 bucket was encrypted on March 1st" → pull up the timeline.

8. SNS Notifications

• Definition: Config can send alerts when a resource becomes non-compliant.
• Production insight: Pair with Slack/email to get real-time alerts (e.g., "A developer just opened port 22 to the world!").

3. Step-by-Step: Deploy a Conformance Pack

Prerequisites

• AWS account with admin IAM permissions (or at least config:* and iam:PassRole).
• AWS CLI installed and configured (aws configure).
• A test region (e.g., us-east-1).

Step 1: Enable AWS Config Recorder

Config Rules won’t work without the recorder. Do this first.

# Enable Config in us-east-1 (replace with your region)
aws configservice put-configuration-recorder \
  --configuration-recorder name=default,roleArn=arn:aws:iam::123456789012:role/aws-service-role/config.amazonaws.com/AWSServiceRoleForConfig \
  --recording-group allSupported=true,includeGlobalResourceTypes=true \
  --region us-east-1

# Start the recorder
aws configservice start-configuration-recorder --configuration-recorder-name default --region us-east-1

Verify:

aws configservice describe-configuration-recorders --region us-east-1

Expected output:

{
  "ConfigurationRecorders": [
    {
      "name": "default",
      "roleArn": "arn:aws:iam::123456789012:role/aws-service-role/config.amazonaws.com/AWSServiceRoleForConfig",
      "recordingGroup": {
        "allSupported": true,
        "includeGlobalResourceTypes": true
      }
    }
  ]
}

Step 2: Deploy a Conformance Pack

We’ll use the CIS AWS Foundations Benchmark v1.4.0 pack (a common compliance standard).

# Download the pack template
wget https://raw.githubusercontent.com/awslabs/aws-config-rules/master/aws-config-conformance-packs/CIS-AWS-Foundations-Benchmark/v1.4.0/cis-aws-foundations-benchmark.yaml

# Deploy the pack (replace ACCOUNT_ID)
aws configservice put-conformance-pack \
  --conformance-pack-name "CIS-AWS-Foundations-Benchmark" \
  --template-body file://cis-aws-foundations-benchmark.yaml \
  --delivery-s3-bucket "config-conformance-pack-bucket-$(aws sts get-caller-identity --query Account --output text)" \
  --region us-east-1

Verify:

aws configservice describe-conformance-packs --region us-east-1

Expected output:

{
  "ConformancePackDetails": [
    {
      "ConformancePackName": "CIS-AWS-Foundations-Benchmark",
      "ConformancePackArn": "arn:aws:config:us-east-1:123456789012:conformance-pack/CIS-AWS-Foundations-Benchmark",
      "DeliveryS3Bucket": "config-conformance-pack-bucket-123456789012",
      "ConformancePackId": "cp-1234567890abcdef"
    }
  ]
}

Step 3: Check Compliance Status

aws configservice get-conformance-pack-compliance-details \
  --conformance-pack-name "CIS-AWS-Foundations-Benchmark" \
  --region us-east-1

Expected output (truncated):

{
  "ConformancePackName": "CIS-AWS-Foundations-Benchmark",
  "ConformancePackRuleEvaluationResults": [
    {
      "ComplianceType": "NON_COMPLIANT",
      "EvaluationResultIdentifier": {
        "EvaluationResultQualifier": {
          "ConfigRuleName": "cis-aws-foundations-benchmark-1.4-ensure-no-root-account-access-key-exists",
          "ResourceType": "AWS::IAM::User",
          "ResourceId": "root"
        }
      }
    },
    {
      "ComplianceType": "COMPLIANT",
      "EvaluationResultIdentifier": {
        "EvaluationResultQualifier": {
          "ConfigRuleName": "cis-aws-foundations-benchmark-1.5-ensure-mfa-is-enabled-for-the-root-account",
          "ResourceType": "AWS::IAM::User",
          "ResourceId": "root"
        }
      }
    }
  ]
}

Interpretation:
- The root account has an access key (bad!).
- The root account has MFA enabled (good!).

Step 4: Fix a Non-Compliant Resource

Let’s remove the root account access key (a common security risk).

# List root account access keys
aws iam list-access-keys --user-name root

# Delete the access key (replace ACCESS_KEY_ID)
aws iam delete-access-key --access-key-id AKIAEXAMPLE123456 --user-name root

Re-evaluate the rule:

aws configservice start-config-rules-evaluation --config-rule-names "cis-aws-foundations-benchmark-1.4-ensure-no-root-account-access-key-exists" --region us-east-1

Wait 1-2 minutes, then check compliance again. The rule should now show COMPLIANT.

4. ? Production-Ready Best Practices

Security

• Least privilege for Config role: The IAM role for Config should only have permissions to read resources and write to S3 (for delivery).
  json {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"config:Put*",
"config:Get*",
"config:List*",
"config:Describe*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": ["s3:PutObject"],
"Resource": ["arn:aws:s3:::config-conformance-pack-bucket-*/AWSLogs/*"]
}
] }
• Encrypt S3 delivery bucket: Use SSE-S3 or SSE-KMS for Config logs.
• Enable SNS notifications: Alert on NON_COMPLIANT events.

Cost Optimization

• Use managed rules first: They’re free (you only pay for Config’s recording).
• Limit custom rules: Lambda invocations for custom rules cost money. Use them only for unique checks.
• Exclude non-critical resources: Use excludedAccounts in the conformance pack to skip dev/test accounts.

Reliability & Maintainability

• Tag everything: Use aws:cloudformation:stack-name to track which CloudFormation stack deployed a resource.
• Multi-region packs: Deploy the same conformance pack in all regions (use AWS Organizations for bulk deployment).
• Version control: Store conformance pack YAML files in Git (e.g., infra/compliance/cis-aws-foundations.yaml).

Observability

• CloudWatch Alarms: Trigger on ConfigRulesComplianceChange events.
• AWS Config Dashboard: Pin compliance reports to the AWS Console homepage.
• Athena queries: Analyze Config logs in S3 with SQL (e.g., "Show all non-compliant S3 buckets in the last 30 days").

5. ⚠️ Common Mistakes & Traps

6. ? Exam/Certification Focus

Typical Question Patterns

1. "Which service evaluates AWS resource configurations against rules?"
2. ✅ AWS Config
3. ❌ AWS Inspector (scans for vulnerabilities, not configurations)

4. ❌ AWS GuardDuty (threat detection)

5. "How do you enforce compliance across multiple accounts?"

6. ✅ Use an aggregator to collect Config data from all accounts.

7. ❌ Deploy Config Rules in each account manually (too slow).

8. "What’s the difference between a Config Rule and a Conformance Pack?"

9. Config Rule: Single check (e.g., "Is S3 bucket encrypted?").
10. Conformance Pack: Bundle of rules (e.g., "CIS Benchmark v1.4.0").

Key ⚠️ Trap Distinctions

• Config vs. CloudTrail:
• Config: Tracks resource configurations (e.g., "S3 bucket policy changed").
• CloudTrail: Tracks API calls (e.g., "User alice called PutBucketPolicy").
• Managed vs. Custom Rules:
• Managed: Pre-built by AWS (e.g., s3-bucket-public-read-prohibited).
• Custom: Written in Lambda (e.g., "Check if EC2 has a Project tag").

Common Scenario-Based Question

"You need to ensure all S3 buckets have versioning enabled. What’s the most cost-effective way?"
- ✅ AWS Config managed rule (s3-bucket-versioning-enabled). Free (only pay for Config recording).
- ❌ Custom Lambda rule (costs money for invocations).
- ❌ AWS Inspector (wrong tool—scans for vulnerabilities, not configurations).

7. ? Hands-On Challenge

Challenge:
Deploy a custom Config Rule that checks if all EC2 instances have a CostCenter tag. If an instance lacks the tag, the rule should mark it as NON_COMPLIANT.

Solution:
1. Create a Lambda function (Python) to evaluate the rule:
```python
import boto3

def lambda_handler(event, context):
config = boto3.client('config')
invoking_event = json.loads(event['invokingEvent'])
result_token = event['resultToken']

   # Get the EC2 instance ID from the event
   instance_id = invoking_event['configurationItem']['resourceId']

   # Check for CostCenter tag
   ec2 = boto3.client('ec2')
   response = ec2.describe_tags(
       Filters=[{
           'Name': 'resource-id',
           'Values': [instance_id]
       }]
   )
   tags = {tag['Key']: tag['Value'] for tag in response['Tags']}

   if 'CostCenter' not in tags:
       compliance_type = 'NON_COMPLIANT'
       annotation = 'EC2 instance is missing CostCenter tag'
   else:
       compliance_type = 'COMPLIANT'
       annotation = 'EC2 instance has CostCenter tag'

   # Put evaluation result
   config.put_evaluations(
       Evaluations=[{
           'ComplianceResourceType': 'AWS::EC2::Instance',
           'ComplianceResourceId': instance_id,
           'ComplianceType': compliance_type,
           'Annotation': annotation,
           'OrderingTimestamp': invoking_event['configurationItem']['configurationItemCaptureTime']
       }],
       ResultToken=result_token
   )

2. Deploy the Lambda and create a custom Config Rule:bash
aws configservice put-config-rule \
--config-rule file://config-rule.json
Where `config-rule.json` is:json
{
"ConfigRuleName": "ec2-costcenter-tag-check",
"Description": "Checks if EC2 instances have a CostCenter tag",
"Source": {
"Owner": "CUSTOM_LAMBDA",
"SourceIdentifier": "arn:aws:lambda:us-east-1:123456789012:function:ec2-costcenter-tag-check",
"SourceDetails": [
{
"EventSource": "aws.config",
"MessageType": "ConfigurationItemChangeNotification"
}
]
},
"Scope": {
"ComplianceResourceTypes": ["AWS::EC2::Instance"]
}
}
`` 3. Why it works: The Lambda runs whenever an EC2 instance is created/updated, checks for theCostCenter` tag, and reports compliance to Config.

8. ? Rapid-Reference Crib Sheet

9. ? Where to Go Next

1. AWS Config Developer Guide – Official docs (start here).
2. AWS Config Rules GitHub – Pre-built conformance packs and custom rules.
3. CIS AWS Foundations Benchmark – The compliance standard we used in the example.
4. AWS Config + CloudFormation – Deploy rules via IaC.