Forem: Mikaeel Khalid

What is Context and its Significance in AWS CDK

Mikaeel Khalid — Fri, 15 Dec 2023 15:29:47 +0000

Amazon Web Services Cloud Development Kit (AWS CDK) is a powerful infrastructure-as-code (IaC) framework that allows developers to define cloud infrastructure using familiar programming languages. One essential concept within AWS CDK that plays a crucial role in configuring and customizing your infrastructure is "context." In this blog post, we will delve into the significance of context in AWS CDK and how it contributes to the flexibility and scalability of your cloud applications.

Context in AWS CDK

In AWS CDK, context refers to the external input provided during the synthesis phase of your application. This external input can be environmental variables, resource-specific configurations, or any changing parameter based on the deployment environment. Context allows you to dynamically adjust certain values in your CDK application without modifying the source code.

Using Context at the App Level

In this example we will set the context at our CDK App level :

import { Stack, StackProps, App } from 'aws-cdk-lib';export class MyCdkStack extends Stack { constructor(scope: App, id: string, props?: StackProps) { super(scope, id, props); console.log('accessing context here ', this.node.tryGetContext('fromApp')); }}const app = new App({ // setting context in our cdk.App context: { fromApp: {name: 'Mikaeel', country: 'BE'}, },});const myStack = new MyCdkStack(app, 'my-cdk-stack', { stackName: `my-cdk-stack`, env: { region: process.env.CDK_DEFAULT_REGION, account: process.env.CDK_DEFAULT_ACCOUNT, },});

Let's synthesize our stack and look at the output:

cdk synth

We can see the output from the console.log:

{ name: 'Mikaeel', country: 'BE' }

Context Managed by CDK

Now take a quick look at how CDK uses context to cache certain values that belong to our deployment environment.

If we open the cdk.context.json file in the root directory of our CDK project, we can see that it's empty.

{}

Let's add a simple console.log call and print the availability zones that belong to the region our stack is configured for:

import { Stack, StackProps, App } from 'aws-cdk-lib';export class MyCdkStack extends Stack { constructor(scope: App, id: string, props?: StackProps) { super(scope, id, props); console.log('context passed in App here ', this.node.tryGetContext('fromApp')); // printing the availability zones console.log(Stack.of(this).availabilityZones); }}

Now synthesize our stack with:

cdk synth

If we now open the cdk.context.json file in the root of our project we'll see that CDK has cached the availability zones that correspond to our stack's region:

{ "availability-zones:account=123456789:region=us-east-1": ["us-east-1a", "us-east-1b", "us-east-1c", "us-east-1d", "us-east-1e"]}

The cdk.context.json file is where CDK caches values related to our deployment environment.

There is also a cdk.json file in the root directory of a CDK project.

The cdk.json file looks similar to the following:

{ "app": "npx ts-node --prefer-ts-exts bin/aws-cdk-group-chat-app.ts", "context": { "@aws-cdk/aws-lambda:recognizeLayerVersion": true, "@aws-cdk/core:checkSecretUsage": true, "@aws-cdk/core:target-partitions": ["aws", "aws-cn"] }}

Where the app key indicates to the CDK CLI how to run our CDK code, which is mostly a compilation step that compiles the typescript code to javascript.

Then we have the context key, which is composed of feature flags.

These feature flags enable us to opt in or out of breaking changes. Their names start with the name of the package that introduces the breaking change i.e: @aws-cdk/aws-lambda.

💡

If we want to roll back to the previous behavior of AWS CDK what certain feature is concerned, we have to set the feature flag to false.

We can also use the cdk.json file to pass in context into our CDK app, let's add another property to it:

{ "app": "npx ts-node --prefer-ts-exts bin/aws-cdk-group-chat-app.ts", "context": { "@aws-cdk/aws-lambda:recognizeLayerVersion": true, "@aws-cdk/core:checkSecretUsage": true, "@aws-cdk/core:target-partitions": ["aws", "aws-cn"], // adding a bucket property as context "bucket": { "region": "us-east-1", "name": "my-s3-bucket" } }}

Now let's access the bucket context in our CDK stack:

import { Stack, StackProps, App } from 'aws-cdk-lib';export class MyCdkStack extends Stack { constructor(scope: App, id: string, props?: StackProps) { super(scope, id, props); console.log('from cdk.json ', this.node.tryGetContext('bucket')); }}

Let's synth our cdk stack:

cdk synth

The output from the console.log will look like this:

 { "region": "us-east-1", "name": "my-s3-bucket" }

Setting Context using the CDK CLI

The next option used for setting context in our CDK app is to use the CDK CLI.

We can set context key-value pairs during synthesis.

First, we'll access context values that we haven't yet set:

import { Stack, StackProps, App } from 'aws-cdk-lib';export class MyCdkStack extends Stack { constructor(scope: App, id: string, props?: StackProps) { super(scope, id, props); console.log('bucketName ', this.node.tryGetContext('bucketName')); console.log('region ', this.node.tryGetContext('region')); }}

Now we'll synth the CDK application passing in the context values using the CLI:

cdk synth \ --context bucketName=myBucket \ --context region=us-east-1

The output from our console.log statements will look like this.

bucketName myBucketregion us-east-1

💡

We can only pass string values when we set the context using the CDK CLI. If we have to pass an object, we have to pass it as a string and parse it in our application code.

If we have multiple CDK stacks and want to set different context values using the CDK CLI, we can prefix the key-value pairs with the stack name , i.e.:

cdk synth \ --context stack-name1:bucketName=myBucket \ --context stack-name2:bucketName=yourBucket

Conclusion

Context is a combination of key-value pairs we can set and make available in our CDK application.

Context is similar to environment variables , in that both are accessible in synthesis time, as opposed to CDK parameters , which are only set at deployment time.

The most common ways to set context are:

At the CDK App level using the context property
In our cdk.json file adding key-value pairs to the context object
Using the CDK CLI with the --context flag

In our CDK applications, we can access the context values with a call tothis.node.tryGetContext('keyName').

💡

I believe it's good to set the context at the CDK App level , it's globally available, it's intuitive and we can set context values of any type.

Setting context using the cdk.json file is too implicit and hidden.

An alternative is using the CDK CLI, however, the CLI only allows us to pass in string values, so the most intuitive way is setting context at the cdk.App level.

Automating AWS CodePipeline Notifications to Discord Using Lambda and Terraform

Mikaeel Khalid — Mon, 11 Dec 2023 16:44:25 +0000

Introduction

In DevOps, continuous integration and delivery (CI/CD) pipelines are integral for efficient software development. AWS CodePipeline facilitates the orchestration of these pipelines, but keeping track of pipeline executions in real time can be challenging. This blog post will guide you through the process of automating notifications to a Discord channel using AWS Lambda whenever there is an update to a CodePipeline execution. The solution leverages serverless computing, AWS Lambda, and Infrastructure as Code (IaC) with Terraform for seamless deployment.

💡 The GitHub link to the complete code can be found at the end of the blog.

1. Overview

AWS CodePipeline is a fully managed CI/CD service, that streamlines the process of building, testing, and deploying code changes. However, being aware of pipeline status changes in real-time is crucial for efficient collaboration and issue resolution.

2. Setting Up Discord Integration

Before diving into the technical details, you need to set up Discord integration. This involves creating a Discord webhook, which will be the communication link for posting messages to your desired Discord channel.

3. AWS Lambda for CodePipeline Notifications

3.1 Understanding the Lambda Function Structure

The heart of this solution is an AWS Lambda function written in Node.js. This function responds to CodePipeline state changes triggered by EventBridge, a serverless event bus. The Lambda function fetches details about the pipeline execution and formats a message to be posted in Discord.

3.2 Utilizing CodePipeline Helper Functions

The codepipeline-helper.js file contains helper functions for interacting with AWS CodePipeline. It establishes a connection to CodePipeline, fetches pipeline execution details, and retrieves the current state of the pipeline.

// codepipeline-helper.js
require('dotenv').config();
const AWS = require('aws-sdk');

AWS.config.update({ region: process.env.REGION });
const codepipeline = new AWS.CodePipeline(process.env.REGION);
const PIPELINE_HISTORY = 'https://###REGION###.console.aws.amazon.com/codepipeline/home?region=###REGION####/view/###PIPELINE###/history';

module.exports.getPipelineExecutionDetails = (executionId, pipeline) => {
  const promises = [];
  promises.push(getPipelineExecution(executionId, pipeline));
  promises.push(getPipelineState(pipeline));

  return Promise.all(promises).then(([execution, state]) => {
    return {
      execution: execution,
      state: state,
      executionHistoryUrl: PIPELINE_HISTORY.replace(new RegExp('###REGION###', 'g'), process.env.REGION).replace(
        new RegExp('###PIPELINE###', 'g'),
        pipeline
      ),
    };
  });
};

// ... other functions like getPipelineExecution and getPipelineState
// The GitHub link to the complete code can be found at the end of the blog.

3.3 Crafting Discord Messages with Discord Helper

The discord-helper.js file is responsible for creating Discord messages based on the CodePipeline execution details. It extracts relevant information such as commit details, and stage statuses, and creates a formatted message ready for Discord.

// discord-helper.js
const CodePipelineHelper = require('./codepipeline-helper');
const Constants = require('./constants');
const AppName = process.env.DISCORD_CHANNEL ? process.env.DISCORD_CHANNEL : 'Github';

module.exports.createDiscordMessage = (codepipelineEventDetails) => {
  return CodePipelineHelper.getPipelineExecutionDetails(
    codepipelineEventDetails['execution-id'],
    codepipelineEventDetails.pipeline
  ).then((pipelineDetails) => {
    // get git info from github directly??? this might require authorization
    const gitCommitInfo = pipelineDetails.execution.pipelineExecution.artifactRevisions[0];

    // ... other code for creating Discord message
  });
};

// ... getColorByState function and other related functions
// The GitHub link to the complete code can be found at the end of the blog.

4. Terraform Infrastructure as Code (IaC)

Terraform is employed to manage AWS resources in a declarative manner. The infrastructure is defined in the main.tf file, specifying IAM roles, policies, Lambda functions, and EventBridge rules.

4.1 IAM Role and Policies

IAM roles and policies are defined to grant necessary permissions to the Lambda function, allowing it to interact with CloudWatch Logs and CodePipeline.

# main.tf
resource "aws_iam_role" "lambda_role" {
  name = "${var.LAMBDA_APP_NAME}-codepipeline-discord-lambda-role"

  assume_role_policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
EOF
}

resource "aws_iam_role_policy" "lambda_role_policy" {
  name = "${var.LAMBDA_APP_NAME}-discord-codepipeline-lambda-role-policy"
  role = aws_iam_role.lambda_role.id

  policy = <<EOF
{
  "Version" : "2012-10-17",
  "Statement" : [{
      "Sid": "WriteLogsToCloudWatch",
      "Effect" : "Allow",
      "Action" : [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource" : "arn:aws:logs:*:*:*"
    }, {
      "Sid": "AllowAccesstoPipeline",
      "Effect" : "Allow",
      "Action" : [
        "codepipeline:GetPipeline",
        "codepipeline:GetPipelineState",
        "codepipeline:GetPipelineExecution",
        "codepipeline:ListPipelineExecutions",
        "codepipeline:ListActionTypes",
        "codepipeline:ListPipelines"
      ],
      "Resource" : "*"
    }
  ]
}
EOF
}

# The GitHub link to the complete code can be found at the end of the blog.

4.2 Deploying Lambda Function with Terraform

The Lambda function, defined in the aws_lambda_function resource block is deployed with the associated IAM role and policies.

# main.tf
resource "aws_lambda_function" "lambda" {
  filename = data.archive_file.lambda_zip.output_path
  source_code_hash = data.archive_file.lambda_zip.output_base64sha256
  description = "Posts a message to Discord channel '${var.DISCORD_CHANNEL}' every time there is an update to codepipeline execution."
  function_name = "${var.LAMBDA_APP_NAME}-discord-codepipeline-lambda"
  role = aws_iam_role.lambda_role.arn
  handler = "handler.handle"
  runtime = "nodejs14.x"
  timeout = var.LAMBDA_TIMEOUT
  memory_size = var.LAMBDA_MEMORY_SIZE

  environment {
    variables = {
      "DISCORD_WEBHOOK_URL" = var.DISCORD_WEBHOOK_URL
      "DISCORD_CHANNEL" = var.DISCORD_CHANNEL
      "RELEVANT_STAGES" = var.RELEVANT_STAGES
      "REGION" = var.REGION
    }
  }
}

# ... other resources like aws_lambda_alias, aws_cloudwatch_event_rule, etc.
# The GitHub link to the complete code can be found at the end of the blog.

4.3 EventBridge Rule for CodePipeline State Changes

An EventBridge rule is established to capture state changes in all CodePipelines. This rule triggers the Lambda function whenever a relevant event occurs.

# main.tf
resource "aws_cloudwatch_event_rule" "pipeline_state_update" {
  name = "${var.LAMBDA_APP_NAME}-discord-codepipeline-rule"
  description = "capture state changes in all CodePipelines"

  event_pattern = <<PATTERN
  {
    "detail-type": [
        "CodePipeline Pipeline Execution State Change"
    ],
    "source": [
        "aws.codepipeline"
    ]
 }
PATTERN
}

resource "aws_lambda_permission" "allow_cloudwatch" {
  statement_id = "AllowExecutionFromCloudWatch"
  action = "lambda:InvokeFunction"
  function_name = aws_lambda_function.lambda.function_name
  principal = "events.amazonaws.com"
  source_arn = aws_cloudwatch_event_rule.pipeline_state_update.arn
  qualifier = aws_lambda_alias.lambda_alias.name
}

resource "aws_cloudwatch_event_target" "lambda_trigger" {
  rule = aws_cloudwatch_event_rule.pipeline_state_update.name
  arn = aws_lambda_alias.lambda_alias.arn
}

# The GitHub link to the complete code can be found at the end of the blog.

5. Customization and Configuration

This solution is designed to be adaptable to specific team needs. You can customize relevant stages to monitor, configure Lambda function parameters, and extend functionality as required.

5.1 Adapting Relevant Stages

In constants.js, you can adjust the relevant stages based on your pipeline structure.

// constants.js
const relevantStages = process.env.RELEVANT_STAGES || 'BUILD,DEPLOY';

module.exports.ACTION_LEVEL_STATES = {
  FAILED: 'FAILED',
  CANCELED: 'CANCELED',
  STARTED: 'STARTED',
  SUCCEEDED: 'SUCCEEDED',
};

module.exports.STAGES = {
  SOURCE: 'SOURCE',
  BUILD: 'BUILD',
  DEPLOY: 'DEPLOY',
};

module.exports.DISCORD_COLORS = {
  INFO: 3447003,
  WARNING: 15158332,
  SUCCESS: 3066993,
  ERROR: 10038562,
};

module.exports.RELEVANT_STAGES = relevantStages
  .split(',')
  .map((stage) => module.exports.STAGES[stage.toUpperCase()])
  .filter((stage) => stage != null);

// The GitHub link to the complete code can be found at the end of the blog.

5.2 Configuring Lambda Function Parameters

In variables.tf, you can configure parameters such as the Discord webhook URL, channel, AWS region, and more.

# variables.tf
variable "LAMBDA_APP_NAME" {
  description = "lambda function name."
  default = "cicd-channel"
}

variable "DISCORD_WEBHOOK_URL" {
  description = "webhook URL provided by Discord."
  default = "https://mikaeels.com" // replace with webhook URL provided by Discord
}

variable "DISCORD_CHANNEL" {
  description = "discord channel where messages are going to be posted."
  default = "#cicd"
}

variable "REGION" {
  description = "AWS deployment region."
  default = "eu-west-2"
}

variable "RELEVANT_STAGES" {
  description = "stages for which you want to get notified (ie. 'SOURCE,BUILD,DEPLOY'). Defaults to all)"
  default = "SOURCE,BUILD,DEPLOY"
}

variable "LAMBDA_MEMORY_SIZE" {
  default = "128"
}

variable "LAMBDA_TIMEOUT" {
  default = "10"
}

# The GitHub link to the complete code can be found at the end of the blog.

5.3 Extending Functionality

The discord-helper.js file can be extended to include additional details or integrations based on your requirements.

// discord-helper.js
const CodePipelineHelper = require('./codepipeline-helper');
const Constants = require('./constants');
const AppName = process.env.DISCORD_CHANNEL ? process.env.DISCORD_CHANNEL : 'Github';

module.exports.createDiscordMessage = (codepipelineEventDetails) => {
  return CodePipelineHelper.getPipelineExecutionDetails(
    codepipelineEventDetails['execution-id'],
    codepipelineEventDetails.pipeline
  ).then((pipelineDetails) => {
    // get git info from github directly??? this might require authorization
    const gitCommitInfo = pipelineDetails.execution.pipelineExecution.artifactRevisions[0];

    // create discord fields per each stage
    const executionStages = pipelineDetails.state.stageStates.filter(
      (x) => x.latestExecution.pipelineExecutionId === codepipelineEventDetails['execution-id']
    );

    const fields = executionStages.map((stage) => {
      const actionState = stage.actionStates[0];
      switch (stage.stageName.toUpperCase()) {
        case Constants.STAGES.SOURCE:
          return {
            name: `Commit`,
            value: `[\`${gitCommitInfo.revisionId.substring(0, 10)}\`](${gitCommitInfo.revisionUrl}) - ${
              gitCommitInfo.revisionSummary
            }`,
            inline: false,
          };
        case Constants.STAGES.DEPLOY:
        case Constants.STAGES.BUILD:
          return {
            name: `${actionState.actionName}`,
            value: actionState.latestExecution.externalExecutionUrl
              ? `[${actionState.latestExecution.status}](${actionState.latestExecution.externalExecutionUrl})`
              : actionState.latestExecution.status,
            inline: true,
          };
        default:
          console.log(`Unknown stage: ${stage.stageName}`);
      }
    });

    const discordMessage = {
      username: `${AppName}`,
      avatar_url: 'https://gravatar.com/avatar/1fd3410d57f8b729ec89a431054cbf41?s=400&d=robohash&r=x',
      content: `Code Pipeline status updated: [${codepipelineEventDetails.pipeline}](${pipelineDetails.executionHistoryUrl})`,
      embeds: [
        {
          color: getColorByState(pipelineDetails.execution.pipelineExecution.status),
          fields: fields,
          footer: {
            text: 'With from CodePipeline 🚀',
          },
        },
      ],
      timestamp: new Date().toISOString,
    };

    return discordMessage;
  });
};

// states for action events in codepipeline
function getColorByState(state) {
  switch (state.toUpperCase()) {
    case Constants.ACTION_LEVEL_STATES.FAILED:
      return Constants.DISCORD_COLORS.ERROR;
    case Constants.ACTION_LEVEL_STATES.SUCCEEDED:
      return Constants.DISCORD_COLORS.SUCCESS;
    case Constants.ACTION_LEVEL_STATES.CANCELED:
      return Constants.DISCORD_COLORS.WARNING;
    case Constants.ACTION_LEVEL_STATES.STARTED:
    default:
      return Constants.DISCORD_COLORS.INFO;
  }
}

// The GitHub link to the complete code can be found at the end of the blog.

6. Deployment

Terraform is utilized to deploy the entire infrastructure to AWS.

Initialize the Terraform environment.

terraform init

Plan the deployment.

terraform plan

Apply the configuration.

terraform apply

7. Conclusion

In conclusion, this comprehensive guide empowers you to automate CodePipeline notifications to Discord using AWS Lambda and Terraform. Following the provided references and step-by-step instructions can enhance collaboration, improve visibility, and respond promptly to changes in your CI/CD workflows. The combination of serverless computing, IaC, and effective Discord integration ensures a streamlined and efficient DevOps experience.

Here's the GitHub repo link to the complete code. 👇

https://github.com/mikaeelkhalid/aws-codepipeline-discord-notifier-terraform

Creating a CI/CD Pipeline for AWS Elastic Beanstalk with AWS CDK

Mikaeel Khalid — Sun, 29 Oct 2023 21:03:39 +0000

In this blog, I will provide a comprehensive guide on how to set up a Continuous Integration/Continuous Deployment (CI/CD) pipeline for an AWS Elastic Beanstalk application using the AWS Cloud Development Kit (CDK). I will break down the code into smaller sections, explaining each part's purpose.

Step 1: Project Structure and Setup

The project is structured into three primary files:

stacks/eb-codepipeline-stack.ts
config/config.yaml
bin/main.ts

This organized structure makes it easier to manage the deployment process and its configurations.

💡 The project GitHub repo link can be found at the end of the blog.

stacks/eb-codepipeline-stack.ts: This file contains the code to define the AWS infrastructure for your Elastic Beanstalk application and the CI/CD pipeline using AWS CDK.
config/config.yaml: This file stores the configuration values for different environments, such as development (dev) and production (prod).
bin/main.ts: This is the entry point for the CDK app, where we create the app and instantiate the CDK stack based on the environment specified.

Now, let's dive into the details of the code.

Step 2: Elastic Beanstalk Configuration

In the eb-codepipeline-stack.ts file, we start by configuring the Elastic Beanstalk environment. This is where your web application will be hosted. Let's break down the code:

Section 2.1: Asset Configuration

const webAppZipArchive = new Asset(this, 'expressjs-app-zip', {
  path: `${__dirname}/../express-app`,
});

Here, we create an asset named 'expressjs-app-zip' from your application code, which is stored in the 'express-app' directory.

Section 2.2: Application Creation

const app = new CfnApplication(this, 'eb-application', {
  applicationName: appName,
});

We define the Elastic Beanstalk application by providing it with a name.

Section 2.3: Application Version Configuration

const appVersionProps = new CfnApplicationVersion(this, 'eb-app-version', {
  applicationName: appName,
  sourceBundle: {
    s3Bucket: webAppZipArchive.s3BucketName,
    s3Key: webAppZipArchive.s3ObjectKey,
  },
});

appVersionProps.addDependency(app); // here we want to create app before its version

Here we're creating a version of your Elastic Beanstalk application, capturing the code from an S3 bucket and associating it with the application named 'appName'.

The appVersionProps.addDependency(app) line ensures that the Elastic Beanstalk Application is created before its associated Application Version.

Section 2.4: Create instance profile

 const instanceRole = new Role(
      this,
      `${appName}-aws-elasticbeanstalk-ec2-role`,
      {
        assumedBy: new ServicePrincipal('ec2.amazonaws.com'),
      }
    );

    const managedPolicy = ManagedPolicy.fromAwsManagedPolicyName(
      'AWSElasticBeanstalkWebTier'
    );

    instanceRole.addManagedPolicy(managedPolicy);

    const instanceProfileName = `${appName}-instance-profile`;

    const instanceProfile = new CfnInstanceProfile(this, instanceProfileName, {
      instanceProfileName: instanceProfileName,
      roles: [instanceRole.roleName],
    });

Here we're creating an instance profile for the Elastic Beanstalk application with an AWS-managed policy 'AWSElasticBeanstalkWebTier' to ensure it has proper permissions.

Section 2.5: Create Option Setting properties

const optionSettingProperties: CfnEnvironment.OptionSettingProperty[] = [
      {
        namespace: 'aws:autoscaling:launchconfiguration',
        optionName: 'IamInstanceProfile',
        value: instanceProfileName,
      },
      {
        namespace: 'aws:autoscaling:asg',
        optionName: 'MinSize',
        value: minSize || DEFAULT_SIZE,
      },
      {
        namespace: 'aws:autoscaling:asg',
        optionName: 'MaxSize',
        value: maxSize || DEFAULT_SIZE,
      },
      {
        namespace: 'aws:ec2:instances',
        optionName: 'InstanceTypes',
        value: instanceTypes || DEFAULT_INSTANCE_TYPE,
      },
    ];

// here we're adding ssl properties if ARN defined
if (sslCertificateArn) {
      optionSettingProperties.push(
        {
          namespace: 'aws:elasticbeanstalk:environment',
          optionName: 'LoadBalancerType',
          value: 'application',
        },
        {
          namespace: 'aws:elbv2:listener:443',
          optionName: 'ListenerEnabled',
          value: 'true',
        },
        {
          namespace: 'aws:elbv2:listener:443',
          optionName: 'SSLCertificateArns',
          value: sslCertificateArn,
        },
        {
          namespace: 'aws:elbv2:listener:443',
          optionName: 'Protocol',
          value: 'HTTPS',
        }
      );
    }

Here we're setting an Option Setting Properties for the Elastic Beanstalk application environment.

Section 2.6: Create ElasticBeanstalk Environment

const ebEnvironment = new CfnEnvironment(this, 'eb-environment', {
      environmentName: envName,
      applicationName: appName,
      solutionStackName: '64bit Amazon Linux 2 v5.8.0 running Node.js 18',
      optionSettings: optionSettingProperties,
      versionLabel: appVersionProps.ref,
    });

Here we're creating an Elastic Beanstalk environment for hosting an application, specifying its name, associated application, runtime stack, and various configurations like instance types and SSL certificates.

Section 2.7: Output ElasticBeanstalk Environment (ALB) endpoint URL

new CfnOutput(this, 'eb-url-endpoint', {
      value: ebEnvironment.attrEndpointUrl,
      description: 'URL endpoint for the elasticbeanstalk',
    });

The above code sets up an application version, pointing to the asset created earlier, which represents your application code.

The code also includes creating an instance profile, defining environment options, handling SSL certificates if provided, and outputting URL.

Step 3: CodePipeline Configuration

Moving on to the CI/CD pipeline configuration. This code sets up a CodePipeline with Source, Build, and Deployment stages.

Section 3.1: Source Stage Configuration

const sourceOutput = new Artifact();
const sourceAction = new GitHubSourceAction({
  actionName: 'GitHub', // we're using github here, can be codecommit, bitbucket etc
  owner: githubRepoOwner,
  repo: githubRepoName,
  branch: branch,
  oauthToken: SecretValue.secretsManager(githubAccessTokenName),
  output: sourceOutput,
});

Here, we configure the source stage. It uses a GitHub repository as the source, which can be triggered based on the specified branch.

Section 3.2: Build Stage Configuration

const buildOutput = new Artifact();
const buildProject = new Project(this, 'codebuild-project', {
  buildSpec: BuildSpec.fromObject({
    version: '0.2',
    phases: {
      install: {
        commands: ['npm install'],
      },
      build: {
        commands: ['npm run build'],
      },
    },
    artifacts: {
      files: ['**/*'],
    },
  }),
  environment: {
    buildImage: LinuxBuildImage.STANDARD_5_0,
  },
});

In this section, we set up the Build stage. It defines a CodeBuild project with build specifications, including installing dependencies and building the application.

Section 3.3: Deployment Stage Configuration

const deployAction = new ElasticBeanstalkDeployAction({
  actionName: 'ElasticBeanstalk',
  applicationName: appName,
  environmentName: envName || 'eb-nodejs-app-environment',
  input: projectType === 'ts' ? buildOutput : sourceOutput,
});

The deployment stage is configured to deploy the application to Elastic Beanstalk. It depends on whether your project is TypeScript or JavaScript.

Step 4: Pipeline (CodePipeline) Creation

Finally, we create the pipeline by specifying the order of stages based on the project type:

const jsProject = [
  { stageName: 'Source', actions: [sourceAction] },
  { stageName: 'Deploy', actions: [deployAction] },
];

const tsProject = [
  { stageName: 'Source', actions: [sourceAction] },
  { stageName: 'Build', actions: [buildAction] },
  { stageName: 'Deploy', actions: [deployAction] },
];

const stages = projectType === 'ts' ? tsProject : jsProject;

const codePipeline = new Pipeline(this, 'codepipeline', {
  pipelineName: pipelineName,
  artifactBucket: getPipelineBucket,
  stages,
});

Here, we define the pipeline stages based on the project type. If it's TypeScript, it includes the Build stage; otherwise, it skips it.

Step 5: Configuration in config/config.yaml

The config.yaml file contains configuration values for your AWS CDK setup, specifically for different environments, such as dev (development) and prod (production). Here's a more detailed breakdown of the config.yaml file:

environmentType: # define the type of environment (e.g., "dev" or "prod").
githubRepoName: # provide the name of the GitHub repository for your source code (Nodjes).
githubRepoOwner: # specify the owner of the GitHub repository.
githubAccessTokenName: # name of the secret in AWS Secrets Manager storing your GitHub access token.
projectType: ts # specify the project type as either "ts" (TypeScript) or "js" (JavaScript).

dev: # configuration specific to the development environment.
  stackName: # define the name of the CDK stack for the dev environment.
  branch: # specify the branch to trigger the pipeline for the dev environment.
  pipelineBucket: # name of the S3 bucket to store artifacts for the dev environment (make sure you create one before deploying)
  pipelineConfig:
    name: # specify a name for the pipeline configuration in the dev environment.
  minSize: 1 # minimum size for the Elastic Beanstalk environment in the dev environment.
  maxSize: 1 # maximum size for the Elastic Beanstalk environment in the dev environment.
  instanceTypes: t2.micro # Define the instance type for the Elastic Beanstalk environment in the dev environment.
  ebEnvName: # specify the name of the Elastic Beanstalk environment in the dev environment.
  ebAppName: # specify the name of the Elastic Beanstalk application in the dev environment.

# similarly, you can configure the "prod" environment with the same set of parameters.

In the config.yaml file, you can define configuration values for both development and production environments. These values are essential for customizing your AWS CDK application to suit different stages of your deployment pipeline. Make sure to adjust these settings according to your project requirements for each environment.

This configuration file plays a crucial role in the flexibility and customization of your CDK setup, allowing you to maintain separate configurations for different environments.

Step 6: App Synthesis and Deployment

In the main.ts file, we create a CDK app and instantiate the CDK stack based on the environment, either dev or prod:

if (devProps?.stackName?.length) {
  const devStackName = devProps.stackName;
  new EbCodePipelineStack(app, devStackName, devProps);
} else {
  const prodStackName = prodProps?.stackName;
  new EbCodePipelineStack(app, prodStackName, prodProps);
}

app.synth();

This code initializes the CDK app and the stack based on the chosen environment, allowing you to create a CI/CD pipeline for your Elastic Beanstalk application.

In conclusion, this blog post detailed the code used to create a CI/CD pipeline for AWS Elastic Beanstalk using AWS CDK. We walked through setting up Elastic Beanstalk, configuring the pipeline, and explained each section of the code to help you understand how to deploy your application with ease.

Here's the GitHub repo link to the code. 👇

https://github.com/mikaeelkhalid/deploy-elasticbeanstalk-codepipeline-cdk

Use AWS CodeCommit to mirror Azure repo using an Azure Pipeline

Mikaeel Khalid — Tue, 17 Oct 2023 14:20:46 +0000

In this blog post, I'll guide you through seamlessly syncing your Git repositories from Azure DevOps to AWS CodeCommit using the power of an Azure DevOps pipeline. This automated setup ensures that your source repository in Azure DevOps and its replica in AWS stay in perfect harmony. Whenever updates are pushed to the source repository, our pipeline springs into action, efficiently cloning the repository and pushing the changes to its AWS CodeCommit replica.

High-level architecture of the Pipeline

To set up repository replication in the AWS Cloud, I'll walk you through the following steps in this blog post:

Establish a CodeCommit repository.
Generate a policy, user, and secure HTTPS Git credentials using AWS Identity and Access Management (IAM).
Craft a pipeline within Azure DevOps.

Prerequisites

Before diving into the process, it's essential to ensure you have the following prerequisites in place:

An active AWS account.
An existing Azure DevOps repository.

Creating a repository in CodeCommit

To prepare your CodeCommit replica repository and obtain its URL and ARN, follow these step-by-step instructions:

Begin by creating a new CodeCommit repository in your preferred AWS region. Pick a distinctive name that reminds you it's a replica or backup repository, for instance, "my-repo" Please note that you should refrain from manually pushing any changes to this replica repository, as it could lead to conflicts when your pipeline syncs change from the source repository. Treat it as a read-only repository and ensure that all development changes are pushed to your source repository.
Navigate to the AWS CodeCommit console.
Select Repositories from the list of options.
Locate your newly created repository and click on View Repository.
Click on Clone URL then select Clone HTTPS This action will copy the repository's URL. Save this URL by pasting it into a plain-text editor for future reference.
In the navigation pane, under Repositories , choose Settings.
Copy the value of the Repository ARN and save it by pasting it into a plain-text editor.

You now have the URL and ARN for your CodeCommit replica repository, which will be essential for setting up the IAM Role and synchronization pipeline.

Creating a policy, user, and Git credentials in IAM

The pipeline needs permissions and credentials to push commits to your CodeCommit repository. In this example, you create an IAM policy, IAM user, and HTTPS Git credentials for the pipeline to give it access to your repository in AWS. You grant the least privilege to the IAM user so the pipeline can only push to your replica repository.

To create the IAM policy, complete the following steps:

On the IAM console, choose Policies.
Choose Create Policy.
Choose JSON.
Enter a policy that grants permission to push commits to your repository. You can use a policy that similar to the following. For the Resource element, specify the ARN of your CodeCommit repository:

 {
     "Version": "2012-10-17",
     "Statement": [
         {
             "Effect": "Allow",
             "Action": "codecommit:GitPush",
             "Resource": "arn:aws:codecommit:eu-west-2:<account-id>:my-repo"
         }
     ]
 }

Choose Review policy.
For Name , enter a name for your policy (for example, codecommit-azure-repo-policy).
Choose to Create policy.

Create an IAM user

On the IAM console, choose Users.
Choose Add user.
Enter a User name (for example, codecommit-azure-devops-pipeline-user).
Select Programmatic access.
Choose Next: Permissions.
Select Attach existing policies directly and select the IAM policy you created "codecommit-azure-repo-policy".
Choose Next: Tags.
Choose Next: Review.
Choose Create user.
When presented with security credentials, choose Close.
Choose your new user by clicking on the user name link.
Choose Security Credentials.
Under Access keys , remove the existing access key.
Under HTTPS Git credentials for AWS CodeCommit , choose Generate credentials.
Choose Download credentials to save the username and password.
Choose Close.

Creating a pipeline in Azure DevOps

In order to execute the pipeline discussed in this blog post, which mirrors your source repository and synchronizes it with your CodeCommit repository, you'll need to obtain the following essential details: the URL of your source repository and HTTPS Git credentials. Here's how to do it:

To identify the URL of your source repository and generate the necessary HTTPS Git credentials, please follow the steps below:

Go to the Repos page within Azure DevOps and choose your repository.
Choose Clone.
Choose HTTPS.
Copy and save the URL by pasting it into a plain-text editor.
Choose Generate Git Credentials.
Copy the username and password and save them by pasting them into a plain-text editor.

Now that you have the URL and HTTPS Git credentials, create a pipeline.

Go to the Pipeline page within Azure DevOps.
Choose Create Pipeline (or New Pipeline ).
Choose Azure Repos Git.
Choose your repository.
Choose Starter pipeline.
Enter or copy the following YAML code to replace the default pipeline YAML:

 # This pipeline will automatically mirror an Azure DevOps repository in AWS CodeCommit

 # Trigger on all branches
 trigger:
 - '*'

 # Use latest Ubuntu image
 pool:
   vmImage: 'ubuntu-latest'

 # Pipeline
 steps:
 - checkout: none
 - script: |

       # Install urlencode function to encode reserved characters in passwords
       sudo apt-get install gridsite-clients

       # Create local mirror of Azure DevOps repository
       git clone --mirror https://${AZURE_GIT_USERNAME}:$(urlencode ${AZURE_GIT_PASSWORD})@${AZURE_REPO_URL} my-mirror-repo

       # Sync AWS CodeCommit repository
       cd my-mirror-repo
       git push --mirror https://${AWS_GIT_USERNAME}:$(urlencode ${AWS_GIT_PASSWORD})@${AWS_REPO_URL}

   displayName: 'Sync repository with AWS CodeCommit'
   env:
     AZURE_REPO_URL: $(AZURE_REPO_URL)
     AZURE_GIT_USERNAME: $(AZURE_GIT_USERNAME)
     AZURE_GIT_PASSWORD: $(AZURE_GIT_PASSWORD)
     AWS_REPO_URL: $(AWS_REPO_URL)
     AWS_GIT_USERNAME: $(AWS_GIT_USERNAME)
     AWS_GIT_PASSWORD: $(AWS_GIT_PASSWORD)

Choose Variables.
Choose New Variable.
Enter the variable Name and Value.
Select Keep this value secret when adding any user name or password variable.
Choose OK.
Repeat for each variable.
Choose Save.
Choose Save and Run.

Test the Pipeline

Upon saving the pipeline, it commits the pipeline's YAML file (azure-pipelines.yml) to the root of your primary branch in the source repository. Subsequently, the pipeline will be triggered to run automatically. To confirm the successful execution of the pipeline, follow these steps:

Azure DevOps Pipelines:
AWS CodeCommit Console:

By following these steps, you can easily confirm that your pipeline ran without issues and that your replica repository in AWS CodeCommit is up-to-date and synchronized with your source repository.

Note : The pipeline runs whenever a new commit is pushed to the source repository. All updates are mirrored in the replica CodeCommit repository, including commits, branches, and references.

Cleaning up

When youve completed all steps and are finished testing, follow these steps to delete resources to avoid incurring costs:

On the CodeCommit console, choose Repositories.
Choose your repository and choose Delete Repository.
On the IAM console, choose Users.
Choose your pipeline user and choose Delete User.
On the navigation pane, choose Policies.
Choose your CodeCommit Git push policy and choose Policy Actions and Delete.
Go to the Pipeline page within Azure DevOps and choose your pipeline.
Choose More Actions and choose Delete.

Conclusion

This post showed how you can use an Azure DevOps pipeline to mirror an Azure repository in AWS CodeCommit. It provided detailed instructions on setting up your replica repository in AWS CodeCommit, creating a least privilege access IAM policy and user credentials for the pipeline in IAM, and creating the pipeline in Azure DevOps.

Building an AWS AppSync Serverless Application using AWS CDK

Mikaeel Khalid — Wed, 02 Aug 2023 10:16:52 +0000

In this blog post, we will explore how to build a serverless application using AWS AppSync and AWS Cloud Development Kit (CDK). We will create a simple note-taking application with Create and Read functionality, powered by AWS AppSync, AWS Lambda, and DynamoDB.

Introduction to AWS AppSync:

AWS AppSync is a fully managed service that makes it easy to develop GraphQL APIs by handling the heavy lifting of securely connecting to data sources like DynamoDB, Lambda, and more. It allows you to build real-time and offline-capable applications with a flexible and powerful API.

AWS CDK Overview:

AWS Cloud Development Kit (CDK) is an open-source software development framework to define cloud infrastructure in code and provision it through AWS CloudFormation. It enables developers to build and manage AWS infrastructure using familiar programming languages like TypeScript, JavaScript, Python, Java, and C#. With CDK, you can easily create, configure, and deploy AWS resources.

Project Overview:

We will create a simple note-taking application with the following features:

A GraphQL API to interact with notes.
A Lambda function to handle the GraphQL resolvers.
A DynamoDB table to store the notes.

Prerequisites:

Before we begin, make sure you have the following prerequisites installed on your machine:

Node.js
AWS CDK

Step 1: Setting Up the Project

Let's start by setting up our project. Open your terminal and follow these steps:

# Create a new directory for your project
mkdir cdk-appsync-serverless-notes-app
cd cdk-appsync-serverless-notes-app

# Initialize a new Node.js project
cdk init --language=typescript

# Create a new directory for Lambda and GraphQL schema
mkdir lambdas graphql

Step 2: Create a new CDK Stack

Create a new CDK stack using the following code:

Import Required AWS CDK Libraries:

import { Duration, Expiration, Stack, StackProps } from 'aws-cdk-lib';
import { GraphqlApi, SchemaFile, AuthorizationType } from 'aws-cdk-lib/aws-appsync';
import { AttributeType, BillingMode, Table } from 'aws-cdk-lib/aws-dynamodb';
import { Runtime } from 'aws-cdk-lib/aws-lambda';
import { NodejsFunction } from 'aws-cdk-lib/aws-lambda-nodejs';
import { Construct } from 'constructs';
import { join } from 'path';

In this section, we import the necessary AWS CDK constructs and AWS AppSync, AWS Lambda, and AWS DynamoDB libraries.

Define the AppsyncServerlessStack Class:

export class AppsyncServerlessStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);
    // ...
  }
}

Here, we define a class named AppsyncServerlessStack, which extends the Stack class from AWS CDK. This class will be used to define our AWS infrastructure stack.

Create the GraphQL API:

const api = new GraphqlApi(this, 'notes-appsync-api', {
  name: 'notes-appsync-api',
  schema: SchemaFile.fromAsset('graphql/schema.graphql'),
  authorizationConfig: {
    defaultAuthorization: {
      authorizationType: AuthorizationType.API_KEY,
      apiKeyConfig: {
        expires: Expiration.after(Duration.days(365)),
      },
    },
  },
  xrayEnabled: true,
});

In this section, we create an instance of GraphqlApi, which represents our AWS AppSync GraphQL API. We provide the API name, and the GraphQL schema file location, and specify that API_KEY authorization is used with an expiration of 365 days. We also enable AWS X-Ray for the API to gain insights into performance and errors.

Create the Lambda Function for Resolvers:

const notesLambda = new NodejsFunction(this, 'notes-lambda', {
  functionName: 'notes-lambda',
  runtime: Runtime.NODEJS_16_X,
  entry: join(__dirname, '../lambdas/notesLambda.ts'),
  memorySize: 1024,
});

In this part, we create a Node.js AWS Lambda function using the NodejsFunction construct. This function will handle the GraphQL resolvers for our API. We specify the function's name, runtime, entry file location, and memory size.

Create a Data Source for the Lambda Function:

const lambdaDataSource = api.addLambdaDataSource('lambda-data-source', notesLambda);

Here, we create a data source for the GraphQL API, which is linked to the Lambda function we created earlier. This data source allows the API to interact with the Lambda function as a data source.

Create Resolvers for GraphQL Queries and Mutations:

lambdaDataSource.createResolver('query-resolver', {
  typeName: 'Query',
  fieldName: 'listNotes',
});

lambdaDataSource.createResolver('mutation-resolver', {
  typeName: 'Mutation',
  fieldName: 'createNote',
});

In this section, we create resolvers for the GraphQL queries and mutations. We specify the type and field names from the GraphQL schema and link them to the corresponding functions in the Lambda function.

Create a DynamoDB Table to Store Notes:

const notesTable = new Table(this, 'notes-api-table', {
  tableName: 'notes-api-table',
  billingMode: BillingMode.PAY_PER_REQUEST,
  partitionKey: {
    name: 'id',
    type: AttributeType.STRING,
  },
});

Here, we create a DynamoDB table to store the notes. We specify the table name, and billing mode (PAY_PER_REQUEST means we pay per request), and define a partition key named 'id' of type STRING.

Grant Lambda Function Access to the DynamoDB Table:

notesTable.grantFullAccess(notesLambda);

This line grants the Lambda function (notesLambda) full access to the DynamoDB table (notesTable). It allows the Lambda function to read and write data to the table.

Add DynamoDB Table Name as an Environment Variable for the Lambda Function:

notesLambda.addEnvironment('NOTES_TABLE', notesTable.tableName);

We add an environment variable to the Lambda function named NOTES_TABLE, and its value is set to the name of the DynamoDB table. This allows the Lambda function to know which table it should interact with.

Here is a complete CDK stack code:

// Import required AWS CDK libraries
import { Duration, Expiration, Stack, StackProps } from 'aws-cdk-lib';
import {
  GraphqlApi,
  SchemaFile,
  AuthorizationType,
} from 'aws-cdk-lib/aws-appsync';
import { AttributeType, BillingMode, Table } from 'aws-cdk-lib/aws-dynamodb';
import { Runtime } from 'aws-cdk-lib/aws-lambda';
import { NodejsFunction } from 'aws-cdk-lib/aws-lambda-nodejs';
import { Construct } from 'constructs';
import { join } from 'path';

export class AppsyncServerlessStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);

    // Create the GraphQL API
    const api = new GraphqlApi(this, 'notes-appsync-api', {
      name: 'notes-appsync-api',
      schema: SchemaFile.fromAsset('graphql/schema.graphql'),
      authorizationConfig: {
        defaultAuthorization: {
          authorizationType: AuthorizationType.API_KEY,
          apiKeyConfig: {
            expires: Expiration.after(Duration.days(365)),
          },
        },
      },
      xrayEnabled: true,
    });

    // Create the Lambda function for the resolvers
    const notesLambda = new NodejsFunction(this, 'notes-lambda', {
      functionName: 'notes-lambda',
      runtime: Runtime.NODEJS_16_X,
      entry: join(__dirname, '../lambdas/notesLambda.ts'),
      memorySize: 1024,
    });

    // Create a data source for the Lambda function
    const lambdaDataSource = api.addLambdaDataSource(
      'lambda-data-source',
      notesLambda
    );

    // Create resolvers for the GraphQL queries and mutations
    lambdaDataSource.createResolver('query-resolver', {
      typeName: 'Query',
      fieldName: 'listNotes',
    });

    lambdaDataSource.createResolver('mutation-resolver', {
      typeName: 'Mutation',
      fieldName: 'createNote',
    });

    // Create a DynamoDB table to store the notes
    const notesTable = new Table(this, 'notes-api-table', {
      tableName: 'notes-api-table',
      billingMode: BillingMode.PAY_PER_REQUEST,
      partitionKey: {
        name: 'id',
        type: AttributeType.STRING,
      },
    });

    // Grant the Lambda function full access to the DynamoDB table
    notesTable.grantFullAccess(notesLambda);

    // Add the DynamoDB table name as an environment variable for the Lambda function
    notesLambda.addEnvironment('NOTES_TABLE', notesTable.tableName);
  }
}

Step 3: Define the GraphQL Schema

In this step, we will define the GraphQL schema for our note-taking application. Create a file named schema.graphql inside the graphql directory with the following content:

type Note {
  id: ID!
  name: String!
  completed: Boolean!
}

input NoteInput {
  id: ID!
  name: String!
  completed: Boolean!
}

type Query {
  listNotes: [Note]
}

type Mutation {
  createNote(note: NoteInput!): Note
}

type Subscription {
  onCreateNote: Note @aws_subscribe(mutations: ["createNote"])
}

Step 4: Implement the Lambda Resolvers

Next, let's implement the Lambda function that will handle the GraphQL resolvers. Create a file named notesLambda.ts inside the lambdas directory with the following code:

// Import the required types
import { createNote, listNotes } from './notesOperations';
import { Note } from './types/Note';

// Define the AppSyncEvent type
type AppSyncEvent = {
  info: {
    fieldName: string;
  };
  arguments: {
    noteId: string;
    note: Note;
  };
};

// Lambda function handler
exports.handler = async (event: AppSyncEvent) => {
  switch (event.info.fieldName) {
    case 'createNote':
      return await createNote(event.arguments.note);

    case 'listNotes':
      return await listNotes();

    default:
      return null;
  }
};

Step 5: Implement the Lambda Operations

Now, let's implement the actual operations for creating and listing notes in DynamoDB. Create a file named notesOperations.ts inside the lambdas directory with the following code:

// Import the AWS SDK and the Note type
import { DynamoDB } from 'aws-sdk';
import { Note } from '../types/Note';

// Create a DynamoDB DocumentClient
const docClient = new DynamoDB.DocumentClient();

// Function to create a new note
export const createNote = async (note: Note) => {
  const params = {
    TableName: process.env.NOTES_TABLE as string,
    Item: note,
  };

  try {
    const data = await docClient.put(params).promise();
    console.log('data', data);
    return note;
  } catch (error) {
    console.log('dynamodb err: ', error);
    return null;
  }
};

// Function to list all notes
export const listNotes = async () => {
  const params = {
    TableName: process.env.NOTES_TABLE as string,
  };

  try {
    const data = await docClient.scan(params).promise();
    return data.Items;
  } catch (error) {
    console.log('dynamodb err: ', error);
    return null;
  }
};

Step 6: Deploy the Application

Now that we have implemented the GraphQL API, Lambda resolvers, and DynamoDB operations, it's time to deploy our application. Make sure you have installed and configured the AWS CLI on your machine.

Run the following commands to deploy the CDK stack:

# Install dependencies
npm install

# Booststrap the CDK Env (if not already)
cdk bootstrap

# Synthesize the CDK stack
cdk synth

# Deploy the CDK stack
cdk deploy

Once the deployment is complete, the AWS CloudFormation will create the necessary resources, including the GraphQL API, Lambda function, and DynamoDB table.

Conclusion:

Congratulations! You have successfully built an AWS AppSync serverless application using AWS CDK. You now have a GraphQL API to interact with your note-taking application, powered by AWS Lambda and DynamoDB. This is just the beginning, and you can extend the application with additional features like authentication, real-time updates using subscriptions, and more.

I hope you found this blog post helpful and that it inspires you to explore further and build more sophisticated serverless applications using AWS AppSync and AWS CDK. Happy coding!

GitHub Repo:

https://github.com/mikaeelkhalid/aws-cdk-appsync-serverless-boilerplate

How to Deploy Dockerized AWS Lambda Using AWS CDK

Mikaeel Khalid — Tue, 16 May 2023 09:54:41 +0000

In this blog post, we'll explore a step-by-step guide on how to deploy Dockerized AWS Lambda functions using the AWS Cloud Development Kit (CDK) with TypeScript.

AWS CDK, a software development framework for defining cloud infrastructure in code, has eased cloud resources management by facilitating the use of familiar programming languages. The combination of Docker, AWS Lambda, and CDK takes it to another level, providing a seamless development and deployment process.

Prerequisites

Before we start, make sure you have the following:

An AWS Account
AWS CLI installed and configured
Docker installed
Node.js and npm installed
AWS CDK installed

Step 1: Initialize a new AWS CDK project

First, create a new directory for your project and navigate to it:

mkdir cdk-docker-lambda && cd cdk-docker-lambda

Initialize a new AWS CDK project:

cdk init --language=typescript

This command creates a new CDK project with TypeScript as the programming language.

Step 2: Create a Dockerfile

Now, let's create a Dockerfile. This file is a set of instructions Docker will use to create your Docker image. Here's an example of a Dockerfile for a Node.js application:

FROM public.ecr.aws/lambda/nodejs:14

WORKDIR /var/task

COPY . .

RUN npm install

CMD ["index.handler"]

This Dockerfile starts from a public Amazon ECR image for Node.js 14, copies your application code into the image, installs your npm dependencies, and sets index.handler as the command that will be executed when your Lambda function is invoked.

Note: The Folder Structure should be like this

.
 bin
 lambdas
    index.js
    Dockerfile
 lib

Step 3: Write your AWS CDK Stack

Now, let's define our AWS CDK stack. In the lib directory, there's a file called cdk-docker-lambda-stack.ts Open this file and write your stack:

import { Duration, Stack, StackProps } from 'aws-cdk-lib';
import { Construct } from 'constructs';
import { DockerImageCode, DockerImageFunction } from 'aws-cdk-lib/aws-lambda';
import path = require('path');

export class CdkDockerLambdaStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);

    new DockerImageFunction(this, 'docker-lambda-function', {
      functionName: "docker-lambda-fn",
      code: DockerImageCode.fromImageAsset(path.join(__dirname, '../lambdas')),
      memorySize: 512,
      timeout: Duration.minutes(2),
      description: "This is dockerized AWS Lambda function"
    });
  }
}

