AWS Cloud Operations Blog

Leveraging custom AWS Config rules to optimize cost saving on AWS

AWS Config assesses, audits, and evaluates the configurations and relationships of your resources in your AWS account. Why might we want to use this service for cost optimization? Well consider a scenario where we can be alerted if a specific Amazon Relational Database Service (Amazon RDS) instance is deployed in the account. If a larger instance type than required is used, it has potential to incur unexpected costs for the given account.

This blog post demonstrates how to implement a custom rule in AWS Config, to optimize cost by monitoring database instances. In scenarios where multiple accounts are used, customers may want to regulate the use of expensive database instances, and be notified of any violations. For example, a test account does not necessarily need to utilize a production size instance for building applications. A custom AWS Config rule monitors the account checking the type of database instance running. Then when a non-compliant database instance type is detected AWS Config will flag it.

Overview of solution

The following diagram illustrates the solution architecture:

Image showing an AWS Config Custom Rule invokes a lambda function that checks if the given RDS instance is compliant or not

Figure 1: Solution Overview

The AWS Config custom rule invokes the AWS Lambda function that detects if an Amazon RDS database instance provision violates pre-defined cost controls. The invocation of this function occurs every time there is a new Amazon RDS database instance detected in the account. The AWS Lambda function checks the instance type to ensure that it complies with an approved instance type. Nothing happens if the resource is evaluated as compliant. If the resource is evaluated as non-complaint, then the lambda function will send an alert through an AWS Simple Notification Service (Amazon SNS) topic to the administration team which will allow the account administrators to take the corrective action.

Walkthrough

In this walkthrough, we will guide you through the following steps to demo the overall procedure presented in the solution diagram above.

Disclaimer: All code provided here should be evaluated in non-production environments.

  • Create necessary resources via AWS CloudFormation template
  • Confirm AWS SNS Topic subscription
  • Create an AWS RDS instance to verify AWS Config custom rule is working

The prerequisites for this walkthrough are as following:

  1. An AWS account in which you have administrator permission.
  2. The AWS Config service is setup in the Region you will use for this walkthrough. If not, follow the documentation for 1-click setup of AWS Config.

Image showing AWS Config setup

Figure 2: Setup AWS Config

Step 1: Create resources using AWS CloudFormation Template

Download and launch this AWS CloudFormation template to deploy the AWS Lambda function, AWS Config custom rule, Amazon SNS topic and other related resources.

Note: Resources deployed will incur costs. Remember to clean up resources following instructions in the “Cleaning Up” section below.

To create a resource by using AWS CloudFormation template, complete the following steps:

  1. Sign in to the AWS Management Console
  2. Navigate to the AWS CloudFormation Console > Create Stack > “With new resources
  3. Upload the YAML template file and choose Next
  4. Specify a “Stack Name” and put an email address for “NotificationEmail” parameter, then choose Next
  5. Leave the “Configure stack options” at default values and choose Next
  6. Review the details on the final screen and under “Capabilities” check the box for “I acknowledge that AWS CloudFormation might create IAM resources with custom names”
  7. Choose Submit

Image showing a confirmation message on the console after clicking submit

Figure 3: Stack Creation Acknowledgement

Note: After the stack creation is submitted, you can view its progress under AWS CloudFormation > Stacks > Stack_Name > Events tab.

Once the Stack is successfully created, you will see a couple of resources deployed into your AWS account: AWS Config Rule, AWS Lambda Function, Amazon SNS Topic and the correspondent Amazon IAM Roles.

Step 2: Confirm AWS SNS Topic subscription

After the Step1 completes, you should receive an email from “sns.amazonaws.com” with title of “AWS Notification – Subscription Confirmation” to the email address provided in Step1. The email content should look like below screenshot.

Image showing a subscription confirmation email

Figure 4: Subscription Confirmation Email

Click the “Confirm Subscription” link in the email to confirm the Amazon SNS topic subscription registered on this email address.

Note: You can verify the subscription status under Simple Notification Service > Topics > aws-config-demo-topic > Subscriptions tab like below.

Image showing AWS SNS Subscription Confirmed in the console

Figure 5: AWS SNS Subscription Confirmed

Step 3: Create an AWS RDS instance

In this step, we’ll create an Amazon RDS instance of MySQL; which triggers the AWS Config rule to check the size of the instance to determine if the account administrators need to be alerted. In this example, the instance size created is “db.r6g.large“.

To create this Amazon RDS instance, complete the following steps:

  1. Sign in to the AWS Management Console
  2. Navigate to the Amazon RDS Console > Databases > “Create database
  3. Choose “Easy create” option and “MySQL” as engine type

Image showing RDS instance creation setup in AWS console

Figure 6: RDS Engine

  1. Choose “Dev/Test” as DB instance size and check the “Auto generate a password” option. We’ll remove this RDS instance after the walkthrough, so we don’t need to keep this password.

Image showing choices for the instance size in the AWS console

Figure 7: RDS Instance Size

  1. Leave the other options at default values and choose “Create database”. By default, this database will be created in default VPC or a new VPC if default VPC doesn’t exist. If this setup doesn’t suit your scenario, then you can choose “Standard create” and change the settings.

Image showing Database instance creation in the AWS console

Figure 8: Create Database

  1. After this Amazon RDS instance is created, you should receive a notification email in your email box within a few minutes.

The AWS Lambda function invoked by the custom rule in AWS Config is checking if the Amazon RDS instance is created with a size of “db.t3.micro”. Therefore, this RDS instance is evaluated as non-compliant in AWS Config and an alert email is sent out. Below is the code snippet used in Lambda function to evaluate RDS instance resource.

def is_compliant(configurationItem):
    logger.info(f"Resource to be evaluated->{configurationItem}")
    if configurationItem['configuration']['dBInstanceClass'] == 'db.t3.micro':
        return True    
    else:
        return False

You can view the complete code of the Lambda function from Lambda > Functions > aws-config-demo-lambda > Code tab.

Cleaning up

To avoid incurring charges from the resources deployed in the walkthrough, delete them with the following steps.

  1. Delete AWS RDS Instance
  2. Delete AWS CloudFormation Stack

Conclusion

In this blog post, we discussed how to implement custom AWS Config rules to manage costs in your AWS account. We walked through a specific use case to validate the Amazon RDS instance type. If you would like to learn more about custom rules with AWS Config take a look at Setting up custom AWS Config rule that checks the OS CIS compliance.

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.

Author bio

Neville Lewis

Neville Lewis is a Cloud Application Architect in AWS. He has extensive experience in application architecture design and is working on becoming a polyglot programmer while also delighting AWS customers at the same time. While off work, he likes hanging out with family, tinkering with gadgets, flying FPV drones and working on his guitar chops

James Hu

James Hu is a Sr. Cloud Application Architect in AWS. He has comprehensive experiences in Microservices architecture, AWS CloudFormation/CDK, HA infrastructure. He spends his free time on open-source technologies, e.g., AI/ML. He is also interested in books, music and go game outside of work.

Desta Pickering

Desta Pickering is a Cloud Application Architect in AWS. She has loves working with AWS customers to help solve their unique problems. When she is not working, she’s out hiking with her beloved giant schnoodle, Loki.

Drishti Arora

Drishti Arora is a Cloud Application Architect on Amazon Web Services Professional Services team. Drishti works with AWS customers and partners to help them in their cloud journey and provide cloud solutions with Application Development.