
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


# Multiple CPU Architecture CDK Deployment of an Asterisk to ECS Fargate

This demo contains a CDK deployment of an Asterisk server to Amazon ECS using Fargate. This will allow us to deploy an Asterisk server to a Docker container.

[https://github.com/schuettc/cdk-fargate-asterisk](https://github.com/schuettc/cdk-fargate-asterisk)

## Docker Image

For this demo, we will be using the [andrius/asterisk](https://github.com/andrius/asterisk) Docker image.

## Asterisk Configuration

To allow for customized configuration, we will copy files from the local directory to the Asterisk server in the `Dockerfile`.

```docker
COPY config/* /etc/asterisk
COPY docker-entrypoint.sh /
RUN chmod +x /docker-entrypoint.sh
```

In this example, we are copying in several files for our configuration including a `pjsip.conf` and `extensions.conf` files.

```asterisk
[udp]
type=transport
protocol=udp
bind=0.0.0.0
external_media_address=PUBLIC_IP
external_signaling_address=PUBLIC_IP
allow_reload=yes
```

In the [`pjsip.conf`](https://github.com/schuettc/cdk-fargate-asterisk/blob/main/src/resources/asterisk/config/pjsip.conf) file, we are simply loading a basic `udp` transport. We will configure this during deployment later.

## Multiple Build Platforms

In order to accommodate deployments from multiple platforms, we will ensure that the deployed version matches the built version.

In the [`Dockerfile`](https://github.com/schuettc/cdk-fargate-asterisk/blob/main/src/resources/asterisk/Dockerfile) we will use `${BUILDPLATFORM}` to make sure we're building using the local architecture. We need to do this because we are copying files to the image and then building it before deploying it.

```docker
FROM --platform=${BUILDPLATFORM} andrius/asterisk
```

In the [`ecs.ts`](https://github.com/schuettc/cdk-fargate-asterisk/blob/main/src/ecs.ts) file, we will determine the local architecture and use that.

```typescript
let deployArch: CpuArchitecture;
const cpuArch = os.arch();
if (cpuArch === 'arm64') {
  deployArch = CpuArchitecture.ARM64;
} else {
  deployArch = CpuArchitecture.X86_64;
}
```

Then, when we create the Task, we will use that `deployArch` as part of the build for the `cpuArchitecture`.

```typescript
this.task = new FargateTaskDefinition(this, 'TaskDefinition', {
  memoryLimitMiB: 2048,
  cpu: 1024,
  runtimePlatform: {
    operatingSystemFamily: OperatingSystemFamily.LINUX,
    cpuArchitecture: deployArch,
  },
  taskRole: asteriskTaskRole,
  volumes: [
    {
      name: 'asteriskLogs',
      efsVolumeConfiguration: {
        fileSystemId: fileSystem.fileSystemId,
        transitEncryption: 'ENABLED',
        authorizationConfig: {
          accessPointId: asteriskAccessPoint.accessPointId,
          iam: 'ENABLED',
        },
      },
    },
  ],
});
```

Now the deployed version will match the locally built version.

For example, when the Docker image is built on an M1 Mac, the Architecture type will be `ARM64`.

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

However, if the Docker image is built on an X86 based CPU, the Architecture type will be `X86_64`.

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

## Access the Asterisk Server

Once deployed, the Asterisk server can be accessed using [`ecs-execute`](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-exec.html)

Included in the output of the CDK will be several commands that can be copied to the terminal for ssh access.

To access the running Asterisk:

- Copy/paste the `CLUSTER=` command
- Copy/paste the `TASK=` command
- Copy/paste either `aws ecs execute-command` command

## Asterisk Configuration

During deployment of the Fargate container, the Dockerfile will use [`docker-entrypoint.sh`](https://github.com/schuettc/cdk-fargate-asterisk/blob/main/src/resources/asterisk/docker-entrypoint.sh) as it's `ENTRYPOINT`. Everything in that file will be executed. We can use this to configure the Asterisk during deployment.

```bash
echo "METADATA: " ${ECS_CONTAINER_METADATA_URI_V4}
curl -o metadata.json ${ECS_CONTAINER_METADATA_URI_V4}/task
cat metadata.json
TASK_ARN=$( curl ${ECS_CONTAINER_METADATA_URI_V4}/task | jq -r '.TaskARN' )
echo "TASK_ARN: " $TASK_ARN
CLUSTER=$( curl ${ECS_CONTAINER_METADATA_URI_V4}/task | jq -r '.Cluster' )
echo "CLUSTER: " $CLUSTER
ENI=$(aws ecs describe-tasks --tasks $TASK_ARN --cluster $CLUSTER | jq -r '.tasks[0].attachments[0].details[1].value' )
echo "ENI: " $ENI
PUBLIC_IP=$( aws ec2 describe-network-interfaces --network-interface-ids $ENI | jq -r '.NetworkInterfaces[0].Association.PublicIp' )
echo "PUBLIC_IP: ${PUBLIC_IP}"

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

With this shell script, we will determine the `PUBLIC_IP` of the container that is running and use that to configure the `pjsip.conf` file. This can be expanded to configure other parts of the Asterisk server as needed.

## Deploy/Destroy

To deploy this demo:

```bash
yarn launch
```

To destroy this demo:

```bash
yarn cdk destroy
```


This CDK will deploy a an Asterisk server to AWS Fargate from multiple CPU architectures

Multiple CPU Architecture CDK Deployment of an Asterisk to ECS Fargate


# Deploying Cross-Region Certificates with AWS Cloudfront via CDK

[AWS Certificate Manager](https://aws.amazon.com/certificate-manager/) (ACM) can be used to deploy TLS certificates for use with things like [Amazon Cloudfront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html). However, ACM certificates must be deployed in `us-east-1`. In order to deploy an ACM certificate and associate with a resource outside of `us-east-1`, a multiple stack deployment must be used. The repo here: [https://github.com/schuettc/cdk-cross-region-cloudfront](https://github.com/schuettc/cdk-cross-region-cloudfront) will show an example of this.

## Certificate Stack

The first stack to be deployed will be the `CertificateStack`. This stack will create a `Certificate` in the `us-east-1` region that can be used by a Cloudfront Distribution in another region.

```typescript
interface CertificateStackProps extends StackProps {
  siteSubdomain: string;
  domain: string;
  hostedZoneId: string;
}

export class CertificateStack extends Stack {
  siteCertificate: Certificate;
  constructor(scope: Construct, id: string, props: CertificateStackProps) {
    super(scope, id, props);

    const certificateResources = new CertificateResources(this, 'certificate', {
      siteSubdomain: props.siteSubdomain,
      domain: props.domain,
      hostedZoneId: props.hostedZoneId,
    });

    this.siteCertificate = certificateResources.siteCertificate;
  }
}

const app = new App();

const certEnv = {
  account: process.env.CDK_DEFAULT_ACCOUNT,
  region: 'us-east-1',
};

const certProps = {
  siteSubdomain: process.env.SITE_SUBDOMAIN || '',
  domain: process.env.DOMAIN || '',
  hostedZoneId: process.env.HOSTED_ZONE_ID || '',
};

const certStack = new CertificateStack(app, 'CertificateStack', {
  ...certProps,
  env: certEnv,
  crossRegionReferences: true,
});

app.synth();
```

Here we are explicitly declaring `us-east-1` as the region to deploy this `Stack` to because ACM certificates used with CloudFront _must_ use `us-east-1`. We are passing in to the `Stack` props from a `.env` file that will be used to create the `Certificate`. This `Certificate` will be used as input to the next `Stack`. Note that the `Stack` must take the input `crossRegionReferences: true` to let the next `Stack` use this `Certificate`.

## Site Stack

```typescript
interface SiteStackProps extends StackProps {
  siteCertificate: Certificate;
  siteSubdomain: string;
  domain: string;
  hostedZoneId: string;
}

export class SiteStack extends Stack {
  constructor(scope: Construct, id: string, props: SiteStackProps) {
    super(scope, id, props);

    const site = new SiteResources(this, 'site', {
      siteCertificate: props.siteCertificate,
      siteSubdomain: props.siteSubdomain,
      domain: props.domain,
      hostedZoneId: props.hostedZoneId,
    });

    new CfnOutput(this, 'distributionURL', {
      value: site.distribution.domainName,
    });

    new CfnOutput(this, 'siteUrl', {
      value: `https://${props.siteSubdomain}.${props.domain}`,
    });
  }
}

const app = new App();

const siteEnv = {
  account: process.env.CDK_DEFAULT_ACCOUNT,
  region: 'eu-central-1',
};

const siteProps = {
  siteCertificate: certStack.siteCertificate,
  siteSubdomain: process.env.SITE_SUBDOMAIN || '',
  domain: process.env.DOMAIN || '',
  hostedZoneId: process.env.HOSTED_ZONE_ID || '',
};

new SiteStack(app, 'SiteStack', {
  ...siteProps,
  env: siteEnv,
  crossRegionReferences: true,
});

app.synth();
```

Here we are creating a second `Stack` as part of this deployment. This `Stack` will deploy the actual website using the `Certificate` from the previous `Stack`. The props used for this `Stack` are the same as the previous `Stack` with the addition of the `Certificate` created in the first `Stack`. This `Stack` uses a typical Single-Page Application (SPA) deployment of S3 + CloudFront with a specific `Certificate` and `ARecord` assigned.

```typescript
this.siteBucket = new Bucket(this, 'websiteBucket', {
  publicReadAccess: false,
  removalPolicy: RemovalPolicy.DESTROY,
  autoDeleteObjects: true,
});

const hostedZone = HostedZone.fromHostedZoneAttributes(this, 'hostedZone', {
  zoneName: props.domain,
  hostedZoneId: props.hostedZoneId,
});

this.distribution = new Distribution(this, 'CloudfrontDistribution', {
  enableLogging: true,
  domainNames: [props.siteSubdomain + '.' + props.domain],
  certificate: props.siteCertificate,
  minimumProtocolVersion: SecurityPolicyProtocol.TLS_V1_2_2021,
  defaultBehavior: {
    origin: new S3Origin(this.siteBucket),
    viewerProtocolPolicy: ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
    cachePolicy: CachePolicy.CACHING_DISABLED,
  },
  defaultRootObject: 'index.html',
});

new ARecord(this, 'clientSiteARecord', {
  zone: hostedZone,
  target: RecordTarget.fromAlias(new CloudFrontTarget(this.distribution)),
  recordName: props.siteSubdomain + '.' + props.domain,
});
```

The result will be an SPA deployed to S3 with a CloudFront Distribution that uses a specific URL from Route53 and a Certificate provided by ACM. This site can be deployed in any Region while the Certificate will be deployed in `us-east-1` as required by CloudFront.

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

## .env File

To deploy this demo, a `.env` file must be used. This `.env` file will contain the following:

```bash
SITE_SUBDOMAIN = 'cross-region-site'
DOMAIN = 'example.com'
HOSTED_ZONE_ID = 'Z00000000000000000000'
```

## Result

![Result](/images/blog/Cross-Region-Deploy-Result.png)

The result is an [SPA deployed](https://cross-region-site.subaud.io/) to a non `us-east-1` Region while still using an ACM Certificate used by CloudFront all deployed by CDK. Information on [cross-region certificates](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_certificatemanager-readme.html#cross-region-certificates) is available on the AWS CDK Reference Documentation.

## Resources

- Github Repo: [https://github.com/schuettc/cdk-cross-region-cloudfront](https://github.com/schuettc/cdk-cross-region-cloudfront)


In order to deploy a Certificate with a CloudFront Distribution, a multi-stack CDK must be used to deploy the Certificate in us-east-1 and the SPA in a different Region.  This CDK deployment will show how to do that.

Deploy a Cross-Region SPA with Cloudfront using CDK


# Minecraft CDK Deployment using AWS Fargate

This [repo](https://github.com/schuettc/cdk-minecraft) will deploy an AWS Fargate based Minecraft server that uses Route 53 to update the service and activate the Minecraft server.

Much of the work here is based on the work by [doctorrat117](https://github.com/doctorray117) from [minecraft-ondemand](https://github.com/doctorray117/minecraft-ondemand).

## Overview

![Overview](/images/blog/Minecraft.png)

## .env File

The .env file used by this deployment includes several variables that will be referenced later. A sample .env file is included: [.env.sample](/.env.sample) and should be updated and renamed to `.env`.

```bash
MINECRAFT_EDITION = 'java'
SERVER_SUBDOMAIN = 'minecraft'
DOMAIN = 'example.com'
HOSTED_ZONE_ID = 'Z00000000000000000000'
MEMORY_SIZE = '8192'
CPU_SIZE = '4096'
SNS_EMAIL = 'admin@example.com'
STARTUP_MIN = '10'
SHUTDOWN_MIN = '20'
DEBUG = 'true'
```

A Route 53 domain and Hosted Zone ID is required for this deployment. These will be used to start the service.

### AWS Fargate Service

This deployment uses an AWS Fargate service to deploy two containers - the Minecraft server and a watchdog server. The Minecraft server is the reason for deploying this and will be used to play the game. The watchdog container is used to ensure that the Minecraft server is still being used.

#### Starting the Service

To start the service and allow someone to use the Minecraft server, a query to `SERVER_SUBDOMAIN`.`DOMAIN` will result in Route 53 updating Cloudwatch logs. This Cloudwatch log will trigger an AWS Lambda Function to set the `desired-count` of the Fargate service to 1.

```python
    if desired == 0:
        ecs.update_service(
            cluster=CLUSTER,
            service=SERVICE,
            desiredCount=1,
        )
        print("Updated desiredCount to 1")
    else:
        print("desiredCount already at 1")
```

By setting the `desired-count` to 1, the containers in the ECS service will be activated and available. The AWS ECS Service includes the Minecraft server container and a watchdog container. Both of these will be started when the `desired-count` is set to 1.

```typescript
this.service = new FargateService(this, "FargateService", {
  serviceName: "MineCraftService",
  cluster: this.cluster,
  capacityProviderStrategies: [
    {
      capacityProvider: "FARGATE",
      weight: 1,
      base: 1,
    },
  ],
  taskDefinition: this.task,
  assignPublicIp: true,
  desiredCount: 0,
  vpcSubnets: { subnetType: SubnetType.PUBLIC },
  securityGroups: [props.securityGroup],
  enableExecuteCommand: true,
});

const minecraftServerContainer = this.task.addContainer(
  "MinecraftServerContainer",
  {
    image: ContainerImage.fromRegistry(props.serverConfig.image),
    environment: {
      EULA: "TRUE",
      MEMORY: "8G",
    },
    portMappings: [
      {
        containerPort: props.serverConfig.port,
        hostPort: props.serverConfig.port,
        protocol: props.serverConfig.protocol,
      },
    ],
    essential: false,
    logging: props.serverConfig.debug
      ? new AwsLogDriver({
          logRetention: RetentionDays.THREE_DAYS,
          streamPrefix: "minecraft",
        })
      : undefined,
  }
);

this.task.addContainer("WatchdogContainer", {
  image: ContainerImage.fromAsset(
    path.resolve(__dirname, "./resources/watchdogContainer")
  ),
  essential: true,
  environment: {
    CLUSTER: this.cluster.clusterName,
    SERVICE: "MineCraftService",
    DNSZONE: props.subDomainHostedZoneId,
    SERVERNAME: `${props.serverSubDomain}.${props.domain}`,
    SNSTOPIC: props.snsTopic?.topicArn || "",
    STARTUPMIN: props.startupMin,
    SHUTDOWNMIN: props.shutdownMin,
  },
  logging: props.serverConfig.debug
    ? new AwsLogDriver({
        logRetention: RetentionDays.THREE_DAYS,
        streamPrefix: "minecraft",
      })
    : undefined,
});
```

#### Stopping the Service

During normal operations, both the Minecraft container and Watchdog container will be active. The Minecraft server is used to play the game while the Watchdog server will monitor the activity of the Minecraft server. When the watchdog server determines that the Minecraft server has not been used for `SHUTDOWN_MIN`, the watchdog server will set the `desired-count` of the Fargate Service to 0. By setting the `desired-count` to 0, the containers will be stopped to reduce costs.

### Notification

When the AWS Fargate service starts or stops, a notification is sent to SNS.

```bash
function send_notification ()
{
  [ "$1" = "startup" ] && MESSAGETEXT="${SERVICE} is online at ${SERVERNAME}"
  [ "$1" = "shutdown" ] && MESSAGETEXT="Shutting down ${SERVICE} at ${SERVERNAME}"

  ## SNS Option
  [ -n "$SNSTOPIC" ] && \
  echo "SNS topic set, sending $1 message" && \
  aws sns publish --topic-arn "$SNSTOPIC" --message "$MESSAGETEXT"
}
```


This demo will use CDK to deploy a Minecraft server on AWS Fargate using Route 53 as the trigger

Deploy a Minecraft server with AWS Fargate and AWS CDK


In this demo, we will show how to conditionally deploy resources using environment variables.

## Passing Environment Variables

This CDK uses a Stack with several inputs. Besides the standard `env` input, we are also defining `StackProps` that will be used to pass the `bucketName` from the environment to the Stack.

```typescript
const devEnv = {
  account: process.env.CDK_DEFAULT_ACCOUNT,
  region: process.env.CDK_DEFAULT_REGION,
};

const stackProps = {
  bucketName: process.env.BUCKET_NAME || "",
};

new ConditionalDeployment(app, "ConditionalDeployment", {
  ...stackProps,
  env: devEnv,
});
```

Here we see the standard `projen` created `devEnv` and the App that is being deployed. We are additionally adding `stackProps` to the Stack that is being created and passing the environment variable `BUCKET_NAME` to it if it is present.

## Stack and StackProps

```typescript
interface ConditionalDeploymentProps extends StackProps {
  bucketName?: string;
}

let deploymentBucket: IBucket;

export class ConditionalDeployment extends Stack {
  constructor(scope: Construct, id: string, props: ConditionalDeploymentProps) {
    super(scope, id, props);
```

Here we have defined `ConditionalDeploymentProps` as a `StackProps` to be passed to the Stack as well as `deploymentBucket`. This will be used later with either a new bucket or the existing bucket.

## Condition

```typescript
if (props.bucketName) {
  deploymentBucket = Bucket.fromBucketName(this, "Bucket", props.bucketName);
} else {
  deploymentBucket = new Bucket(this, "Bucket", {
    encryption: BucketEncryption.S3_MANAGED,
    blockPublicAccess: BlockPublicAccess.BLOCK_ALL,
    removalPolicy: RemovalPolicy.DESTROY,
    autoDeleteObjects: true,
  });
}
```

This is where we will check to see if a string has been passed as a prop named `bucketName` to the Stack. It is not required to be passed, but if it is, we want to use that bucket as the deployment destination. To do that, we need to get the [`IBucket`](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_s3.IBucket.html) using [`Bucket.fromBucketName`](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_s3.Bucket.html#static-fromwbrbucketwbrnamescope-id-bucketname).

If no prop named `bucketName` was passed to the Stack, we will create a bucket. In either case, the bucket that we will be deploying to is referenced by `deploymentBucket`.

## Deploying to the Bucket

```typescript
const data = {
  bucketName: deploymentBucket.bucketName,
  text: "Hello World",
};

new BucketDeployment(this, "Deployment", {
  sources: [Source.jsonData("config.json", data)],
  destinationBucket: deploymentBucket,
});
```

Now, we will create a simple JSON file using `Source.jsonData` and upload this file to the bucket. This will either be an existing bucket referenced in the environment variables, or a newly created bucket. In either case, we can use `deplyomentBucket` as the `destinationBucket` because we are always creating an `IBucket`. If the bucket already exists, we use `fromBucketName` and if the bucket does not exist, `new Bucket` will return an `IBucket`.

## Deploying with Environment Variables

> Note: You must replace `conditional-cdk-deploy-demo` with a unique name

```bash
export BUCKET_NAME=conditional-cdk-deploy-demo
yarn launch
```

or

```bash
BUCKET_NAME=conditional-cdk-deploy-demo yarn launch
```

Once completed, we can see that an existing S3 bucket has the `config.json` file in it.

```bash
aws s3 ls s3://conditional-cdk-deploy-demo
aws s3 cp s3://conditional-cdk-deploy-demo/config.json ./
cat config.json
```

## Deploying without Environment Variables

```bash
unset BUCKET_NAME
yarn launch
```

When the CDK is deployed, a new bucket will be created. This bucket name will be in the output of the CDK and can be used to verify the creation of the bucket and the deployment of the `config.json` file.

## Testing the CDK

In order to verify that our CDK is correct, we should test it. This is done as part of a projen build. In this demo, we are using Snapshots to test.

```typescript
test("Snapshot", () => {
  const app = new App();
  const stack = new ConditionalDeployment(app, "test", {});

  const template = Template.fromStack(stack);
  expect(template.toJSON()).toMatchSnapshot();
});

test("SnapshotWithBucketName", () => {
  const app = new App();
  const stack = new ConditionalDeployment(app, "test", {
    bucketName: "test-bucket",
  });

  const template = Template.fromStack(stack);
  expect(template.toJSON()).toMatchSnapshot();
});
```

This will now create snapshots for both scenarios. Without the second snapshot, we would have uncovered lines in the test.


This demo will describe how to create a CDK with conditional resource deployment and how to use Environment Variables with that conditional deployment

Conditional Resource Deployment and Environment Variables with CDK


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

Building off of the previous example of [building CDK Custom Resources Constructs](https://subaud.io/blog/building-cdk-custom-resource-constructs-with-projen-and-typescript), in this post, we will look at the steps required to convert this from a JavaScript Lambda to a Typescript Lambda using some of the [magic of projen](https://projen.io/awscdk.html#aws-lambda-functions).

## CDK Construct Code

<pre>
.
├── .eslintrc.json
├── .gitattributes
├── .gitignore
├── .jsii
├── .mergify.yml
├── .npmignore
<mark>├── .projenrc.js</mark>
├── API.md
├── LICENSE
├── README.md
├── package.json
├── src
│   ├── custom-resource-function.ts
<mark>│   ├── custom-resource.lambda.ts
│   └── index.ts</mark>
├── test
│   └── customResource.test.ts
├── tsconfig.dev.json
├── tsconfig.json
└── yarn.lock
</pre>

### Lambda Function

In this example, we will be using projen AWS Lambda Functions to automatically create the Lambda function that will be used by the Custom Resource. In order to create this function, we will create `custom-resource.lambda.ts` in the `src` directory. This will include the Lambda code to be executed during the CDK deployment.

After creating this file, running `npx projen` will create the `custom-resource-function.ts` file in the `src` directory. This is what we will be using in the `index.ts` file as the Lambda function for the Custom Resource.

After importing the function:

```typescript
import { CustomResourceFunction } from "./custom-resource-function";
```

We can reference it here:

```typescript
const customResourceLambda = new CustomResourceFunction(
  this,
  "customResourceLambda",
  {
    role: customResourceRole,
    architecture: Architecture.ARM_64,
    timeout: Duration.seconds(60),
  }
);
```

To define the runtime of the Lambda function, in the `.projenrc` file:

```js
  lambdaOptions: {
    runtime: awscdk.LambdaRuntime.NODEJS_18_X,
    bundlingOptions: {
      externals: ['aws-sdk'],
      sourcemap: true,
    },
  },
```

Be sure to check out projen documentation for details on how to use this. [https://projen.io/awscdk.html#aws-lambda-functions](https://projen.io/awscdk.html#aws-lambda-functions)

> **_NOTE:_** NODEJS_18_X is not currently available and this will default to NODEJS_14_X for now.

### Provider

Next, we will include a [`Provider`](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.custom_resources.Provider.html) The [Provider Framework](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.custom_resources-readme.html#provider-framework) will simplify some of the responses in the Lambda function. This is the recommended approach when using Custom Resources in CDKs.

```typescript
const customResourceProvider = new Provider(this, "customResourceProvider", {
  onEventHandler: customResourceLambda,
});
```

### Custom Resource

Finally, we will call this Custom Resource

```typescript
const customResourceResult = new CustomResource(this, "customResourceResult", {
  serviceToken: customResourceProvider.serviceToken,
  properties: {
    customResourceNumber: props.customResourceNumber,
  },
});
```

## Custom Resource Lambda Code

The Typescript Lambda will use the type definitions from [`DefinitelyTyped`](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/aws-lambda) to make things easier in the Lambda code.

```typescript
import {
  CdkCustomResourceEvent,
  CdkCustomResourceResponse,
  Context,
} from "aws-lambda";

export const handler = async (
  event: CdkCustomResourceEvent,
  context: Context
): Promise<CdkCustomResourceResponse> => {
  console.log("Lambda is invoked with:" + JSON.stringify(event));

  const response: CdkCustomResourceResponse = {
    StackId: event.StackId,
    RequestId: event.RequestId,
    LogicalResourceId: event.LogicalResourceId,
    PhysicalResourceId: context.logGroupName,
  };

  if (event.RequestType == "Delete") {
    response.Status = "SUCCESS";
    response.Data = { Result: "None" };
    return response;
  }

  try {
    const multiplyResult = event.ResourceProperties.customResourceNumber * 2;
    response.Status = "SUCCESS";
    response.Data = { Result: multiplyResult };
    return response;
  } catch (error) {
    if (error instanceof Error) {
      response.Reason = error.message;
    }
    response.Status = "FAILED";
    response.Data = { Result: error };
    return response;
  }
};
```

Because we used the `Provider` when creating this Custom Resource, the response is significantly easier. We just need to [return](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.custom_resources-readme.html#handling-lifecycle-events-onevent) a `SUCCESS` or `FAILED` to the `onEvent`. We can do this with the `CdkCustomResourceResponse`.

## Using the Construct

No actual changes are needed in the [demo](https://github.com/schuettc/cdk-custom-resource-construct-demo).

### CDK Stack Code

```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,
    });
  }
}
```

### Deploy

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

### Result

```bash
CdkCustomResourceConstructDemoStack: deploying...
 ✅  CdkCustomResourceConstructDemoStack

✨  Deployment time: 81.79s

Outputs:
CdkCustomResourceConstructDemoStack.customResourceOutput = 10
Stack ARN:
arn:aws:cloudformation:us-east-1:112233445566:stack/CdkCustomResourceConstructDemoStack/e47e0d90-742d-11ed-ab03-128d8230a997

✨  Total time: 84.66s
```

## 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)


An update to the previous CDK Construct Custom Resource post.  This time we will be using Typescript instead of JavaScript for the Lambda function.

Using a Typescript Lambda as a CDK Construct Custom Resource


In order to deploy a Python Lambda function with additional dependencies, we must use something that will [install those dependencies](https://packaging.python.org/en/latest/tutorials/managing-dependencies/). With NodeJS, we can use something like [`esbuild`](https://esbuild.github.io/) to do this. In a Typescript CDK, we can use npm or yarn to install this as a [development dependency](https://classic.yarnpkg.com/en/docs/dependency-types#toc-devdependencies). However, we do not have this option with a Python Lambda. To have this built during deployment, we can use the [bundlingOptions interface](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.BundlingOptions.html).

```typescript
this.queryLambda = new Function(this, "QueryLambda", {
  code: Code.fromAsset(path.join(__dirname, "resources/query_lambda"), {
    bundling: {
      image: Runtime.PYTHON_3_9.bundlingImage,
      command: [
        "bash",
        "-c",
        "pip install -r requirements.txt -t /asset-output && cp -au . /asset-output",
      ],
    },
  }),
  runtime: Runtime.PYTHON_3_9,
  vpc: props.vpc,
  vpcSubnets: { subnetType: SubnetType.PRIVATE_WITH_EGRESS },
  architecture: Architecture.ARM_64,
  handler: "index.handler",
  timeout: Duration.minutes(5),
  role: props.role,
  layers: [props.powerToolsLayer],
  environment: {
    RDS_SECRET_NAME: props.dataBase.secret?.secretName!,
  },
});
```

In [this](https://github.com/schuettc/cdk-private-rds-with-lambda/blob/main/src/lambda.ts) example from the [cdk-private-rds-with-lambda](https://github.com/schuettc/cdk-private-rds-with-lambda) repository, we can see the `QueryLambda` function is being created using `Code` from the `/resources/query_lambda` directory and bundled using a Docker image. This does require Docker desktop to be run locally or from the pipeline that is deploying this function.

When this Lambda function is deployed, `pip install` will be used with the `requirements.txt` file in the `/query_lambda` directory to create the zip file that will be uploaded as the Lambda function.

```bash
resources/
├── initialize_lambda/
│   ├── index.py
│   └── requirements.txt
└── query_lambda/
    ├── index.py
    └── requirements.txt
```


This article will show you how to deploy a Python Lambda function with additional dependencies using CDK

All posts

Multiple CPU Architecture CDK Deployment of an Asterisk to ECS Fargate

Deploy a Cross-Region SPA with Cloudfront using CDK

Deploy a Minecraft server with AWS Fargate and AWS CDK

Conditional Resource Deployment and Environment Variables with CDK

Using a Typescript Lambda as a CDK Construct Custom Resource

Deploying a Python Lambda with Requirements using CDK