Managed and Custom Config Rules

A Config rule evaluates whether your resources comply with a desired configuration and reports each as COMPLIANT or NON_COMPLIANT. Recording state is passive; rules add the judgment layer that flags insecure settings automatically, turning Config into a continuous compliance engine.

Managed rules are prebuilt by AWS for common checks, so you enable them without writing code. Examples include s3-bucket-public-read-prohibited, encrypted-volumes, iam-password-policy, and restricted-ssh. There are hundreds covering best practices, making them the fastest way to establish a compliance baseline.

When no managed rule fits, you write a custom rule. These run as a Lambda function that receives the resource configuration and returns a compliance verdict, or as a Guard policy using AWS's policy-as-code language. Custom rules encode organization-specific requirements that managed rules cannot express.

Rules run on two trigger types. A configuration-change trigger evaluates a resource whenever it changes, giving near-real-time compliance. A periodic trigger runs on a fixed schedule regardless of changes, useful for checks that depend on time or on account-level settings rather than a single resource event.

The Config dashboard shows each rule's compliance and lists the non-compliant resources. This gives a prioritized to-do list of insecure configurations. For security, rules like public S3 buckets, unencrypted volumes, and open security groups surface the exact resources that need fixing.

Many rules accept parameters to tailor the check. The iam-password-policy rule, for instance, lets you specify minimum length and rotation requirements. Parameters let one managed rule enforce your organization's specific standard rather than a generic default, without writing custom code.

A conformance pack bundles many rules and remediation actions into a single deployable package, often mapped to a framework like CIS or PCI DSS. Deploying a pack across accounts via an aggregator or Organizations applies a whole compliance standard at once instead of enabling rules one by one.

You can scope a rule to specific resource types or tags so it only evaluates what matters, reducing both noise and cost. Config charges per rule evaluation, so scoping and choosing the right trigger type keeps a large rule set affordable while still covering the security-critical resources.

Config rules and Security Hub standards overlap, and Security Hub actually uses Config behind many of its checks. Config rules give you fine-grained, customizable, per-resource compliance; Security Hub aggregates findings across services into a posture score. The exam may ask which to use for custom, resource-level checks: that is Config rules.

Consider restricted-ssh: it marks a security group NON_COMPLIANT if it allows unrestricted inbound SSH on port 22 from 0.0.0.0/0. Enabling this single rule across your accounts continuously catches one of the most common and dangerous misconfigurations with no custom code at all.

Start with managed rules and conformance packs for broad coverage, then add custom rules for your unique policies. Scope thoughtfully, parameterize to your standards, and pair high-value rules with remediation. This layered approach gives continuous, automated assurance that your environment stays configured securely.

Test your Config rules knowledge.

Config rules mark resources COMPLIANT or NON_COMPLIANT. Hundreds of managed rules cover common checks with optional parameters, while custom rules (Lambda or Guard) encode unique policies. Rules trigger on change or on a schedule, bundle into conformance packs for frameworks, and complement Security Hub by providing fine-grained, per-resource compliance.