Understanding AWS-CDK Directory Structure

I am in the process of learning AWS-CDK using Typescript. I am coming from a Terraform background so I am having re-learn and unlearn a lot of the concepts I have taken for granted when coding IaC. Its super important to understand the directory structure of your CDK App and what the default CDK Files do.

If you want to learn CDK, I can highly recommend the CDK Workshop website.

Step 1 – Create a Working Folder and Init CDK

Create yourself a CDK folder. Something like

mkdir cdk-workshop && cd cdk-workshop

Then use the CDK Init command

cdk init sample-app --language typescript

Step 2 – Open your Folder in your Favourite IDE to browse CDK Files

In this example I will be using WebStorm by JetBrains to examine my CDK Files

Understanding the CDK Files Folder Structure

lib/cdk-workshop-stack.ts:

This file acts as the heart of your AWS CDK application. Here, you define your CDK stacks, the primary building blocks of your infrastructure. Constructs, representing AWS resources and their configurations, make up these stacks. You define desired resources in this file, such as Amazon S3 buckets, AWS Lambda functions, Amazon DynamoDB tables, and more. Most of your design and specification work will occur here.

bin/cdk-workshop.ts:

This file is your CDK application’s entry point. It loads and deploys the stack from the lib/cdk-workshop-stack.ts file. Additionally, it might have code for configuring the deployment environment, setting regions, and specifying stack parameters.

package.json:

This file serves as a manifest for your npm module and contains details about your project. It carries metadata like your application’s name, version, and dependencies. Here, you can also define scripts for tasks such as building, testing, and deploying your application. npm generates and maintains the package-lock.json file to ensure deterministic dependency resolution.

cdk.json:

The AWS CDK Toolkit uses this configuration file to determine your application’s run and deployment methods. It defines the deployment command for the CDK application, typically “npx ts-node bin/cdk-workshop.ts”. You can tailor this configuration to your specific deployment needs.

tsconfig.json:

This TypeScript configuration file sets the rules for transpiling and compiling your TypeScript code. It outlines compiler options like target, module type, and source map settings. Setting TypeScript options here ensures consistent and correct code compilation throughout your project.

.gitignore and .npmignore:

These files instruct version control systems (like Git) and the npm package manager on which files and directories to exclude when tracking changes or publishing the package. Excluding unnecessary files from your repository or package distribution is vital.

node_modules:

npm creates and oversees this directory. It houses all your project’s dependencies, including the AWS CDK libraries and any third-party libraries. npm takes care of the installation and management of dependencies based on your package.json file.

App Entry Point and Main Stack information

Within the AWS CDK (Cloud Development Kit) framework, both the “App entry point” and the “main stack” are pivotal in defining and deploying your infrastructure as code.

App Entry Point: The App entry point kickstarts your AWS CDK application. In your example, the bin/cdk-workshop.ts file serves as the entry point. It initializes your CDK application and determines which stacks to deploy. Let’s delve into the code you provided:

#!/usr/bin/env node
import * as cdk from 'aws-cdk-lib';
import { CdkWorkshopStack } from '../lib/cdk-workshop-stack';

const app = new cdk.App();
new CdkWorkshopStack(app, 'CdkWorkshopStack');

• The #!/usr/bin/env node line is called a shebang and indicates that this script should be executed using the node runtime.
• The import statements bring in necessary CDK modules and your custom stack class.
• const app = new cdk.App(); creates a new instance of the CDK App, which is the root construct for your CDK application.
• new CdkWorkshopStack(app, 'CdkWorkshopStack'); instantiates an instance of your CdkWorkshopStack stack and adds it to the CDK application. This is where you define the main stack for your application.

Main Stack: The main stack, in this case, is represented by the CdkWorkshopStack class defined in the lib/cdk-workshop-stack.ts file. This class extends cdk.Stack and defines the infrastructure resources you want to create within this particular stack. Your CdkWorkshopStack class includes an SQS Queue and an SNS Topic:

const queue = new sqs.Queue(this, 'CdkWorkshopQueue', {
  visibilityTimeout: cdk.Duration.seconds(300)
});

const topic = new sns.Topic(this, 'CdkWorkshopTopic');

topic.addSubscription(new subs.SqsSubscription(queue));

• An SQS Queue named CdkWorkshopQueue is created with a specified visibility timeout of 300 seconds.
• An SNS Topic named CdkWorkshopTopic is created.
• The SQS Queue is subscribed to the SNS Topic using topic.addSubscription(new subs.SqsSubscription(queue));. This means that any messages published to the SNS Topic will be sent to the SQS Queue.

In summary, the App entry point (bin/cdk-workshop.ts) initializes your CDK application and defines which stacks to deploy. The main stack (CdkWorkshopStack in lib/cdk-workshop-stack.ts) defines the resources within that stack, which in your case includes an SQS Queue, an SNS Topic, and a subscription that connects them. This modular approach allows you to easily manage and deploy different parts of your infrastructure using code.