Description
Describe the feature
CDK should inform users of potentially (or actually) hitting account service limit quotas, since at build time it knows the settings that will fail at runtime after cloud formation tries to deploy.
Use Case
Recently when I went to create an ASG for my service's largest production region, I ran into a series of account service limits, which I feel could have been preempted at build time by CDK.
For example, I decided to use a small instance type, namely C5.Large, but use a lot of them. So, I set my min capacity to a small number (400) to let ASG do its thing, and set the max number to 3,000. Upon ramping up traffic to my new service, after 1,000 instances the ASG started to fail to launch new instances, because I hit the max number of targets behind a target group limit (1,000).
Later, I updated my configuration and went to go re-deploy just to run into another limit. This time while using C5.2XLarge, I hit the max vCPU for my account. I had to get either both or one of the tickets I filed with AWS Support approved before being able to ramp up to handle my production load.
Proposed Solution
At build time, ASG CDK code could simply print a warning that setting max instances to 1,000+ could be problematic without increasing account service limits first of max TG instances. It could also do math on how many vCPU I could possibly have at max based on my instance type and max instances settings in order to pre-empt ASG from failing to launch due to my account hitting the max vCPU limit.
Getting more advanced, to avoid API calls at build time, the library could be supplemented with another library that has a static list of all of these limits for all services and each CDK package can integrate with it to print warnings/errors to users based on their configuration settings.
Other Information
No response
Acknowledgements
- I may be able to implement this feature request
- This feature might incur a breaking change
CDK version used
2.73.0
Environment details (OS name and version, etc.)
AL2