fix(lambda): enforce lambda alias alphanumeric logical id

[vicheey]

Issue #, if available

When using the AutoPublishAlias property in a SAM template, SAM appends the alias string to form a new logical ID for the alias resource. If the alias value contains non-alphanumeric (- or/and _), the resulting logical ID violates the naming convention, causing the deployment to fail. The CloudFormation naming convention for logical IDs (resource names) requires all name to be strictly alphanumeric.

The issue happens during deployment when the customers specify alias names for AutoPublishAlias that containing - and/or _ in an AWS Serverless Application Model (SAM) CloudFormation template.

According to https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-alias.html#cfn-lambda-alias-name, the valid alias name should match the following regex: (?!^[0-9]+$)([a-zA-Z0-9-_]+) which

• Match strings containing letters, numbers, hyphens, and underscores
• Must contain at least one character
• Will not match strings that consist of only numbers

Examples:

• Will match: "abc123", "user_name", "test-123", "a1b2c3"
• Won't match: "123456", "000"

Description of changes

This commit adds validation for Lambda alias names in the AWS SAM transform to ensure they produce valid CloudFormation logical IDs. The key changes are:

1. Added validation for Lambda alias names:
   • Implemented regex validation to ensure alias names follow the pattern (?!^[0-9]+$)([a-zA-Z0-9-_]+)
   • This ensures alias names contain only alphanumeric characters, hyphens, and underscores
   • Prevents purely numeric alias names (which would create invalid CloudFormation resources)

2. Modified logical ID generation for Lambda aliases:
   • Previously: {function.logical_id}Alias{name}
   • Now: {function.logical_id}Alias{alias_alphanumeric_name}
   • The change strips hyphens and underscores from alias names to ensure the logical ID contains only alphanumeric characters

Description of how you validated changes

Added test cases:
• Tests for valid alias names (e.g., "aliasname", "alias-name", "alias_name", "mixed-Case_123")
• Tests for invalid alias names (e.g., purely numeric "123", names with spaces, names with special characters)
• Verification that the logical IDs are correctly generated

Checklist

• Adheres to the development guidelines
• Add/update transform tests
  • Using correct values
  • Using wrong values
• Add/update integration tests

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[valerena]

So this is currently already failing, but with a different error, right? (because we try to use the - as part of a Logical name).

Should we try to actually support this instead of just showing a better error? (it's an honest question, I'm not sure if it's possible to do something about it, instead of just "making it fail correctly") Because the console, API and CFN do support Aliases with dashes.

[vicheey]

So this is currently already failing, but with a different error, right? (because we try to use the - as part of a Logical name)

No. The changes contain 2 parts as described on the overview: 1)added validation for Lambda alias names which only allow numeric characters, alphabetic characters, - or _. 2) strips hyphens and underscores from alias names before using it to create resource logical id for alias resource.

I think something we can improve is rather than replace - and _ with empty space, we should replace with the D and U to differentiate the following case:

• 1-0_1 --> 101
• 1-0-1 --> 101
• 10-1 --> 101
• 101 --> 101
• 1-01 --> 101
  The problem is all these cases should generate different logical id. I can update the logic so that
• 1-0_1 --> 1D0U1
• 1-0-1 --> 1D0D1
• 10-1 --> 10D1
• 101 --> 101 Denied because cannot be all numeric (considered a version)
• 1-01 --> 1D01
• 1_01 --> 1U01

[mbfreder]

Can we add transform failure tests as well? Like testing that a SAM template with an invalid Alias name results in a specific transform error? Please see Transform failure tests guide.

[vicheey]

There is no backward compatibility issue since SAM users currently cannot deploy a SAM template with alias name containing - or _. So we can safely assume no deployed stack through SAM template that contain alias resource with such naming.

[valerena]

Is this the error message that gets returned from the API for example? We could try to have a consistent messaging with what the API returns in case of error

[vicheey]

While, I agree that we should try to preserve the wording from the API, in this case I think we should improve on the message. The proposed error message format enhances clarity by identifying invalid properties, providing user-friendly validation requirements, and including regex patterns for technical users.

In console, frontend validation already shows different message than what api shows. I do not see much value to stick to the exact API error message.

Console:

CLI:

$ aws lambda create-alias --function-name my-project-one-stack-name --function-version '$LATEST' --name 'asdf67#*9_-'                         

An error occurred (ValidationException) when calling the CreateAlias operation: 1 validation error detected: 
Value 'asdf67#*9_-' at 'name' failed to satisfy constraint: Member must satisfy regular expression pattern: (?!^[0-9]+$)([a-zA-Z0-9-_]+)

[valerena]

Can you add one extra input/output test case file that's VALID, with dashes and/or underscores? (that tests the new behavior that this PR supports)

[vicheey]

Added multiple valid alias name combinations for contrac test.