AWS Config is service for auditing and evaluating the configurations of AWS resources or services. In the first article we introduced AWS Config and created some database instances to evaluate with AWS Config. In this article we shall add AWS Config rules and evaluate the databases, which include RDS, DynamoDB and Redshift.

This article has the following sections.

Adding AWS Config Rules

Adding and Evaluating AWS Config Rules for DynamoDB

Adding and Evaluating AWS Config Rules for Databases on RDS

Adding and Evaluating AWS Config Rules for Redshift

Finding and Listing Resources that are managed by AWS Config

Adding AWS Config Rules

Next, add AWS Config rules for the databases AWS resources created. Select Rules in the AWS Config Console and click on Add rule as shown in Figure 1.

Figure 1. Add rule

AWS Config provides 35 built-in config rules to select from, as shown in Figure 2.

Figure 2. Built-In AWS Config Rules

Adding and Evaluating AWS Config Rules for DynamoDB

We’ve already created a DynamoDB table. In this section we shall add an AWS Config rule for DynamoDB. AWS Config provides the managed config rule discussed in Table 1.

Table 1. Managed Config Rules for DynamoDB

Config Rule




Evaluates whether the provisioned DynamoDB throughput is exceeding a configured threshold. By default the threshold is 80% of the account limit. The DynamoDB account limits are different for different AWS regions.

accountRCUThresholdPercentage:Percentage of read-capacity units for an AWS account. The default is 80%. When the threshold is reached the Config rule is considered as noncompliant


accountWCUThreshold: Percentage of write-capacity units for an AWS account. The default is 80%. When the threshold is reached the Config rule is considered as noncompliant.


To add the DynamoDB rule, navigate to the AWS Config Console and select Rules. In Add rule search for “DynamoDB”, which should list the dynamodb-throughput-limit-check rule. Click on the dynamodb-throughput-limit-check rule as shown in Figure 3.

Figure 3. Adding the dynamodb-throughput-limit-check Rule

The Add AWS managed rule wizard gets started, as shown in Figure 4. All the settings for the managed rule are preconfigured. The Frequency may be modified as shown by the 1 hour setting in Figure 4.

Figure 4. Add AWS Managed Rule

Scroll down for the rule parameters discussed in Table 1. The rule parameters are preconfigured at 80%, as shown in Figure 5. Click on Save.

Figure 5. AWS Managed Rule Parameters

The dynamodb-throughput-limit-check managed rule gets added to AWS Config Console, as shown in Figure 6. Initially the Compliance is listed as “Evaluating”. It could take a few minutes to evaluate compliance.

Figure 6. AWS Managed Rule dynamodb-throughput-limit-check

Two CloudWatch alarms get created for the DynamoDB table: Write Capacity and Read Capacity, as shown in Figure 7.

Figure 7. CloudWatch Alarms for DynamoDB Table

Adding and Evaluating AWS Config Rules for Databases on RDS

AWS Config provides managed rules for RDS databases, as indicated in Table 2.

Table 2. Managed Config Rules for RDS Databases

Managed Rule




Evaluates whether high availability is provisioned on an RDS DB instance. Does not evaluate Aurora databases, which are by design highly available. High availability is configured by setting   Multi-AZ to Yes. Not all database engines and not all database engine editions and deployments support high availability. As an example, Oracle Database 11g does not support high availability but Oracle Database 12c does.



Evaluates whether storage encryption is enabled.

kmsKeyId: KMS Key Id or ARN used to encrypt database storage.


Evaluates whether backup is enabled on the RDS DB instances. All the parameters are optional.

backupRetentionPeriod; Retention period for storing backups.


preferredBackupWindow: Time range in which backups are created.


checkReadReplicas: Evaluates whether backups are enabled for read replicas


Evaluates whether a resource (RDSCluster, EC2 instance, EBS volume, S3 bucket) has a CloudWatch alarm for a specified metric

metricName: Metric associated with a CloudWatch alarm


To configure AWS Config managed rules for RDS DB instances, search for “RDS” in Rules>Add Rule in the AWS Config Console. The four Config rules discussed in Table 2 get listed, as shown in Figure 8. The managed rule cloudwatch-alarm-resource-check is not for an RDS instance but may be used with an RDS cluster. We shall discuss the cloudwatch-alarm-resource-check managed rule with an Aurora DB cluster.

Figure 8. AWS Config Rules for RDS

