First impressions of CloudFormation’s IaC generator and CDK migrate

AWS recently announced the CloudFormation IaC generator [1]. It lets you:

1. Scan your AWS account and catalogue manually recreated resources.
2. Select manually created resources and capture them in a generated CloudFormation template.

Concurrently, CDK announced [2] 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.

Navigation problems

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.

Resource coverage

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.

No JavaScript support

Interestingly, the cdk migrate command doesn’t support JavaScript as the output language.

I guess the reason is that you can’t declare custom interface types in JavaScript. The generated CDK code includes custom stack property types. This wouldn’t have been possible with JavaScript.

Nonetheless, this means more work for teams who are using CDK with JavaScript.

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 --from-path flag.

Summary

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 the CloudFormation IaC Generator still leaves a lot to be desired. And I don’t think 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.
• The cdk migrate command to generate L2 constructs.
• The cdk migrate command to support JavaScript.
• The cdk migrate command 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.

Links

[1] Import entire applications into CloudFormation

[2] Announcing CDK Migrate: A single command to migrate to the AWS CDK