CloudFormation recently announced the IaC generator . It lets you:
- Scan your AWS account and catalogue manually recreated resources.
- Select manually created resources and capture them in a generated CloudFormation template.
Concurrently, CDK announced  a new
cdk migrate command. Which lets you generate a CDK application from CloudFormation.
On paper, these sound amazing! It solves the problem of turning manually created resources into infrastructure-as-code. It opens the door to easily migrate from SAM and Serverless Framework to CDK with a single command.
It was perfect timing because I face these exact challenges on a client project. Here are my first impressions after taking these new capabilities for a spin.
For the CloudFormation IaC generator. The initial scan can take a while if you have a lot of resources in your AWS account.
Once the scan is complete, you can create a template with the discovered resources. And there lies the problem – it’s difficult to find your resources. Because you can only search by “Resource Type”, “Resource Identifier”, “Tag key”, and “Tav value”.
Take API Gateway for example, the “Resource Identifier” is the API ID, not the API name. So I can’t tell which API I’m selecting in this screen. Instead, I have to go back to the API Gateway console and find the ID for the API I want to add to the template.
This was a recurring theme for me. I had to jump back and forth between different service consoles to find my resources.
Unfortunately, many resource types are not covered by the resource scanner.
I encountered many examples of this. Some are minor things like SES email templates. But surprisingly, even important resources such as OpenSearch domains are not supported.
L1 constructs only
Moving to the
cdk migrate command. You can use the new command to convert an existing CloudFormation stack into a CDK app.
But this conversion process only generates CDK L1 constructs. I can understand why they did that but it also makes the generated CDK app less production-ready.
It meant I had to spend a lot of time converting the generated constructs into L2 constructs. Overall, I’m not sure how much time I managed to save over creating a new project by hand.
SAM macros not supported
In my particular use case, I tried to import a CloudFormation stack generated by SAM into CDK. Unfortunately, this didn’t work out of the box. The process failed with an “unreachable” error.
Leaving the unhelpful error message aside. The problem is that SAM templates use the
AWS::Serverless-2016–10–31 macro. Which is not supported by the
cdk migrate command.
Luckily, there is a workaround. In the CloudFormation console, you can view the processed template.
Capture the process template as a JSON file on your local drive.
And run the
cdk migrate command again with the
It’s great to see AWS working to address the problem of manually created resources. The ability to migrate existing CloudFormation templates into CDK is also a welcomed move.
It’s a solid start, but the current state of affairs still leaves a lot to be desired. And I don’t know if I managed to save much time with the
cdk migrate command.
Here are things that I’d love to see:
- The resource scanner to support more resource types. It was a big surprise to me that OpenSearch domains are not supported.
- Display the name of scanned resources so it’s easier to identify them.
cdk migratecommand to generate L2 constructs.
cdk migratecommand to give better error messages.
If you liked this and want to get more practical tips on building real-world applications on AWS, then why not subscribe to my newsletter and never miss a beat? I post weekly tips and best practices and you can get them straight in your inbox.