A script and python package to check your AWS service limits and usage via boto3.
AGPL-3.0 License
EC2 / Max spot instance requests per region
limit, which has been removed by AWS, in favor of six new vCPU-based limits: All F Spot Instance Requests
, All G Spot Instance Requests
, All Inf Spot Instance Requests
, All P Spot Instance Requests
, All X Spot Instance Requests
, and All Standard (A, C, D, H, I, M, R, T, Z) Spot Instance Requests
.CertificateManager
(ACM) and CloudFront
.acm:ListCertificates
, cloudfront:ListCloudFrontOriginAccessIdentities
, cloudfront:ListKeyGroups
, cloudfront:ListDistributions
, cloudfront:ListCachePolicies
, and cloudfront:ListOriginRequestPolicies
.As I commented in Issue #500, I'm looking for someone to share (and perhaps take over) maintenance of this project. awslimitchecker is, and has always been, a personal-time-only project for me; the only time I've done work on it during my day job is when my employer was experiencing an issue or requested a specific feature. Because of a variety of issues, including changing personal interests and my employer relying on this project much less (following an AWS account restructuring that largely avoids service limits), I've been spending much less time on this project than it deserves. As a result, I'm looking for someone to help with maintenance... at the very least, helping review PRs and get them to a merge-able state. If you're interested, please comment on Issue #500 or contact me directly. While I am incredibly flattered by the offers I've received for sponsorship, paid support, or other financial incentive, I'd ask that anyone who's willing to make that commitment instead dedicate a few hours to working on issues or PRs. I, for my part, will make a concerted effort to quickly merge and release any PRs that meet all of the development.pull_request_guidelines
{.interpreted-text role="ref"}.
EC2 / Max spot instance requests per region
limit, which has been removed by AWS, with new vCPU-based spot instance requests limits. This also switches to using CloudWatch metric data to retrieve current usage. Thanks to TagadaPoe for this contribution.Published by jantman over 3 years ago
General Purpose (SSD) volume storage (GiB)
limit in favor of General Purpose (SSD gp2) volume storage (GiB)
and General Purpose (SSD gp3) volume storage (GiB)
limits, to account for the new gp3 volume type and corresponding AWS service limits.Provisioned IOPS
and Provisioned IOPS (SSD) storage (GiB)
limits in favor of Provisioned IOPS (io1)
and Provisioned IOPS (io2)
, and Provisioned IOPS SSD (io1) storage (GiB)
and Provisioned IOPS SSD (io2) storage (GiB)
, respectively, to account for the new io2
EBS volume type and corresponding AWS service limtits.As I commented in Issue #500, I'm looking for someone to share (and perhaps take over) maintenance of this project. awslimitchecker is, and has always been, a personal-time-only project for me; the only time I've done work on it during my day job is when my employer was experiencing an issue or requested a specific feature. Because of a variety of issues, including changing personal interests and my employer relying on this project much less (following an AWS account restructuring that largely avoids service limits), I've been spending much less time on this project than it deserves. As a result, I'm looking for someone to help with maintenance... at the very least, helping review PRs and get them to a merge-able state. If you're interested, please comment on Issue #500 or contact me directly. While I am incredibly flattered by the offers I've received for sponsorship, paid support, or other financial incentive, I'd ask that anyone who's willing to make that commitment instead dedicate a few hours to working on issues or PRs. I, for my part, will make a concerted effort to quickly merge and release any PRs that meet all of the development.pull_request_guidelines
{.interpreted-text role="ref"}.
gp3
EBS volume type. Thanks to spockNinja for this contribution!KeyError: 'labels'
). Thanks to jwu2 for first reporting this issue and sebasrp for the fix!KeyError: 'LaunchSpecifications'
in EC2 service. Thanks to nitrocode for this.docker
, docs
, and integration3
tox environments from 3.8 to 3.9.Published by jantman almost 4 years ago
eks:ListClusters
, eks:DescribeCluster
, eks:ListNodegroups
, eks:ListFargateProfiles
, eks:DescribeFargateProfile
, kinesis:DescribeLimits
.EC2/Security groups per VPC
limit, which no longer exists, and adds the new EC2/VPC security groups per Region
limit.Units set to "None"
error when retrieving load balancer data from Service Quotas. We now allow the (A|E)LB per Region quota with a unit of either "Count" (prior to November 2020) or "None" (November 2020 on).Manual Cluster Snapshots
, Custom Endpoints Per DB Cluster
, DB Instance Roles
, and DB Cluster Roles
. Thanks to sebasrp for this contribution!EKS
service, and 8 new limits for it. Thanks to sebasrp for this contribution!Kinesis
service, and one new limit for it. Thanks to sebasrp for this contribution!Rules per VPC security group
limit to support retrieving the current limit value from Service Quotas.EC2/Security groups per VPC
limit, which no longer exists.EC2/VPC security groups per Region
limit.VPC/Network interfaces per Region
limit for new calculation method.Published by jantman about 4 years ago
Important: This release requires new IAM permissions: sts:GetCallerIdentity
and cloudwatch:GetMetricData
Important: This release includes updates for major changes to ECS limits, which includes the renaming of some existing limits.
owner-id
filter, supply that filter when describing them, set to the current account ID. This will prevent shared resources from other accounts from being counted against the limits. Thanks to pritam2277 for reporting this issue and providing details and test data.support:*
with the specific permissions that we need.EC2 Tasks per Service (desired count)
limit has been replaced with Tasks per service
, which measures the desired count of tasks of all launch types (EC2 or Fargate). The default value of this limit has increased from 1000 to 2000.Clusters
has increased from 2,000 to 10,000.Services per Cluster
has increased from 1,000 to 2,000.Fargate Tasks
limit has been removed.Fargate On-Demand resource count
limit has been added, with a default quota value of 500. This limit measures the number of ECS tasks and EKS pods running concurrently on Fargate. The current usage for this metric is obtained from CloudWatch.Fargate Spot resource count
limit has been added, with a default quota value of 500. This limit measures the number of ECS tasks running concurrently on Fargate Spot. The current usage for this metric is obtained from CloudWatch.~._AwsService
{.interpreted-text role="class"} to get Service Quotas usage information from CloudWatch.Published by jantman about 4 years ago
ConnectTimeoutError
in some regions. This has been added to the list of SES exceptions that we catch and silently ignore. This is a new exception thrown by regions that do not have SES support..dockerignore
file to make local builds quite a bit smaller.<6.0.0
to avoid some breaking changes for now.Published by jantman over 4 years ago
Published by jantman almost 5 years ago
dateutil
dependency.botocore
dependency.docs
, localdocs
, and docker
environments to use Python 3.8.Published by jantman almost 5 years ago
Important: This release includes major changes to the EC2 On-Demand Instances service limits! For most users, this means the 175 Instance-type-specific limits will be removed and replaced with five (5) limits. Please see the changelog.8_0_0_vcpu_limits
section below for further details, as this will especially impact anyone using limit or threshold overrides, or post-processing awslimitchecker's output. This is also a time to remind all users that this project adheres to a strict development.versioning_policy
and if occasional breakage due to limit or IAM policy changes is unacceptable, you should pin to a major version.
Important: Python versions prior to 3.5, including 2.7, are now pending deprecation. As of January 1, 2020, they will no longer be tested or supported, and awslimitchecker will require Python 3.5 or newer. Please see below for details. Also take note that running via the official Docker image is a way to ensure the best version of Python is always used.
Important: This release requires a new IAM permission, servicequotas:ListServiceQuotas
.
cn-*
and us-gov-*
(which still use old per-instance-type limits). See section below <changelog.8_0_0_vcpu_limits>
for further information. For regions other than cn-*
and us-gov-*
, this will remove all 175 Running On-Demand <type> instances
and the Running On-Demand EC2 instances
limit, and replace them with:
Running On-Demand All F instances
Running On-Demand All G instances
Running On-Demand All P instances
Running On-Demand All X instances
Running On-Demand All Standard (A, C, D, H, I, M, R, T, Z) instances
cn-*
and us-gov-*
regions.botocore.exceptions.ParamValidationError
exception in accounts that have Trusted Advisor but do not have a "Service Limits" check in the "performance" category.GetEventSelectors
on an Organization trail. When calling DescribeTrails
, we will now pass includeShadowTrails
as False, to not include replications of trails in different regions or organization trails in member accounts (relevant API documentation).PendingDeprecationWarning
for users running under this version, announcing that support for Python 3.4 will be removed on January 1, 2020.DeprecationWarning
when running on any Python2 version prior to 2.7 or any Python3 version prior to 3.4, in accorance with the published end-of-life dates of those versions.python:3.8-alpine
.CLI Usage
or Python Usage
documentation for further details.Rules per VPC security group
limit. We were previously calculating the number of "Rules" (from port / to port / protocol combinations) in a Security Group, but the limit is actually based on the number of permissions granted. See this comment on the issue for further details.changelog.8_0_0_service_quotas
section below for more information.AWS has announced new, completely different handling of EC2 On-Demand Instances service limits. Instead of having a limit per instance type (currently 261 limits), there will now be only five limits, based on the number of vCPUs for instance families: one each for "F", "G", "P", and "X" family instances (defaulting to a total of 128 vCPUs each) and one limit for all other "Standard" instance families (currently A, C, D, H, I, M, R, T, and Z) defaulting to a combined total of 1152 vCPUs. Please see the link, and the EC2 On-Demand Instance Limits section of the AWS FAQ for further information.
This greatly simplifies handling of the EC2 On-Demand limits, but does mean that any existing code that references EC2 Running On-Demand limit names, including any limit and/or threshold overrides, will need to be updated for this change.
This change is only going into effect in the "standard" AWS regions/partitions, i.e. not in the China partition (cn-
regions) or GovCloud (us-gov-
regions). It is a phased rollout from October 24 to November 7, 2019 based on the first character of your account ID (see the "How will the transition to vCPU limits happen?" entry in the FAQ linked above for exact dates). Unfortunately, there is no clear way to determine via API if a given account is using the new vCPU limits or the old per-instance-type limits. As a result, and given that this release is being made already part-way through the rollout window, the current behavior of awslimitchecker is as follows:
cn-
or us-gov-
, use the old per-instance-type limits, unless the USE_VCPU_LIMITS
environment variable is set to true
.USE_VCPU_LIMITS
environment variable is set to something other than true
.As such, if you install this release before November 7, 2019 and need to force your non-China, non-GovCloud accout to use the older per-instance-type limits, setting the USE_VCPU_LIMITS
environment variable to false
will accomplish this until your account switches over to the new vCPU limits. Alternatively, you can leave awslimitchecker as-is and accept possibly-slightly-inaccurate limit calculations for a few days.
Please also note that with the change to vCPU limits, there is no longer an overall Running On-Demand EC2 instances
limit for accounts that use the new vCPU limits.
I have not yet implemented Trusted Advisor (TA) support for these new limits, as they're presented in a different category of Trusted Advisor checks from the previous EC2 limits. I'm not going to be implementing TA for these limits, in favor of spending the time instead on implementing Service Quotas support via Issue #413.
Calculation of current usage for the vCPU limits is based on the EC2 Optimizing CPU Options documentation which specifies, "The number of vCPUs for the instance is the number of CPU cores multiplied by the threads per core." The CpuOptions
field of the EC2 DescribeInstances
API specifies the core and thread count for each running instance.
AWS' new Service Quotas service provides a unified interface to retrieve current limits from many AWS services. These limit values are second only to the services' own APIs (for the services that provide limit information via API), and are much more current and complete than the information provided by Trusted Advisor. The introduction of Service Quotas should greatly reduce the number of limits that need to be retrieved from Trusted Advisor or specified manually.
If you currently have any Limit Overrides set (via either the CLI
or Python API
), please verify on the limits
page whether Service Quotas data is now available for those limits. You should be able to remove manual overrides for the limits that now retrieve data from Service Quotas.
Published by jantman about 5 years ago
botocore.vendored.requests.exceptions.ConnectTimeout
in favor of new, and higher-level, botocore.exceptions.ConnectionError
awslimitchecker.utils._get_latest_version
, replace use of botocore.vendored.requests
with urllib3
.--limit-override-json
and --threshold-override-json
CLI options.Published by jantman about 5 years ago
This release removes one limit and adds two new limits!
ELB
Service Active load balancers
limit is now two separate limits, Classic load balancers
and Application load balancers
. Anyone who was using the "Active load balancers" limit name (e.g. in overrides or custom code) must update their code accordingly. This release removes the Active load balancers
limit and adds two new limits, Classic load balancers
and Application load balancers
, to match how AWS now calculates and exposes these limits.Published by jantman over 5 years ago
null
timestamp.Published by jantman over 5 years ago
Published by jantman over 5 years ago
ClientError
when checking SES in some regions, but some regions such as ap-southeast-2 are now returning a 503 Service Unavailable for SES instead. Handle this case as well. Thanks to @TimGebert for reporting the issue and bergkampsliew for verifying.Published by jantman over 5 years ago
Published by jantman over 5 years ago
Published by jantman over 5 years ago
Published by jantman over 5 years ago
ClientError
exception when checking SES Send Quota in certain regions. Thanks to bergkampsliew.Published by jantman over 5 years ago
Network interfaces per Region
limit. Thanks to @nadlerjessie.Published by jantman over 5 years ago
ClientError
exception when checking SES Send Quota in certain regions. Thanks to bergkampsliew for PR #376.Published by jantman almost 6 years ago
This release requires new IAM permissions:
lambda:GetAccountSettings
Important: This release removes the ApiGateway APIs per account
limit in favor of more-specific limits; see below.
awslimitchecker.limit.AwsLimit.get_limit
returns None
).ApiGateway
service now has three ReST API limits (Regional API keys per account
, Private API keys per account
, and Edge API keys per account
) in place of the previous single APIs per account
to reflect the current documented service limits.VPC Links per account
limit.Network load balancers
and Listeners per network load balancer
.Certificates per application load balancer
.Registered instances per load balancer
limit.dev/terraform.py
to dev/update_integration_iam_policy.py
and move from using terraform to manage integration test IAM policy to pure Python.Targets per application load balancer
and Targets per network load balancer
limits. Checking usage for these requires iterating over DescribeTargetHealth
for each target group, so I've opted to leave it out at this time for performance reasons and because I'd guess that the number of people with 500 or 1000 targets per LB is rather small. Please open an issue if you'd like to see usage calculation for these limits.awslimitchecker has had documented support for Limits that are unlimited/"infinite" since 0.5.0 by returning None
from :pyawslimitchecker.limit.AwsLimit.get_limit
. Until now, that edge case was only triggered when Trusted Advisor returned "Unlimited" for a limit. It will now also be returned for the Lambda service's Function Count
Limit. Please be aware of this if you're using the Python API and assuming Limit values are all numeric.
If you are relying on the output format of the command line awslimitchecker
script, please use the Python API instead.