Join 8k+ readers and level up you AWS game with just 5 mins a week. Every Monday, I share practical tips, tutorials and best practices for building serverless architectures on AWS.
Read on my blog
Read time: 4 minutes
CloudFormation recently announced the IaC generator [1]. It lets you:
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.
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.
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.
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.
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.
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:
cdk migrate
command to generate L2 constructs.cdk migrate
command to support JavaScript.cdk migrate
command to give better error messages.[1] Import entire applications into CloudFormation
[2] Announcing CDK Migrate: A single command to migrate to the AWS CDK
by Yan Cui, AWS Serverless Hero
Join 8k+ readers and level up you AWS game with just 5 mins a week. Every Monday, I share practical tips, tutorials and best practices for building serverless architectures on AWS.
"The offer is strong with this one." Hey there! I've got an awesome offer for you this Star Wars Day. I've partnered with the best AWS content creators to give you 30% off on a fantastic range of AWS books and courses! From left to right: me, Philip Riecks, Sandro Volpicella, Alex DeBrie, Daniel Galati and Tobias Schmidt. Enter the code TBMAPRBD at checkout to get your discount. But hurry, this offer ends in 3 days. Check out these deals: 30% OFF on AppSync Masterclass: Learn fullstack...
I can’t believe it’s May already! It’s been a busy few months here. Here’s what I've been up to and what you might have missed. Blog posts How to handle execution timeouts in AWS Step Functions How to apply the TDD mindset to serverless Here are four ways you can implement WebSockets using serverless DynamoDB now supports cross-account access. But is that a good idea? When to use Step Functions vs. doing it all in a Lambda function When to use API Gateway vs. Lambda Function URLs First...
Step Functions lets you set a timeout on Task states and the whole execution. By default, a Task state times out after 60 seconds. But an execution can run for a year if no TimeoutSeconds is configured. To a user, the execution would appear as “stuck”. AWS best practices recommend using timeouts to avoid such scenarios [1]. So it’s important to consider what happens when you experience a timeout You can use the Catch clause to handle the States.Timeout error when a Task state times out. You...