{"id":13602625,"url":"https://github.com/awslabs/aws-config-rdk","last_synced_at":"2026-03-03T20:08:10.882Z","repository":{"id":38145668,"uuid":"99261539","full_name":"awslabs/aws-config-rdk","owner":"awslabs","description":"The AWS Config Rules Development Kit helps developers set up, author and test custom Config rules. It contains scripts to enable AWS Config, create a Config rule and test it with sample ConfigurationItems. ","archived":false,"fork":false,"pushed_at":"2024-05-22T18:43:42.000Z","size":3741,"stargazers_count":437,"open_issues_count":37,"forks_count":169,"subscribers_count":36,"default_branch":"master","last_synced_at":"2024-05-22T19:51:44.366Z","etag":null,"topics":["amazon-web-services","aws","aws-config","aws-config-rules","rdk"],"latest_commit_sha":null,"homepage":"https://aws-config-rdk.readthedocs.io","language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/awslabs.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2017-08-03T18:06:51.000Z","updated_at":"2024-05-29T19:46:23.243Z","dependencies_parsed_at":"2024-01-18T18:45:44.943Z","dependency_job_id":"2f4c824b-1885-4c46-afbf-6cfd927fe4d4","html_url":"https://github.com/awslabs/aws-config-rdk","commit_stats":{"total_commits":486,"total_committers":64,"mean_commits":7.59375,"dds":0.7098765432098766,"last_synced_commit":"ff944bc5a3e0e8824c166824a08a74df71a5fcdc"},"previous_names":[],"tags_count":39,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/awslabs%2Faws-config-rdk","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/awslabs%2Faws-config-rdk/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/awslabs%2Faws-config-rdk/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/awslabs%2Faws-config-rdk/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/awslabs","download_url":"https://codeload.github.com/awslabs/aws-config-rdk/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":223464889,"owners_count":17149648,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["amazon-web-services","aws","aws-config","aws-config-rules","rdk"],"created_at":"2024-08-01T18:01:32.066Z","updated_at":"2026-03-03T20:08:10.854Z","avatar_url":"https://github.com/awslabs.png","language":"Python","funding_links":[],"categories":["aws","Python"],"sub_categories":[],"readme":"# AWS RDK\n\n[![pypibadge](https://static.pepy.tech/personalized-badge/rdk?period=total\u0026units=international_system\u0026left_color=black\u0026right_color=blue\u0026left_text=downloads)](https://pepy.tech/project/rdk)\n![PyPI](https://img.shields.io/pypi/v/rdk)\n\nAWS Config Rules Development Kit\n\nWe greatly appreciate feedback and bug reports at\n\u003crdk-maintainers@amazon.com\u003e! You may also create an issue on this repo.\n\nThe RDK is designed to support a \"Compliance-as-Code\" workflow that is\nintuitive and productive. It abstracts away much of the undifferentiated\nheavy lifting associated with deploying AWS Config rules backed by\ncustom lambda functions, and provides a streamlined\ndevelop-deploy-monitor iterative process.\n\nFor complete documentation, including command reference, check out the\n[ReadTheDocs documentation](https://aws-config-rdk.readthedocs.io/).\n\n## Getting Started\n\nUses Python 3.7+ and is installed via pip. Requires you to have\nan AWS account and sufficient permissions to manage the Config service,\nand to create S3 Buckets, Roles, and Lambda Functions. An AWS IAM Policy\nDocument that describes the minimum necessary permissions can be found\nat `policy/rdk-minimum-permissions.json`.\n\nUnder the hood, rdk uses boto3 to make API calls to AWS, so you can set\nyour credentials any way that boto3 recognizes (options 3 through 8\n[here](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/credentials.html#guide-credentials))\nor pass them in with the command-line parameters `--profile`,\n`--region`, `--access-key-id`, or `--secret-access-key`\n\nIf you just want to use the RDK, go ahead and install it using pip.\n\n```bash\npip install rdk\n```\n\nAlternately, if you want to see the code and/or contribute you can clone\nthe git repo, and then from the repo directory use pip to install the\npackage. Use the `-e` flag to generate symlinks so that any edits you\nmake will be reflected when you run the installed package.\n\nIf you are going to author your Lambda functions using Java you will\nneed to have Java 8 and gradle installed. If you are going to author\nyour Lambda functions in C# you will need to have the dotnet CLI and the\n.NET Core Runtime 1.08 installed.\n\n```bash\npip install -e .\n```\n\nTo make sure the rdk is installed correctly, running the package from\nthe command line without any arguments should display help information.\n\n```bash\nrdk\nusage: rdk [-h] [-p PROFILE] [-k ACCESS_KEY_ID] [-s SECRET_ACCESS_KEY]\n           [-r REGION] [-f REGION_FILE] [--region-set REGION_SET]\n           [-v] \u003ccommand\u003e ...\nrdk: error: the following arguments are required: \u003ccommand\u003e, \u003ccommand arguments\u003e\n```\n\n## Usage\n\n### Configure your env\n\nTo use the RDK, it's recommended to create a directory that will be\nyour working directory. This should be committed to a source code repo,\nand ideally created as a python virtualenv. In that directory, run the\n`init` command to set up your AWS Config environment.\n\n```bash\nrdk init\nRunning init!\nCreating Config bucket config-bucket-780784666283\nCreating IAM role config-role\nWaiting for IAM role to propagate\nConfig Service is ON\nConfig setup complete.\nCreating Code bucket config-rule-code-bucket-780784666283ap-southeast-1\n```\n\nRunning `init` subsequent times will validate your AWS Config setup and\nre-create any S3 buckets or IAM resources that are needed.\n\n- If you have config delivery bucket already present in some other AWS account then use `--config-bucket-exists-in-another-account` as argument.\n\n```bash\nrdk init --config-bucket-exists-in-another-account\n```\n\n- If you have AWS Organizations/ControlTower Setup in your AWS environment then additionally, use `--control-tower` as argument.\n\n```bash\nrdk init --control-tower --config-bucket-exists-in-another-account\n```\n\n- If bucket for custom lambda code is already present in current account then use `--skip-code-bucket-creation` argument.\n\n```bash\nrdk init --skip-code-bucket-creation\n```\n\n- If you want rdk to create/update and upload the rdklib-layer for you, then use `--generate-lambda-layer` argument. In supported regions, rdk will deploy the layer using the Serverless Application Repository, otherwise it will build a local lambda layer archive and upload it for use.\n\n```bash\nrdk init --generate-lambda-layer\n```\n\n- If you want rdk to give a custom name to the lambda layer for you, then use `--custom-layer-namer` argument. The Serverless Application Repository currently cannot be used for custom lambda layers.\n\n```bash\nrdk init --generate-lambda-layer --custom-layer-name \u003cLAYER_NAME\u003e\n```\n\n## Create Rules\n\nIn your working directory, use the `create` command to start creating a\nnew custom rule. You must specify the runtime for the lambda function\nthat will back the Rule, and you can also specify a resource type (or\ncomma-separated list of types) that the Rule will evaluate or a maximum\nfrequency for a periodic rule. This will add a new directory for the\nrule and populate it with several files, including a skeleton of your\nLambda code.\n\n```bash\nrdk create MyRule --runtime python3.12 --resource-types AWS::EC2::Instance --input-parameters '{\"desiredInstanceType\":\"t2.micro\"}'\nRunning create!\nLocal Rule files created.\n```\n\nOn Windows it is necessary to escape the double-quotes when specifying\ninput parameters, so the `--input-parameters` argument would instead\nlook something like this:\n\n`'{\\\"desiredInstanceType\\\":\\\"t2.micro\\\"}'`\n\nAs of RDK v0.17.0, you can also specify `--resource-types ALL` to include all resource types.\n\nNote that you can create rules that use EITHER resource-types OR\nmaximum-frequency, but not both. We have found that rules that try to be\nboth event-triggered as well as periodic wind up being very complicated\nand so we do not recommend it as a best practice.\n\n### Edit Rules Locally\n\nOnce you have created the rule, edit the python file in your rule\ndirectory (in the above example it would be `MyRule/MyRule.py`, but may\nbe deeper into the rule directory tree depending on your chosen Lambda\nruntime) to add whatever logic your Rule requires in the\n`evaluate_compliance` function. You will have access to the CI that was\nsent by Config, as well as any parameters configured for the Config\nRule. Your function should return either a simple compliance status (one\nof `COMPLIANT`, `NON_COMPLIANT`, or `NOT_APPLICABLE`), or if you're\nusing the python or node runtimes you can return a JSON object with\nmultiple evaluation responses that the RDK will send back to AWS Config.\n\nAn example would look like:\n\n```python\nfor sg in response['SecurityGroups']:\n    evaluations.append(\n    {\n        'ComplianceResourceType': 'AWS::EC2::SecurityGroup',\n        'ComplianceResourceId': sg['GroupId'],\n        'ComplianceType': 'COMPLIANT',\n        'Annotation': 'This is an important note.',\n        'OrderingTimestamp': str(datetime.datetime.now())\n    })\nreturn evaluations\n```\n\nThis is necessary for periodic rules that are not triggered by any CI\nchange (which means the CI that is passed in will be null), and also for\nattaching annotations to your evaluation results.\n\nIf you want to see what the JSON structure of a CI looks like for\ncreating your logic, you can use\n\n```bash\nrdk sample-ci \u003cResource Type\u003e\n```\n\nto output a formatted JSON document.\n\n### Write and Run Unit Tests\n\nIf you are writing Config Rules using either of the Python runtimes\nthere will be a `\u003crule name\u003e_test.py` file deployed along with your\nLambda function skeleton. This can be used to write unit tests according\nto the standard Python unittest framework (documented\n[here](https://docs.python.org/3/library/unittest.html)), which can be\nrun using the `test-local` rdk command:\n\n```bash\nrdk test-local MyTestRule\nRunning local test!\nTesting MyTestRule\nLooking for tests in /Users/mborch/Code/rdk-dev/MyTestRule\n\n---------------------------------------------------------------------\n\nRan 0 tests in 0.000s\n\nOK\n\u003cunittest.runner.TextTestResult run=0 errors=0 failures=0\u003e\n```\n\nThe test file includes setup for the MagicMock library that can be used\nto stub boto3 API calls if your rule logic will involve making API calls\nto gather additional information about your AWS environment. For some\ntips on how to do this, check out this blog post:\n[Mock Is Magic](https://sgillies.net/2017/10/19/mock-is-magic.html)\n\n### Modify Rule\n\nIf you need to change the parameters of a Config rule in your working\ndirectory you can use the `modify` command. Any parameters you specify\nwill overwrite existing values, any that you do not specify will not be\nchanged.\n\n```bash\nrdk modify MyRule --runtime python3.12 --maximum-frequency TwentyFour_Hours --input-parameters '{\"desiredInstanceType\":\"t2.micro\"}'\nRunning modify!\nModified Rule 'MyRule'.  Use the `deploy` command to push your changes to AWS.\n```\n\nAgain, on Windows the input parameters would look like:\n\n`'{\\\"desiredInstanceType\\\":\\\"t2.micro\\\"}'`\n\nIt is worth noting that until you actually call the `deploy` command\nyour rule only exists in your working directory, none of the Rule\ncommands discussed thus far actually makes changes to your account.\n\n### Deploy Rule\n\nOnce you have completed your compliance validation code and set your\nRule's configuration, you can deploy the Rule to your account using the\n`deploy` command. This will zip up your code (and the other associated\ncode files, if any) into a deployable package (or run a gradle build if\nyou have selected the java8 runtime or run the Lambda packaging step\nfrom the dotnet CLI if you have selected the dotnetcore1.0 runtime),\ncopy that zip file to S3, and then launch or update a CloudFormation\nstack that defines your Config Rule, Lambda function, and the necessary\npermissions and IAM Roles for it to function. Since CloudFormation does\nnot deeply inspect Lambda code objects in S3 to construct its changeset,\nthe `deploy` command will also directly update the Lambda function for\nany subsequent deployments to make sure code changes are propagated\ncorrectly.\n\n```bash\nrdk deploy MyRule\nRunning deploy!\nZipping MyRule\nUploading MyRule\nCreating CloudFormation Stack for MyRule\nWaiting for CloudFormation stack operation to complete...\n...\nWaiting for CloudFormation stack operation to complete...\nConfig deploy complete.\n```\n\nThe exact output will vary depending on Lambda runtime. You can use the\n`--all` flag to deploy all of the rules in your working directory. If\nyou used the `--generate-lambda-layer` flag in rdk init, use the\n`--generated-lambda-layer` flag for rdk deploy.\n\n### Deploy Organization Rule\n\nYou can also deploy the Rule to your AWS Organization using the\n`deploy-organization` command. For successful evaluation of custom rules\nin child accounts, please make sure you do one of the following:\n\n1. Set ASSUME_ROLE_MODE in Lambda code to True, to get the Lambda to assume the Role attached on the Config Service and confirm that the role trusts the master account where the Lambda function is going to be deployed.\n2. Set ASSUME_ROLE_MODE in Lambda code to True, to get the Lambda to assume a custom role and define an optional parameter with key as ExecutionRoleName and set the value to your custom role name; confirm that the role trusts the master account of the organization where the Lambda function will be deployed.\n\n```bash\nrdk deploy-organization MyRule\nRunning deploy!\nZipping MyRule\nUploading MyRule\nCreating CloudFormation Stack for MyRule\nWaiting for CloudFormation stack operation to complete...\n...\nWaiting for CloudFormation stack operation to complete...\nConfig deploy complete.\n```\n\nThe exact output will vary depending on Lambda runtime. You can use the\n`--all` flag to deploy all of the rules in your working directory. This\ncommand uses `PutOrganizationConfigRule` API for the rule deployment. If\na new account joins an organization, the rule is deployed to that\naccount. When an account leaves an organization, the rule is removed.\nDeployment of existing organizational AWS Config Rules will only be\nretried for 7 hours after an account is added to your organization if a\nrecorder is not available. You are expected to create a recorder if one\ndoesn't exist within 7 hours of adding an account to your organization.\n\n### View Logs For Deployed Rule\n\nOnce the Rule has been deployed to AWS you can get the CloudWatch logs\nassociated with your Lambda function using the `logs` command.\n\n```bash\nrdk logs MyRule -n 5\n2017-11-15 22:59:33 - START RequestId: 96e7639a-ca15-11e7-95a2-b1521890638d Version: $LATEST\n2017-11-15 23:41:13 - REPORT RequestId: 68e0304f-ca1b-11e7-b735-81ebae95acda    Duration: 0.50 ms    Billed Duration: 100 ms     Memory Size: 256 MB     Max Memory Used: 36 MB\n2017-11-15 23:41:13 - END RequestId: 68e0304f-ca1b-11e7-b735-81ebae95acda\n2017-11-15 23:41:13 - Default RDK utility class does not yet support Scheduled Notifications.\n2017-11-15 23:41:13 - START RequestId: 68e0304f-ca1b-11e7-b735-81ebae95acda Version: $LATEST\n```\n\nYou can use the `-n` and `-f` command line flags just like the UNIX\n`tail` command to view a larger number of log events and to continuously\npoll for new events. The latter option can be useful in conjunction with\nmanually initiating Config Evaluations for your deploy Config Rule to\nmake sure it is behaving as expected.\n\n## Running the tests\n\nThe `testing` directory contains scripts and buildspec files that I use\nto run basic functionality tests across a variety of CLI environments\n(currently Ubuntu Linux running Python 3.7/3.8/3.9/3.10, and Windows Server\nrunning Python 3.10). If there is interest I can release a CloudFormation\ntemplate that could be used to build the test environment, let me know\nif this is something you want!\n\n## Advanced Features\n\n### Cross-Account Deployments\n\nFeatures have been added to the RDK to facilitate the cross-account\ndeployment pattern that enterprise customers have standardized for\ncustom Config Rules. A cross-account architecture is one in which the\nLambda functions are deployed to a single central \"Compliance\" account\n(which may be the same as a central \"Security\" account), and the\nConfig Rules are deployed to any number of \"Satellite\" accounts that\nare used by other teams or departments. This gives the compliance team\nconfidence that their rule logic cannot be tampered with and makes it\nmuch easier for them to modify rule logic without having to go through a\ncomplex deployment process to potentially hundreds of AWS accounts. The\ncross-account pattern uses two advanced RDK features:\n\n- `--functions-only` (`-f`) deployment\n- `create-rule-template` command\n\n#### Functions-Only Deployment\n\nBy using the `-f` or `--functions-only` flag on the `deploy` command the\nRDK will deploy only the necessary Lambda Functions, Lambda Execution\nRole, and Lambda Permissions to the account specified by the execution\ncredentials. It accomplishes this by batching up all of the Lambda\nfunction CloudFormation snippets for the selected Rule(s) into a single\ndynamically generated template and deploy that CloudFormation template.\nOne consequence of this is that subsequent deployments that specify a\ndifferent set of rules for the same stack name will update that\nCloudFormation stack, and any Rules that were included in the first\ndeployment but not in the second will be removed. You can use the\n`--stack-name` parameter to override the default CloudFormation stack\nname if you need to manage different subsets of your Lambda Functions\nindependently. The intended usage is to deploy the functions for all of\nthe Config rules in the Security/Compliance account, which can be done\nsimply by using `rdk deploy -f --all` from your working directory.\n\n#### create-rule-template command\n\nThis command generates a CloudFormation template that defines the AWS\nConfig rules themselves, along with the Config Role, Config data bucket,\nConfiguration Recorder, and Delivery channel necessary for the Config\nrules to work in a satellite account. You must specify the file name for\nthe generated template using the `--output-file` or\n`-o` command line flags. The generated template takes a\nsingle parameter of the AccountID of the central compliance account that\ncontains the Lambda functions that will back your custom Config Rules.\nThe generated template can be deployed in the desired satellite accounts\nthrough any of the means that you can deploy any other CloudFormation\ntemplate, including the console, the CLI, as a CodePipeline task, or\nusing StackSets. The `create-rule-template` command takes all of the\nstandard arguments for selecting Rules to include in the generated\ntemplate, including lists of individual Rule names, an `--all` flag, or\nusing the RuleSets feature described below.\n\n```bash\nrdk create-rule-template -o remote-rule-template.json --all\nGenerating CloudFormation template!\nCloudFormation template written to remote-rule-template.json\n```\n\n### Disable the supported resource types check\n\nIt is now possible to define a resource type that is not yet supported\nby rdk. To disable the supported resource check use the optional flag\n'--skip-supported-resource-check' during the create command.\n\n```bash\nrdk create MyRule --runtime python3.12 --resource-types AWS::New::ResourceType --skip-supported-resource-check\n'AWS::New::ResourceType' not found in list of accepted resource types.\nSkip-Supported-Resource-Check Flag set (--skip-supported-resource-check), ignoring missing resource type error.\nRunning create!\nLocal Rule files created.\n```\n\n### Custom Lambda Function Name\n\nAs of version 0.7.14, instead of defaulting the lambda function names to\n`RDK-Rule-Function-\u003cRULE_NAME\u003e` it is possible to customize the name for\nthe Lambda function to any 64 characters string as per Lambda's naming\nstandards using the optional `--custom-lambda-name` flag while\nperforming `rdk create`. This opens up new features like :\n\n1. Longer config rule name.\n2. Custom lambda function naming as per personal or enterprise standards.\n\n```bash\nrdk create MyLongerRuleName --runtime python3.12 --resource-types AWS::EC2::Instance --custom-lambda-name custom-prefix-for-MyLongerRuleName\nRunning create!\nLocal Rule files created.\n```\n\nThe above example would create files with config rule name as\n`MyLongerRuleName` and lambda function with the name\n`custom-prefix-for-MyLongerRuleName` instead of\n`RDK-Rule-Function-MyLongerRuleName`\n\n### RuleSets\n\nNew as of version 0.3.11, it is possible to add RuleSet tags to rules\nthat can be used to deploy and test groups of rules together. Rules can\nbelong to multiple RuleSets, and RuleSet membership is stored only in\nthe parameters.json metadata. The [deploy](docs/commands/deploy.md),\n[create-rule-template](docs/commands/create-rule-template.md), and [test-local](docs/commands/test-local.md)\ncommands are RuleSet-aware such that a RuleSet can be passed in as the\ntarget instead of `--all` or a specific named Rule.\n\nA comma-delimited list of RuleSets can be added to a Rule when you\ncreate it (using the `--rulesets` flag), as part of a `modify` command,\nor using new `ruleset` subcommands to add or remove individual rules\nfrom a RuleSet.\n\nRunning `rdk rulesets list` will display a list of the RuleSets\ncurrently defined across all of the Rules in the working directory\n\n```bash\nrdk rulesets list\nRuleSets:  AnotherRuleSet MyNewSet\n```\n\nNaming a specific RuleSet will list all of the Rules that are part of\nthat RuleSet.\n\n```bash\nrdk rulesets list AnotherRuleSet\nRules in AnotherRuleSet :  RSTest\n```\n\nRules can be added to or removed from RuleSets using the `add` and\n`remove` subcommands:\n\n```bash\nrdk rulesets add MyNewSet RSTest\nRSTest added to RuleSet MyNewSet\n\nrdk rulesets remove AnotherRuleSet RSTest\nRSTest removed from RuleSet AnotherRuleSet\n```\n\nRuleSets are a convenient way to maintain a single repository of Config\nRules that may need to have subsets of them deployed to different\nenvironments. For example your development environment may contain some\nof the Rules that you run in Production but not all of them; RuleSets\ngives you a way to identify and selectively deploy the appropriate Rules\nto each environment.\n\n### Managed Rules\n\nThe RDK is able to deploy AWS Managed Rules.\n\nTo do so, create a rule using `rdk create` and provide a valid\nSourceIdentifier via the `--source-identifier` CLI option. The list of\nManaged Rules can be found\n[here](https://docs.aws.amazon.com/config/latest/developerguide/managed-rules-by-aws-config.html)\n, and note that the Identifier can be obtained by replacing the dashes\nwith underscores and using all capitals (for example, the\n\"guardduty-enabled-centralized\" rule has the SourceIdentifier\n\"GUARDDUTY_ENABLED_CENTRALIZED\"). Just like custom Rules you will need\nto specify source events and/or a maximum evaluation frequency, and also\npass in any Rule parameters. The resulting Rule directory will contain\nonly the parameters.json file, but using `rdk deploy` or\n`rdk create-rule-template` can be used to deploy the Managed Rule like\nany other Custom Rule.\n\n### Deploying Rules Across Multiple Regions\n\nThe RDK is able to run init/deploy/undeploy across multiple regions with\na `rdk -f \u003cregion file\u003e -t \u003cregion set\u003e`\n\nIf no region group is specified, rdk will deploy to the `default` region\nset.\n\nTo create a sample starter region group, run `rdk create-region-set` to\nspecify the filename, add the `-o \u003cregion set output file name\u003e` this\nwill create a region set with the following tests and regions\n`\"default\":[\"us-east-1\",\"us-west-1\",\"eu-north-1\",\"ap-east-1\"],\"aws-cn-region-set\":[\"cn-north-1\",\"cn-northwest-1\"]`\n\n### Using RDK to Generate a Lambda Layer in a region (Python3)\n\nBy default `rdk init --generate-lambda-layer` will generate an rdklib\nlambda layer while running init in whatever region it is run, to force\nre-generation of the layer, run `rdk init --generate-lambda-layer` again\nover a region\n\nTo use this generated lambda layer, add the flag\n`--generated-lambda-layer` when running `rdk deploy`. For example:\n`rdk -f regions.yaml deploy LP3_TestRule_P39_lib --generated-lambda-layer`\n\nIf you created layer with a custom name (by running\n`rdk init --custom-lambda-layer`), add a similar `custom-lambda-layer`\nflag when running deploy.\n\n### Proactive Rules\n\nAs of version `1.0.0`, RDK now supports proactive rule creation. Proactive evaluation mode only applies to CloudFormation template deployment, and does not apply to already-deployed resources. Proactive rules are therefore only evaluated as \"configuration changes\", not periodic rules.\n\nYou can create a proactive rule using `rdk create`'s flag `--evaluation-mode` and specifying an argument as outlined by `rdk create`'s help text. This will set the evaluation mode in the `parameters.json`.\n\nFor more detail on proactive rules, see [this blog post](https://aws.amazon.com/blogs/mt/how-to-use-aws-config-proactive-rules-and-aws-cloudformation-hooks-to-prevent-creation-of-non-complaint-cloud-resources/). Note that the presence of a proactive rule does NOT automatically block misconfigured resources. You need to configure [CloudFormation Hooks](https://docs.aws.amazon.com/cloudformation-cli/latest/hooks-userguide/what-is-cloudformation-hooks.html) in order to use the Config rule to assess (and potentially block) the CFT deployment.\n\nNote that proactive rules are **NOT** supported for Organization Rules, as of May 2024. This is a limitation of the Config service. Proactive evaluation mode is supported for single-account custom and managed rules.\n\n## Support \u0026 Feedback\n\nThis project is maintained by AWS Solution Architects and Consultants.\nIt is not part of an AWS service and support is provided best-effort by\nthe maintainers. To post feedback, submit feature ideas, or report bugs,\nplease use the [Issues section](https://github.com/awslabs/aws-config-rdk/issues) of this repo.\n\n## Contributing\n\nEmail us at \u003crdk-maintainers@amazon.com\u003e if you have any questions. We\nare happy to help and discuss.\n\n## Contacts\n\n- **Benjamin Morris** - [bmorrissirromb](https://github.com/bmorrissirromb) - _current lead maintainer_\n- **Nima Fotouhi** - [nimaft](https://github.com/nimaft) - _current maintainer_\n\n## Past Contributors\n\n- **Michael Borchert** - _Original Python version_\n- **Jonathan Rault** - _Original Design, testing, feedback_\n- **Greg Kim and Chris Gutierrez** - _Initial work and CI definitions_\n- **Henry Huang** - _Original CFN templates and other code_\n- **Santosh Kumar** - _maintainer_\n- **Jose Obando** - _maintainer_\n- **Jarrett Andrulis** - [jarrettandrulis](https://github.com/jarrettandrulis) - _maintainer_\n- **Sandeep Batchu** - [batchus](https://github.com/batchus) - _maintainer_\n- **Mark Beacom** - [mbeacom](https://github.com/mbeacom) - _maintainer_\n- **Ricky Chau** - [rickychau2780](https://github.com/rickychau2780) - _maintainer_\n- **Julio Delgado Jr** - [tekdj7](https://github.com/tekdj7) - _maintainer_\n- **Carlo DePaolis** - [depaolism](https://github.com/depaolism) - _current maintainer_\n\n## License\n\nThis project is licensed under the Apache 2.0 License\n\n## Acknowledgments\n\n- the boto3 team makes all of this magic possible.\n\n## Link\n\n- to view example of rules built with the RDK: [https://github.com/awslabs/aws-config-rules/tree/master/python](https://github.com/awslabs/aws-config-rules/tree/master/python)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fawslabs%2Faws-config-rdk","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fawslabs%2Faws-config-rdk","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fawslabs%2Faws-config-rdk/lists"}