Cloudformation-coverage-roadmap: Re-evaluate Limits

[ngamradt-turner]

Scope of request

Per the documentation, there is a limit of 60 parameters per template:

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html

Expected behavior

The 60 parameter limit appears to be arbitrary and often causes problems with complex templates or with resources that may require a large number of parameters (for instance, a large number of environment variables needed for an ECS task definition).

We would like to see this number either doubled to 120 parameters per template or eliminated all together. At 120 parameters, this problem would occur much less frequently and the case could probably me made more often that a refactor could eliminate the issue, but at 60 parameters, we run into it often due to us wanting to make templates more reusable. Some resources have a lot of options that need to be accounted for.

It should also be noted that the lack of a "latest" option for SSM parameters when using Dynamic references makes them much less useful than they could be, otherwise these could be used to reduce the need for parameters:

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/dynamic-references.html

[PatMyron]

Going to generalize this issue since most of CloudFormation's limits should be re-evaluated

[benkehoe]

Separate from simply more parameters, the ability to use (and validate) JSON objects as parameters would enable a lot more information to be injected into templates with better semantics. Should I open that as a separate issue?

[ngamradt-turner]

@PatMyron Okay, if this is going to become a general-purpose ticket about limits, then let me add another one:

For the AWS::CodePipeline::Pipeline resource, there are 1000 character limits for things such as...

1. ParameterOverrides (for CloudFormation)
2. EnvironmentVariables (for CodeBuilds)

Again, these limits seem odd, depending on variable name lengths, these limits are easy to hit for fairly normal implementations.

[trav-c]

@PatMyron

Here's another on I seem to hit not too infrequently:
AWS::Lambda::Function.Code.ZipFile is limited to 4096 bytes.

It's pretty easy to hit that when putting together custom resources to handle not yet supported by CloudFormation resource types when you are trying to keep some resources inline in templates for portability, especially if you are trying to keep code readable, obviously after a certain size it usually doesn't makes much sense to keep the code inline in the template, but in my experience that threshold is more than 4 kiB and it would greatly increase the utility if the limit could be increased to something in the 8 kB+ range.

[ngamradt-turner]

@PatMyron I have sent you an example over Slack, please take a look and let me know what further details you need from me regarding the EnvironmentVariables limit.

[PatMyron]

@ngamradt-turner this error is being thrown by CodePipeline, not CloudFormation:

1 validation error detected: Value at 'pipeline.stages.3.member.actions.1.member.configuration' failed to satisfy constraint: Map value must satisfy constraint: [Member must have length less than or equal to 1000, Member must have length greater than or equal to 1] (Service: AWSCodePipeline; Status Code: 400; Error Code: ValidationException; Request ID: REDACTED)

CloudFormation cannot unilaterally bypass the underlying service's limits

[kteague]

The maximum number of Stacks at 200 is the easiest one for me to hit. Especially as I find it easier to manage Stacks without jamming a lot of unrelated Resources into mega-Stacks, 200 is really low.

If there is a Stack for an S3 Bucket, a Stack for RDS, a Stack for EFS an a Stack for an AutoScalingGroup/LaunchConfiguration and a Stack for an ALB and Target Groups - a fairly simple application can easily be 10 stacks. If there are also global Stacks for IAM, CloudTrail, Config, SNS Topics resources and network Stacks for VPCs, Subnets and SecurityGroups ... then it's easy to set-up a new account and deploy a few apps into it and already be close to 100 Stacks.

[benbridts]

@kteague the total number of stacks is a soft limit you can increase within the Service Quotas service.

[josb]

Any updates on this, especially on raising the 60-parameters-per-stack limit? Or, can you at least give us some insight into why raising this limit isn't trivial? Please?

[luiseduardocolon]

@josb Hi there. We are making good progress on this. Stay tuned.

[josb]

@luiseduardocolon thanks for the update! Waiting patiently...

[jdub]

My favourite disappointing CloudFormation limit is DetectStackDrift. I created a Config rule to detect drift every 3 hours and on stack changes, but with 110+ stacks in our test account, it always throttles and fails. 😢 (See case ID 6832938811.)

[PatMyron]

AWS CloudFormation now supports increased limits on five service quotas

The maximum size of a template that can be passed in an S3 Object is now 1MB (previously 450KB). The new per template limits for the maximum number of resources is 500 (previously 200), parameters is 200 (previously 60), mappings is 200 (previously 100), and outputs is 200 (previously 60)
You can now declare a maximum of 200 mapping attributes for each mapping in your AWS CloudFormation template

[josb]

Thanks @PatMyron! Appreciate the 140 extra stack parameters!

[luiseduardocolon]

Shipped and closing.