I will be creating an S3 bucket to see if our CDK app is linked to our account. We have done already verified our setup with the cdk bootstrap command in the previous post (Preparing Your AWS CDK Framework), but this is another litmus test to see if it works.

Or, you want to build your S3 bucket via AWS CDK, this will be the steps to take.

If you want to follow the code reference, I have it committed in this “CDK-T2” branch in my Github repo: https://github.com/jonathan-moo/gefyra-cdk-demo/tree/CDK-T2

Isolating your architecture into its different components

When you first initialize the CDK command to create an app, the app creates a default file in the bin directory, and it is named after the root folder. In this case, I have a gefyra-cdk-demo.ts file.

The same goes in the lib folder. I have a gefyra-cdk-demo-stack.ts file.  I will be removing all references of gefyra-cdk-demo-stack.ts within the gefyra-cdk-demo.ts script. That’s because I want to create individual modules for different stacks so that AWS CDK can build them separately, and modularly. For now, I will be removing these lines of code: 

I will also ignore the gefyra-cdk-demo-stack.ts file in the lib folder, and create a new file called create-s3-bucket.ts file. Then, I will copy the contents from the gefyra-cdk-demo-stack.ts into s3-bucket-stack.ts and rename the class name to S3BucketStack as shown:

Why? I’m specifying that this script contains all the code to deploy S3 bucket as a stack. There are a multitude number of ways to create stacks and infrastructure, but I find it too messy to build everything under one stack. By separating the stacks, you can isolate components and remove coupling or dependencies across different pipelines.

Writing code to create an S3 bucket

Install dependencies
We need to install the AWS S3 module for CDK by typing:

npm install @aws-cdk/aws-s3 --save

You should check if the dependencies are installed in your package.json here:

Important Reminder On Dependencies

AWS CDK will trigger an error if the AWS CDK dependencies are of different versions of one another. Make sure all the dependencies are of the same version number, or you will not be able to run your code at all.

Writing Code To Create An S3 Bucket
Import the library, and create your desired bucket with the following code here:

Ref Code In Github: https://github.com/jonathan-moo/gefyra-cdk-demo/tree/CDK-T2

A few highlights in this block of code:

  • Within the class, the public readonly bucket: s3.Bucket; is to reference this newly created S3 bucket as an object for other stacks to be reused.
  • All AWS S3 rules apply, such as the bucket name must be unique throughout the S3 ecosystem.

From here, we are almost done, but we need to reference our library under our bin/gefyra-cdk-demo-stack.ts here:

A few highlights in this block of code:

  • The stack name can be different from the bucket name. The stack name is used by AWS CDK to uniquely identify the deployment, while the bucket name is unique to the S3 environment within the cloud.
  • Remember how we created a public read-only object? The const bucket = s3_bucket_stack.bucket; references the object here.

Let’s recap from the previous post (Preparing Your AWS CDK Framework) on the folder structure:

  • Files within the bin folder executes the script to build architecture
  • The parameters of the architecture (in our case, an S3 bucket), is referenced within our lib folder.

So we’re ready to start deploying our S3 bucket!

Deploying The Infrastructure Using AWS CDK

As we are using Typescript, we will need to compile the files using the following command:

npm run build

If there are no errors, we can proceed to do a final check with:

cdk synth

What does synth do? It compiles the Typescript code into a CloudFormation template as you can see here:

As we often have to do both lines of code together, we can shorten it to a single command here:

npm run build && cdk synth

What is happening? When we run any CDK command, CDK would look for the first line of code here:

What is the flow of process?

  • Earlier, I said that CDK uses the bin folder to run the script, but the actual command it runs is on the app. It’s not running every file within the folder, but the particular file that was referenced above. You can always modify it, but I suggest not while you’re still learning about AWS CDK.
  • After running npm run build && cdk synth, CDK would compile the code and store it in the `cdk.out` folder here:

It is time to deploy the infrastructure:

cdk deploy --profile <AWS profile name>

And in my setup, you can see it right here:

Some notes on this:

  • You don’t have to specify your profile name in your setup if you have a default credential which you can use. Simply run: cdk deploy
  • As AWS CDK allows object-oriented deployment, if you have more than 1 stack, it will prompt you to choose the infrastructure you want to deploy by specifying the stack name.

Validate your deployment by visiting your AWS console here:

What If I want to remove the infrastructure/component?

There is this command called cdk destroy, and it follows the same pattern as cdk deploy. If you want to delete infrastructure in a certain profile, you would have to use: cdk destroy --profile <AWS profile name>.

However, I’m not doing it here for 2 reasons:

  • S3 buckets are storage nodes. AWS typically don’t remove a bucket flippantly because the data loss within the bucket is almost permanent (unless you have a business account and you raise support to get it back.)
  • You have to specify the removal policy within your S3 parameters if you want to explicitly delete an S3 bucket through CDK: https://docs.aws.amazon.com/cdk/api/latest/docs/@aws-cdk_aws-s3.Bucket.html

What’s next?

Typing a profile name can be tedious if we deploy frequently, but we can remove that tediousness by introducing context variables.
In the next post, we will deal with context variables and how we can make our deployments seamless.