In this code, we're defining a new Lambda function that uses a Docker image as its code. lambda.DockerImageCode.fromImageAsset takes the path to the directory containing your Dockerfile and builds your Docker image.

Step 4: Deploy your AWS CDK Stack

Compile your TypeScript code:

npm run build

Next, you'll need to bootstrap your AWS environment to use the CDK if you haven't already:

cdk bootstrap

Finally, deploy your AWS CDK stack:

cdk deploy

This command will build your Docker image, push it to an Amazon ECR repository, and create your AWS Lambda function with the Docker image.

Note: If the deploy command failed due to ECR login

You can use the following command:

aws ecr get-login-password --region your-region | docker login --username AWS --password-stdin aws-account-id.dkr.ecr.us-east-1.amazonaws.com

After login success, you can cdk deploy again

Conclusion

In this blog post, we've seen how to use the AWS CDK with TypeScript to deploy Dockerized AWS Lambda functions. This combination allows you to define your AWS infrastructure using a familiar programming language, leverage the power of modern software practices like version control and CI/CD, and package your Lambda functions as Docker containers. This last point is particularly powerful, as it enables you to use any programming language that can run inside a Docker container, not just those natively supported by AWS Lambda.

https://github.com/mikaeelkhalid/aws-cdk-docker-lambda/tree/main

