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
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
