From Terraform to CDK

Published in

carsales-dev

5 min readMar 1, 2021

Our journey of migrating to CDK (Part 1)

In the past few years, our team was using terraform to manage all our AWS resources. In July 2019, AWS launched CDK, a code-first approach to defining AWS based application infrastructure. In this series, we will explore the migration journey from terraform to AWS CDK together by an simple example. This is also my first attempt with AWS CDK and I will share the lessons learnt.

System Overview

In this article, we will migrate a simple SPA website which consists one R53 record, one Cloudfront distribution, one certificate in the Virginia region and five s3 buckets in theSydney region. Cloudfront distribution only accepts certificate from US East (N. Virginia) in the AWS Certificate Manager for HTTPS between viewers and Cloudfront.

First Attempt

After reading a number of documents about migrating existing resource to CDK, I understood that CDK supports converting resources in existing Cloudformation templates to AWS by cloudformation-includemodule. Our first thought was to use cloudfomer to generate cloudformation templates and then use cloudformation-include module to reference the resources in the CDK application. It sounded great, however, cloudformer is deprecated and no longer maintained by AWS.

Second Attempt

Thanks to some helpful hints from Vikas Bajaj, I approached my second attempt using the following process:

Create an empty stack by CDK.

Then rewrite infrastructure in CDK.

Use cdk synth to generate cloudformation template.

Import the existing resource into the empty stack with the template generated by cdk synth .

Use cdk diff to check the difference.

This time, it worked!

We then had to make the S3 bucket a bit more complex by adding one BucketPolicy and repeating the process.

Unfortunately, BucketPolicy is not supported for resource importing. This is the same for Cloudfront distribution and Certificate in Certificate manager. Therefore, this approach would not work for us. However, if your AWS resources are in the supported list for importing, this is a nice way to migrate.

Final Solution

As it was impossible to import the resources into a new stack, I had to recreate them by CDK. This was the process I followed:

Create a stack in the Virginia region for the certificate and write the certificate ARN to parameter store.
Create a stack in Sydney region for S3 buckets, Cloudfront distribution and a custom resource for reading certificate ARN from parameter store.

Single Cloudformation stack cannot create resources cross regions. Hence, we created two stacks. AWS CDK supports cross stack resource reference. But it is not supported if the referencing resource is in a different region stack. Hence, we write certificate arn to parameter store in Virginia region and a custom resource to read it within the Sydney region stack.

The custom resource for reading Parameter

Use aws s3 sync to copy files from the source bucket to new bucket.
At last, move the subdomain name to the new Cloudfront distribution. Here is the AWS recommended steps to move subdomain name to another distribution.

Summary

During this journey, we’ve tried three ways to migrate resources created by terraform. If your resources are supported in the import list, you are best to follow the second approach to import your resources into new Cloudformation stack.

From my experience, CDK has the following advantages comparing with Terraform:

Support complex logic (if, for and any combination).
Object oriented program in which I can use familiar language to modularize the infrastructure project and create a shared library.
No state file.
Custom resource. Theoretically, I can do any operation within stack.
Quicker coverage for new features.

However, there are some disadvantages:

More code.
Longer learning curve. Although AWS provides a lots of examples and reference documents, it is still hard to locate some properties, especially when your coding language is not typescript.
Some properties are not exposed yet.
No cross-region stack. Terraform can create resources in a different region easily by different provider.
Hard to reference resources in a different region stack.

As a dev, my preference is to use CDK to manage my future AWS infrastructure.

Although Cloudfomer is deprecated, there is another third party tool called Former2 which provides similar functionality, better resource coverage and is still actively maintained. In next article, I will explore Former2 to find out whether it can accelerate our migration.