No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

I haven’t worked with Layers myself yet, but i suspect that you need to force the Layer to be replaced so that it picks up the latest code. You should be able to do that by changing its `name` or `description` to be dependent on something tied to the version you are trying to deploy (like a hash of the contents?). 

If you are deploying the code to S3 outside of Pulumi, do you then want every Pulumi deployment to update the layer, or only based on some signal?

Because coordinating these is often difficult and clumsy, we typically recommend patterns where the code itself is deployed as part of the Pulumi program, so that the lifecycle of all the updates can be managed. 

Thanks <@UB3BGTV63>! When I create the *aws.lambda.LayerVersion* in my pulumi script, I set the *sourceCodeHash* field to the `crypto sha256 base64` checksum of the associated zip file archive.

So I believe the correct Pulumi behavior is to check for changes in the `sourceCodeHash` value. If it has changed, then Pulumi will need to _update_ the LayerVersion resource.

This update will produce a new aws layer arn (ie. the layer version autoincrements on each `aws lambda publish-layer-version` command).

Because the layer arn has changed, the `aws.lambda.Function` will pick up the new layer arns in the `layers` field, and thus the function gets updated.

I hope this makes sense.

My other related question: do I need to explicitly set the LayerVersion `sourceCodeHash` field, or does Pulumi already do this for me?

Because I noticed in the Pulumi resource dashboard, the LayerVersion resources have values for the `sourceCodeSize` field eventhough I do not explicitly set it

<@UB3BGTV63> So I employed an implementation based on your advice for naming.

For `dev` stacks, I tag the name of the resources with the zip file's `last modified timestamp`.

For `prod` and `stage` stacks, I tag the name of the resources with the git revision hash.

I believe this strategy will work out.

But I do wonder for `prod` stack deployments ... I believe Pulumi will destroy the resources if they get a new resource name.

For `dev` and `stage` stacks this is OK, but I assume I will need to mark these resources as `protected` for `prod` stack deployments because we will want to keep the older versions. There may be other lambda functions that are dependent on the older layer versions.