AWS CDK (Cloud Development Kit)
With AWS providing numerous cloud services that help us to handle the huge amount of data that we are generating these days, the AWS CDK, widely known as AWS Cloud Development Kit, is a smart way for any kind of open-source software development framework to define the cloud application resources by use of programming languages. AWS CDK uses the familiarity and expressive power of the programming languages that help the users build cloud applications with ease by using the constructs( high-level components) which provides preconfigured cloud resources with proven defaults. By implementing AWS CDK you can expedite new projects within your organization as AWS CDK provides the resources in a safe, allows you to share your custom constructs in addition to enabling repeatable manner implementing it with AWS CloudFormation.
Infrastructure Deployment (Manual)
With Manual infrastructure deployment, you either need to use the GUI(graphical user interface) or CLI(command line interface). This involves manual intervention, difficulty in sharing, the creation of a new environment that is not repeatable, not reliable, and consistency is not maintained. The run books(documents containing information about how to set up and run tasks) have to be up to date in addition knowledge transfer is necessary when a change is encountered. Also, when an application uses multiple cloud resources, you will have to spend the same amount of time n number of time for each of the services associated along with ensuring the inter-service permissions are correctly set.
The below diagram represents a workflow for manually processing the service request:
A DevOps engineer would first list the affected cloud services, and simultaneously log in to the corresponding service account for creating, modifying, or deleting resources along with updating the access-control policies. Finally, event triggers need to be set that invokes every time the cloud storage emits a PUT object event. hence, it's clear that Manually managing infrastructure isn’t a feasible option for big projects with complex cloud requirements while it's easier to Manually manage infrastructure for smaller projects. Also, once you work on new projects you could start with manual deployment and then gradually switch to IaC(Infrastructure as Code) if frequent changes are required.
Infrastructure Deployment (Programmatic)
Programmatic infrastructure management is a descriptive model where many cloud providers either offer some way to manage infrastructure using templates or code. With AWS we can manage the infrastructure programmatically either with AWS CloudFormation templates or by implementing AWS CDK. The AWS CloudFormation templates are YAML- or JSON-based configuration files that can be configured together and launched as a stack. Whereas Google offers its Deployment Manager for managing the infrastructure programmatically. Similarly, Microsoft Azure offers Azure Resource Manager (ARM) templates that are JSON templates used to define resources and their relationships. We also have Terraform which supports many cloud providers, like AWS, Google Cloud, and Microsoft Azure where your infrastructure is managed as .tf files using the HashiCorp configuration language (HCL) syntax.
Whether it is AWS CloudFormation, Microsoft ARM, Google Cloud Deployment Manager, or Hashicorp Terraform — all are accessed via the YAML-, JSON-, or TF-based templates, which is not appreciated by developers. The configuration is hard to modularize as the use cases' complexity increases. Hence, with AWS, you can use AWS CDK, whereas, for another cloud provider, Terraform is considered the best IaC solution (use HashiCorp configuration language (HCL) for defining the infrastructure).
Introduction to AWS Cloud Development Kit (AWS CDK)
While provisioning cloud applications a lot of manual actions are required such as writing customized scripts, maintaining templates, or even adopting new domain-specific programming languages. With this paint, developers are not able to focus on the main goal of building and deploying the resources instead a lot of time gets wasted with these manual processes. To solve this pain point, The AWS CDK came into existence which was flexible to let developers code in their familiar programming languages and helped create constraints for their code so that it can be shareable, reusable, and customizable.
The AWS CDK (v.0.8.0) in beta version was launched in 2018 as an alternative approach for developing AWS resources programmatically with the help of TypeScript programming languages. But once this project was made open- source many contributed to the code and feedback helped maintainers track its performance. Developers create reusable cloud components called Constructs which are then assembled into Stacks and Apps.
A few key points of AWS CDK are given below:
- Define more infrastructure with less code by creating high-level constructs.
- Strengthen your infrastructure with engineering methods like unit tests, code reviews, and source control.
- All the code written for the application, infrastructure, and configuration can be kept at one location making it a complete cloud-deployable solution.
- Quickly import the AWS CloudFormation templates to provide the CDK API.
- Implementing the AWS CloudFormation for application's infrastructure deployments for maintaining consistency.
How does AWS CDK Work?
Now let us learn how the AWS CDK works. As we know, AWS offers a tool called CloudFormation template which helps to define your AWS resources. All this can be done via the YAML code which is quite difficult to learn and work with.
For deploying infrastructure using AWS CDK, there are two methods. Either you can use the AWS CDK Toolkit for directly deploying the infrastructure ( via the CLI command CDK) or can use the CloudFormation templates and traditionally deploy them. With the AWS CDK command, you can differentiate against a deployed stack in one line after another method. This helps to view the effect of code adjustments before they get deployed.
The below diagram shows the flow of how the AWS CDK works:
Features of AWS CDK
Listed below are seven key features that the AWS CDK offers to its users and has its wide demand accordingly:
- Using Constructs and CFN Resources(CloudFormation CLI ) for generating the AWS infrastructure: By using the high-level cloud components called 'Constructs' you can encode configuration detail, glue logic, and boilerplate, for one or multiple AWS services. With AWS CDK, you get a library of constructs covering various AWS features and services. This helps to define a high-level applications infrastructure as constructs are highly adjustable and composable. With CFN(CloudFormation CLI) Resources available in the AWS Construct Library you can quickly map 1:1 base-level AWS CloudFormation resources which provisions complete coverage of CloudFormation resources that are readily available after a CloudFormation resource is newly available or even updated.
- Work with familiar tools, programming languages, and workflows: You can model the application's infrastructure in any programming language of your choice( Java, TypeScript, Go, .NET, and Python ). You also get the flexibility to use the existing IDE, testing tools, and workflow patterns by utilizing tools like in-line and autocomplete documentation, helping you to save time by allowing you to quickly switch between the service documentation and the code.
- Command line interface (CLI) was never that Developer-friendly: With AWS CDK you can now get a Developer-friendly interaction with your CDK applications which enables functionality like showcasing the dissimilarities between the running stack and proposed changes, processing a CFN template, validating any changes before deployment, allowing you to deploy multiple stacks on various environments.
- Powered by AWS CloudFormation: With AWS CDK you can quickly define your infrastructure by coding and easily provision it via AWS CloudFormation. By implementing like this you get powered by AWS CloudFormation and start to do an easy rollback, drift detection, and repeatable deployment.
- Collaborative deployment and runtime coding: If you love to work together as a team on application infrastructure, well AWS CDK gives you the flexibility to reference the runtime code assets for the same project and in the same programming language.
- Reuse, share and customize the constructs : You get the capability to Reuse, share and customize the constructs which allows you to get started faster and incorporate the best practices by default.
Benefits of AWS CDK
Let's discuss the four major benefits the AWS CDK offers to its customers and make it a smart way for any kind of open-source software development framework:
Easy Cloud Onboarding : With AWS CDK, you can easily start with your application infrastructure as your onboarding to AWS is accelerated as it is compatible with most of the popular programming languages. It doesn't let your existing skills and tools knowledge go to waste and you can simply start to build cloud infrastructure.
Quick Development Process : With its expressive power and Familiar features such as objects, loops, and conditions of the popular programming languages accelerates your development process with your existing and already integrated development environment (IDE).
Shareable, Reuse and Customize : The constructs once created (meeting your organization’s security, compliance, and governance requirements) are Shareable, Reuse, and Customizable which rapidly bootstrap new projects with best practices by default.
No Context Switching : With AWS CDK, you can start your development process of the cloud application's infrastructure without leaving the IDE. You can simply write your runtime code, visualize your CDK application stacks and resources and define the AWS resources while working with the same programming language as before.
The below diagram shows the Benefits of AWS CDK listed:
Concept of AWS CDK
The core concept which forms the building blocks for AWS CDK is shown in the diagram below:
When any AWS CDK application is arranged, the output is a cloud assembly containing the developed AWS CloudFormation templates. This template contains the stacks and the assets of the application created which can then be deployed using the AWS CDK CLI on to preferred AWS account and region.
The App is the base of any constructs that you shall be built. The App contains the constructed tree where all the stacks and constructs are synthesized into a single Cloudformation template which is then deployed on AWS Cloud. The App includes the Stacks and Constructs
The Stacks are deployable components of the AWS CDK. It can be shareable as it can consume resources from another stack as a project can have either one or more stacks. At the backend, The AWS CDK leverages the AWS CloudFormation import value to process different CloudFormation stacks.
Now inside the AWS CDK stacks lies what is called the high-level component is widely known as Constructs. These Constructs are defined as the AWS resources which include everything that AWS CloudFormation requires to build a reusable and customizable cloud component. These constructs are dived into two constructions as defined below.
L1 construct : Also known as the Low-level constructions with a CFN prefix represent the to CloudFormation resources and properties. These are similar to CloudFormation (instead of JSON or YAML) but created in our familiar programming language.
L2 Construct : Also known as the higher-level constructions. These include building a network address translation (NAT) gateway or even Amazon Virtual Private Cloud (Amazon VPC) in one or many of the Availability Zone (AZ) in a single line of code.
One of the most important components of AWS CDK is the AWS CDK constructs which are referred to as the high-level components that capture all the important configuration detail along with the glue logic offer a range of constructs for commonly used AWS services and features. These are customizable constructs that based on your needs can be reused by changing parameters in the code. These AWS CDK objects are initialized and compiled as a YAML template which can later be deployed as an AWS CloudFormation stack.
Below are a few different mostly commonly used types of constructs, which we shall learn in detail about each one.
The L1 constructs are called the low-level constructs, which comprise and directly represent the resources available in AWS CloudFormation. We shall be talking about two of them namely, the s3.Bucket class which represents the Amazon S3 bucket, and the dynamodb. Table class defines the Amazon DynamoDB table.
Let’s dive into understanding how they are defined in an AWS CDK application.
S3 Bucket Construct
The below code snippet is used to create an S3 bucket where we are attaching a policy that shall grant GetObject permission to the root user's AWS account. We have also used the addToResourcePolicy method which attaches an IAM PolicyStatement that provisions fine-grained permissions to the bucket:
below code snippet is widely used to create a DynamoDB table having the autoscaling rules too:
Both the examples of the S3 bucket and Dynamo DB represent the power of L1 constructs and how they are leveraged to join the resources together.
We also have L2 Constructs which are majorly used to define AWS resources that have a higher-level intent-based API. L2 constructs provide some defaults, glue logic, and boilerplate code, in addition, to the L1 constructs.
With L2 constructs, we can use the bucket.addLifeCycleRule() to define that a lifecycle rule is added to an S3 bucket as shown in below code snippet:
Also, we can use the addCorsRule construct to add the CORS rule to the S3 bucket. We use the rule while trying to access the objects in an S3 bucket via a third-party domain.
L3 constructs are also the highest level of constructs, widely known as patterns. We often make use of them to complete common tasks in AWS, which require the involvement of various kinds of AWS resources. For example, aws-apigateway.LambdaRestApi is implemented with inline code passed to the LambdaRestApi method for connecting with an AWS API Gateway API having an AWS Lambda function too as shown in below code snippet:
How to Get Started with AWS CDK?
We need to follow the below steps as prerequisites to get started with the AWS CDK application.
Configuring the programmatic access to your AWS account : Start by accessing the AWS account where the application's infrastructure shall be created. Move towards accessing the keys for making programmatic calls to AWS. These access keys are created from the AWS IAM console which is then set up in the credentials file.
Installing the AWS CDK Toolkit : We move ahead to install the AWS CDK Toolkit. The AWS CDK Toolkit s an open-source project in GitHub and also the primary tool that helps AWS users easily interact with the AWS CDK application via the CLI command CDK. With this users can use the AWS CDK to generate and finally start producing and deploying the AWS CloudFormation templates.
- On your machine, Start by installing the AWS CDK toolkit by using the node package manager.
- To install the package globally in your terminal use the below command:
For installing the latest version of the AWS CDK toolkit, you can verify the version with the below command:
Setting Up the Prerequisites for CDK
To start working with AWS CDK, We can easily get started with AWS CDK by completing the following steps to get started with working on AWS CDK:
Setting up language-defined prerequisites : As We know that AWS CDK supports the use of multiple programming languages. Hence, we get the flexibility of creating the AWS CDK applications in any programming language of our choice using the language’s familiar tools such as the JDK for Java.
The below command will help to create an empty directory cdk-app and then by implementing the cdk init command you can create a Maven-based CDK project in Java language as shown below:
When you run the cdk init command you will observe the following important CDK commands:
Most Useful Commands are As Shown Below
- cdk deploy deploy this stack in your default AWS account/region
- mvn package compiles and runs the tests
- cdk docs for opening nay AWS CDK documentation
- cdk ls lists all the stacks in the application
- cdk diff used to compare the deployed stack with the current state
- cdk synth emits the synthesized CloudFormation template
CDK Best Practices
Now let us look at some AWS CDK best practices that will help developers start working with AWS CDK to define their cloud infrastructure using a supported programming language and following the best practices from the beginning by default:
Organization Best Practices : As the company starts to adopt the AWS CDK, it's good to have a team of experts for training and guiding as well as setting standards about the usage of cloud infrastructure. A "landing zone" could be handy which define the different units of the company within AWS that could be pre-configured, secure, scalable, multi-account AWS environment based on best practice blueprints. Also, the development teams need to access their accounts for testing and deploying new resources as per need.
below diagram depict how Organization's Best Practices are being followed as the organization starts to adopt AWS CDK:
Coding best practices : The coding best practices start from having a simple code base and only add complexity when the requirement or scenario wants you to, need it, always align with the AWS Well-Architected framework by creating, reusing, and sharing the components (libraries) via the artefact repositories. It is recommended to have a single package in a single repository for each application as this shall help you define how and where the various logical units are being deployed, along with keeping a check on the CI/CD pipeline once you start to deploy the application.
The below diagram depicts the relationship between a team and the team's applications, code repositories, packages, and construct libraries:
Construct best practices : The high-level cloud components also called Constructs are customizable, reusable components that encapsulate the resources and form the base for building and we use the stacks for deployment purposes. and so we should utilize it and make it the most reusable potential in your infrastructure. We can start to configure with properties and methods, as environment variable lookups could only be used to pass in information in a runtime environment. Also, always run a full suite of unit tests for configuring build while building your application infrastructure.
Application best practices : Concerning the Application best practices, it's recommended to make decisions at synthesis time like which construct to instantiate, in your AWS CDK application, etc. Always separate the application into multiple stacks as mentioned in the deployment requirements as this makes it easier to keep multiple resources in the same stack until you have a requirement to separate them. The removal policies and log retention must always be defined before as it prevents any data loss from happening due to accidents or malicious activity.
Developer Tools for AWS CDK
While trying to speed up the development time in addition to improving the code quality, we may require help in the form of tools. Below are a few tools that shall help to improve the workflow when implementing that via AWS CDK:
- Cdk-nag : – To enforce high standards ( or policies) on the AWS resources, you can use the Cdk-nag which shall check the application while building or deploying your CI/CD pipeline as this validates the standards based on a library of rules.
- AWS Toolkit for VS Code : With this you can get a tree view access within the code editor for the CDK Application.
- Visual Studio IntelliCode : – When you build constructs using AWS CDK, with the Visual Studio IntelliCode you can get AI-assisted code completion.
- Projen : For initialization of new CDK projects which are already pre-configured, you can use the Projen tool. This takes care of all the management of the project configuration files for new projects.
- Eslint : With Eslint, you can analyze your code and find bugs based on pre-configured rules.
Let us discuss the pricing structure for AWS CDK. There are no additional or upfront charges attached to AWS CDK. You only get charged for the AWS resources ( Amazon EC2 or Amazon S3 etc) that were created using AWS CDK. You are only charged only for usages made by you without any minimum fees with no upfront commitments.
AWS CDK vs CloudFormation
When we start working with AWS CDK, you will realize how convenient it is to create constructs, share them with groups and invoke new ideas. Many DevOps engineer would recommend using AWS CDK over AWS CloudFormation as the comparison between the two make AWS CDK outshines as explained below:
AWS CDK vs AWS Cloud Formation -
- When we start working with AWS CDK, you will realize how convenient it is to create constructs, share them with groups, reusing the constructs when scenarios were similar leading to spending more time invoking new ideas. Whereas with AWS CloudFormation, sharing AWS CloudFormation templates were not so common, other than sharing code on GitHub.
- AWS CDK behaves as a transpiler (widely known as a source-to-source compiler, that converts a high-level language to another high-level language) for AWS CloudFormation. This happens by turning your TypeScript source definition into a JSON template using the cdk synth that can then be developed using AWS CloudFormation.
- Flexibility to start working with the programming language of our choice. You don't have to define infrastructure by riding declaring resources via the YAML or JSON.
- Speed up the Development time for new resources is accelerated. This happened as the L2/L3 constructs have sensible defaults and security best practice policies already followed and implemented.
- With AWS CDK, you can start by gaining expertise by learning and over time mastering the programming language of your choice (Writing code daily has a transferable effect in another technical job) than writing a YAML file in AWS CloudFormation.
Below is a tweet from one member of the AWS community that make a unique selling point for AWS CDK over AWS Cloud formation:
Note : Always validate code output (with tools like cfn-lint or check) to prevent from misconfiguration of any of your infrastructure as a code (IaaS).
- The AWS Cloud Development Kit is a smart way for any kind of open-source software development framework to define the cloud application resources by use of programming languages.
- AWS CDK uses the familiarity and expressive power of the programming languages that help the users build cloud applications with ease by using the constructs( high-level components) which provide preconfigured cloud resources with proven defaults.
- When we start working with AWS CDK, you will realize how convenient it is to create constructs, share them with groups, reusing the constructs when scenarios were similar leading to spending more time invoking new ideas.
- There are no additional or upfront charges attached to AWS CDK. You only get charged for the AWS resources ( Amazon EC2 or Amazon S3 etc) that were created using AWS CDK. You are only charged only for usages made by you without any minimum fees with no upfront commitments.