Allow configuration of AWS Asset RemovalPolicy to prevent accidental deletion

[dmeehan1968]

I had added a Dynamo DB to my sst config, used it in the app including writing some data. In the process of my work I had to checkout a prior version which caused sst to destroy the DB, so I lost data (only a couple of records so just a minor inconvenience).

AWS CDK allows one to configure the removal policy for assets, to avoid the risk of inadvertant deletion. This does introduce some complications in terms of naming conflicts, and does potentially leave one needing to adopt an existing resource rather than creating a new one.

This may therefore be beyond the scope of SST and in the realms of backup/restore policies, even when in dev environments.

[jayair]

Do you mean on a per resource basis as opposed to on the entire app? https://github.com/sst/ion/blob/dev/examples/aws-api/sst.config.ts#L7

[dmeehan1968]

Do you mean on a per resource basis as opposed to on the entire app? https://github.com/sst/ion/blob/dev/examples/aws-api/sst.config.ts#L7

Aah, I'd not spotted that as an option. The docs suggest this is around behaviour during an explicit sst remove, whereas I experienced this during a deploy (because I'd checked out an earlier commit whilst working on a bug). Those options for remove are presumably to give an option to 'detach' oneself from SST and leave all the resources in place?

It's easy to get into a mindset that deploy 'adds' resources, rather than removes them, which is what caught me out. I'd forgotten that I'd added Dynamo between the dev head and the commit I checked out.

In some ways, during deploy, a warning that you are removing storage resources (S3, Dynamo) requiring confirmation (and a --force/yes flag for CI) would seem like a useful behaviour, and/or an explicit removal policy per resource (so the config can define whether its ok to remove or not) would be more robust, especially if the default is to retain.

As an aside, could you then re-add the resource and have it adopted back, or would this just create a name conflict and you'd either have to rename anyway or manually import rather than have SST manage the resource?

[jayair]

Yeah you can re-add things back into your app's state. We'll have some docs on this moving forward. It'll be the same process when you migrate from SST2 to Ion.

You can set retain on a per resource basis as well: https://www.pulumi.com/docs/concepts/options/retainondelete/, you can pass this in to a Bucket for example through the opts https://ion.sst.dev/docs/component/aws/bucket/#constructor

Closing for now.