To anyone who isn't aware what is CDK and why use it, my reasons are:
1. It's the actual "code" part of infrastructure as code. For "developers who also like ops" this is a great way to let anyone who can write code (CDK supports most major languages) contribute to a project's infra pretty much the same way as you would use the AWS SDK for the backend services themselves.
2. Let's face it, terraform is so popular because CloudFormation missed the mark, it is too verbose and fine grained, no sensible defaults, pretty much the assembly language of our days. CDK fixes that by adding high level constructs, e.g. in one line of CDK, e.g. new ec2.Vpc(this, "MyVPC") you create a VPC with sane defaults (it will pick the right CIDR arrangement, multi-AZ, both private and public subnets etc). You can override everything but you get the sensible defaults. What I also love about it is how it abstracts IAM permissions and make it easy to be least privilege, by just writing dynamoTable.grantRead(lambdaFunction) CDK creates the right execution role and policy for you.
3. It has 1:1 support also with plain old CFN too, (other than the high level constructs), so still writing things with type safety, autocompletion is more fun to me than writing the same thing in JSON / YAML.
4. It generates plain old (and mostly readable) CloudFormation templates.
5. There is experimental support for "CDK for Terraform", so if you don't really want CloudFormation behind the scenes, but love being able to just import a ts file with a high level construct you made, or have a for loop or if statement in your infra-as-code, you are not limited to CloudFormation
YMMV and I know CDK is too little too late, but for teams that have no DevOps engineers and want to create infra as code using the same language as the rest of the code, (and write unit tests on your infra-as-code, how about that!) then CDK is an amazing solution IMHO (disclaimer - I used to work at AWS and perhaps I'm a bit biased, but I chose CDK for my startup as well, and it allowed our engineers to contribute to infra as code pretty fast as they are already familiar with TypeScript, and the fact that CDK has a very strong type guards, makes it so that it's harder to get it wrong on compile time... )
1. It's the actual "code" part of infrastructure as code. For "developers who also like ops" this is a great way to let anyone who can write code (CDK supports most major languages) contribute to a project's infra pretty much the same way as you would use the AWS SDK for the backend services themselves.
2. Let's face it, terraform is so popular because CloudFormation missed the mark, it is too verbose and fine grained, no sensible defaults, pretty much the assembly language of our days. CDK fixes that by adding high level constructs, e.g. in one line of CDK, e.g. new ec2.Vpc(this, "MyVPC") you create a VPC with sane defaults (it will pick the right CIDR arrangement, multi-AZ, both private and public subnets etc). You can override everything but you get the sensible defaults. What I also love about it is how it abstracts IAM permissions and make it easy to be least privilege, by just writing dynamoTable.grantRead(lambdaFunction) CDK creates the right execution role and policy for you.
3. It has 1:1 support also with plain old CFN too, (other than the high level constructs), so still writing things with type safety, autocompletion is more fun to me than writing the same thing in JSON / YAML.
4. It generates plain old (and mostly readable) CloudFormation templates.
5. There is experimental support for "CDK for Terraform", so if you don't really want CloudFormation behind the scenes, but love being able to just import a ts file with a high level construct you made, or have a for loop or if statement in your infra-as-code, you are not limited to CloudFormation
YMMV and I know CDK is too little too late, but for teams that have no DevOps engineers and want to create infra as code using the same language as the rest of the code, (and write unit tests on your infra-as-code, how about that!) then CDK is an amazing solution IMHO (disclaimer - I used to work at AWS and perhaps I'm a bit biased, but I chose CDK for my startup as well, and it allowed our engineers to contribute to infra as code pretty fast as they are already familiar with TypeScript, and the fact that CDK has a very strong type guards, makes it so that it's harder to get it wrong on compile time... )