CODEWITHSUNDEEP
amazon-web-servicesaws-cdk
Judi
Judi

Reputation: 910

How does removalPolicy: cdk.RemovalPolicy.DESTROY works?

I am using removalPolicy: cdk.RemovalPolicy.DESTROY.

The other two options are RETAIN and SNAPSHOT.

If I delete my table from the console and try to create using the cdk it gives an error say could not find resource.

Question -- what option I can use if the script is unable to find the table then it should create ?

Upvotes: 4

Views: 13596

Answers (2)

Balu Vyamajala
Balu Vyamajala

Reputation: 10333

CDK RemovalPolicy sets CloudFormation DeletionPolicy and UpdateReplacePolicy, which affect resources removed via CDK/CloudFormation code:

  • DESTROY: usually the default, deletes actual resource
  • RETAIN: retains actual resource
  • SNAPSHOT: deletes actual resource but snapshots beforehand (for resources like databases)

These apply when resources are removed via code. Manually deleted resources are longer maintained by CDK/Cloudformation stacks and will cause stack errors. To continue managing via stack, manually re-create a resource with the same physical id

Upvotes: 0

Malvineous
Malvineous

Reputation: 27300

The RemovalPolicy has nothing to do with things you remove yourself outside of CDK. This is a bad idea (and in some cases not permitted) as you are supposed to delete resources by updating your CDK code to remove that resource, and then redeploying it.

The RemovalPolicy tells CloudFormation what to do if you change your CDK code so that the resource is no longer part of your CDK stack.

For example if you have an S3 bucket you cannot rename it, but you can still change its name in your CDK stack. If you do, CDK will need to remove the old S3 bucket and create a new one with the new name. The same applies for a number of other resources that can't be renamed, such as DynamoDB tables.

How CDK handles removing this old resource is what the RemovalPolicy is for. If you set it to RETAIN it will just forget about it and leave it up to you to clean up manually later. Using the DESTROY policy tells CDK to try to delete your resource automatically along with all the data it contains.

Usually you would use DESTROY if the data is not important and can be easily recreated (e.g. cache data), and RETAIN if the data is important and you would not want to lose it (e.g. user data).

Often it is a good idea just to always use RETAIN. This way if you accidentally make a typo in your CDK stack and rename a resource by mistake, all the data in it won't get deleted!

what option I can use if the script is unable to find the table then it should create ?

You just create the resource normally. When you write a CDK stack, you are not telling it what to do (create this S3 bucket, create this DynamoDB table) but rather you are telling it what you want (I want an S3 bucket with this name, and a DynamoDB table with that name). CDK will figure out which resources need to be created to meet your request, and if CDK has already created those resources in an earlier deploy, it will just update them if changes are needed or leave them untouched if no changes are required.

The reason you got an error after you deleted the resource manually is because CDK was trying to find it to figure out whether it needed to be updated or not. This is why you should never change any AWS resources manually that were configured by CDK - always update the CDK template and redeploy. If you fiddle with the resources manually it is very easy to break CDK, and in that situation the only solution is to destroy the stack, manually clean up any resources that couldn't be destroyed, then redeploy it from scratch (and then also reupload any user data you might have, often a big deal!)

Upvotes: 6

Related Questions