AWS Config Rules (Managed & Custom) | Overview.

AWS Config Rules (Managed & Custom) - Overview.

Scope:

• Intro,
• Key Rule Types,
• Evaluation Modes,
• Remediation and Management,
• Links to documentation,
• The concept of  Config Rules (deep dive),
• Archiecture,
• Types of Config Rules,
• Rule Evaluation Triggers (Rules can be triggered by),
• Anatomy of a Rule (A rule definition contains),
• Sample Managed Rule for S3 bucket (aws-managed rule),
• Rule Outcomes,
• Remediation with Rules (tied to automated remediation),
• Rules at Scale,
• Best Practices,
• Sample Custom Rule for Tag Compliance,
• Final Takeaway.

Intro:

• AWS Config rules are essentially compliance "checklists" that continuously monitor, evaluate whether twtech AWS resource configurations match its desired settings. 

Key Rule Types

• Managed Rules: These are predefined, customizable rules created and maintained by AWS for common compliance scenarios (e.g., checking if S3 buckets are public or if IAM access keys are rotated).
• Custom Rules: twtech can build its own logic using AWS Lambda functions or AWS CloudFormation Guard, a policy-as-code language. 

Evaluation Modes

• Detective Mode: Evaluates existing resources after they are created or updated. 
• It triggers based on configuration changes or at a periodic frequency (e.g., every 24 hours).
• Proactive Mode: Checks resource configurations before they are provisioned, often used within CloudFormation templates to prevent non-compliant resources from ever being created. 

Remediation and Management

• Remediation: twtech can configure AWS Systems Manager Automation to automatically fix non-compliant resources identified by a rule.
• Compliance Status: Rules return one of three statuses: 
• COMPLIANT, 
• NON_COMPLIANT,  
• INSUFFICIENT_DATA.
• Centralized Governance: twtech can deploy Organization Config Rules across all accounts in an AWS Organization from a single master account. 

NB:

• Since they’re the “brains” of AWS Config’s compliance engine.

 Links to documentation

https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_develop-rules_cfn-guard.html
 

https://docs.aws.amazon.com/config/latest/developerguide/evaluating-your-resources.html

1. The concept of  Config Rules (deep dive)

• AWS Config Rules are logical checks that continuously evaluate whether AWS resources comply with twtech desired configurations or security policies.
• Each rule runs an evaluation against a resource (or group of resources).
• The result is a compliance status:
• ✅  COMPLIANT
• ❌  NON_COMPLIANT
• ⚪  NOT_APPLICABLE

Archiecture

2. Types of Config Rules

1. Managed Rules
• Prebuilt by AWS.
• Cover common best practices/security checks.
• Examples:
• s3-bucket-public-read-prohibited
• iam-user-mfa-enabled
• rds-storage-encrypted
2. Custom Rules
• Defined with Lambda functions.
• twtech controls the evaluation logic.
• Example: “EC2 instances must have a specific tag (Owner=TeamX).”

 3. Rule Evaluation Triggers (Rules can be triggered by):

1. Configuration Change
• Evaluates when a resource changes (e.g., someone modifies a Security Group).
2. Periodic
• Runs on a schedule (1h, 3h, 6h, 12h, or 24h).
• Useful for things like “all IAM users must rotate keys every 90 days.”

 4. Anatomy of a Rule (A rule definition contains):

• Rule Name (unique identifier).
• Scope (which resource types are evaluated).
• Trigger Type (configuration change vs periodic).
• Parameters (rule-specific options).
• Lambda Function (if custom).

#  Sample Managed Rule for S3 bucket (aws-managed rule):

# json

{

  "ConfigRuleName": "twtech-s3-bucket-public-read-prohibited",

  "Source": {

    "Owner": "AWS",

    "SourceIdentifier": "S3_BUCKET_PUBLIC_READ_PROHIBITED"

  },

  "Scope": {

    "ComplianceResourceTypes": ["AWS::S3::twtechs3Bucket"]

  }

}

 5. Rule Outcomes

• Each resource evaluated produces a compliance event.
• AWS Config keeps a history of evaluations (who, when, what).
• twteeh can query compliance results via:
• AWS Console (Compliance Dashboard)
• CLI (aws configservice describe-compliance-by-config-rule)
• API

 6. Remediation with Rules (tied to automated remediation):

• If a rule fails, Config can trigger:
• SSM Automation Document (preferred).
• Lambda function (for custom fixes).
• Example:
• Rule: “Security Groups must not allow 0.0.0.0/0 on port 22.”
• Remediation: Automatically remove offending ingress rule.

 7. Rules at Scale

• Conformance Packs → collections of rules + remediation in YAML/JSON.
• Aggregator Accounts → view compliance across multi-account/multi-region setups.
• Security Hub integration → feeds rule violations into centralized findings.

8. Best Practices

1. Start with Managed Rules – they cover 70–80% of common compliance cases.
2. Use Parameters – make rules reusable across environments (e.g., define allowed AMIs via parameter).
3. Avoid Over-evaluation – recording all resources with too many rules = cost explosion.
4. Automate Remediation – otherwise rules just nag without fixing.
5. Organize via Conformance Packs – easier deployment and reporting.
6. Map Rules to Frameworks – CIS, PCI DSS, HIPAA, FedRAMP.

 9. Sample Custom Rule for Tag Compliance

NB:

# Lambda function checks if all EC2 instances have a CostCenter tag:

 # json

def lambda_handler(event, context):

    config_item = json.loads(event['invokingEvent'])['configurationItem']

    tags = config_item.get('tags', {})

    if 'CostCenter' in tags:

        compliance = 'COMPLIANT'

    else:

        compliance = 'NON_COMPLIANT'

    return {

        'compliance_type': compliance,

        'annotation': 'Instance missing CostCenter tag' if compliance == 'NON_COMPLIANT' else ''

    }

 

Final Takeaway:

• AWS Config Rules is the guardrails that enforce compliance.
• Remediation actions is the mechanisms responsible for self-healing.