Everything about AWS CDK

Infrastructure as Code

Infrastructure as code is the process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools.

In simple words - Infrastructure as code (IaC) means to manage your IT infrastructure using configuration files.

If you want to know more about Infrastructure as Code and and when to use different IaC tools take a look at this article of mine.

What is Infrastructure-as-Code and how is Terraform, CDK Ansible different?

AWS CDK

• The AWS Cloud Development Kit (AWS CDK) is an open-source software development framework to define cloud infrastructure in code and provision it through AWS CloudFormation.

• It offers a high-level object-oriented abstraction to define AWS resources imperatively using the power of modern programming languages. Using the CDK's library of infrastructure constructs, you can easily encapsulate AWS best practices in your infrastructure definition and share it without worrying about boilerplate logic.

• The AWS CDK has first-class support for TypeScript, JavaScript, Python, Java, and C#.

Why AWS CDK?

• Powered by AWS CloudFormation - AWS CDK enables you to define your infrastructure with code and provision it through AWS CloudFormation. You get all the benefits of CloudFormation, including repeatable deployment, easy rollback, and drift detection.

• Use familiar programming languages, tools, and workflows - AWS CDK enables you to model application infrastructure using TypeScript, Python, Java, and .NET. With CDK developers can use existing IDE, testing tools, and workflow patterns. By leveraging tools like autocomplete and in-line documentation, AWS CDK enables you to spend less time switching between service documentation and your code.

• Deploy infrastructure and runtime code together - AWS CDK enables you to reference your runtime code assets in the same project with the same programming language. For example, you can include your AWS Lambda runtime code or Docker container image in your CDK project, and when you deploy your application, the CDK framework automatically uploads and configures the AWS service with your runtime assets. When the CDK deployment is complete, you will have a fully functional application.

• Developer-friendly command line interface (CLI) - The AWS CDK CLI enables you to interact with your CDK applications and enables functionality such as synthesizing a CFN template, showing the differences between the running stack and proposed changes, confirming security related changes prior to deployment, and deploying multiple stacks across multiple environments.

And more advantages

• Use logic (if statements, for-loops, etc) when defining your infrastructure
• Use object-oriented techniques to create a model of your system
• Define high level abstractions, share them, and publish them to your team, company, or community
• Organize your project into logical modules
• Share and reuse your infrastructure as a library
• Testing your infrastructure code using industry-standard protocols
• Use your existing code review workflow
• Code completion within your IDE

CDK Code structure

Apps

• Executable program
• Used to render and deploy cfn templates

Stacks

• Deployable unit
• Knows about region and account

Constructs

• Representations of AWS resources
• Can form a hierarchical tree structure

• They are files that include everything needed to deploy your app to a cloud environment.

• The unit of deployment in the AWS CDK is called a stack. All AWS resources defined within the scope of a stack, either directly or indirectly, are provisioned as a single unit. Because AWS CDK stacks are implemented through AWS CloudFormation stacks, they have the same limitations as in AWS CloudFormation.

• Constructs are the basic building blocks of AWS CDK apps. A construct represents a "cloud component" and encapsulates everything AWS CloudFormation needs to create the component.

A construct can represent a single resource, such as an Amazon Simple Storage Service (Amazon S3) bucket, or it can represent a higher-level component consisting of multiple AWS resources. Examples of such components include a worker queue with its associated compute capacity, a cron job with monitoring resources and a dashboard, or even an entire app spanning multiple AWS accounts and regions.

More on Constructs

Level 1 Construct

CFN Resources are periodically generated from the AWS CloudFormation Resource Specification. They are named CfnXyz, where Xyz is name of the resource. For example, CfnBucket represents the AWS::S3::Bucket AWS CloudFormation resource. When you use Cfn resources, you must explicitly configure all resource properties, which requires a complete understanding of the details of the underlying AWS CloudFormation resource model.

Level 2 Construct

The next level of constructs, L2, also represent AWS resources, but with a higher-level, intent-based API. They provide similar functionality, but provide the defaults, boilerplate, and glue logic you'd be writing yourself with a CFN Resource construct. AWS constructs offer convenient defaults and reduce the need to know all the details about the AWS resources they represent, while providing convenience methods that make it simpler to work with the resource. For example, the s3.Bucket class represents an Amazon S3 bucket with additional properties and methods, such as bucket.addLifeCycleRule(), which adds a lifecycle rule to the bucket.

Pattern Construct

Finally, the AWS Construct Library includes even higher-level constructs, which we call patterns. These constructs are designed to help you complete common tasks in AWS, often involving multiple kinds of resources. For example, the aws-ecs-patterns.ApplicationLoadBalancedFargateService construct represents an architecture that includes an AWS Fargate container cluster employing an Application Load Balancer (ALB). The aws-apigateway.LambdaRestApi construct represents an Amazon API Gateway API that's backed by an AWS Lambda function.

CDK Lifecycle

1. CDK (with help of AWS CLI) compiles its 'App' (App is the executable program that contains Stacks and Constructs
2. CDK synthesizes the code to convert it into CloudFormation template. When you run cdk deploy the code we placed in lib/<code_name>.ts is parsed by the CDK Framework which then generates a CloudFormation template located in the cdk.out folder and finally deploys it to CloudFormation. 3. CloudFormation template gets deployed in AWS account and runs to create all the AWS components

AWS workflow