Add each of the four rules discussed in Table 2. To add a rule, click on the rule. Start by adding db-instance-backup-enabled for which click on the db-instance-backup-enabled rule as shown in Figure 9.

Figure 9. Adding the db-instance-backup-enabled Rule

The Add AWS managed rule wizard gets started, as shown in Figure 10.

Figure 10. Add AWS Managed Rule

The Rule parameters Value may be kept blank, as these are optional. Scroll down and click on Save as shown in Figure 11.


Figure 11. Rule Parameters for db-instance-backup-enabled are optional

Similarly add the other threemanaged rules for RDS. For the cloudwatch-alarm-resource-check managed rule specify Rule parameter resourceType to AWS::RDS::DBCluster and rule parameter metricName to CPUUtilization as shown in Figure 12. Click on Save.

Figure 12. Adding cloudwatch-alarm-resource-check Managed Rule

The managed rules added take a while to audit compliance of the AWS resources and are listed with Compliance status as “Evaluating”, as shown in Figure 13.

Figure 13. Managed Rules with Compliance status as Evaluating

When a managed rule evaluation completes and all the AWS resources configured with the managed rule are compliant, the Compliance status becomes “Compliant”, as shown for the db-instance-backup-enabled managed rule in Figure 14.

Figure 14. Managed Rule db-instance-backup-enabled Compliant

If a managed rule is not compliant for some AWS resources the Compliance status gets listed as noncompliant resource(s ) and includes the number of resources that are noncompliant, as shown in Figure 15. The number of resources is indicated only for the noncompliant AWS resources, not the compliant ones.

Figure 15. For the rds-multi-az-support Managed Rule 2 noncompliant resources are indicated

The Compliance status of an RDS database or any other AWS database does not become available while the database is getting created. If the status of an RDS database is “Creating”, as shown in Figure 16, the Compliance status would be “Evaluating”.

Figure 16. RDS Database Status is “Creating” , which implies Compliance is “Evaluating”

When an RDS DB instance is backing-up, as shown in Figure 17, the Compliance status is “available” because the database has already been created.

Figure 17. RDS DB Status “backing-up”

Click on a Rule name link to find the AWS resources that are monitored by the rule and the Compliance status of each of the resources. As an example, the db-instance-backup-enabled managed rule lists two RDS DB instances as “Compliant” in Figure 18.

Figure 18. The db-instance-backup-enabled Managed Rule lists two RDS DBs as “Compliant”

The rds-storage-encrypted managed rule lists two RDS DB instances as “Noncompliant”, as shown in Figure 19.

Figure 19. The rds-storage-encrypted Managed Rule lists two RDS DB instances as “Noncompliant”

A managed rule could have some of the AWS resources “Compliant” while some other resources are “Noncompliant”. As an example, the rds-multi-az-support managed rule has two RDS DB instances “Compliant” and four RDS DB instances “Noncompliant”, as shown in Figure 20.

Figure 20. Some RDS DB Instances Compliant and some Noncompliant for Managed Rule rds-multi-az-support

While a configuration that is monitored by a managed rule is getting applied and not yet complete its compliance status is Noncompliant. In Figure 21, the RDS DB instance for an Oracle EE Engine based Oracle Database 12c is modifying, as indicated by the “Applying modifications to convert to a Multi-AZ DB Instance” Event.

Figure 21. Applying modifications to convert to a Multi-AZ DB Instance

The managed rule rds-multi-az-support monitors the Multi AZ support. The Multi AZ status for the RDS DB instance is “No”, as shown in Figure 22. The Maintenance Details lists Pending Modifications of Multi-AZ: Yes.

Figure 22. Pending Modifications Multi-AZ :Yes

The rds-storage-encrypted Managed Rule is listed as “Noncompliant” for two RDS DB instances in Figure 29. To make an RDS DB instance Compliant with managed rule rds-storage-encrypted the Enable Encryption must be set to Yes, as shown in Figure 23.

Figure 23. Setting Enable Encryption to Yes

If the Compliance status cannot be determined because no result is available the status is listed as “No results available”, as for the cloudwatch-alarm-resource-check managed rule in Figure 24.

Figure 24. Compliance Status for cloudwatch-alarm-resource-check is: No results available

Account limits for RDS also limit the configurations that may be used.

Adding and Evaluating AWS Config Rules for Redshift

AWS Config provides the managed rules for Redshift discussed in Table 3.

Table 3. Managed Config Rules for Redshift

