serverless: 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 v3 check manually if service name and stage match the format, and show deprecation if they do not.

In v4 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.