
subaud is authored by Court Schuett (he/him). While Court is an 8090 Inc employee, opinions and statements on this blog are his own.


Court Schuett


To add on to the previous [article](https://subaud.io/importing-an-amazon-lex-bot-with-cdk/) that described how to import an Amazon Lex Bot with CDK, I have created a [CDK Construct](https://constructs.dev/packages/cdk-lex-zip-import/v/0.0.4?lang=typescript) that you can import and use in your own CDK projects.

To add this to your CDK project, simply import the Construct:

```bash
yarn add cdk-lex-zip-import
```

Within your CDK:

```typescript
const bot = new lexupload.ImportBot(this, 'lexBot', {
  sourceDirectory: './resources/LexBot',
  lexRoleArn: lexRole.roleArn,
});
```

The `sourceDirectory` must include a file named `LexBot.zip`. This file will be uploaded to an S3 Bucket and then imported using a Lambda backed Custom Resource.

Additionally, a Resource Policy can be applied to the Alias once it is imported.

```typescript
bot.addResourcePolicy(resourceArn, policy);
```

A complete example might look like this:

```typescript
import { Stack, StackProps } from 'aws-cdk-lib';
import * as iam from 'aws-cdk-lib/aws-iam';
import * as lexupload from 'cdk-lex-zip-import';
import { Construct } from 'constructs';

export class MyStack extends Stack {
  constructor(scope: Construct, id: string, props: StackProps = {}) {
    super(scope, id, props);

    const lexRole = new iam.Role(this, 'lexRole', {
      assumedBy: new iam.ServicePrincipal('lex.amazonaws.com'),
      inlinePolicies: {
        ['lexPolicy']: new iam.PolicyDocument({
          statements: [
            new iam.PolicyStatement({
              resources: ['*'],
              actions: ['polly:SynthesizeSpeech', 'comprehend:DetectSentiment'],
            }),
          ],
        }),
      },
    });

    const bot = new lexupload.ImportBot(this, 'lexBot', {
      sourceDirectory: './resources/LexBot',
      lexRoleArn: lexRole.roleArn,
    });

    const resourceArn = `arn:aws:lex:${this.region}:${this.account}:bot-alias/${bot.botId}/${bot.botAliasId}`;
    const policy = {
      Version: '2012-10-17',
      Statement: [
        {
          Sid: 'AllowChimePstnAudioUseBot',
          Effect: 'Allow',
          Principal: { Service: 'voiceconnector.chime.amazonaws.com' },
          Action: 'lex:StartConversation',
          Resource: resourceArn,
          Condition: {
            StringEquals: { 'AWS:SourceAccount': `${this.account}` },
            ArnEquals: {
              'AWS:SourceArn': `arn:aws:voiceconnector:us-east-1:${this.account}:*`,
            },
          },
        },
      ],
    };
    bot.addResourcePolicy(resourceArn, policy);
  }
}
```

For more information or to contribute, please see the [GitHub repo](https://github.com/schuettc/cdk-lex-zip-import).


To add on to the previous [article](https://subaud.io/importing-an-amazon-lex-bot-with-cdk/) that described how to import an Amazon Lex Bot with CDK, I have created a [CDK Construct](https://constructs.dev/packages/cdk-lex-zip-import/v/0.0.4?lang=typescript) that you can import and use in your own CDK projects.

A CDK Construct for Importing Amazon Lex Bots


Amazon Lex Bots are a way to use natural language conversational interfaces that can be used through a variety of integrations such as Facebook and Slack. A Lex Bot can be built and deployed through the AWS console. However, it can also be deployed by CDK, Cloudformation, or SDK. In this post, I will explain how to import an existing Lex Bot using CDK and SDK.

![LexBot](/images/blog/Directory.png)

After cloning [this repo](https://github.com/schuettc/cdk-lex-import), you will see a zipped LexBot in the `resources` directory. As part of the CDK, this file will be copied up with the Lex import Lambda. You can replace this Zip file with a Lex Bot of your choosing.

```typescript
const lexDeployLambda = new lambda.Function(this, 'lexDeployLambda', {
  runtime: lambda.Runtime.PYTHON_3_9,
  code: lambda.Code.fromAsset(path.join(__dirname, '@/resources/lexBot')),
  handler: 'index.handler',
  architecture: lambda.Architecture.ARM_64,
  timeout: Duration.minutes(1),
  role: lexCustomResourceRole,
});

const uid: string = Names.uniqueId(this);

const LexResourceProvider = new cr.Provider(this, 'LexResourceProvider', {
  onEventHandler: lexDeployLambda,
});

const lexBot = new CustomResource(this, 'LexCustomResource', {
  serviceToken: LexResourceProvider.serviceToken,
  properties: { uid: uid, lex_role_arn: lexRole.roleArn },
});
```

While the CDK is being deployed, the Custom Resource Lambda will be triggered with a `Create` RequestType. This will cause the Lambda to begin the process of importing the bot.

```python
def create_bot(bot_name, lex_role_arn, account_id):
    response_data = {}
    upload_info = lex.create_upload_url()
    upload_bot(upload_info)
    import_bot(bot_name, upload_info["importId"], lex_role_arn)
    bot_id = get_bot_id(bot_name)
    bot_alias_id = get_bot_alias_id(bot_id)
    put_resource_policy(bot_id, bot_alias_id, account_id)
    build_bot(bot_id)
    response_data["bot_id"] = bot_id
    response_data["bot_alias_id"] = bot_alias_id
    return response_data
```

There are multiple steps required to import and build a Lex bot. This function will work through each of those.

The first step is to create a URL that will be used as part of the import. This is done with a single lexv2-models API call:

```python
upload_info = lex.create_upload_url()
```

Once this URL is created, it is passed to the upload_bot function and the `LexBot.zip` file is uploaded to the specified URL.

```python
def upload_bot(upload_info):
    http = urllib3.PoolManager()
    try:
        with open("LexBot.zip", mode="rb") as bot:
            file_data = bot.read()

    except Exception as e:
        error = {"error": f"Exception thrown: {e}"}
        print(error)
        raise Exception(error)
    try:
        upload = http.request(
            "PUT", upload_info["uploadUrl"], body=file_data, headers={"Content-Type": "application/zip"}
        )

    except Exception as e:
        error = {"error": f"Exception thrown: {e}"}
        print(error)
        raise Exception(error)
    logger.info(upload.data.decode("utf-8"))
    return upload
```

Once uploaded to S3, the bot must be imported.

```python
def import_bot(bot_name, import_id, lex_role_arn):
    bot_import_result = lex.start_import(
        importId=import_id,
        resourceSpecification={
            "botImportSpecification": {
                "botName": bot_name,
                "roleArn": lex_role_arn,
                "dataPrivacy": {"childDirected": False},
                "idleSessionTTLInSeconds": 600,
            },
        },
        mergeStrategy="Overwrite",
    )
    logger.info(bot_import_result)
    return bot_import_result
```

If a Resource Policy is required for your Bot, it can be added with the `put_resource_policy` function also included. The Bot will then be built and is now ready for use.

Once the Lambda has completed importing the Bot to Lex, it will return the bot_id and bot_alias_id to the CDK.

Once the Lex bot has been imported, it can be tested in the Lex console.

![LexTest](/images/blog/LexTest.png)

### Resources

- [GitHub Repo](https://github.com/schuettc/cdk-lex-import)
- [Amazon Lex](https://aws.amazon.com/lex/)
- [Boto3 - Lexv2-Models](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/lexv2-models.html)


Amazon Lex Bots are a way to use natural language conversational interfaces that can be used through a variety of integrations such as Facebook and Slack.  A Lex Bot can be built and deployed through the AWS console.  However, it can also be deployed by CDK, Cloudformation, or SDK.  In this post, I will explain how to import an existing Lex Bot using CDK and SDK.

Importing an Amazon Lex Bot with CDK


## Full Stack CDK Example

This example will build a CDK Pipeline that will build a backend and frontend and then pass API Gateway URL information from the backend to the frontend. This information can be used to make calls to the backend without having to manually pass the URL information. When connected to a Github repo, the CDK pipeline will automatically trigger and rebuild so changes to any portion of the app through GitHub.

**Please note: this deployment will create a file that will be accessible to the public so sensitive information should not be included. **

![Full Stack App Overview](/images/Pipeline.png)

### CDK Pipeline

The pipeline created is a self-mutating pipeline associated with a GitHub repo using a CodeStar connection. This can be adjusted to other Pipeline [sources](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.pipelines-readme.html#synth-and-sources).

This pipeline contains a single Stage with three Stacks.

```typescript
    const pipeline = new pipelines.CodePipeline(this, 'Pipeline', {
      ...
    });

    const stages = new Stages(this, 'Stages', {});
    pipeline.addStage(stages);
```

### Backend Stack

```typescript
export class Backend extends Stack {
  public readonly config: Object;

  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);
    ...
    this.config = {
      API_URL: api.url,
    };
  }
}
```

The Backend stack creates a sample Lambda function and associates it with an API Gateway. The URL from this API Gateway is used as the output in a JSON Object that will be used in the Config Stack.

### Frontend Stack

The Frontend Stack is a simple S3 + Cloudfront Distribution that will be used to host a React SPA. Before uploading to the S3 bucket with `s3deploy.BucketDeployment` it must be bundled. The output of this `yarn build` will be copied to the outputDir and deployed to the S3 bucket.

```typescript
const bundle = s3deploy.Source.asset('./site', {
  bundling: {
    command: [
      'sh',
      '-c',
      'echo "Docker build not supported. Please install esbuild."',
    ],
    image: DockerImage.fromRegistry('alpine'),
    local: {
      tryBundle(outputDir: string) {
        try {
          execSync('esbuild --version', execOptions);
        } catch {
          /* istanbul ignore next */
          return false;
        }
        execSync(
          'cd site && yarn install --frozen-lockfile && yarn build',
          execOptions,
        );
        copySync('./site/build', outputDir, {
          ...execOptions,
          recursive: true,
        });
        return true;
      },
    },
  },
});
```

### Config Stack

The Config stack creates a `config.json` file in the S3 bucket that was created in the Frontend Stack with the API URL information from the Backend Stack using a CustomResource.

```typescript
new customresource.AwsCustomResource(this, 'ConfigFrontEnd', {
  onUpdate: {
    service: 'S3',
    action: 'putObject',
    parameters: {
      Body: JSON.stringify(props.config),
      Bucket: props.siteBucket.bucketName,
      Key: 'config.json',
    },
    physicalResourceId: customresource.PhysicalResourceId.of(
      Date.now().toString(),
    ),
  },
  policy: customresource.AwsCustomResourcePolicy.fromSdkCalls({
    resources: customresource.AwsCustomResourcePolicy.ANY_RESOURCE,
  }),
});
```

### React App

With the Backend and Frontend created, the React App deployed to the S3 bucket must read the `config.json` file that was created in the Config Stack. It is very important to note that this file is publicly visible so you should not put any sensitive information in it. Another [method](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-to-api.html) should be used to secure your API Gateway.

```javascript
export async function config() {
  const data = await fetch('./config.json').then((response) => response.json());

  const AmplifyConfig = {
    API: {
      endpoints: [
        {
          name: 'demoApi',
          endpoint: data.API_URL,
        },
      ],
    },
  };

  return AmplifyConfig;
```

The `Config.js` file is used to fetch the information in the `config.json` file that was written to the S3 bucket by the Config Stack. To use this locally, this file must be copied to the `src/site/public` directory.

```javascript
const apiConfig = await config();
API.configure(apiConfig);
const randomNumberResult = await API.post('demoApi', 'demo', {
  body: {},
});
setRandomNumber(randomNumberResult);
```

The React App uses Amplify to make API calls using the API information from the `Config.js` file. This could be enhanced with Cognito to provide API Gateway security.

Complete demo [here](https://github.com/schuettc/full-stack-cdk-example).


This example will build a CDK Pipeline that will build a backend and frontend and then pass API Gateway URL information from the backend to the frontend. This information can be used to make calls to the backend without having to manually pass the URL information.  When connected to a Github repo, the CDK pipeline will automatically trigger and rebuild so changes to any portion of the app through GitHub.

Creating a Full Stack App with CDK Pipelines


### Overview

![EC2](/images/blog/Example-EC2.png)

Cloud-init is a powerful way of configuring an EC2 instance. CDK can create an EC2 instance and use cloud-init to pass dynamically created variables to this EC2 instance which can be used to configure the instance. When combined, these tools can be used to create fully configured and deployed dynamic EC2 instances.

[This GitHub repo](https://github.com/schuettc/cdk-ec2-example) will deploy an EC2 instance using CDK. This EC2 instance will download and install [Asterisk 18](https://wiki.asterisk.org/wiki/display/AST/Asterisk+18+Documentation) on the EC2 instance. Additionally, it will create a `pjsip.conf` file and configure that using the Elastic IP address created by the CDK.

Once the Elastic IP is created, by the CDK, it is passed to the EC2 Instance using cloud-init:

```ts
      init: ec2.CloudFormationInit.fromConfigSets({
        configSets: {
          default: ['install', 'config'],
        },
        configs: {
          install: new ec2.InitConfig([
            ec2.InitFile.fromObject('/etc/config.json', {
              IP: ec2Eip.ref,
            }),
```

This file will be stored on the newly created instance based on resources created by the CDK. In this example, the Elastic IP address is passed to the JSON object. This information can also be [queried with metadata](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html), but is used in this example as information that can be dynamically created by the CDK and passed to the EC2 Instance.

Files can be loaded to the EC2 instance from [multiple sources](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_ec2.InitSource.html). In this example, we are loading a bash script from the local deployment of the CDK and executing it on the EC2 instance. This cloud-init configuration in the CDK will load the [`install.sh`](https://github.com/schuettc/cdk-ec2-example/blob/main/src/asteriskConfig/install.sh) file from the `./src/asteriskConfig/` directory into the `/etc/` directory of the Instance and then execute it.

```ts
            ec2.InitFile.fromFileInline(
              '/etc/install.sh',
              './src/asteriskConfig/install.sh',
            ),
            ec2.InitCommand.shellCommand('chmod +x /etc/install.sh'),
            ec2.InitCommand.shellCommand('cd /tmp'),
            ec2.InitCommand.shellCommand('/etc/install.sh'),
          ]),
```

The example script will download and install an Asterisk PBX on to the EC2 instance. Additional files are included in the GitHub repo that are used to more fully configure the Asterisk server using `jq` and `sed` with the information passed to the Instance from the CDK:

```bash
IP=$( jq -r '.IP' /etc/config.json )

sed -i "s/IP_ADDRESS/$IP/g" /etc/asterisk/pjsip.conf
```

[initOptions](https://docs.aws.amazon.com/cdk/api/v2//docs/aws-cdk-lib.aws_ec2.ApplyCloudFormationInitOptions.html) can also be used to ensure that the configuration of the EC2 instance succeeds.

```json
      initOptions: {
        timeout: Duration.minutes(15),
      },
```

If the timeout fails or the Instance returns a failure, the CDK will roll back to the previous state. When the cloud-init configuration of the Instance succeeds, it will pass this information back to the CDK. Until then, the CDK will remain in a Creating state and will not progress. This is useful when you want to ensure that the build and configuration of the EC2 instance succeeds before deploying additional resources with the CDK.

More details are provided in the [GitHub repo](https://github.com/schuettc/cdk-ec2-example).


Cloud-init is a powerful way of configuring an EC2 instance. CDK can create an EC2 instance and use cloud-init to pass dynamically created variables to this EC2 instance which can be used to configure the instance.  When combined, these tools can be used to create fully configured and deployed dynamic EC2 instances.

Building an EC2 Instance with CDKv2 and Cloud-Init


> Note: This has been updated [here](/content/blog/updated-cdk-construct-with-custom-resources.md)

CDK Constructs are a great way to create reusable and flexible code for yourself and others. projen makes it easy to create and publish the project. CDK Custom Resources are a way to do complex deployments and deploy AWS resources not native to CDK within a CDK. In this example, an AWS Lambda will be used as a Custom Resource from a published package.

## Setting Up the Project

To do this yourself: `npx projen new awscdk-construct`

This will create a [projen](https://github.com/projen/projen) project to be used. More information is available here when working with [AWS CDK Constructs](https://github.com/projen/projen/blob/main/docs/awscdk-construct.md). Additionally, this can be set up to publish to the very useful [constructs.dev](https://constructs.dev/contribute) so that others can use your Construct.

## Publishing the Project

Create an Access Token within npm to allow GitHub to publish to npm. Add this Access Token to GitHub in the Secrets section of the repository Settings as `NPM_TOKEN`

```bash
npx projen build
git add .
git commit -m 'commit comment'
git push
```

This will start a GitHub workflow action that will publish to npm.

## Example Construct Code

Standard Imports:

```typescript
import * as path from 'path';
import * as cdk from 'aws-cdk-lib';
import * as iam from 'aws-cdk-lib/aws-iam';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import { Construct } from 'constructs';
```

The Interface that will be used to take input from the deployable CDK. Because this is Typescript, these will be enforced but can be a wide range of types.

```typescript
export interface CdkCustomResourceExampleProps extends cdk.ResourceProps {
  readonly customResourceNumber: number;
}
```

This is the object that will be returned to the deployable CDK as the output from the Custom Resource:

```typescript
export class CustomResourceExample extends Construct {
  public readonly customResourceResult: string;

  constructor(
    scope: Construct,
    id: string,
    props: CdkCustomResourceExampleProps,
  ) {
    super(scope, id);
```

The IAM Role used by the Lambda:

```typescript
const role = new iam.Role(this, 'CustomResourceRole', {
  description: 'Custom Resource Construct Example',
  assumedBy: new iam.ServicePrincipal('lambda.amazonaws.com'),
  managedPolicies: [
    iam.ManagedPolicy.fromAwsManagedPolicyName(
      'service-role/AWSLambdaBasicExecutionRole',
    ),
  ],
});
```

The Lambda that will be created to be used as the Custom Resource:

```typescript
const fn = new lambda.Function(this, 'CustomResourceLambda', {
  runtime: lambda.Runtime.NODEJS_14_X,
  code: lambda.Code.fromAsset(path.join(__dirname, '@/resources')),
  handler: 'index.handler',
  architecture: lambda.Architecture.ARM_64,
  role: role,
  timeout: cdk.Duration.minutes(1),
});
```

The Custom Resource that will be invoked using the above Lambda taking in the properties supplied by the deployable CDK.

```typescript
    const customResourceResult = new cdk.CustomResource(
      this,
      'customResourceResult',
      {
        serviceToken: fn.functionArn,
        properties: {
          customResourceNumber: props.customResourceNumber,
        },
      },
    );

    this.customResourceResult = customResourceResult.getAttString('Result');
  }
}
```

The Lambda code being invoked is a simple multiplication but can be used to create complex deployments that are not native to CDK. In order to simplify deployment, NodeJS has been used for the Lambda instead of Typescript. Typescript must be transpiled to NodeJS to run as a Lambda and using Typescript for the Construct allows us to take advantage of Types within the deployable CDK while still allowing for an easy-to-use package. Python could also be used for the same reasons.

## Demo CDK Code

To add the newly created package to the deployable CDK `yarn add cdk-custom-resource-construct-example`.

This will add it to the `package.json` like other installed dependencies.

```json
  "dependencies": {
    "aws-cdk-lib": "2.3.0",
    "cdk-custom-resource-construct-example": "*",
    "constructs": "^10.0.0",
    "source-map-support": "^0.5.16"
  }
```

In this simple example, the only resource being created is the output from the Custom Resource. `customResourceNumber` is required based on the configuration of the Interface in the Construct.

## Testing the CDK

```bash
git clone https://github.com/schuettc/cdk-custom-resource-construct-demo.git
cd cdk-custom-resource-construct-demo
yarn
yarn run build
yarn cdk deploy
```

This will deploy the CDK and produce the output of the Custom Resource.

```typescript
import { CfnOutput, Stack, StackProps } from 'aws-cdk-lib';
import { Construct } from 'constructs';
import { CustomResourceExample } from 'cdk-custom-resource-construct-example';

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

    const result = new CustomResourceExample(this, 'customResourceResult', {
      customResourceNumber: 5,
    });

    new CfnOutput(this, 'customResourceOutput', {
      value: result.customResourceResult,
    });
  }
}
```

## Resources

- [GitHub Repository for Construct](https://github.com/schuettc/cdk-custom-resource-construct-example)
- [GitHub Repository for Demo](https://github.com/schuettc/cdk-custom-resource-construct-demo)
- [NPM Package](https://www.npmjs.com/package/cdk-custom-resource-construct-example)
- [constructs.dev construct](https://constructs.dev/packages/cdk-custom-resource-construct-example)


CDK Constructs are a great way to create reusable and flexible code for yourself and others.  projen makes it easy to create and publish the project.  CDK Custom Resources are a way to do complex deployments and deploy AWS resources not native to CDK within a CDK.  In this example, an AWS Lambda will be used as a Custom Resource from a published package.

Building CDK Custom Resource Constructs with projen and Typescript


Managing multiple AWS accounts with AWS CLI can be a challenge. Here is how I set up my macOS terminal. This configuration will set up a terminal shell that will show your AWS account and git information in the prompt. The example provided includes access key and SSO with MFA logins.

- Install [iTerm2](https://iterm2.com/)
- Install [Oh My Zsh](https://ohmyz.sh/#install)
- Install [Powerline Fonts](https://github.com/powerline/fonts)
- Install [AWS CLI v2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)
- Configure [Command Completion for AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-completion.html#cli-command-completion-linux)
- Install [git](https://github.com/git-guides/install-git#install-git-on-mac)
- Install [fig](https://fig.io/)

### Configure Oh My Zsh - ~/.zshrc

```bash
ZSH_THEME="agnoster"
plugins=(git aws)
```

### Configure agnoster - ~/.oh-my-zsh/themes/agnoster.zsh-theme

This will remove the context from the prompt to shrink it down a little and add a right prompt with the current date/time. These are optional and can be customized to your preference.

```bash
#  prompt_context
RPROMPT="[%D{%y/%m/%f}|%@]"
```

### Configure iTerm Profile

```bash
Preferences -> Profile -> Text -> Font: Any of the Powerline Fonts
Preferences -> Profile -> Colors -> Color Presets: Solarized Dark
```

### Configure AWS Config - ~/.aws/config

This is a sample config file that shows how to use an account with and without SSO.

```text
[profile account1]
region=us-east-1
output=json

[profile account2]
region = us-east-1
output = json
sso_start_url = https://xxxxxxxxxxxxx.awsapps.com/start
sso_region = us-east-1
sso_account_id = 123456789012
sso_role_name = ROLE
```

### Configure AWS Credentials - ~/.aws/credentials

Because the SSO account will acquire credentials during the login process, it is not needed here.

```text
[account1]
aws_access_key_id=XXXXXXXXXXXXX
aws_secret_access_key=XXXXXXXXXXXXXXXXXXXXXXXXX
```

### Using aws plugin

The Oh My Zsh aws plugin will allow you to easily switch between accounts.

- Switch to account without SSO: `asp account1`
- Switch to account with SSO and MFA: `asp account2 login`
- Clear account: `asp`

### Empty profile

It can be useful to have an empty profile that is used with exported `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, and `AWS_SESSION_TOKEN` information. To create a profile using AWS CLI:

```bash
aws configure set profile.PROFILE_NAME.region us-east-1
aws configure set profile.PROFILE_NAME.output json
aws configure set profile.PROFILE_NAME.aws_access_key_id ''
aws configure set profile.PROFILE_NAME.aws_secret_access_key ''
aws configure set profile.PROFILE_NAME.aws_session_token ''
```

## Configured Result

![Configured Shell](/images/blog/shell.png)


Managing multiple AWS accounts with AWS CLI can be a challenge.  Here is how I set up my macOS terminal.  This configuration will set up a terminal shell that will show your AWS account and git information in the prompt.  The example provided includes access key and SSO with MFA logins.

All posts

A CDK Construct for Importing Amazon Lex Bots

Importing an Amazon Lex Bot with CDK

Creating a Full Stack App with CDK Pipelines

Building an EC2 Instance with CDKv2 and Cloud-Init

Building CDK Custom Resource Constructs with projen and Typescript

Setting up a shell for multiple AWS accounts