Most organizations have compliance requirements that go beyond what out-of-the-box cloud tooling provides. AWS Config addresses this by offering several levels of customization—from tweaking predefined managed rules in the console, to defining infrastructure-as-code stacks with CloudFormation, to writing fully custom rules driven by AWS Lambda. This tutorial walks through all three approaches, with a focus on the more advanced techniques.
Three Approaches to AWS Config Rule Customization
Before diving into the details, it helps to understand the three available paths:
- Console-based editing of managed rules — Rename rules, adjust trigger frequency, narrow the scope of configuration changes, and modify rule parameters directly in the AWS Config console. This is the quickest approach but offers the least flexibility.
- CloudFormation template customization — Associate AWS Config managed rules with CloudFormation stacks to deploy and manage compliance checks as infrastructure as code. Ideal for repeatable environments and CI/CD pipelines.
- Custom rules backed by AWS Lambda — Write a Lambda function containing the evaluation logic, then bind it to a new custom rule in AWS Config. This gives you full control over what constitutes compliance for any resource type or configuration state.
The console-based approach is straightforward and well-documented in the AWS console itself. The sections below cover approaches two and three in depth.
Customize AWS Config Rules with CloudFormation
AWS CloudFormation lets you model and provision AWS infrastructure using YAML or JSON templates. A template can define individual resources or a collection of related resources called a stack, which you create, update, and delete as a single unit. Embedding AWS Config managed rules inside a CloudFormation stack ensures that compliance checks are provisioned alongside the resources they govern.
Selecting a Managed Rule for CloudFormation Deployment
Navigate to the list of AWS Config managed rules in the console and identify the rule you want to apply. As a concrete example, consider the ec2-volume-inuse-check rule, which verifies that Amazon Elastic Block Store (EBS) volumes are attached to EC2 instances. This rule fires whenever a configuration is created or changed. It also supports a deleteOnTermination parameter that flags whether EBS volumes should be deleted when the associated EC2 instance is terminated—a useful cost-control measure.
At the bottom of the rule description page, you have two options:
- View — Downloads the CloudFormation template so you can inspect and edit it before deployment. You can then upload the template to an Amazon S3 bucket and launch it later from the CloudFormation console.
- Launch Stack — Opens the CloudFormation console directly with the template pre-loaded, prompting you to supply stack-specific details immediately.
Launching and Configuring the Stack
If you choose Launch Stack, the CloudFormation wizard walks you through naming the stack, setting rule parameters (for example, toggling deleteOnTermination to true or false), adding optional tags, and reviewing the configuration before creation. Once created, the customized managed rule appears in the AWS Config Rules page and begins evaluating resources immediately.
Using CloudFormation Stacks with AWS CodePipeline
A compelling use case for embedding Config rules in CloudFormation is CI/CD pipelines built on AWS CodePipeline. CodePipeline is a managed service for modeling and automating software release stages. Config can track changes to the pipeline itself—such as action definitions or component locations—while CloudFormation stacks that include Config managed rules can provision the hosting environment for each build in a repeatable, compliant way.
For example, a CodePipeline deploy stage can invoke a CloudFormation template that spins up compute, storage, and load-balancing resources, with embedded Config rules that immediately begin monitoring the new environment. When the stack is torn down, the Config rules are removed along with it, keeping your rules list clean.
Create Custom AWS Config Rules with AWS Lambda
AWS Config managed rules cover many common scenarios, but custom business logic often requires rules that do not exist in the managed catalog. For these cases, you can write an AWS Lambda function containing the compliance evaluation logic and associate it with a new custom rule in AWS Config.
It is important to understand the division of responsibility here: the Lambda function is not the rule itself—it is the logic that determines compliance. The rule in AWS Config defines the scope, trigger conditions, and parameters. The function performs the actual evaluation and reports results back to Config using the Config API.
Step 1: Create the Lambda Function
Sign in to the AWS Lambda console and confirm that your chosen region supports AWS Config custom rules. When creating the function, you can start from a blueprint such as config-rule-change-triggered, which provides a skeleton suited to configuration-change events. Key decisions at this stage:
- Name and runtime — Choose a descriptive name and select your preferred runtime (for example, Python or Node.js).
- Handler — Specify the entry-point handler that AWS Lambda will invoke.
- Execution role — Attach an IAM role that grants the function permission to call AWS Config APIs, specifically
config:PutEvaluations, as well as read permissions on the resources it needs to evaluate. - Permission policy template — Use the AWS Config Rules permission policy template available in the console to ensure the function has the correct permissions.
There is no need to configure Lambda triggers manually—AWS Config will invoke the function based on the trigger type defined in the custom rule. After creating the function, test it by running a configured test event in the Lambda console to verify it returns evaluations in the correct format before wiring it to a Config rule.
Step 2: Create the Custom Rule in AWS Config
Open the AWS Config console, go to the Rules page, and select Add rule, then Add custom rule. Fill in the following fields:
- Rule name and description — Use a name that clearly reflects what the rule evaluates.
- AWS Lambda function ARN — Paste the Amazon Resource Name of the Lambda function created in Step 1. This is the critical link between the rule and its evaluation logic. Ensure the function is in the same AWS region as the Config rule.
- Trigger type — Choose Configuration changes (fires when a resource configuration changes), Periodic (fires on a schedule), or both.
- Trigger scope and resource types — Narrow the rule to specific resource types or tags so Config only invokes the Lambda function when relevant resources change.
- Rule parameters — Define key-value pairs that the Lambda function reads at runtime to adjust its behavior without redeploying code. For example, a function that checks EC2 instance types might accept a parameter named
desiredInstanceTypewith a value such ast3.medium.
Save the rule. It will appear on the Rules page, and AWS Config will begin invoking the Lambda function according to the defined trigger conditions. Evaluation results—COMPLIANT, NON_COMPLIANT, or NOT_APPLICABLE—will appear in the Config console alongside the rule.
Choosing the Right Approach
| Approach | Best for | Skill required |
|---|---|---|
| Console editing of managed rules | Quick adjustments to existing AWS-managed checks | Low |
| CloudFormation template customization | Repeatable, stack-based deployments; CI/CD pipelines | Medium |
| Custom rules with Lambda | Organization-specific compliance logic not covered by managed rules | High |
For most teams, a combination of all three approaches makes sense: managed rules handle baseline AWS best practices, CloudFormation integration keeps compliance checks tied to infrastructure lifecycle, and Lambda-backed custom rules encode the business-specific requirements that no managed rule can anticipate.
Summary
AWS Config is a flexible compliance monitoring service that goes well beyond its built-in managed rules. By combining CloudFormation-based deployment with Lambda-driven custom rules, DevOps teams can build a compliance framework that evolves alongside their infrastructure, enforces organization-specific policies, and integrates naturally into automated release pipelines.