What Is AWS Config Rules? Security Definition

Imagine you own a large apartment building and you want every apartment to follow the same safety rules. You write down a list of rules, such as “every apartment must have a working smoke detector” and “windows must not be left open when it rains.” Then you hire a manager who walks through the building every day and checks each apartment against that list. If the manager finds an apartment without a smoke detector, they flag it and tell you so you can fix it. AWS Config Rules work exactly like that manager, but for your virtual resources in the cloud. Instead of smoke detectors, AWS Config Rules check things like “Is this virtual server using a secure type of encryption?” or “Is this storage bucket publicly accessible to the internet?” You define the rules yourself, or you can use pre‑built rules written by AWS security experts. Once a rule is set up, AWS Config automatically evaluates each resource against that rule every time the resource’s configuration changes. If the resource violates the rule, AWS Config marks it as noncompliant and sends you a notification. You can then look at the details and take corrective action. This is incredibly handy because manually checking every single resource in a large cloud account would be like your building manager trying to check 1,000 apartments every day without a checklist. AWS Config Rules provide that automated, always‑on checklist so you never miss a violation. The best part is that the rules run in the background without stopping your applications. They simply report what they find, and you decide what to do next.

Another way to think about it is a security guard who watches security cameras. The guard isn’t there to stop everything; they are there to look for specific bad things, like a door being propped open or a light that is off when it should be on. When they see something wrong, they radio you. AWS Config Rules are that security guard, only they never sleep and they never miss a detail. They are always watching your cloud resources, comparing each one to the list of allowed configurations that you provided. If anything drifts away from the allowed state, you get a report. This helps you keep your cloud environment stable, secure, and compliant with industry standards like HIPAA or PCI. It also gives you a full history of every change made to a resource, which is useful for audits or troubleshooting. In short, AWS Config Rules are a simple but powerful way to enforce good practices in your cloud environment without extra manual work.

AWS Config Rules are a feature of AWS Config, a fully managed service that provides resource inventory, configuration history, and configuration change notifications. A Config Rule is essentially a function that evaluates a resource’s configuration settings against a desired state. The rule can be a managed rule provided by AWS or a custom rule you write using AWS Lambda. Each rule is defined with a trigger type and a set of parameters. The trigger type determines when the rule runs: either on configuration changes (change‑triggered) or at periodic intervals (periodic). When a resource configuration changes, AWS Config records the configuration change as a configuration item and then evaluates all applicable rules against that new configuration. For periodic rules, AWS Config runs an evaluation on a schedule you define, such as every hour or every day.

At its core, an AWS Config Rule uses a JSON file called a conformance pack template or a simple AWS Lambda function to implement the evaluation logic. For managed rules, the evaluation logic is already written by AWS and tested. For example, the managed rule ‘s3-bucket-public-read-prohibited’ checks whether any S3 bucket has a bucket policy that allows public read access. If the rule detects a bucket with public read, it sets the compliance status to NON_COMPLIANT. For a custom rule, you write a Lambda function in a language such as Python or Node.js. That function receives an event from AWS Config that contains the resource configuration. You then write code to check the configuration against your own business rules. For instance, you could write a custom rule that checks whether every EC2 instance has a specific tag (like “Environment:Production”) and marks the instance as noncompliant if the tag is missing.

The evaluation result is stored in the AWS Config timeline for that resource, and you can view compliance status in the AWS Config console, through the AWS CLI, or via the AWS Config API. AWS Config also integrates with AWS Security Hub, AWS CloudTrail, and AWS Lambda for automated remediation. You can set up automatic remediation actions, such as triggering a Lambda function to automatically remove a public bucket policy when a rule flags it. The service maintains a complete audit trail of every evaluation, which can be exported to Amazon S3 or streamed to Amazon CloudWatch Logs. All of this works under the AWS shared responsibility model: AWS manages the infrastructure of the Config service, and you are responsible for defining and managing the rules.

