AWS announced the general availability (GA) of CDK Migrate, a component of the AWS Cloud Development Kit (CDK – an open source project), which enables developers to migrate AWS CloudFormation templates, previously deployed CloudFormation stacks or resources created outside of Infrastructure as Code (IaC) into a CDK application.
With the GA release of CDK Migrate, the company also launched the CloudFormation IaC Generator, which helps developers import resources created outside of CloudFormation into a template and a newly generated, fully managed CloudFormation stack.
Various methods exist for creating and managing resources in AWS, including "ClickOps" via the AWS Console, AWS APIs, or Infrastructure as Code (IaC). While managing resources with IaC is recommended, it can be an on-ramp for getting started, often resorting to console usage, which can suffice for smaller cases but becomes cumbersome as complexity increases, primarily when replicating configurations across multiple accounts, environments, or regions, leading to potential errors.
Adam Keller, a senior technologist at AWS, writes:
IaC is built to help solve this problem by allowing users to define once and deploy everywhere. For those who have been putting off the move to IaC, now is the time to take the plunge with the IaC generator functionality and CDK migrate, which can accelerate and simplify the move.
Yet he also mentioned limitations in a tweet:
I'm super stoked about this feature and what folks can do with it. That said, there are some limitations when importing *some* resource types - see here: https://t.co/jKV2WR6LrR
The migration from the CloudFormation template to the CDK is done with a single command: cdk migrate. The output and result from running the command will be a directory comprised of the CDK code and dependencies, yet it will not deploy the stack. The CDK CLI will convert the template and create a project folder along with the required dependencies for the CDK application.
CDK Migrate Command (Source: AWS DevOps blog post)
The output will represent the scaffold for the CDK Typescript application that is ready for deployment. Before deployment, developers might need to run the cdk bootstrap command, which creates assets required for the CDK to deploy resources to the region and account properly. Next, they can run a cdk diff to see what will be deployed - it creates a change set and surfaces the changes being proposed. And finally, they can deploy the stack by running the cdk deploy command.
Yan Cui, an AWS serverless hero, expressed in a tweet his enthusiasm for CDK Migrate:
I'm not a fan of CDK, but this does look pretty cool.
With sheraz responding:
What I have seen is people coming from sysops prefer declarative stacks, whether it’s AWS CFN or terraform HCL, and people from dev backgrounds prefer CDKs/Pulumi.
And Teri Radichel, an AWS Security Hero, described in a lengthy tweet:
I get why people use the CDK who don’t want to learn CloudFormation or don’t want to write it. But the CDK writes CloudFormation under the hood…
Sometimes, the layers are helpful. They help you get things done faster. CDK may do that. But for me, I’d rather just learn CloudFormation and create reusable templates aligned with governance standards in my organization and eliminate the layers. If someone wants to use the CDK to create an initial template, that’s cool. But check the templates into source control and use drift detection...
I thought CDK was a tool to help people who don’t know how to write CloudFormation and don’t want to learn. Feeding templates into a system that writes templates makes no sense to me. But to each his own.
Lastly, more details and guidance are available in the best practices guide, CDK workshop, and CDK Live! YouTube channel.