What does the AWS CDK Diff command do

Mikaeel Khalid — Mon, 20 Mar 2023 11:56:03 +0000

Introduction

The AWS Cloud Development Kit (CDK) is an open-source software development framework that simplifies the process of creating, deploying and managing AWS infrastructure. It enables developers to use familiar programming languages such as TypeScript, Python, Java, and C# to define reusable cloud components and provision them using AWS CloudFormation.

One of the commands that the AWS CDK offers is the cdk diff command. In this blog post, we'll delve into the cdk diff command, its purpose, and how it can help you manage your infrastructure with ease. We will also explore practical examples to illustrate its utilizations.

What is the CDK Diff?

The cdk diff command is a part of the AWS CDK CLI and helps developers identify the differences between the current AWS CDK application state and the deployed state in AWS CloudFormation. This comparison can be useful in various scenarios, such as validating changes before deployment, auditing infrastructure modifications, or reviewing pull requests in collaborative projects.

The command provides a clear and concise output, showing the differences between your local and deployed resources, properties, and settings.

How to use CDK Diff?

To use the cdk diff command, first, ensure that you have the AWS CDK CLI installed. If you don't have it installed, you can follow the official AWS CDK installation guide.

Once the AWS CDK CLI is installed, navigate to your CDK project directory and run the following command

