AWS CDK — a glimpse into the future.
Since the announcement of the AWS Cloud Development Kit (CDK) in August 2018, we were excited about using it in production-ready environments. Unfortunately, since it’s still in developer preview, we shouldn’t really do that for business-critical applications, so we decided not to play with it outside of our playgrounds. Then, a really good chance happened — we had to build a roadmapper tool for internal use.
This is a follow-up to our first article about our roadmapper tool. If you haven’t seen it yet, you should absolutely read it.
What’s the deal with AWS CDK?
The AWS Cloud Development Kit is a new way to define your infrastructure by using an imperative programming language. Developers can choose from 4 supported languages: Java, JavaScript, TypeScript and C#. Your code is translated into CloudFormation template and deployed on AWS account using a simple and very friendly CLI (Command Line Interface) — AWS CDK Toolkit.
CDK is an additional layer of abstraction on top of CloudFormation resources. It comes with an AWS Construct Library, which consists of reusable components (constructs) that integrate multiple cloud services and follow some best-practices out of the box. Constructs can be used together in Stacks and Apps —which make the project structure. This is a new way of defining cloud infrastructure, which is much simpler and allows e.g. developers to provision needed resources easily, without deep knowledge about complicated services like Identity and Access Management (IAM).
Let’s build something for fun
Back to our case — Roadmapper was pretty simple, so there weren’t many resources needed. Let’s list everything that is necessary to run this app and review it:
- S3 bucket for the Markdown files
- S3 bucket for the Application code
- Cloudfront distribution, because we want a custom domain with TLS certificate for the S3 bucket
- Cognito for identities
- Some IAM roles for people accessing S3 buckets
Above I can see three things I don’t like in CloudFormation, because they require thinking while writing the code: Cognito, CloudFront and IAM. CDK promised me easy encapsulation of AWS best practices, so let’s see if it’s true.
Of course, I don’t want it to be too easy, also CDK’s supported languages do not include my favourite ones, so I need to choose something I don’t really know or like… so let’s go with TypeScript, looks pretty nice and I can ask my frontend colleagues for help when dealing with syntax errors.
After learning the basics of TypeScript I started coding the definition of S3 bucket for Markdown files. It looks like this:
Of course, it had to be a little bit difficult for beginners. First line — awesome, just created a Bucket object, but then I had to configure CORS (oh how I love it ❤️). With some help from our awesome JS geek — Kuba Holak and a little bit of googling, I finally managed to access the correct object and override required configuration. We have it! Let’s create another bucket, this time publicly accessible for application code.
Wait, that was easy. I just had to use grantPublicAccess and… it’s done. I’m starting to like it. Cognito Identity Pool? Just a few lines of code. Okay, let’s move to the hard part — IAM roles. I need my authenticated users to access S3 bucket with Markdown files. I need to create this role and give its ARN (Amazon Resource Name) to Cognito object.
I believe that most of my struggle comes from my unfamiliarity with TypeScript. I could create a Role that can be assumed by FederatedPrincipal that I need to know. Not as easy as promised, but still pretty readable. Then it was smooth, add a statement with a policy that allows sts:AssumeRoleWithWebIdentity , but the last line is what shows what CDK is capable of — bucket.grantRead! Now this role is capable of accessing S3 bucket for reading! 📖
The last thing I need to define is a CloudFront distribution.
Pretty clear, I need an instance of CloudFrontWebDistribution with an origin pointing to S3 bucket that I have at my bucket variable. For alias configuration, I use values from the settings file. As it’s a React application, for every 403 error I redirect it as 200 OK serving index.html . Wait, is that enough? Not bad, still need to create things with simple cdk deploy and voilà. Our application is up and running.
Best practices out of the box
As a Cloud Architect, I wouldn’t be myself if I didn’t check the output of cdk synth . Our template consists of roughly 200 lines of code (in YAML). IAM policies look tight and secure, access is granted only to specified resources and for a limited set of actions. Cloudfront distribution has some nice default options enabled. The good thing is that this is a 100% correct Cloudformation template which is still easily readable by a human. If I don’t want to use CDK anymore, I will just take this template and modify it on my own.
Our first CDK-based application is ready and it was a pretty good experience. Of course, there are always some flaws, like having to debug my code for 2 hours because I didn’t notice that in the meantime there was a new release with breaking changes, but it’s ok for a tool under heavy development. I wouldn’t recommend it yet for production systems, but I encourage everyone to play with it and get familiar, as in the future it might be a very good way to manage your cloud infrastructure.
At Nordcloud we are always looking for talented people. If you enjoy reading this post and would like to work with public cloud projects on a daily basis — check out our open positions here.
