I am glad to hear version numbers are not reused! I’ve updated the article to reflect that. The reason I want a hash alias is that I can pre-compute this alias before I deploy, so I can use it in my CloudFormation templates in IAM policies, other Lambda environment variables, etc. In theory I could do this using an output of a Lambda CloudFormation resource, but I’d prefer the ability to use a token that a priori I know the meaning of.
Instead of passing in the CodeSha256, what about the ability to specify the ETag for the S3 object?
I think hash-based protections are a relatively advanced use case, more suited to use by tools, rather than having a lot of utility in the console — but I could very well be wrong (one of the reasons I like to put feature requests like this on Medium is so that others can chime in with their opinions).
For restricting $LATEST, I’d like to force all invocations to go against published versions, rather than the mutable one. This has to be enforced through IAM one way or another. I guess a deny statement against lambda:Invoke with a resource of arn:aws:lambda:*:*:function:*:$LATEST might work, but it seems more error prone versus, say, a blanket deny against lambda:EnableInvokeLatest.
Finally, thank you for responding! I appreciate you taking the time, and it’s great to see AWS’s commitment to security continuing in the serverless space.