AWS Config Rules are region‑specific. Each rule exists in a single AWS region and applies only to resources in that region. To enforce rules across all regions, you must create the rule in each region or use an AWS Organizations‑based approach with conformance packs. Conformance packs are collections of Config Rules and remediation actions that can be deployed across multiple accounts and regions using AWS Organizations. This allows large enterprises to enforce consistent security policies across hundreds of accounts. The pricing for AWS Config Rules is based on the number of rule evaluations performed per month, with the first 10,000 evaluations free for the first year of AWS Config usage. For certification exams, you should remember that Config Rules are not the same as AWS Trusted Advisor checks; Trusted Advisor provides best‑practice recommendations, while Config Rules enforce specific, customizable compliance policies.

Internally, AWS Config uses a resource configuration snapshot model. When you enable AWS Config, it records the configuration of supported resources as configuration items (CIs). Each CI contains metadata about the resource, its current configuration, and a timestamp. Config Rules compare the latest CI against the rule’s condition. For custom rules using Lambda, the Lambda function must be properly configured with the necessary IAM permissions to read the resource configuration and to invoke the function from AWS Config. A common gotcha is forgetting to attach the AWSLambdaBasicExecutionRole or a similar policy that allows logs to be written to CloudWatch. The rule evaluation can be synchronous (for change‑triggered rules) or asynchronous (for periodic rules). Synchronous evaluations happen immediately after a configuration change, while asynchronous evaluations happen on a schedule. Resource types are added to AWS Config over time, so not all AWS services are supported yet. As of this writing, over 270 AWS resource types are supported. You should check the AWS Config Developer Guide for the current list.

For exam questions, you need to understand the rule evaluation lifecycle: a resource change triggers an evaluation, the rule engine evaluates the resource, and the compliance result is stored. You also need to know that Config Rules can be evaluated using the AWS Config console, CLI, or API, and that the results can be aggregated via AWS Config Aggregators to see compliance across multiple accounts and regions. An important detail is that AWS Config Rules do not prevent a change from happening; they only report after the fact. For proactive prevention, you would use AWS Service Control Policies (SCPs) in AWS Organizations or IAM policies. Config Rules are detective, not preventative. This distinction is crucial for exam questions about security controls.

AWS Config Rules matter because they transform cloud security and compliance from a manual, error‑prone process into an automated, continuous, and auditable system. In a real IT environment, you often have hundreds or thousands of resources running across multiple regions and accounts. Manually checking each resource’s configuration is impossible, and even if you automate the checks with scripts, you lose the valuable audit trail and the integration with other AWS services. Config Rules provide a centralized, managed way to define, evaluate, and track compliance. For example, a company handling credit card transactions must comply with PCI DSS, which requires that all data at rest is encrypted. You can create a Config Rule that checks every Amazon RDS database, Amazon EBS volume, and S3 bucket to ensure encryption is enabled. If a new developer launches an unencrypted database, the rule flags it automatically, and you can set up an automatic remediation action to encrypt it or delete it. This catch‑and‑fix cycle happens within minutes, preventing a potential compliance violation and a fine.

Another real‑world scenario is managing cost and security in a multi‑account environment. Using AWS Organizations and Config Rules, you can define a baseline of rules that every account must follow. For instance, you can enforce that no security group allows inbound SSH from 0.0.0.0/0 (the entire internet). If an account creates a security group that violates that rule, Config Rules mark it as noncompliant, and you can trigger a Lambda function to revoke the rule or notify the account owner. This prevents the common mistake of leaving a port open to the internet, which leads to data breaches. Without Config Rules, you would need to manually audit security groups or rely on infrequent manual checks.

Config Rules provide a compliance scoreboard. AWS Config Aggregator lets you view compliance across all accounts and regions in a single dashboard. This makes it easy for a security team to see which accounts have the most violations and focus remediation efforts. For IT operations, the history of evaluations can be used to demonstrate compliance during an audit. You can export all compliance data to S3 and retain it for years. This is far more reliable than maintaining spreadsheets or manual logs.

