CDK - under Construction - should we use it for the next project?


Should we use CDK for the next project?

The AWS CDK (Cloud Development Kit) is great - and still in beta - so the question for the next project would be:

Should we use cdk or not?

This post will look at the state of the cdk. Also we provide our CDK Templates updated to the CDK Version 0.38 if you want to get started.

See this diagramm for the number of features, bugs and breaking changes of the CDK this year.

CDK convergion

The y scale show us the breaking changes. If a breaking change affects your CDK project, you have to update our code. But how breaking are these changes? Should they stop us from using the CDK?

To get an answer we also have to look at the number of features but also on the number of bugs. If the CDK is stabilizing, my assumption is, that we want to have:

  • small bubbles, because that would mean the main work of implementing constructs is done and only the new CloudFormation features will be added
  • dark bubbles, which means less bugfixes which hopefully means less bugs :)
  • bubbles at the bottom, so less breaking features

But what means “breaking change” in ammount of time we need to update a project to a new CDK version? Let’s have a look!

A few examples for that from our CDK Templates:

Some “breaking changes”

Change in 0.36: rename core module

This is an easy one. Text in changelog says:

“ core: the @aws-cdk/cdk module was renamed to @aws-cdk/core, python: aws_cdk.core, java: the artifact cdk in groupId was renamed to core “


import cdk = require('@aws-cdk/cdk');


import cdk = require('@aws-cdk/core');

0.35 rename managedPolicyArn

This gives you a small task to think. The changelog says:

“ iam: managedPolicyArns renamed to managedPolicies, takes return value from ManagedPolicy.fromAwsManagedPolicyName(). “

To solve this, you go to the CDK TypeScript Reference

and goto aws-iam/ManagedPolicy.

(Just searching for ManagedPolicy.fromAwsManagedPolicyName gives no result.)

The documentation shows you how to change the code.


   managedPolicyArns: ['arn:aws:iam::aws:policy/service-role/AmazonEC2RoleforSSM'],


 managedPolicies: [ManagedPolicy.fromAwsManagedPolicyName('service-role/AmazonEC2RoleforSSM')],

0.37 EC2 instance Autoscaling Group

This is one of the tiny number of small changes, which did not make it into the changelog 0.37, but 0.38:

“ chore: fix build by conflict introduced with parallel PRs (#2992)

new InstanceTypePair was renamed to InstanceType.of. “


   const asg = new autoscaling.AutoScalingGroup(this, 'ASG', {
      instanceType: new ec2.InstanceTypePair(ec2.InstanceClass.Burstable2, ec2.InstanceSize.Micro),
      machineImage: new ec2.AmazonLinuxImage({generation: AmazonLinuxGeneration.AmazonLinux2}),


 const asg = new autoscaling.AutoScalingGroup(this, 'ASG', {
      vpc: albVpc,
      instanceType: InstanceType.of(InstanceClass.BURSTABLE2, InstanceSize.MICRO),
      machineImage: new AmazonLinuxImage({generation: AmazonLinuxGeneration.AMAZON_LINUX_2}),
      role: instanceRole,

Breaking Workaround

Another possibility is to just use a fixed version of the cdk. But it is recommended that you update to a newer version soon. Because it is less work updaten minor breaking changes than to update a lot of changes.

Why CDK is better than pure CloudFormation

(and most other IaC frameworks)

  • Abstract constructs give you bundles of ressources with less code
  • e.g. you do not have to implement each resource of a test VPC, you just add a VPC
  • You can really code:
    • import data files
    • loops
    • AutoCompletion from editor
  • integrate with assets like lambda functions or Docker containers
  • write your own extensions
  • Embedded CLI to manage multiple stacks

and so on…

Bottom Line

If you just look at the number of breaking changes you could say the CDK is not stable enough. But if you compare the benefits i would still say:

Use it! (personal opinion)

[Update] Some comments said i was ignoring the evidence when coming to this conclusion:

What i meant is - compare for yourself the cost of the refactoring (which i thought is relatively easy) against the benefits of using the tool (which i think is good). The conclusion is different for each project and person.