# aws-config-rules is a sample library, and the README tells you to read every rule before you ship it

> aws-config-rules is an AWS Labs community repository of custom AWS Config rules in Python, Node.js and Java, meant to illustrate how to build rules with the Rule Development Kit. It is a teaching resource rather than a hardened compliance set, and the project says so plainly: review each rule and test it in a dev environment before production.

**awslabs/aws-config-rules** — [Node, Python, Java] Repository of sample Custom Rules for AWS Config. 

- Repository: https://github.com/awslabs/aws-config-rules
- Website: http://aws.amazon.com/config/
- Stars: 1,743 · Forks: 877
- Language: Python
- License: CC0-1.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/awslabs-aws-config-rules

## A community sample set that the project itself calls examples

aws-config-rules is an AWS Labs community repository of custom rules for AWS Config, covering Node, Python and Java. The framing matters more here than in most repositories, because the README is unusually direct about what the code is. It states that the rules are examples intended to guide users in working with the AWS Config Rule Development Kit, that they are not intended to have comprehensive coverage of all possible states your resources may encounter, and that they are not guaranteed to be up to date. It then tells you to review each rule carefully and test within your dev/test environment before integrating into production.

That framing tells you what to use this for. It is a working reference for how a Config rule is shaped, written in three runtimes, plus a source of patterns to adapt. It is not a compliance pack you can point a security team at, and no amount of automation in your pipeline changes the fact that each rule is code you did not write and have not reviewed.

The repository is not archived and the last push was on 2026-10-06, and contributions are welcome through the CONTRIBUTING.md file that the README links for getting started with rule development. The licence is CC0-1.0, which places the samples in the public domain and carries none of the usual obligations for reuse.

## Deploying an RDK-generated rule with three commands

Rules created with the RDK are recognisable by their layout: each one has its own directory and there is a parameters.json file. Once you have cloned the repository and moved into the python directory, deployment is a single RDK invocation naming the rule:

```bash
git clone https://github.com/awslabs/aws-config-rules
cd python
rdk deploy NAME_OF_THE_RULE
```

The RDK tool is what creates the AWS resources needed for the rule in your account, which is the reason the repository points you at it rather than at a script of its own. You need the RDK installed and configured against the target account before the deploy command does anything useful, and the README does not document the RDK setup steps, so that part belongs to the RDK project itself.

The top level of the repository is organised by language and by purpose: java, node, python, python-rdklib and aws-config-conformance-packs directories, alongside the README, CONTRIBUTING.md and LICENSE. A conformance pack directory alongside the rule directories is a sign that some of the samples are grouped for bulk deployment rather than for single rule use.

## The manual path is Lambda first, then a Config rule pointing at it

Not every sample is an RDK deployment, and the README documents the manual route in detail. The mechanism has two halves. First you create an AWS Lambda function from the sample code. Then you create a rule in AWS Config and associate it with that function. When the rule's trigger occurs, AWS Config invokes the function to evaluate your resources.

The code entry type determines what you upload. For a Python or Node.js function you copy and paste the sample code into the Lambda console. For a Java function you must provide a JAR file containing the Java classes, and the build instructions are in java/HOWTO.md. The function's execution role matters: the README tells you to choose the AWS Config Rules permission option, which includes the AWS managed policy AWSConfigRulesExecutionRole, an AWS managed policy that allows your Lambda function permission to put evaluations.

After the function exists, note its ARN, then open the AWS Config console in the same region as the Lambda function and add a custom rule, specifying the function ARN, the trigger type and any required parameters. The trigger type is where the samples differ: configuration changes for the triggered samples, periodic for the periodic samples. The per-rule trigger types and required parameters are listed in RULES.md for Python and Node.js and in java/RULES_JAVA.md for Java.

## Trigger type and parameters decide what the rule actually checks

This is the practical part of using the samples, and it is where a misconfigured rule produces quiet results rather than errors. A rule set to configuration changes fires when the resource configuration changes, while a periodic rule runs on a schedule. Choosing the wrong trigger type for the sample you deployed means the rule either never fires when you expect it to, or runs more often than the check requires.

The same applies to parameters. Each function has required parameters, and the rule's parameter list is filled in when you create it in the console. These are not optional decoration: for a check that looks for a specific setting or a specific value, a missing or wrong parameter changes the result of the evaluation.

A summary of the evaluation results appears after several minutes, and the rule then shows on the Rules page in the AWS Config console. Note also the permission detail, which differs by path. When you create a custom rule through the console, the permissions for invoking the Lambda are created for you. If you create the rule with the AWS CLI instead, you have to give AWS Config permission to invoke your Lambda yourself, using the aws lambda add-permission command. Mixing up the two paths is a common cause of a rule that exists but never evaluates.

## Java rules need a JAR, and the handler name is part of the contract