Cost is another factor. AWS Config Rules are not free at scale, but the cost is often much lower than the cost of a data breach or a compliance fine. For example, the average cost of a data breach in 2024 was over $4 million, while Config Rule evaluations cost a few cents per evaluation. Investing in a few well‑designed rules can save your organization millions. Config Rules help you enforce best practices that reduce the attack surface and improve operational stability. For instance, a rule that ensures all EC2 instances are launched from approved AMIs helps prevent the use of insecure or outdated images. Another rule that checks for CloudTrail being enabled in every region ensures you have complete audit logs for incident response.

AWS Config Rules are a foundational tool for security, compliance, and governance in the cloud. They automate policy enforcement, provide continuous monitoring, generate auditable records, and integrate with other AWS services for remediation. For IT professionals, understanding Config Rules is not just about passing an exam; it is about running a secure, well‑managed cloud environment that meets regulatory requirements and internal standards.

In certification exams, AWS Config Rule questions typically fall into three patterns: scenario‑based selection questions, configuration design questions, and troubleshooting questions. In scenario‑based questions, you are given a company requirement and asked to choose the best AWS service to meet that requirement. For example, a question might describe a company that needs to continuously monitor their S3 buckets for public read access and receive an email when a bucket is opened to the public. The answer would be AWS Config Rules with an SNS notification, not AWS Trusted Advisor (which is a manual check) or AWS Inspector (which scans for vulnerabilities). Another scenario might ask you to ensure every EC2 instance has a specific tag. The correct approach is to create a custom Config Rule using Lambda to check for the tag, and then set up an SNS topic for alerts.

Configuration design questions focus on how to set up Config Rules correctly. For instance, you might be asked to design a solution that enforces a security policy across 50 accounts in an AWS Organization. The best answer would be to use a conformance pack that is deployed via the management account to all member accounts and regions. A common distractor is to suggest creating the Config Rule in each account manually, which is not efficient. Another design question might ask about how to automatically remediate a noncompliant S3 bucket. The correct answer involves using an AWS Config rule with an automatic remediation action that triggers an AWS Systems Manager Automation document to modify the bucket policy. You need to know that the remediation action requires an IAM role for Config to invoke the automation.

Troubleshooting questions present a situation where something is not working as expected. For example, you created a custom Config Rule with a Lambda function, but no evaluations are running. Potential causes: the Lambda function lacks permissions to be invoked by AWS Config, the resource type is not supported by AWS Config, or the trigger type is misconfigured. Another common troubleshooting scenario: the Config Rule shows “N/A” for a resource. This often means that the resource was deleted, or the rule does not apply to that resource type. You may also see a question where compliance results are not appearing in the Config console. The cause could be that AWS Config is not enabled in that region, or the rule is in a different region than the resource.

Another pattern is comparing services. You might be asked which service is best for detecting a specific misconfiguration. For example, you need to detect if an IAM role has too permissive trust policies. The best option is AWS Config with a custom rule, because IAM is a supported resource type. AWS Identity and Access Management Access Analyzer could also detect suspicious trust policies, but the question may specify that you need a custom policy beyond the standard checks. The key is to read the question carefully: if it says “custom rule” or “continuous evaluation,” it is pointing to Config. If it says “reviewing IAM policies for unintended access,” IAM Access Analyzer is more appropriate.

Finally, exam questions might ask about pricing or limits. For example, how often a periodic rule can evaluate resources. The answer is every 1 hour, 3 hours, 6 hours, 12 hours, or 24 hours. A common trick is that you cannot set a custom interval like every 30 minutes. Change‑triggered rules evaluate when the configuration changes, so no schedule is needed. Understanding these nuances is critical for getting the right answer on exam day.