cdk diff

This command will display the differences between your local AWS CDK application and the deployed AWS CloudFormation stack. The output will show added, modified, or removed resources, as well as changes in their properties.

Examples

Let's consider a simple example to understand how the cdk diff command works. We'll use TypeScript for this example, but the concepts apply to other programming languages as well.

Creating a new CDK project

cdk init app --language typescript

Adding an Amazon S3 bucket to your CDK stack

Modify the file lib/your_stack_name-stack.ts and add the following code snippet

import { Stack, StackProps} from 'aws-cdk-lib';
import { Bucket, RemovalPolicy } from 'aws-cdk-lib/aws-s3';

export class YourStackNameStack extends Stack {
  constructor(scope: cdk.App, id: string, props?: StackProps) {
    super(scope, id, props);

    new Bucket(this, 'MyFirstBucket', {
      versioned: true,
      removalPolicy: RemovalPolicy.DESTROY,
    });
  }
}

Deploy the CDK stack

cdk deploy

Now, let's say you want to update the S3 bucket to enable server access logging. Modify the lib/your_stack_name-stack.ts file as follows

import { Stack, StackProps } from 'aws-cdk-lib';
import { Bucket, RemovalPolicy } from 'aws-cdk-lib/aws-s3';

export class YourStackNameStack extends Stack {
  constructor(scope: cdk.App, id: string, props?: StackProps) {
    super(scope, id, props);

    const loggingBucket = new Bucket(this, 'LoggingBucket', {
      removalPolicy: RemovalPolicy.DESTROY,
    });

    new Bucket(this, 'MyFirstBucket', {
      versioned: true,
      removalPolicy: RemovalPolicy.DESTROY,
      serverAccessLogsBucket: loggingBucket,
    });
  }
}