Managed Rule


Rule Parameters


Evaluates whether a Redshift Cluster has the specified configuration settings. Three configurations may be evaluated.

clusterDbEncrypted: Whether database encryption is enabled.


node Types: Whether a specific node type is used.


loggingEnabled: Whether audit logging is enabled.



Evaluates whether a Redshift Cluster has the specified maintenance settings. Three configurations may be evaluated.

allowVersionUpgrade: Whether version upgrade is enabled. Default value is “true”.


preferredMaintenanceWindow: The scheduled maintenance window. Optional parameter.


automatedSnapshotRetentionPeriod: Number of days to retain automated snapshots. Default value is 1, which indicates 1 day.


To add Config rules for Redshift, search for “Redshift” in AWS Config>Rules>Add Rule as shown in Figure 25. The two managed rules discussed in Table 3 get listed. Click on a managed rule to add the rule.

Figure 25. Managed Rules for Redshift

The default configurations for the three rule parameters are pre-specified, as shown in Figure 26. Click on Save to add the managed rule.

Figure 26. Default Rule Parameters

The redshift-cluster-maintenancesettings-check is “Compliant” and the redshift-cluster-configuration-check is “Noncompliant”, as shown in Figure 27.

Figure 27. Compliance for the Managed Rules for Redshift gets listed: One Compliant and One Noncompliant

All the rule parameters values must be as specified in the managed rule for the managed rule to be compliant. The redshift-cluster-configuration-check is Noncompliant because, while two of the rule parameters are compliant, one is noncompliant. The Node Type is dc1.large, as shown in Figure 39, which is the same as specified in the rule parameter nodeTypes (true). The Encrypted property is Yes, which is also in compliance with the clusterDbEncrypted rule parameter value of “true”. The rule parameter loggingEnabled is set to “true” while Audit Logging Enabled is No, as shown in Redshift Console in Figure 28.

Figure 28. Redshift Cluster Properties

To make the managed rule redshift-cluster-configuration-check compliant, set the loggingEnabled rule parameter to false as shown in Figure 29.

Figure 29. Modifying Managed Rule loggingEnabled to “false”

After modifying the rule parameter value, re-evaluate managed rule compliance. To re-evaluate compliance click on Re-evaluate as shown in Figure 30. The Compliance status should become “Compliant”, also shown in Figure 30.

Figure 30. Re-Evaluating Compliance

The Compliance column value for redshift-cluster-configuration-check managed rule in the Rules table also becomes Compliant, as shown in Figure 31.

Figure 31. Compliance for redshift-cluster-configuration-check managed rule is “Compliant”

The account limits for Redshift limit the configurations that be applied. It may need to be determined whether a managed rule has been evaluated since being modified or when a managed rule was last evaluated. The last successful invocation and evaluation for a managed rule may be found from the managed rule detail page, as shown for rds-multi-az-support in Figure 32.

Figure 32. Finding Last Successful Invocation and Evaluation

Finding and Listing Resources that are Managed by AWS Config

AWS resources that are being monitored for managed rule compliance may be found by Resource Type and by Tag/s on resources in the Resources Inventory. Select the resources in the Resources drop-down as shown in Figure 33.

Figure 33. Selecting Resource Types Monitored by AWS Config

Click on Look Up to list the resources as shown in Figure 34.

Figure 34. Look up

The AWS resources get listed, as shown in Figure 35.

Figure 35 Listing Resources Monitored by AWS Config

Alternatively, tags on AWS resources may be used to find resources. As an example, click on Tags to add tag/s to a MySQL Database RDS DB instance, as shown in Figure 36.

Figure 36. RDS>Tags

In the Tags table click on Add/Edit Tags as shown in Figure 37.

Figure 37. Add/Edit Tags

Add a Key/Value for a tag and click on Save Tags as shown in Figure 38.

Figure 38. Adding a Tag

The tag rds-engine-type with value mysql gets added, as shown in Figure 39.

Figure 39. Tag rds-engine-type/mysql

In Resource Inventory specify the rds-engine-type tag and click on Look up to list the RDS DB instance as shown in Figure 40.

Figure 40. Finding RDS DB Instance by Tag


In this two-article series, we discussed using AWS Config to monitor and evaluate compliance for configurations on AWS databases, which include RDS DB instances and Aurora DB Cluster, DynamoDB, and Redshift. Using managed Config rules to monitor compliance of configurations on AWS databases is a coding best practice.