A rather nice feature of AWS Secrets Manager is the ability to configure a secret to be automatically rotated on a schedule, taking the worry out of having credentials that get stale & remain static unless manually rotated periodically..

The way that this is achieved is via an AWS Lambda that is invoked by Secrets Manager that takes care of the creation of a new password (at least for the majority of the 'out of box' rotations), testing the new password and creating a new version of the secret.

The simplest* way to have the lambda created & associated with the secret is to define in your Cloudformation template for the secret an AWSSecretsManagerRotationSchedule resource that specifies the rotation rules, and the HostedRotationLambda details. (* we do use Cloudformation or similar for standing up all our AWS resources, yes? :) OK, so the same can be achieved via the AWS Console UI). AWS will stand up a new Lambda using a template based on the HostedRotationLambda:RotationType specified, with the appropriate permissions to access the Secret as well as update it, write Cloudwatch Logs etc.

However, there are some minor drawbacks with this approach, IMHO. Now most of these really are rather trivial to different extents, and depending on your circumstances, the 'out of box' templated solution is probably going to be perfectly OK. But - here's some things to consider.

All Secret Access

Keen observers will have noted in the RotationSchedule template reference (or the Credential Rotation settings in the AWS Console UI) the ability to point the Rotation Schedule at an existing Lambda. Secrets Manager passes the ARN for the Secret that it is rotating in the call to the Lambda, so it is possible to use the same Lambda to rotate multiple different secrets - so long as the secrets are all for the same type of credential (e.g. InfluxDB passwords, or RDS PostgreSQL passwords) then the one Lambda can handle multiple secret rotations.

Because of this, the OOB permissions for the Lambda are somewhat broad, allowing read, write, and version updates to all secrets. This is obviously necessary to allow for multiple secrets to be rotated by the same Lambda.

This may not necessarily be a major concern, but for the particularly security conscious who work hard to apply the principle of least privilege, allowing read and update access to all secrets might set some teeth on edge.

Runtime

The template used by AWS for the Hosted Rotation Lambda will stand a up a python lambda with (as of September 2025) a runtime version of 3.10. This is significantly behind the latest version of the python runtime supported by AWS for Lambdas, which is currently 3.13. The 3.10 runtime is due to be deprecated on June 30, 2026.

If you are particular about a different language runtime, or prefer a more current version of the python runtime, you cannot (currently) specify a preferred runtime for the Lambda that is stood up if you use the OOB template.

(Possible) Multiple Lambdas

If you simply use the HostedRotationLambda