Running the CDK Diff command

Before deploying the changes, let's run the cdk diff command to inspect the differences between the local AWS CDK application and the deployed AWS CloudFormation stack

cdk diff

You should see an output similar to the following

Stack YourStackNameStack
Resources
[+] AWS::S3::Bucket LoggingBucket LoggingBucketA1B2C3D4
[-] AWS::S3::Bucket MyFirstBucket MyFirstBucketE5F6G7H8
[+] AWS::S3::Bucket MyFirstBucket MyFirstBucketI9J0K1L2
   [+] LoggingConfiguration
       [+] DestinationBucketName: {"Ref":"LoggingBucketA1B2C3D4"}

The output indicates the following changes:

A new S3 bucket (LoggingBucket) has been added.
The existing S3 bucket (MyFirstBucket) will be replaced with a new S3 bucket.
The new S3 bucket (MyFirstBucket) will have a logging configuration pointing to the LoggingBucket.

Deploying the changes

Now that we've reviewed the differences using cdk diff, we can proceed to deploy the changes with the cdk deploy command

cdk deploy

This will update the AWS CloudFormation stack with the new resources and configurations.

Conclusion

In this blog post, we've explored the importance and usage of the cdk diff command in the AWS CDK. The command serves as an efficient tool for managing and validating infrastructure changes before deployment, allowing you to catch potential issues early and maintain a clear understanding of your AWS infrastructure.

