AWS News Blog

AWS Config Rules – Now Available in US East (Northern Virginia)

We announced AWS Config Rules (Dynamic Compliance Checking for Cloud Resources) at AWS re:Invent and made a preview available to interested customers.

As I noted at the time, you can use these rules to verify that existing and newly launched AWS resources conform to your organization’s security guidelines and best practices without having to spend time manually inspecting them. Instead, you define rules (AWS Lambda functions) that are run when resources are created or changed. The rule has access to the Configuration Item associated with the resource, and can also make calls to other AWS API functions as needed.

Available Now
Today we are making Config Rules accessible to all AWS customers, with initial availability in the US East (N. Virginia) region and the ability to create up to 25 Config Rules per account.

We added some important features during the preview:

  • Support for additional IAM and EC2 resource types. You can now write rules that process IAM Users, Groups, Roles, including customer-managed policies. You can also write rules that process EC2 Dedicated Hosts.
  • Lambda Blueprints to help create custom rules. You now have access to blueprints for periodic rules and for rules that run in response to changes.
  • CloudFormation Support for Config and for Config Rules. You can now automate the setup of AWS Config for new accounts, and you can automate the creation and configuration of the Config Rules.

Several AWS partners are already making great use of Config Rules in production. For example, Alert Logic, CloudHealth Technologies and Trend Micro Deep Security are using Config Rules as integral parts of their respective flagship products.

Creating a Custom Rule
I will create a rule that inspects an IAM Policy named DBSuperUserPolicy. I want to make sure that the policy has only one user, DBSuperUser, attached to it. If this is the case, the Policy is compliant; otherwise, it is not.

I start by creating a Lambda function using one of the new blueprints. I open up the Lambda Console, click on Create a Lambda function, and locate the blueprint that I want to use. I enter “config” in the search box:

I want my rule to run every time the IAM Policy is changed, so I select the first blueprint, config-rule-change-triggered. Then I enter a name and description for the function:

The code provided in the blueprint includes a function named evaluateCompliance. This function is the heart of the rule; it is activated on each configuration change and always returns one of the following strings:

  • NOT_APPLICABLE -The rule does not apply to the resource or the resource type that it was given.
  • COMPLIANT – The rule is relevant to the resource, and the resource is configured in a compliant way.
  • NON_COMPLIANT – The rule is relevant to the resource, and the resource is not configured in a compliant way.

I replace the default implementation of the function with my own. It looks like this:

function evaluateCompliance(configurationItem, ruleParameters, context)
  if ((configurationItem.resourceType !== 'AWS::IAM::Policy') || 
      (configurationItem.resourceName !== 'DBSuperUserPolicy'))
    return 'NOT_APPLICABLE';
  if (configurationItem.relationships[0].resourceName === ruleParameters.attachedIAMUser)
    if (configurationItem.relationships[1])
      return 'NON_COMPLIANT';
      return 'COMPLIANT';
    return 'NON_COMPLIANT';

This rule is simple and powerful! Let’s go through it, line-by-line.

  • Lines 3 and 4 check to see if the rule was invoked on an IAM Policy named DBSuperUserPolicy; line 5 returns NOT_APPLICABLE if this is not the case.
  • Line 6 verifies that there is an IAM User attached to the Policy; line 14 returns NON_COMPLIANT if this is not the case.
  • Line 8 verifies that there is no more than one User attached to the Policy; line 9 returns NON_COMPLIANT if this is not the case.
  • Line 11 returns COMPLIANT to indicate that the Policy has exactly one IAM User attached, and is therefore compliant.

As you can see, this simple, 15-line function is all that you need to enforce an organization-wide policy across all of your AWS resources.

I also need to create an IAM Role so that the function can send the results to AWS Config:

If the function needs to access other AWS resources or APIs, I would amend the policy document accordingly. I select the role, confirm that I want to create the function, and I am already halfway there:

With the function in place, I need to arrange for Config Rules to call it as needed. I visit the Config Rules Console and click on Add Rule:

At this point I can choose one of the seven AWS managed rules, or I can click on Add custom rule (sounds good to me):

Now I name my rule, point it at my Lambda function (via its ARN), and indicate that I want it to be run when the configuration of an IAM Policy changes:

The rule will be evaluated within a few minutes; I can verify that my function has been invoked by taking a peek at the function’s Monitoring tab in the Lambda console:

From looking at these metrics I can see that the function has been run 7 times (I have that number of customer-managed IAM Policies), that each invocation lasts for less than 1 second, and that the invocations are not raising any errors. So far, so good!

Exercising the Rule
With the function running and attached to the rule, the next step is to make sure that it performs as expected. I create an IAM Policy named DBSuperUserUsagePolicy and attach user jeff to it (this is not in compliance with my rule, and it should be marked as such):

After allowing some time for the rule to be run, I return to the Config Rules console and I can see that there’s an issue:

I can learn more with a click:

If I don’t recall making the change or don’t know who did it (I did, but I was tired and clearly made a mistake), I can click on the Config timeline to learn more:

After some investigation I realize that I was supposed to use DBSuperUser, and update my Policy accordingly:

I wait a few minutes and check the rule details again. I am good to go – my resource is now compliant with my policy:

My change is reflected in the timeline (as you can see, I actually do spend some time away from the keyboard; I created the policy last night and edited it this morning):

Finally, I can see that my Lambda function was invoked after I updated my policy:

CloudFormation Support
You can now use CloudFormation templates to create your Config Rules and your Lambda functions. Here’s how you would create a rule that references a function called VolumeAutoEnableIOComplianceCheck:

"ConfigRuleForVolumeAutoEnableIO": {
      "Type": "AWS::Config::ConfigRule",
      "Properties": {
        "ConfigRuleName": "ConfigRuleForVolumeAutoEnableIO",
        "Scope": {
          "ComplianceResourceId": {"Ref": "Ec2Volume"},
          "ComplianceResourceTypes": ["AWS::EC2::Volume"]
        "Source": {
          "Owner": "CUSTOM_LAMBDA",
          "SourceDetails": [{
              "EventSource": "aws.config",
              "MessageType": "ConfigurationItemChangeNotification"
          "SourceIdentifier": {"Fn::GetAtt": ["VolumeAutoEnableIOComplianceCheck", "Arn"]}
      "DependsOn": "ConfigPermissionToCallLambda"

Partner Support
As I mentioned earlier, several AWS partners are already making great use of this feature. Here’s some more information on their offerings:

Alert Logic Cloud Insight allows customers to use AWS Config to configure checks for additional custom vulnerabilities. Learn more on the Alert Logic Partner Page.

CloudHealth Technologies stores AWS infrastructure configuration history and supports searching of changes by group, access to historical changes, and a history of asset configuration. Learn more on the CloudHealth Technologies Partner Page.

Trend Micro provides a comprehensive set of security controls. Learn more on the Trend Micro Partner Page.

Availability and Pricing
Config Rules is now available in the US East (N. Virginia) region and you can start using it today. Now that it is generally available, you will be charged for usage as described on the Config Rules Pricing page.


Jeff Barr

Jeff Barr

Jeff Barr is Chief Evangelist for AWS. He started this blog in 2004 and has been writing posts just about non-stop ever since.