In this video, you’ll see how to define cloud infrastructure in code with the AWS Cloud Development Kit
(AWS CDK).
With this software development framework, you can model cloud applications using familiar
programming languages, provision applications with customized CloudFormation templates,
and accelerate application deployments on AWS.
The AWS CDK is a software development framework that allows you to build highly reliable,
highly scalable, cost-effective applications in the cloud
without worrying about creating and configuring the underlying AWS infrastructure.
The AWS CDK enables you to build your cloud application
without leaving your integrated development environment (IDE).
For the purposes of this example, we’ll be coding in the AWS Cloud9 IDE.
Let’s go there now to get started.
First, let’s ensure we have the AWS command-line interface (CLI) and CDK CLI
installed on this Cloud9 instance.
As you can see, the AWS CDK is not currently installed.
Let’s install the AWS CDK using the Node Package Manager (NPM).
Next, let’s use the “cdk doctor” command to examine the environment to ensure it is ready for deployment.
Notice that the command displays the current CDK version, as well as the environment variables.
For the purposes of this example, we’ll also create and deploy a load balanced web application
as a fully managed Fargate service within the Amazon Elastic Container Service (or Amazon ECS).
Create a folder for the application and navigate into it.
The AWS CDK lets you define your AWS cloud infrastructure in a variety of general-purpose
programming languages, including TypeScript, JavaScript, Python, Java, and C#.
For our purposes, we’ll use TypeScript.
Initialize the application using the “cdk init” command.
As you can see, the command bootstrapped the cloud infrastructure service with several folders and files.
It created a bin folder, a lib folder, and several other folders and files necessary
for a TypeScript project with node.js.
Let’s look at the project configuration in the package.json file.
This file was created with a starting default project name, version, script definitions, and dependencies.
Next, let’s look in the automatically generated bin folder to see the starting code.
This code is the entry point into the application.
Next, let’s take a look in the lib folder, which contains the Typescript code for the application’s infrastructure.
This is the file we can edit to change the infrastructure of the application.
Next, let’s return to the command prompt and try building this bootstrapped project.
Running the build script generates further project files, which readies the service for deployment.
Next, let’s run the “cdk synth” command,
which generates the CloudFormation template that would be deployed from the starter project.
This is the starter CloudFormation template.
Note that it does not contain any cloud resources.
Now, let’s begin editing the code and installing further AWS CDK dependencies
to add functionality to our application.
Now that we’ve installed some dependencies, let’s look at the package.json file.
As you can see, the newly installed CDK dependencies are listed here.
Let’s add them to the TypeScript library code.
Now we can use AWS CDK constructs to begin defining our stack, starting with the VPC.
A construct represents a "cloud component" and encapsulates everything AWS CloudFormation
needs to create the component.
Just like that, we created a new Amazon Elastic Compute Cloud (or Amazon EC2) Virtual Private
Cloud (or VPC) with three Maximum Availability Zones that uses public and private subnets,
according to best practices.
AWS CDK constructs are designed to follow best practices, but you can override the default parameters.
Next, we’ll create an ECS cluster inside the VPC.
Notice that this construct has only one required parameter, which is to point it to the VPC we created.
Now let’s add the Fargate service.
Finally, this code used a higher-level construct known as a “pattern”
to include an AWS Fargate container service employing an Application Load Balancer.
We don’t have to worry about the underlying instances,
and we’ll be able to scale the service up and down based on demand.
Next, let’s pass the cluster with the VPC to the created service, along with a set of other parameters.
Save the file and return to the command prompt.
Now that we’ve defined the application in code, let’s run the build script.
Now let’s look at the generated CloudFormation template to see all the resources
that have been created by the AWS CDK.
Now, let’s deploy the CloudFormation template using the AWS CDK “deploy” command.
Note that CDK surfaces all security-related changes for review.
While the AWS CDK deploys the template,
let’s quickly switch to CloudFormation to ensure that the stack is being created.
Select the stack.
Navigate to the Events tab and refresh the view.
As you can see, the Fargate stack is being created.
Now let’s skip forward a few minutes to when the deployment has completed.
As you can see, the CloudFormation template that we modified using only a few lines of
simple TypeScript code created 38 resources across numerous AWS services.
Let’s look at the application it deployed.
As you can see, the application is now running on a container in Amazon ECS.
Next, let’s switch to ECS to look at the container tasks and service that were created
for the Application Load Balancer Fargate service.
Refresh the page.
Here you can see the cluster we defined in the code earlier.
We can drill into the cluster to get a closer look at its resources.
We can see the active service.
We can see the tasks that are running.
Here, we can see two tasks running our sample container.
Now, let’s go to the Amazon EC2 console to see the generated load balancer.
Here you can see the load balancer that was generated by the code.
Next, let’s look at the target group that is registered to the load balancer and receiving traffic.
Here we can see that two registered targets are receiving traffic.
Now let’s return to Cloud9 to make a simple change to the application.
We’ll change the desiredCount parameter to 4.
This updates the tasks and targets in the ECS container from 2 to 4.
Save the changes.
Let’s return to the command prompt to rebuild the application.
To rebuild the application, simply run the build script again.
The "cdk diff" command shows the parameters of the project code that will be changed
upon another deployment.
Let’s run the AWS CDK “deploy” command to update the affected resources.
Return to the ECS console and refresh the view.
As you can see, the service now has four running tasks.
Let’s check the EC2 Target Groups page.
As expected, four containers are now registered to the load balancer and receiving traffic.
The infrastructure has been fully updated.
To bring the infrastructure down, you can simply run the command “cdk destroy,”
which will also deprovision all resources associated with the application.
You’ve just seen how to create and provision AWS infrastructure deployments using the AWS CDK.
Thanks for watching.
Now it’s your turn to try.