By incorporating cdk diff into your development workflow, you can maintain better control over your AWS resources, ensure that your infrastructure changes are consistent with your expectations, and improve collaboration in your team by reviewing infrastructure changes more effectively.

Using AWS CDK to Deploy an AWS Fargate Service

Mikaeel Khalid — Thu, 16 Mar 2023 09:28:14 +0000

Introduction

Amazon Web Services (AWS) offers a wide range of tools and services for developers to build, deploy, and manage their applications in the cloud. One such service is AWS Fargate, a serverless compute engine for containers that make it easier to run containerized applications without managing the underlying infrastructure. The AWS Cloud Development Kit (CDK) is an open-source software development framework for defining cloud infrastructure in code and provisioning it through AWS CloudFormation.

This blog post will dive deep into using the AWS CDK to deploy an AWS Fargate service, complete with code examples. By the end of this guide, you will better understand how to deploy a containerized application using the AWS CDK and Fargate.

Prerequisites

Before getting started, make sure you have the following installed and configured:

Node.js (v10.x or later)
AWS CLI (v2.x)
AWS CDK (v2.x)
Docker (for building and testing the container)

Get Started

Step 1: Initialize the AWS CDK project

First, create a new directory for your project and initialize a new CDK project using TypeScript:

$ mkdir fargate-cdk && cd fargate-cdk
$ cdk init --language typescript

