I am required to modify pre-existing resources using cdk. I understand that there are methods to call upon that allows you to import a given resource, but how can I go about modifying that resource? For example, I have an RDS that was manually created and I want to change the instance type after creation. How do I go about doing that using cdk/cloue formation?
If you'd like to 'take ownership' of a resource in AWS with CloudFormation you can follow the steps outline here. In short:
Create a CloudFormation template that only has the one RDS resource you'd like to take ownership of. Have the template match the resource as much as possible. You should use the CDK to do this, just make sure your CDK code ONLY includes those resources you want to import. That can sometimes be tricky since L2 constructs often create more than just one CloudFormation resource. Trim back the synthesized CloudFormation template as much as needed to get just the one RDS resource you want to import.
Create a new Stack using the 'import' option. It's important that the only resources in the template are resources you are trying to import and 'take ownership of'.
Run Drift Detection and correct anything that is out of sync by updating your template and then running additional Update Stack steps.
You can, of course, have the CDK generate this template. Same rules apply, though. You need to make sure you have only the RDS instance.
Please refer to this post as I go into more detail there.
Additionally, there is a command link option, cdk import which can help do this (not detailed here or in the blog, though).
Once you have the resource imported into a stack you can continue making future changes using the CDK.
Related
I have two CDK/Cfn stacks which instantiate application load balancers with SSL certificates. I'm using DNS validation which the CDK manages by creating a Lambda function which requests and validates the certificates.
Unfortunately, those Lambda functions were manually deleted and now when I try to update my CDK resources, CloudFormation attempts to replace these Lambdas but fails because they no longer exist.
I wish that CloudFormation would behave like Terraform and just say "oh that thing I need to replace isn't there, nbd I needed to replace it anyway, so let's carry on" but it does not.
Not sure how to get out of this jam. Any help is appreciated.
The easiest fix to this drift is redeploying your CDK app with the deleted resource temporarily removed (e.g. commented out). CloudFormation will "delete" the already deleted resource, bringing the template back into sync with the deployed configuration. Then add back the resource to your app and deploy again. Problem solved.
There's a complication in your case. The missing Lambda function is being constructed indirectly by a higher-level CDK construct. Removing the L2/L3 parent will destroy more resources than just the Lambda. If you want to avoid this collateral damage, you can use escape hatch syntax and the node.tryRemoveChild method to surgically remove the missing Lambda only.
You have to import them back to CloudFormation. In TF it is same, and you also import resources into TF.
Could you please suggest easy way to copy/move already created AWS stuffs from current VPC to another ?
There is no "easy" way but you can use different tools to import existing resources and deploy them to different VPCs.
There is a free tool called Former2 (https://github.com/iann0036/former2) which can be used to scan existing resources and produce outputs. These outputs can be used to deploy new resources. I tested this tool and it seems to be quite intuitive to use to gather information about existing resources and produce outputs in different template languages (Cloudformation, Terraform, CDK, Stroposphere, Pulumi).
Terraform can be used to import existing resources to the current state and after that copy resources to configuration. Future versions of Terraform will be able to also update the configuration. To use terraform you must know every resource you want to import and use import command with their ids. Terraform does not support nested imports so importing vpc does not add subnets or other resources to the state but they have to be imported separately.
I think CloudFormation has also import feature but specific resource template must be written beforehand and submitted during the import. This is not an easy or fast way to copy resources but should work and as an end product there should a template which can be used to deploy resources to another VPCs.
As described in the documentation, I think CloudFormation will update with no interruption just by changing to add a tag.
In my case, another team uses terraform to add tag resources with generic tags, and my team uses CloudFormation to update the application-specific tags. Does this cause replacement...?
Also, this only occurred for limited resources such as security groups.
Does anyone know anything about this issue?
Cloudformation is a Jealous Tool - in otherwords, if it doesn't control the Resource in entirety it will overwrite changes, assuming that the changes are in a location it thinks it has to update.
In order for CloudFormation stacks not to do work that is not needed they generate ChangeSets - indicating what resources need updating/rebuilding/ect. If you don't change anything in the template (or your cdk stack) then the ChangeSet won't update that resource cause nothing needs to change. Depending on the resource (and it varies from service to service) sometimes changes made outside of CloudFormation control (by either other services like Terraform or by manual changes in the console - both of which are referred to as 'Drift') dont get overwritten by the stack updating (most common I can think of is API gateway - adding / deleting resources or methods doesn't always get re done by a redeploy of the stack.
However, for things like tags, yes - it will overwrite any changes made in there at any time and reapply the tags as of the moment it deploys - (again, depending on the Service) often even if there are no other changes to deploy for that given resource. I suspect the reason for this is because of the way AWS uses tags on the backend to sort and search resources.
Your best bet is to pick one service and do everything with it.
Each of these two tools will overwrite the tags the other created. You can configure Terraform to ignore certain tags However I'm not sure you can configure CloudFormation to ignore any tags. I think CloudFormation will always delete tags that it doesn't manage. In general it's not going to work well using both CloudFormation and Terraform to manage the same resources.
I followed all the steps mentioned in the official blog post here:
Remediate drift via resource import with AWS CloudFormation | AWS Management & Governance Blog
Instead of using "import resource" at step 4, if I use "update" button, I get the same results.
Select our stack and Import resource into stack, from the Stack actions menu.
What is the difference between Update and Import?
Update is normally used to tell CloudFormation that the template has changed. This can result in new resources being created, modified or deleted.
CloudFormation is not aware of any changes made outside of itself, so it is preferable to always change resources through CloudFormation so that it remains in-sync with the resource configuration.
That article seems to pushing the idea that, if something has changed outside of CloudFormation, it is best to "forget" about the resource, then Import it into the stack. An Import adds an existing resource to the stack without CloudFormation attempting to create it.
I guess Updating the DynamoDB table works because only the BILLING_MODE has changed. It is possible that CloudFormation can become confused when it tries to make a change that has already been made. For example, if a subnet needs to change AZs, it will need to delete and recreate the subnet. This would lead to resources with different IDs. In such a case, the recommended process of Forget + Import would need to be used.
Bottom line: The article is showing the general process, but in some situations, and Update might suffice.
I've got a big-ass Serverless project and I wonder if matching the cloud formation template schema with CDK would do the trick, or is there something extra to the process.
It is possible to deploy a CDK app to an existing CloudFormation stack, although it would be very difficult to achieve for non-trivial stacks since CDK apps usually involve many resources.
The cdk diff command will be your best friend. You can name your stack in the CDK app using the same name as the existing stack:
MyExistingStack(app, 'my-existing-stack')
Then you can iteratively add/remove resources and run cdk diff to check your success in matching the current deployment. CDK will additionally create metadata resources that will be added to the stack in addition to the currently existing resources.
Matching resource names can be difficult. CDK automatically names many of the resources in a way that will not match you existing stack. Following the instructions on CDK Escape Hatches, you can access lower level CFN Resources directly and modify the name.
If a Construct is missing a feature or you are trying to work around an issue, you can modify the CFN Resource that is encapsulated by the Construct.
All Constructs contain within them the corresponding CFN Resource. For example, the high-level Bucket construct wraps the low-level CfnBucket construct. Because the CfnBucket corresponds directly to the AWS CloudFormation resource, it exposes all features that are available through AWS CloudFormation.
The basic approach to get access to the CFN Resource class is to use construct.node.defaultChild (Python: default_child), cast it to the right type (if necessary), and modify its properties.