Customizing Service Limits Best Practice Checks

Each AWS account has a default limit on the number of resources that can be deployed within each region. These limits can be anything from the number of EC2 instances you can launch, to DynamoDB read capacity units, to the number of server certificates you can store within IAM.

Once any of those limits is reached, you have two options: remove an existing resource so you are not at your limit, or submit a limit increase to AWS Support. When creating a support case with AWS it can often take a day or two before the limit increase is granted. Because of this, you should closely monitor your deployment and request your increases prior to hitting any limits.

Best Practice Checks

CloudCheckr provides two Best Practice checks that allow you to monitor your AWS Service limits. You can find these checks under the Availability tab of the report:

  • Services Nearing AWS Service Limits: Medium Importance

    Alerts you when you have reached 90% of your limit for any resource. If you see a resource flagged in this check, take immediate action.

  • Current AWS Service Limits: Informational

    Tracks your resources against your service limits. It's recommended that you review the list of resources and limits in this check to see if you are nearing a limit.


Configure Checks

When CloudCheckr runs its Best Practice checks against your AWS account, it can only retrieve the default service and resource limits. This means that if you had AWS Support increase any of your limits, that new limit is not available to CloudCheckr.

We are working with Amazon to expose these detailed programmatically, but we are not able to access custom limits at this time. AWS does allow you to see your EC2 service limits in the Reports section of the AWS EC2 console.

The details of your Service Limits check may resemble the On-Demand EC2 Instances for Instance Type m3.xlarge:

35 | Limit: Unknown | Region: EU (Ireland)

Because CloudCheckr can't retrieve your custom service limits from AWS, you can configure these checks to reflect the proper increased limits.

To configure these checks, click the icon to the right of the check and enter your custom service limits in the text field.

Custom Limit Parameters

When configuring these checks, you must enter the limits in a format that CloudCheckr expects.

Below are the guidelines you should follow when configuring your checks.Depending on the type of service limit you would like to customize in the check, you will use one (or more) of the following parameters:
  • autoscaling-groups-per-region
  • cloudformation-stacks-per-region
  • dynamodb-tables-per-region
  • elasticache-nodes-per-region
  • iam-groups-per-account
  • iam-users-per-account
  • rds-db-instances-per-region
  • rds-storage-tb-per-region
  • redshift-nodes-per-account
  • sns-topics-per-region
  • vpc-vpcs-per-region
  • ec2-elastic-load-balancers-per-region
  • ec2-elastic-ips-per-region
  • ec2-instances-reserved-per-region
  • ec2-instances-spot-per-region

When entering the parameter(s) into CloudCheckr you will separate the parameter and its custom value with a colon.

Examples:

ec2-elastic-ips-per-region:15

sns-topics-per-region:5000iam-groups-per-account:10000

iam-groups-per-account:10000

If you have more than one limit to configure, separate with a comma.

Example:

ec2-elastic-ips-per-region:15,vpc-vpcs-per-region:10,iam-groups-per-account:10000

On-Demand EC2 Instance Type Limits

In addition to a general limit on the number of EC2 instances you can launch within a region, AWS places further limits around the types of On-Demand EC2 instances you can have deployed at any given time.

You can also configure your CloudCheckr Service Limits Best Practice checks for these specialized cases.

You will use the following parameter with additional data points:

ec2-instances-ondemand-per-region

You will also need to add the region and instance type whose limit has been increased.

You will separate these values with a colon.

Examples:

ec2-instances-ondemand-per-region:us-east-1:t2.micro:100

ec2-instances-ondemand-per-region:us-west-2:cg1.4xlarge:6

Running the Newly Configured Checks

Once you have updated your Best Practice checks against these new limits, the data in CloudCheckr won't immediately reflect these changes.Your report needs to be updated against the new values you've entered.

You can wait for CloudCheckr to update your reports automatically (this happens once per day), or you can manually update your reports by clicking Reports Updated in the top-right of your account and selecting Run Now.

When the Best Practice checks are updated, you should see your new limits reflected in the report.

How did we do?