My First Foray Into The AWS CDK

I've been a long-time self-admitted Terraform addict. I'll Terraform anything down to a single-page S3-based website. So when a close friend (who I trust to give good tech advice) recommended using the AWS Cloud Development Kit, I was skeptical. The AWS CLI is great, but CloudFormation (which the CDK uses under the hood) is... well... not the greatest user experience. But I figured I'd give it a try, and I already had a side project with a small infrastructure footprint to tinker with.

Installing The CDK

This was one of the most confusing parts of this whole process. You have to install it as a global NPM package, even if you're not working on a Node project (for example, I'm using the Python libraries). It was strange, but it works.

Writing Out Your Infrastructure Is Fun(?)

This is definitely the neatest part of using this tool. You get the normal Infra-as-Code concepts, including really useful code hints. However, you also get the power of object-oriented programming. You can use Python code alongside your infrastructure (e.g. generating a unique ID). You can reference other resources like you can with Terraform, but the CDK also offers AWS-native concepts. For example, instead of needing to know an EC2 Instance Type id, you can use ec2.InstanceSize.MICRO.

The tool also offers a concept of Patterns, which are predefined best practices with minimal configuration required. For example, I created a full Fargate stack with Load Balancers, Target Groups, and networking using a single Pattern called ecs_patterns.ApplicationLoadBalancedFargateService. I also needed an RDS database - the rds.DatabaseInstance Pattern setup the database, chose the correct subnets from my VPC, and created a Secret Manager entry for the connection info.

All of this from one block of code! For someone who hates networking and configuring security groups, this was magical. I just described an abstract concept of what I wanted, and the tool figured out the underlying connection points.

Deploying The Stack Is Slow

The speed of CloudFormation is a huge bottleneck to using this tool to it's full potential. Changes take forever to apply, and the slightest failure triggers a full (and extremely slow) rollback. A successful deploy took ~5 minutes. A failed deploy and rollback took ~8 minutes. Keep in mind you have to wait for this every time you make a change.

The CLI offers a really neat mode called watch, which automatically applies changes every time you save a file. However, the agonizing slowness of changes renders it essentially useless. You have to wait for a full deployment every time you save a file. If you try to keep editing, it gets too far behind in changes and can become undeployable. However, the concept of watch is amazing, and I would absolutely love using i.

That being said, when your deployments are succeeding, it's a really amazing flow. You use a similar write -> plan -> deploy workflow as Terraform. Another interesting note - since the changes are being run in CloudFormation, you don't need to keep your laptop open.

Changes Are Fraught and Rollbacks Are Painful

If a single resource failed to create (which happened often, for weird reasons), the whole stack tries to roll back. It takes a pretty long time for CloudFormation to detect a failure, especially if it happens during the image deployment to ECS.

In some cases, I got stuck with this error and had to delete the stack manually through the console.

?The stack named dev failed creation, it may need to be manually deleted from the AWS console: ROLLBACK_COMPLETE

This happened multiple times. One time, deleting the stack manually didn't delete the Load Balancer, so my next deploy from scratch failed and, of course, rolled back.

Overall, getting from 0 to your first successful deploy is a challenging experience that would make me hesitant to use this in production. I'm sure it will improve over time

Nice Docker/ECR Integration

I needed to deploy a local Docker image to ECR. The flow was seamless - one aws_ecr_assets.DockerImageAsset creates the ECR repo for you, then builds and pushes your image on every deployment. Terraform has some ways of doing this, but none of them are this straightforward.

Security Is Front And Center

This will likely be a selling point for InfoSec teams. By default, the CDK explicitly requires approval for security changes. You can also override to require approval for all changes. If AWS expands on this, I could imagine having a human-in-the-loop deploy step to approve any high-risk changes. You could write your own rulesets.

You can also use their add-on tool cdk-nag to write security tests against your CDK code to enforce best practices. I imagine this is similar to tfsec.

Finding Help Can Be Hard

I had issues finding good solutions to problems I ran into. Stackoverflow was surprisingly sparse. The Github issues occasionally had workarounds. The Developer Guides were both verbose and barely useful - par for the course with fresh AWS docs. Bobbyhadz.com was hands down the best place source of concrete examples (thanks Borislav Hadzhiev !).

Overall, A Great Tool

I'm definitely going to start using this for small projects. Writing out the infrastructure felt much smoother than Terraform. The power of object-oriented programming mixed with support for native cloud resources makes the tool extremely powerful. There's some work to be done on the AWS side to improve the deployment speed and provide better error handling. However, when considering all of the pros and cons I found, I'd argue it's on par with Terraform and may even surpass it in the near future!