AWS CDK shares many properties of CDKTF – it supports many programming languages, including Typescript, Python, C#, Go (soon), and Java. It also shared the concepts of an App, the program code that describes the infrastructure. The code may create one or more stacks, which are units of deployment. Constructs represent infrastructure resources. These maps directly to the provider’s resources, or more higher-level components. A process called synthesising executes the code to produce Cloudformation JSON resource descriptions, which is then used to provision resources. The AWS CDK-specific tooling is significantly better than what is provided for lain CloudFormation, and also provides additional assets handling in addition to the plain CloudFormation, such as deploying code and data. AWS CDK is focused on AWS naturally and does not support other providers outside of AWS. Technically it is possible to build custom components outside of AWS. A key benefit with AWS CDK is its many higher-level components on top of what is provided by CloudFormation. A general principle is to provide sane best practice defaults and allow customizations if needed. Access permissions and network access have higher-level mechanisms in place. Thus you do not need to understand and know precisely which permissions or security rules to set, the AWS CDK will figure that out for you based on the guidance you have provided. If you connect different resources, it will often automatically set the permissions needed for these to communicate with each other. AWS starts to provide more examples using AWS CDK also, and not only CloudFormation. It is a key toolset for AWS moving forward.