Caching solution for AWS SSM parameter store to be used with dotnet lambdas

You can use SSM in environment variables like

environment:
    VariableName: ${ssm:/serverless-VariableName}

and reference in your code from environment. We are using this approach.

This will store SSM when you deploy your app, and reuse it without calling SSM Store for every request

• For reducing number of network calls to SSM parameter store, you can
  assign configuration values from SSM to static properties on
  application startup. And use these static properties for
  configuration values in your application instead of calling SSM parameter store again throughout the life of that particular instance of lambda. Changes to SSM parameters will reflect only in new instances of lambda.

• If you are using provisioned concurrency on lambda then the above mentioned solution will not be helpful as the changes in SSM store parameters will not reflect to provisioned lambda as it is always kept in initialized state. For changes to reflect you need to redeploy or remove provision concurrency and add it back.

• If you have a use case where parameter values get changed frequently and it should be reflected in your lambda code immediately then you can use secret manager to store such values and use aws provided client side caching support for secrets https://aws.amazon.com/blogs/security/how-to-use-aws-secrets-manager-client-side-caching-in-dotnet/.