Step 2: Open in VSCode or any editor

In VSCode:

$ code .

Step 3: Define the Fargate service stack

Open the lib/fargate-cdk-stack.ts file and replace its content with the following code:

import * as cdk from 'aws-cdk-lib';
import * as ecs from 'aws-cdk-lib/aws-ecs';
import * as ecr from 'aws-cdk-lib/aws-ecr';
import * as ecs_patterns from 'aws-cdk-lib/aws-ecs-patterns';

export class FargateCdkStack extends cdk.Stack {
  constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // Create an ECS cluster
    const cluster = new ecs.Cluster(this, 'FargateCluster', {
      vpc: new cdk.Vpc(this, 'Vpc'),
    });

    // Load the ECR repository
    const ecrRepository = ecr.Repository.fromRepositoryName(
      this,
      'EcrRepository',
      'your-ecr-repo-name'
    );

    // Define the Fargate service
    new ecs_patterns.ApplicationLoadBalancedFargateService(this, 'FargateService', {
      cluster: cluster,
      taskImageOptions: {
        image: ecs.ContainerImage.fromEcrRepository(ecrRepository),
        containerPort: 80,
      },
      desiredCount: 2,
      publicLoadBalancer: true,
    });
  }
}

Replace 'your-ecr-repo-name' with the name of your existing ECR repository.

Step 4: Build the Docker image and push it to ECR

Create a Dockerfile in your project's root directory:

FROM node:14-alpine

WORKDIR /app

COPY package*.json ./

RUN npm install

COPY . .

EXPOSE 80

CMD ["npm", "start"]

Build the Docker image and push it to your ECR repository:

$ aws ecr --region us-west-2 get-login-password | docker login --username AWS --password-stdin <your_account_id>.dkr.ecr.us-east-1.amazonaws.com

$ docker build -t your-ecr-repo-name .

$ docker tag your-ecr-repo-name:latest <your_account_id>.dkr.ecr.us-east-1.amazonaws.com/your-ecr-repo-name:latest

$ docker push <your_account_id>.dkr.ecr.us-east-1.amazonaws.com/your-ecr-repo-name:latest

Replace <your_account_id> with your AWS account ID.

Step 5: Deploy the Fargate service

Now that you have the Docker image pushed to ECR, you can deploy the Fargate service using the AWS CDK:

$ npm run build
$ cdk deploy

The cdk deploy command will create a new CloudFormation stack with the specified Fargate service, load balancer, and other required resources. You can view the progress of the deployment in the AWS Management Console under the CloudFormation service.

Note: If you're using CDK for the first time make sure to bootstrap your environment.

$ cdk bootstrap

Step 6: Test the Fargate service

After the deployment has been completed, you can test your Fargate service by navigating to the provided load balancer URL. You can find the URL in the CloudFormation stack outputs or the AWS Management Console under the Elastic Load Balancing service.

Conclusion

In this blog post, we have demonstrated how to use the AWS CDK to deploy a containerized application with an AWS Fargate service. By leveraging the AWS CDK and Fargate, you can simplify the deployment and management of your applications, allowing you to focus on writing code rather than managing infrastructure.

How to List Stacks in AWS CDK

Mikaeel Khalid — Fri, 03 Mar 2023 01:26:39 +0000

AWS Cloud Development Kit (CDK) is a powerful tool that allows developers to define and deploy their infrastructure as code. One of the key features of CDK is the ability to create and manage stacks, which are collections of AWS resources that are deployed together. In this article, we will explore how to list stacks in AWS CDK.

To list stacks in AWS CDK, you can use the cdk list command. This command will display a list of all stacks that have been defined in your CDK application. The output will include the stack name, the stack environment, and the stack status.

To list all stacks in your CDK application, you can use the following command:

cdk list

Note, we could use the alias - cdk ls

This command will display a list of all stacks that have been defined in your CDK application, including the stack name, the stack environment, and the stack status.

If you want to list stacks in a specific environment, you can use the -e or --environment option. For example, to list stacks in the prod environment, you can use the following command:

cdk list -e prod

This command will display a list of all stacks that have been defined in the prod environment, including the stack name, the stack environment, and the stack status.

If you want to list stacks in a specific region, you can use the -r or --region option. For example, to list stacks in the us-east-1 the region, you can use the following command:

cdk list -r us-east-1

This command will display a list of all stacks that have been defined in the us-east-1 region, including the stack name, the stack environment, and the stack status.

In addition to listing stacks, the cdk list command also allows you to filter the output by stack status. You can use the -s or --status option to filter the output based on the stack status. For example, to list only stacks that are in the CREATE_COMPLETE status, you can use the following command:

cdk list -s CREATE_COMPLETE

This command will display a list of all stacks that are in the CREATE_COMPLETE status, including the stack name, the stack environment, and the stack status.

Another useful option when using the cdk list command is the --long option. This option will display additional information about each stack, such as the stack's id, name, AWS account, region, environment, and where the stack is deployed.

For example, if you want to view all the stacks in your CDK application, along with additional information, you can use the following command:

cdk list --long

The --long flag outputs information about the environment (accountand region) our stacks belong to:

- id: my-stack-prod
  name: my-stack-prod
  environment:
    account: '123456789'
    region: us-east-1
    name: aws://123456789/us-east-1

- id: my-stack-dev
  name: my-stack-dev
  environment:
    account: '123456789'
    region: us-east-1
    name: aws://123456789/us-east-1

In conclusion, the cdk list command is a powerful tool that allows you to list stacks in AWS CDK. You can use this command to list all stacks in your CDK application, list stacks in a specific environment, list stacks in a specific region, and filter the output by stack status. This makes it easy to manage your stacks and ensure that your infrastructure is deployed correctly.

Build serverless applications with AWS CDK

Mikaeel Khalid — Wed, 15 Feb 2023 15:51:13 +0000

Serverless computing is becoming an increasingly popular way to develop and deploy applications. With serverless, developers can focus on writing code and not worry about the underlying infrastructure. AWS Lambda and API Gateway are two popular AWS services used for serverless computing. In this blog post, we will explore how to use AWS CDK to deploy serverless applications using these services.

Getting started with AWS CDK

Before we get into the specifics of building serverless applications, let's start with a brief introduction to AWS CDK. AWS Cloud Development Kit (CDK) is an open-source software development framework for defining cloud infrastructure in code. With AWS CDK, you can define your infrastructure in familiar programming languages such as TypeScript, Python, and Java. AWS CDK uses AWS CloudFormation under the hood, so all of your infrastructure is defined in a CloudFormation stack.

Creating a serverless stack

To create a serverless stack with AWS CDK, we first need to define our resources. In this case, we will be defining an AWS Lambda function and an API Gateway endpoint. Let's start with the Lambda function:

import * as cdk from 'aws-cdk-lib';
import * as lambda from 'aws-cdk-lib/aws-lambda';

export class ServerlessStack extends cdk.Stack {
  constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    const myFunction = new lambda.Function(this, 'MyFunction', {
      runtime: lambda.Runtime.NODEJS_14_X,
      handler: 'index.handler',
      code: lambda.Code.fromAsset('path/to/lambda/code'),
    });
  }
}

In this example, we are defining a new Lambda function with the runtime of Node.js 14.x. We are also specifying the location of the code for the function. This code could be located in a local directory or in an S3 bucket.

Next, we will define the API Gateway endpoint:

import * as apigw from 'aws-cdk-lib/aws-apigatewayv2';

