AWS secrets manager, 'A previous rotation isn’t complete' when rotating secrets

Question

I've created a secret and updated it to have a lambda rotation function

My secret looks like

aws secretsmanager list-secret-version-ids --secret-id envir/username
{
    "Versions": [
        {
            "VersionId": "90179cd3-daa1-48e4-9fe5-dde0a4cf22e4",
            "VersionStages": [
                "AWSPREVIOUS"
            ],
            "LastAccessedDate": 1524528000.0,
            "CreatedDate": 1524568488.358
        },
        {
            "VersionId": "60576823-5d98-4360-af53-7e1f909b88d0",
            "VersionStages": [
                "AWSCURRENT"
            ],
            "LastAccessedDate": 1524528000.0,
            "CreatedDate": 1524568827.466
        }
    ],
    "ARN": "arn:aws:secretsmanager:eu-west-1:8282828282828:secret:username-YdgbPA",
    "Name": "envir/username"
}

and when i try to rotate it, i get this error

An error occurred (InvalidRequestException) when calling the RotateSecret operation: A previous rotation isn’t complete. That rotation will be reattempted.

I can rotate the secret without issues if i trigger the lambda function without issues.

Anyone has any ideas ?

---

related links:

• https://forums.aws.amazon.com/thread.jspa?threadID=280093&tstart=0 which does not apply to me as i dont have the secret in AWSPENDING state.

Answer 1

Just a note for people in future who might get the same error...

If you are using the AWS Secrets Manager to rotate an Amazon RDS password, the Secrets Manager will automatically create a Lambda function. This function requires:

• Access to the Internet (to call the Secrets Manager) OR VPC endpoint for Secrets Manager service in subnet/subnets associated with the lambda function
• Access to the RDS instance (to login and change the password)

As such, the following combinations work:

• Publicly accessible database (bad for security) with a Lambda function that is not attached to a VPC, OR
• The Lambda function in a private subnet with a NAT Gateway in the public subnet (so the Lambda function can access the Internet) OR an Elastic IP Address attached to the Lambda function's ENI

Also, the Security Group attached to the database needs to permit inbound access from the Lambda function. By default, the Lambda function is assigned the same security group as used by the database, so either:

• Edit the database security group to permit inbound connections from itself (that is, from Lambda to the database via the same security group), OR
• Change the security group that is used by the Lambda function to one that is currently permitted to access the database security group