AWS CDK with Python — 1

Why CDK?

Pratik
5 min readAug 8, 2023

AWS Managment Console:

When you are just learning AWS or trying a new service,it is OK to use manual provisioning tools, such as AWS Management Console. You configure everything manually, familiarize yourself with the service, and see whether it will suit your project. However, manual processes like this are prone to errors. You can always forget to configure something.They are not consistent or repeatable. To relaunch a similar infrastructure, you must repeat yourself precisely as before by filling in the forms, clicking buttons, etc. So, manual processes are slow, and you need automation to deploy reliably and fast.

Scripts:

Therefore, DevOps engineers started writing bash or Python scripts to automate this process using AWS CLI commands. But these scripts don’t provide a reliable mechanism for handling failures. For example, what if you lose the connection in the middle of the script or have a bug?What will happen to the AWS resources you created until then? Well. It isn’t easy to roll them back in these cases. So, although deployment scripts solve the automation problem, they bring their own issues.

AWS CloudFormation:

As a result, AWS provided its first infrastructure as code tool as a solution: AWS CloudFormation. While using CloudFormation, you provide a template in JSON or YAML format containing all resources you want to launch declaratively. You set the state of your resources with all necessary configurations. Then, CloudFormation creates a stack from this template and automatically launches the resources as configured in it.

But what happens in case of failure? Well. If your stack creation fails, CloudFormation automatically rolls the stack deployment back by deleting the resources created until that point. Hence, CloudFormation is a well-established and reliable tool to automate your provisioning process on AWS.

However, CloudFormation templates also have limitations.First, you must write them in JSON or YAML declaratively. Hence, you can’t use common control flow tools as in common programming languages. Besides, your templates must be verbose.You must know the resources well and configure their properties in detail. And there is no way to define abstractions like classes, as in object-oriented programming.

AWS CDK

Therefore, to offer a more efficient way to write infrastructure code, AWS launched AWS CDK as an alternative, built on top of CloudFormation. AWS CDK allows you to write infrastructure code using common programming languages like Python, TypeScript, JavaScript, Java, C#/. Net, and Go instead of JSON or YAML. Hence, you can use the expressive power of these programming languages, control flow tools, and abstractions.

WS CDK synthesizes your code into a CloudFormation template and deploys it as a CloudFormation stack. Therefore, as CDK is a tool built on CloudFormation, it is subject to CloudFormation’s limitations during deployment.

What are the main CDK concepts?

Well, first you create a CDK application as the top-level container for your infrastructure code.

Then, you define one or more stacks in this application. And each of these stacks corresponds to a separate CloudFormation stack deployed via your CDK app. And in your stacks, you define constructs that deploy one or more AWS resources.

Constructs

Constructs are the basic building blocks of CDK applications. Now! There are three levels of constructs in CDK.

L1 Constructs

L1 constructs are the lowest level that map to CloudFormation resource types one-to-one, and they are automatically generated from the CloudFormation specification when a new resource type is supported. As in CloudFormation, you must configure each resource property in detail when using L1 constructs. So, you can’t benefit from CDK fully if you only use them.

L2 Constructs

So next, we have L2 level constructs, first-class citizen CDK constructs, which also represent AWS resources, but this time, at a higher level with some convenient defaults according to the most used scenarios and security best practices. Therefore, you don’t need to know the resources as much as in L1 constructs. L2 constructs enable you to use the power of abstractions in programming languages.

For example, you can add a Function URL to a Lambda function using an instance method provided by its L2 construct class. Now, L2 constructs focus on configuring a single resource as the center with some related resources from the same or other AWS services like IAM. So, to create a complete solution, you still need to use different L2 constructs from other services, such as the Table construct from the DynamoDB package, to add a DynamoDB table accessed by your Lambda function.

L3 Constructs

At the highest level, we have L3 constructs or, in other words, CDK patterns. They enable you to bundle resources often from multiple AWS services to create a complete solution instead of defining components using L1 or L2 constructs individually.

For example, using a single L3 construct, you can create a Lambda function with all necessary permissions to access a DynamoDB table. Besides, you can create custom L3 constructs and export them as common libraries in your programming language to share with your colleagues.

Tools

Our primary tool is the CDK Toolkit, a command-line interface to create CDK applications and produce and deploy CloudFormation templates from them.

Besides, if you use Visual Studio Code, there is an open-source plugin, the AWS Toolkit for Visual Studio Code, which provides the CDK Explorer feature to view the components of your CDK apps easily.

--

--

No responses yet