Skip to main content

AWS Config

AWS Config is a service that enables you to assess, audit, and evaluate the configurations of your AWS resources. Config continuously monitors and records your AWS resource configurations and allows you to automate the evaluation of recorded configurations against desired configurations.

Overview​

With AWS Config, you can do the following:

  • Evaluate your AWS resource configurations for desired settings.
  • Get a snapshot of the current configurations of the supported resources that are associated with your AWS account.
  • Retrieve configurations of one or more resources that exist in your account.
  • Retrieve historical configurations of one or more resources.
  • Receive a notification whenever a resource is created, modified, or deleted.
  • View relationships between resources.

AWS Config continuously detects when any resource of a supported type is created, changed, or deleted. AWS Config records these events as configuration items. We can customize AWS Config to record changes for all supported types of resources or for only those types that are relevant to us. AWS Config sends notifications and updated configuration states through the delivery channel. The delivery channel has the following options:

  • The Amazon S3 bucket to which AWS Config sends configuration snapshots and configuration history files.
  • How often AWS Config delivers configuration snapshots to your Amazon S3 bucket.
  • The Amazon SNS topic to which AWS Config sends notifications about configuration changes.

AWS Config uses config rules to evaluate the configuration settings of our AWS resources. Each rule represents the ideal configuration settings. AWS Config continuously tracks the configuration changes and checks whether these changes violate any of the conditions in the rules. If a resource violates a rule, AWS Config flags the resource and the rule as noncompliant. AWS Config provides AWS managed rules, which are predefined, customizable rules that AWS Config uses to evaluate whether AWS resources comply with common best practices. We can also develop custom rules and add them to AWS Config.

Tagging​

The main purpose of using AWS Config is to be able to audit and manage the tagging across our infrastructure.

An AWS managed rule, required-tags, checks if the resources have the tags we specify. The problem with this rule is the supported resource types for it. Currently, our infrastructure relies mainly on SQS and Lambdas and these are not supported. So we will need to create a custom rule for this.

Tagging custom rule POC​

Goal: Create a custom rule to identify SQS which still require tagging.

The first step is to create a lambda function that contains the logic to evaluate if the AWS resources have the required tags.

As an example this lambda was created https://eu-west-1.console.aws.amazon.com/lambda/home?region=eu-west-1#/functions/aws-config-test?newFunction=true&tab=code. It is based on the blueprint config-rule-change-triggered.

This lambda is triggered by configuration changes to AWS resources and receives the following event:

{
    version: '1.0',
    invokingEvent: '{}',
    ruleParameters: '{"Name":"","Project":"","Description":"","Owner":"","Terraform":"","Version":""}',
    resultToken: 'eyJlbmNyeXB0ZWRE',
    eventLeftScope: false,
    executionRoleArn: 'arn:aws:iam::979821157320:role/aws-service-role/config.amazonaws.com/AWSServiceRoleForConfig',
    configRuleArn: 'arn:aws:config:eu-west-1:979821157320:config-rule/config-rule-2ozbuq',
    configRuleName: 'required-tags-sqs',
    configRuleId: 'config-rule-2ozbuq',
    accountId: '979821157320'
}

ruleParameters contains the list of the required tags.

The information we need about the AWS resource being modified is available in the invokingEvent field. This is how this field looks like:

{
    "configurationItemDiff": {
        "changedProperties": {
            "Tags.1": {
                "previousValue": null,
                "updatedValue": "Newstore poc",
                "changeType": "CREATE"
            },
            "SupplementaryConfiguration.Tags.1": {
                "previousValue": null,
                "updatedValue": "Newstore poc",
                "changeType": "CREATE"
            }
        },
        "changeType": "UPDATE"
    },
    "configurationItem": {
        "relatedEvents": [],
        "relationships": [],
        "configuration": {},
        "supplementaryConfiguration": {
            "Tags": {
                "Client": "NewStore",
                "Name": "Newstore poc"
            }
        },
        "tags": {
            "Client": "NewStore",
            "Name": "Newstore poc"
        },
        "configurationItemVersion": "1.3",
        "configurationItemCaptureTime": "2021-05-03T11:55:06.954Z",
        "configurationStateId": 1620042906954,
        "awsAccountId": "979821157320",
        "configurationItemStatus": "OK",
        "resourceType": "AWS::SQS::Queue",
        "resourceId": "https://sqs.eu-west-1.amazonaws.com/979821157320/newstore-poc-queue.fifo",
        "resourceName": "newstore-poc-queue.fifo",
        "ARN": "arn:aws:sqs:eu-west-1:979821157320:newstore-poc-queue.fifo",
        "awsRegion": "eu-west-1",
        "availabilityZone": "Not Applicable",
        "configurationStateMd5Hash": "",
        "resourceCreationTime": "2021-02-10T12:17:43.000Z"
    },
    "notificationCreationTime": "2021-05-03T11:55:08.356Z",
    "messageType": "ConfigurationItemChangeNotification",
    "recordVersion": "1.3"
}

The lambda only needs to check the resourceType and the tags fields on the configurationItem.

In the example code, it is checking the tags only for AWS::SQS::Queue but we could create a lambda that takes into account all the resources types we have in our infrastructure.

Once the lambda is created, we need to create the rule. We have the following options.

Trigger type:

  • Configuration changes: AWS Config invokes your Lambda function when it detects a configuration change. In this case, we need to select the scope of changes.
    • All changes: When any resource recorded by AWS Config is created, changed or deleted.
    • Resources: When any resource that matches the specified type, or the type plus identifier, is created, changed or deleted.
    • Tags: When any resource with the specified tag is created, changed or deleted.
  • Periodic: AWS Config invokes your Lambda function at the frequency that we choose.

Parameters:

Specify any parameters used in the lambda.

For this example, the rule is set up to be evaluated when a configuration change is made in a SQS. https://eu-west-1.console.aws.amazon.com/config/home?region=eu-west-1#/rules/edit?configRuleName=required-tags-sqs

Although for this POC the configuration has been made manually, all of this can be made using Terraform.

Tagging custom periodic rule POC​

Goal: Create a custom periodic rule to identify SQS which still require tagging.

In the same way as for non-periodic rules, the first step is to create a lambda function that contains the logic to evaluate if the AWS resources have the required tags.

As an example this lambda was created https://eu-west-1.console.aws.amazon.com/lambda/home?region=eu-west-1#/functions/aws-config-periodic-test?tab=code. It is based on the blueprint config-rule-periodic.

This lambda is triggered periodically and receives the following event:

{
  version: '1.0',
  invokingEvent: '{
        "awsAccountId":"979821157320",
        "notificationCreationTime":"2021-05-10T07:31:56.865Z",
        "messageType":"ScheduledNotification",
        "recordVersion":"1.0"
  }',
  ruleParameters: '{"applicableResourceType":"AWS::SQS::Queue"}',
  resultToken: 'eyJlbmNyeXB0ZWREYXRhIjpbLTMyLDMxLC0xMjgs',
  eventLeftScope: false,
  executionRoleArn: 'arn:aws:iam::979821157320:role/aws-service-role/config.amazonaws.com/AWSServiceRoleForConfig',
  configRuleArn: 'arn:aws:config:eu-west-1:979821157320:config-rule/config-rule-0scev4',
  configRuleName: 'periodic-test',
  configRuleId: 'config-rule-0scev4',
  accountId: '979821157320'
}

In this case, it’s necessary to use the AWS Config API to get the resources to evaluate, the information needed is not in the event in this type of rule.

Once the lambda is created, we need to create the rule choosing the desired frequency.

Resources​