DynamoDB resource being deleted even with DeletionPolicy: Retain


#1

I’ve got a DynamoDB resource with DeletionPolicy: Retain, i wanted to rename this table which I expected would create a new table with the new name and leave the old one intact, however it’s deleting the old one.

resources:
  Resources:
  companiesTable:
    Type: AWS::DynamoDB::Table
    DeletionPolicy: Retain
    Properties:
      TableName: "${self:custom.stage}-companies-testing"
      AttributeDefinitions:
        - AttributeName: companyId
          AttributeType: S
      KeySchema:
        - AttributeName: companyId
          KeyType: HASH
      ProvisionedThroughput:
        ReadCapacityUnits: 5
        WriteCapacityUnits: 5

Output:

Any ideas?


#2

I think you’ll find it’s deleting the old table from the Cloud Formation stack but not actually removing it from DynamoDB.

If it has deleted it from DynamoDB then did you deploy with DeletionPolicy: Retain before changing the name of the table?


#3

The deletion policy only applies when you delete the the resource (or stack, which contains the resource).

If you rename the table, then you get the behaviour described in the docs: replacement

The only thing that might work (not that I’ve tested it) it would be to rename the logical resource (i.e. companiesTable in this case) and the table name at the same time…


#4

@rowanu AWS doesn’t supports renaming DynamoDB tables. If you’re renaming a table in your serverless.yml, which is what I assume @msingleton is doing, then you’re really deleting the old table and creating a new one.

Even with DelectionPolicy: Retain you still see CloudFormation report the table has been deleted but in the DynamoDB console the table is still there. That’s why I think the delete message is in reference to deleting it from the CloudFormation stack and not actually deleting the resource.


#6

@buggy yea it definitely is removing the actual table from dynamo, it’s no longer in the dynamodb console.

Sounds like I might just need to be careful not to do that? or it’s just better to manage that resource outside of serverless just to be safe


#7

Yeah. A common pattern is to manage it in a different stack i.e. a resource-only stack. You can still use SLS to provision it, even if the service doesn’t have any functions.


#8

@msingleton Was the application deployed with DeletionPolicy: Retain before you renamed then table? I’ve done this many times and it’s always worked for me but if you added the DeletionPolicy and renamed in the same deploy then it makes sense that it would still delete the old table.


#9

@buggy the initial application was deployed without deletion policy. I added it after renaming, then renamed a few more times to test and it deleted every time.

Possibly if I rename the resource in the config file and deploy it with Retain, it may work