The Java samples are the ones with extra steps. Because Lambda expects an archive, the Java classes must be built and uploaded as a JAR file, with the build procedure in java/HOWTO.md. Once the function type is Java, the Handler field is no longer a default value: you have to specify the handler for the Java function you created, and the expected handler values are listed in java/RULES_JAVA.md.

That is a small detail with a large failure surface. A wrong handler string produces a function that exists, has a role, and never returns a valid evaluation, and the error surfaces in the Config console as a failed invocation rather than as a configuration mistake that is obvious from the console itself. Compare that with the Python and Node.js path, where the README says to keep the default handler value.

The java directory therefore carries two documents rather than one, with RULES_JAVA.md alongside HOWTO.md, and the RULES.md file at the root covers the Python and Node.js samples. A team working across runtimes needs both.

## RDK, RDKLib and the Config Rules Engine fill in the surrounding work

The README points at three related projects that cover the parts a repository of samples cannot. RDK, the Rule Development Kit, is what generates and deploys the rules, and the deployment command in this repository is an RDK command. RDKLib is described as a library to run rules at scale, and the python-rdklib directory in this repository mirrors that side of the work. The Config Rules Engine is described as the project for deploying and managing rules at scale.

Those three fill the operational gap between a sample function and a fleet of rules across many accounts. Writing a Lambda is the small part. Running the same checks across an organisation, scheduling them, and reporting the results needs something else, and that is what the related projects are for.

The important structural point for an adopter is that this repository is a reference implementation, not the engine. If your requirement is dozens of rules across many accounts with consistent deployment, RDKLib and the Config Rules Engine are the tools to evaluate, and the rules in this repository are the examples you port. If your requirement is a single custom check in one account, the manual Lambda path is already enough and the surrounding projects are unnecessary.

## Reviewing a rule means reading the function, not trusting the name

The README's warning is specific: review each rule carefully and test within your dev/test environment before integrating into production. Combined with the statement that the samples are not guaranteed to be up to date, that gives you a concrete review checklist rather than a vague caveat. Check which resource types the function inspects and which configuration item it looks at, confirm the trigger type and parameters against RULES.md, and then run the rule against a resource in a dev account to see the evaluation it actually produces rather than the one you assumed.

A test in a dev account is the step most likely to be skipped, because the rule looks like it works once it is created. The evaluation summary appears only after several minutes, and a rule whose parameters are wrong or whose trigger never fires produces no result rather than a wrong one, which is easy to read as success.

The licence, CC0-1.0, means there is no attribution or licence-compliance step in your adoption path, which is unusually convenient when you plan to fork a rule into your own account. The cost is entirely the review effort, and that effort is exactly what the project asks you to spend.

## Conclusion

aws-config-rules fits engineers learning to write AWS Config custom rules or looking for a starting point for an internal compliance check, and it does not fit teams that need a maintained, complete set of controls they can enable as is. Before using any rule from this repository, review the rule directory you are copying and test it in a dev account, since the project states the samples are not guaranteed to be up to date and do not cover every possible resource state, and check the trigger type and required parameters listed in RULES.md before creating the rule in AWS Config.

## FAQ

### How do I deploy a rule from aws-config-rules?

Rules created with the RDK have their own directory and a parameters.json file, so you can spot them. Clone the repository, change into the python directory, and run rdk deploy NAME_OF_THE_RULE in your account.

### Can I create an AWS Config rule without the RDK?

Yes. Create an AWS Lambda function from the sample code, note its ARN, then add a custom rule in the AWS Config console in the same region, specifying the function ARN, the trigger type and any required parameters. The console creates the invoke permissions; with the CLI you need aws lambda add-permission yourself.

### What trigger types do the sample rules use?

The triggered samples use Configuration changes and the periodic samples use Periodic, and the per-rule trigger types and required parameters are listed in RULES.md for Python and Node.js functions and in java/RULES_JAVA.md for Java. The parameter list is filled in when the rule is created.

### What is the difference between deploying a Java rule and a Python rule?

A Python or Node.js function is created by copying and pasting the sample code into the Lambda console and keeping the default handler value. A Java function must be supplied as a JAR file built according to java/HOWTO.md, and you must specify the handler value, which is listed in java/RULES_JAVA.md.

### What licence applies to the rules in aws-config-rules?

The repository is licensed under CC0-1.0. The project states the rules are examples intended to guide users working with the RDK, and that they are not guaranteed to be up to date, so each rule should be reviewed and tested before production use.

## Sources

- [awslabs/aws-config-rules on GitHub](https://github.com/awslabs/aws-config-rules)
- [Issues](https://github.com/awslabs/aws-config-rules/issues)
- [License: CC0-1.0](https://github.com/awslabs/aws-config-rules/blob/master/LICENSE)
- [Project website](http://aws.amazon.com/config/)
- [README](https://github.com/awslabs/aws-config-rules/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/awslabs-aws-config-rules