Abuse CDK functionality in CloudFormation

Each “Infrastructure as Code” framework has pros and cons. My go-to framework is CloudFormation, but I like CDK’s tree view, so I started thinking about borrowing this.

What is the tree view?

AWS announced this functionality on September the 14th, 2022.

Customers using CDK want a simple way to map the resources synthesized in a CloudFormation template back to the source CDK Construct.

Normally, the Resources tab looks something like this:

But when you deploy a CDK stack, you get a new option, the Tree view! When you navigate to the stack in the console, you will see the following:

How is CDK using it?

When you write your constructs, each resource will be nested in the construct. You can use a construct inside of a construct. This will result in a nested tree structure like this:

As you might have noticed, there is some unneeded nesting here. At the root level, we have only one entry, the environment name from the pipeline. Then, we have the name of the stack that we use. Going back to the intention of this feature, it makes sense, but we are looking at a stack deployment in CloudFormation. So yes, this will be in the development account we already knew because we logged into it. Next, the stack name, we needed to click the stack name to get to this view. From that point of view, it has no value in showing it here.

The third level becomes more interesting. Here are the constructs that we use inside the stack itself. On this level, CDK does a pretty good job of organizing the resources into logical nested groups. A bucket policy applies to a bucket, so it’s nested under the bucket itself, for example.

How can we abuse it?

When you look at the resource definitions in the synthesized version, you can see how it is done. The bucket will contain some additional metadata like this:

ApplicationBucketPolicy:
 Type: AWS::S3::BucketPolicy
 Metadata:
   aws:cdk:path: Development/AppStack/StaticWebsiteConstruct/Bucket/BucketPolicy/Resource
 Properties:

You can play around with this and organize the resources any way you want. Here is an example that I did to experiment with:

As you can see, this is organized more logically. We have the following major components:

• Database
• DNS
• Authentication
• API

Going into the Authentication, you can see that I have some triggers. Diving deeper, you can see what kind of triggers. From there, you will have the resources needed for the operation, like permissions, log groups, and the function itself.

Known requirements

While playing around with the organization of this tree view, I discovered the following requirements:

• The value in the aws:cdk:path must be unique across the processed template!
• When you use the AWS Serverless Application Model, you need to ensure that the resource definition does not result in multiple resources. (This will lead to multiple values being the same, which will break the rendering of the tree view.)
• When you omit the /Resource at the end, the LogicalId in the template is used. This could lead to uglier names in the tree view.

Conclusion

If you like organizing your CloudFormation templates, check out the tree view. It might have been built for CDK, but you can use it directly in your CloudFormation templates too.

Photo by Pixabay