AWS recently announced the Parameters and Secrets Lambda Extension, a new way for developers to retrieve parameters from Systems Manager Parameter Store and secrets from Secrets Manager. The Lambda extension caches parameters and secrets, reducing latency and costs.
Mark Promnitz, senior solutions architect at AWS, explains:
Accessing your secrets from Lambda just got easier. Now you don't need to include that boilerplate in every function or worry about your caching implementation. Just use the AWS Parameters and Secrets Lambda Extension - easily added as a layer to your function.
Before being able to retrieve secrets from the cache, developers have to add the new layer to the Lambda function, grant permissions to the Lambda execution role, configure the cache with Lambda environment variables and add the X-AWS-Parameters-Secrets-Token to the request header. To retrieve a secret within the Lambda function, a HTTP GET request is performed, for example:
GET: /secretsmanager/get?secretId=secretId&versionId=versionId
A similar process is required to retrieve parameters from the Parameter Store:
GET: /systemsmanager/parameters/get?name=parameter-path?version=version&label=label&withDecryption={true|false}
Handling parameters and secrets in a serverless function has traditionally been done by initializing the core library of the service or the entire SDK inside the function. The new extension caches parameters and secrets, persisting them throughout the lifecycle of the function. Hayato Kosugi, infrastructure engineer at Saison Information Systems, wrote an article to demonstrate how to use the new feature.
Retrieving a cached secret is faster than retrieving it from Secrets Manager. As there is a cost associated with the requests to the Secrets Manager APIs, introducing the extension might reduce costs too. Shridhar Pandey, senior product manager at AWS, triggered a popular thread writing:
This is BIG! (...) This helps you save on cost and latency in retrieving secrets/params from your Lambda function!
The extension instantiates separate instances corresponding to the concurrency level that the function requires and each instance maintains its own local cache of configuration data. Harshad Ranganathan, senior software engineer at Optum, is skeptical:
Not sure why this has to be through an extension and require an HTTP call - why not just provide it as an out-of-the box capability in lambda where it's an integration and you specify the parameter store path/secret and it gets injected as an environment variable?
Jeremy Daly, author of the weekly serverless newsletter Off-by-none, agrees:
I hate to criticize, because I like the idea of implementing a best practice like this, but the interface for it is pretty terrible. A local http server makes sense so it can be supported across runtimes, but making an http call seems messy. Would have liked to see runtime specific implementations of this.
The extension can log details to CloudWatch, setting the environment variable PARAMETERS_SECRETS_EXTENSION_LOG_LEVEL to debug, and is available at no additional charge in all AWS regions.
