- 最新
- 最多得票
- 最多評論
This behavior isn't possible with CloudFormation. The reason is that referring to $LATEST
cannot guarantee a reproducible state for your stack.
Suppose you performed a successful deployment. Then, after the deployment, the latest version of your Lambda Layer changed. Later, you attempt a new deployment that fails. If this happens, CloudFormation will then attempt to revert to the previous known good state. To revert to that known state, CloudFormation needs the specific version number of the Lambda Layer. That's why the specific version number needs to be in the stack template.
Many customers overcome this limitation by including the layer itself in the stack template (via AWS::Lambda::LayerVersion
) and making a reference to it. Otherwise, you can do things like put placeholders like $LAYER_VERSION
into your CloudFormation YAML template, and substitute the value of the Lambda version into it after you upload it using an external program such as envsubst
, before updating the stack with the rendered template.
相關內容
- 已提問 6 個月前
- 已提問 1 年前
- AWS 官方已更新 3 年前
- AWS 官方已更新 1 年前
I had my
RetentionPolicy
setting for the layer set to delete originally, and that caused the stack to get stuck because it couldn't reproduce it's previous state like you were talking about. I'll look into merging these separate lambda applications into one big application or maybe writing some sort of aws cli script that would increment the version number across the different lambda projects or just getting rid of the layer and moving the logic to another lambda instead.