Long service names tend to crash deploys

I’ve named my service test-api-gateway-provisioned-concurrency, then stack creation succeed but update failed with:

 An error occurred: IamRoleLambdaExecution - 1 validation error detected: Value 'test-api-gateway-provisioned-concurrency-dev-us-east-1-lambdaRole' at 'roleName' failed to satisfy constraint: Member must have length less than or equal to 64 (Service: AmazonIdentityManagement; Status Code: 400; Error Code: ValidationError; Request ID: 4eee3989-ad51-4d8b-a104-d1e632e4bf22).

I think there’s need to be set upfront limit for service name, and then there should be ensured not other resource names are generated too long cause that.

Fixing that seems not trivial though, as also length of stage and region influences that.

---

Solution proposal:

• Restrict service name length to max 20 chars, additionally restrict format to ^[a-z][a-z0-9]*(?:-[a-z0-9]+)*$
• Restrict stage name length to max 11 chars (and ensure it’s valid for APIGateway), additionally restrict format to ^[a-z][a-z0-9]*(?:-[a-z0-9]+)*$ In v2 check manually if service name and stage match the format, and show deprecation if they do not.

In v3 configure pattern into the schema validation

Having above ensured we may design all resource names around that (knowing that prefix won’t be longer that 32 chars, we may ensure that eventual postfix won’t exceed the limit)

For cases where expected names needs to be quite short (e.g. there’s implied 32 chars limit) I believe we should use hashes.

[vmo-khanus]

Thanks for your insight on this. We’re not jumping on that issue given your feedback either and if we do go forward we’ll for sure build a case around it. Agree on preventing a per resource naming situation, that doesn’t sound fun. For us it’s a lot more about standardization than customization of individual names. We have a significant number of non-serverless managed stacks and so we’re just looking to make sure naming of resources is seamless between the framework and non-framework stacks and I don’t think we’d be unique in that requirement. But ya, that’s a different issue and something we’ll for sure put thought into before going any further. Thanks for your feedback and thanks to the serverless team, we really enjoy working with it!

[pgrzesik]

@Kevchan85 I believe we have a similar issue here: https://github.com/serverless/serverless/issues/8887. It is currently blocked due to https://github.com/serverless/serverless/issues/8681 but that should be closed quite soon.