export class ServerlessStack extends cdk.Stack {
  constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    const myFunction = new lambda.Function(this, 'MyFunction', {
      runtime: lambda.Runtime.NODEJS_14_X,
      handler: 'index.handler',
      code: lambda.Code.fromAsset('path/to/lambda/code'),
    });

    const api = new apigw.HttpApi(this, 'MyApi');
    api.addRoutes({
      path: '/',
      methods: [apigw.HttpMethod.GET],
      integration: new apigw.LambdaProxyIntegration({
        handler: myFunction,
      }),
    });
  }
}

In this example, we are defining a new HTTP API Gateway endpoint that routes to our Lambda function. We are specifying that this endpoint should respond to GET requests and forward them to our Lambda function.

Deploying and testing your serverless application

Once we have defined our resources, we can deploy our stack using the AWS CDK CLI:

cdk deploy

This will create the necessary resources in your AWS account. Once the deployment is complete, we can test our API Gateway endpoint by sending an HTTP GET request to the endpoint URL:

curl https://api-gateway-url/

This should return the output from our Lambda function.

Conclusion

In this blog post, we have seen how to use AWS CDK to define and deploy a serverless stack containing an AWS Lambda function and an API Gateway endpoint. With AWS CDK, you can define your infrastructure in code and easily manage it through version control systems and continuous integration/continuous deployment (CI/CD) pipelines. AWS CDK abstracts away the complexity of CloudFormation and provides an intuitive programming interface that makes it easy to create and manage AWS resources.

With AWS CDK, you can take advantage of the benefits of serverless computing, such as automatic scaling and pay-as-you-go pricing. AWS Lambda and API Gateway are just two of the many serverless services provided by AWS, and with AWS CDK, you can easily create and manage these services alongside other AWS services.

In summary, AWS CDK provides an excellent framework for defining and deploying serverless applications. With its intuitive programming interface and integration with AWS CloudFormation, you can easily manage your serverless infrastructure in code. By using AWS CDK, you can take advantage of the benefits of serverless computing, such as automatic scaling and pay-as-you-go pricing, and build reliable and scalable serverless applications.

How to Create an IAM User with AWS CDK

Mikaeel Khalid — Wed, 08 Feb 2023 12:19:38 +0000

The AWS Identity and Access Management (IAM) service allow you to manage users and their permissions within your AWS environment. In this article, we will show you how to create an IAM user using the AWS Cloud Development Kit (CDK).

The AWS CDK is an open-source software development framework for defining cloud infrastructure as code and provisioning it through AWS CloudFormation. With the AWS CDK, you can use familiar programming languages, such as TypeScript, Python, Java, and others, to write infrastructure-as-code scripts that define your AWS environment.

To create an IAM user in the AWS CDK, you will need to write a script that creates an IAM user object and assigns the desired permissions to it. To get started, you will need to install the AWS CDK and initialize a new project in your preferred programming language.

Here is an example of how to create an IAM user in the AWS CDK using TypeScript:

import * as cdk from 'aws-cdk-lib';
import * as iam from 'aws-cdk-lib/aws-iam';

export class IamUserStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    const user = new iam.User(this, 'IamUser', {
      userName: 'iam-user',
    });

    const policy = new iam.Policy(this, 'Policy', {
      policyName: 'IamUserPolicy',
      statements: [
        new iam.PolicyStatement({
          actions: ['s3:ListBucket'],
          resources: ['arn:aws:s3:::*'],
        }),
      ],
    });

    policy.attachToUser(user);
  }
}

In the code above, we first import the AWS CDK and IAM modules from the aws-cdk-lib library. Then, we define a new IAM user by creating an instance of the User class and specifying the desired user name.

Next, we create an IAM policy using the Policy class. The policy defines the permissions that will be assigned to the IAM user. In this example, we are granting the ListBucket action on all S3 buckets in the AWS account.

Finally, we attach the policy to the IAM user using the attachToUser method of the Policy class.

Once you have written the script, you can use the AWS CDK CLI to deploy the IAM user to your AWS environment. To deploy the IAM user, you will need to run the following command in your terminal:

cdk deploy

The AWS CDK will then create a CloudFormation stack and deploy the IAM user to your AWS environment. You can verify the successful deployment of the IAM user by logging into the AWS Management Console and checking the IAM section.

To destroy the above stack:

cdk destroy

In conclusion, the AWS CDK provides an easy and convenient way to manage IAM users in your AWS environment. With the AWS CDK, you can define IAM users and their permissions using code, making it easy to automate the creation and management of IAM users in your AWS environment.

How to do Subnet Selection in AWS CDK

Mikaeel Khalid — Fri, 03 Feb 2023 03:30:39 +0000

AWS CDK, or Amazon Web Services Cloud Development Kit, is a software development framework for building and deploying cloud-based applications on Amazon Web Services. The CDK provides an easy-to-use and high-level API for building cloud-based applications and automates many of the underlying infrastructure management tasks. The CDK supports several programming languages, including TypeScript, Python, and Java.

In this post, we will explore how to select a subnet in AWS CDK using TypeScript. Subnets are a logical partition of a VPC (Virtual Private Cloud) network and allow you to allocate network resources and control network access. The selection of the right subnet is important in order to ensure that your applications are deployed in the desired environment and can communicate with other resources in the VPC.

We will start by creating a new AWS CDK project using TypeScript. To do this, you will need to have the AWS CDK CLI installed. You can install it by running the following command:

npm install -g aws-cdk

Next, create a new project by running the following command:

cdk init sample-app --language typescript

This will create a new AWS CDK project named sample-app and set the programming language to TypeScript.

Now, let's create a VPC with two subnets in the project. To do this, add the following code to the lib/sample-app-stack.ts file:

import * as cdk from 'aws-cdk-lib';
import * as ec2 from 'aws-cdk-lib/aws-ec2';

export class SampleAppStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    const vpc = new ec2.Vpc(this, 'VPC', {
      cidr: '10.0.0.0/16',
      subnetConfiguration: [
        {
          cidrMask: 24,
          name: 'Subnet1',
          subnetType: ec2.SubnetType.PUBLIC,
        },
        {
          cidrMask: 24,
          name: 'Subnet2',
          subnetType: ec2.SubnetType.PRIVATE,
        },
      ],
    });
  }
}

In the code above, we are creating a new VPC with two subnets. The first subnet is a public subnet and the second subnet is a private subnet. The subnet configuration is specified using the subnetConfiguration parameter, which takes an array of subnet configurations. Each subnet configuration contains the CIDR mask, subnet name, and subnet type.

Next, we need to select the desired subnet to deploy our applications in. To do this, we can use the selectSubnets method on the VPC object. The selectSubnets method allows us to specify a filter function that determines which subnets should be selected.

For example, to select the private subnet, we can add the following code to the lib/sample-app-stack.ts file:

import * as cdk from 'aws-cdk-lib';
import * as ec2 from 'aws-cdk-lib/aws-ec2';

export class SampleAppStack extends cdk.Stack {
constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
super(scope, id, props);

const vpc = new ec2.Vpc(this, 'VPC', {
  cidr: '10.0.0.0/16',
  subnetConfiguration: [
    {
      cidrMask: 24,
      name: 'Subnet1',
      subnetType: ec2.SubnetType.PUBLIC,
    },
    {
      cidrMask: 24,
      name: 'Subnet2',
      subnetType: ec2.SubnetType.PRIVATE,
    },
  ],
});

const privateSubnets = vpc.selectSubnets({
  subnetType: ec2.SubnetType.PRIVATE,
});

  } 
}

In the code above, we are selecting the private subnets using the selectSubnets method and the subnetType filter. The filter is set to ec2.SubnetType.PRIVATE, which means that only the subnets with the type PRIVATE will be selected. The selected subnets are stored in the privateSubnets variable. Now that we have selected the desired subnet, we can use it to deploy our applications. For example, to deploy an EC2 instance in the private subnet, we can add the following code to the lib/sample-app-stack.ts file:

import * as cdk from 'aws-cdk-lib';
import * as ec2 from 'aws-cdk-lib/aws-ec2';

export class SampleAppStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    const vpc = new ec2.Vpc(this, 'VPC', {
      cidr: '10.0.0.0/16',
      subnetConfiguration: [
        {
          cidrMask: 24,
          name: 'Subnet1',
          subnetType: ec2.SubnetType.PUBLIC,
        },
        {
          cidrMask: 24,
          name: 'Subnet2',
          subnetType: ec2.SubnetType.PRIVATE,
        },
      ],
    });

    const privateSubnets = vpc.selectSubnets({
      subnetType: ec2.SubnetType.PRIVATE,
    });

    new ec2.Instance(this, 'Instance', {
      vpc,
      subnet: privateSubnets[0],
      instanceType: ec2.InstanceType.of(ec2.InstanceClass.T2, ec2.InstanceSize.MICRO),
      machineImage: new ec2.AmazonLinuxImage(),
    });

  }
}

In the code above, we are creating a new EC2 instance using the Instance class from the AWS CDK library. The instance is deployed in the VPC and the selected private subnet is specified using the subnet property of the Instance class. The instance is deployed in the first subnet of the privateSubnets array, which is accessed using privateSubnets[0].

Additionally, we have specified the instance type, machine image, and other required properties to deploy the EC2 instance.

In conclusion, the AWS CDK library provides a simple and straightforward way to select subnets in your VPCs. With the selectSubnets method, you can easily filter the subnets based on different criteria, such as subnet type, availability zone, or tags, to deploy your applications in the desired subnets.

By using the subnet selection feature, you can control the network access to your applications and maintain the security of your resources. Moreover, you can optimize your network architecture by deploying applications in subnets that best match their requirements and ensure the optimal performance of your applications.