
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


```typescript
import { RemovalPolicy, IgnoreMode } from 'aws-cdk-lib';
import { Bucket, ObjectOwnership } from 'aws-cdk-lib/aws-s3';
import { Source, BucketDeployment } from 'aws-cdk-lib/aws-s3-deployment';
import { Construct } from 'constructs';

export class BucketDeploymentExample extends Construct {
  constructor(scope: Construct, id: string) {
    super(scope, id);

    const assetBucket = new Bucket(this, 'assetBucket', {
      publicReadAccess: false,
      removalPolicy: RemovalPolicy.DESTROY,
      objectOwnership: ObjectOwnership.BUCKET_OWNER_PREFERRED,
      autoDeleteObjects: true,
    });

    new BucketDeployment(this, 'assetBucketDeployment', {
      sources: [
        Source.asset('src/resources/server/assets', {
          exclude: ['**/node_modules/**', '**/dist/**'],
          ignoreMode: IgnoreMode.GIT,
        }),
      ],
      destinationBucket: assetBucket,
      retainOnDelete: false,
      memoryLimit: 512,
    });
  }
}
```

Here we can see an example of how to prevent some files and directories from being uploaded as part of the bucket deployment. In this case, we want to prevent `**/node_modules/**` and `**/dist/**` from being uploaded as they are part of the local development and not needed in the bucket. We are going to use [`IgnoreMode`](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.IgnoreMode.html) to use the [`.gitignore specification`](https://git-scm.com/docs/gitignore).

Now, when using [`BucketDeployment`](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_s3_deployment.BucketDeployment.html) with a [`Source`](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_s3_deployment.Source.html), we can use [`AssetOptions`](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_s3_assets.AssetOptions.html) to prevent those entire directories from being included in the upload.


When uploading files and directories during a CDK bucket deployment, `exclude` can be used.  This samples shows how to use that feature.

Excluding files and directories from a CDK Bucket Deployment


# Simple Dev EC2 Instance

This simple Cloudformation template will deploy a new EC2 instance in a new VPC that can be used for dev work. This instance uses [Ubuntu](https://ubuntu.com/) with either an [ARM64](https://aws.amazon.com/ec2/instance-types/m7g/) or [X86_64](https://aws.amazon.com/ec2/instance-types/m5/) CPU and can be deployed as a `LARGE`, `XLARGE`, or `2XLARGE` instance size. It comes pre-installed with several commonly used packages:

- NodeJS 18
- Python 3.10
- pip
- jq
- Docker

## Adding Keys (optional)

If you'd like to copy private or public keys to the instance during deployment, you can add them to SSM before deploying.

```bash
aws ssm put-parameter --name /devServer/publicKey --overwrite --type SecureString --value $(cat ~/.ssh/key.pub | base64)
aws ssm put-parameter --name /devServer/githubKey --overwrite --type SecureString --value $(cat ~/.ssh/private.pem | base64)
```

These commands will base64 encode the contents of these files and store in them in [SSM Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html).

During deployment, these parameters will be read and used to configure the instance.

```bash
GITHUB_KEY=$(aws ssm get-parameter --with-decryption --name /devServer/githubKey --query Parameter.Value --output text 2> /dev/null)
EXIT_CODE=$?
if [[ "$EXIT_CODE" -ne 0 ]]; then echo 'No GitHub Key found'; else echo 'Found GitHub Key' && echo $GITHUB_KEY | base64 -d > /home/ec2-user/.ssh/github.pem; fi
PUBLIC_KEY=$(aws ssm get-parameter --with-decryption --name /devServer/publicKey --query Parameter.Value --output text 2> /dev/null)
EXIT_CODE=$?
if [[ "$EXIT_CODE" -ne 0 ]]; then echo 'No Public Key found'; else echo 'Found Public Key' && echo $PUBLIC_KEY | base64 -d >> /home/ec2-user/.ssh/authorized_keys; fi
chmod 600 /home/ec2-user/.ssh/github.pem
chown ec2-user:ec2-user /home/ec2-user/.ssh/*
```

## Security Group

Several TCP ports will be opened in the Security Group.

```yaml
SecurityGroupIngress:
  - IpProtocol: tcp
    FromPort: '22'
    ToPort: '22'
    CidrIp: 0.0.0.0/0
  - IpProtocol: tcp
    FromPort: '80'
    ToPort: '80'
    CidrIp: 0.0.0.0/0
  - IpProtocol: tcp
    FromPort: '443'
    ToPort: '443'
    CidrIp: 0.0.0.0/0
  - IpProtocol: tcp
    FromPort: '3000'
    ToPort: '3000'
    CidrIp: 0.0.0.0/0
  - IpProtocol: tcp
    FromPort: '8080'
    ToPort: '8080'
    CidrIp: 0.0.0.0/0
```

This will open the following ports:

- 22
- 80
- 443
- 3000
- 8080

## Deployment Options

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

During deployment, you can choose the CPU Type, the Instance Size, and if you wish to add Administrator Access.

> Adding Administrator Access will allow you to use all AWS resources, but **must** be used with caution

[![Launch](https://s3.amazonaws.com/cloudformation-examples/cloudformation-launch-stack.png)](https://us-east-1.console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/create/review?templateURL=https://subaud-resources.s3.amazonaws.com/ec2-cloudformation/template.yaml&stackName=DevServer)


This Cloudformation template will deploy a simple EC2 instance to be used as a development server.  Several common packages are included in the deployment and keys can be installed during deployment.

Deploy a simple EC2 Instance via Cloudformation


# CDK Custom Resource Construct Example

[This](https://github.com/schuettc/cdk-custom-resource-construct-example) is an updated example of how to create a Custom Resource Construct for CDK. This example will walk you through the process of creating a [CDK Construct](https://constructs.dev/) that uses Typescript Custom Resources.

## Custom Resources

[Custom Resources](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-custom-resources.html) allow you to deploy and invoke Lambda functions during the deployment of a CDK. This can be used to supplement CDKs with features that are not natively part of CloudFormation or CDK.

In this example, our Lambda function is simply multiplying an input and returning the result

```typescript
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;
}
```

## Bundling

Because we are using Typescript for our Lambda, we must transpile it before we use it. To do this, we will use [projen](https://github.com/projen/projen) to execute an `esbuild` on our Lambda source code during the build.

To do this, in the `.projenrc.ts` we use `bundler.addBundle`:

```typescript
project.bundler.addBundle('./resources/lambda/', {
  platform: 'node',
  target: 'node18',
});
```

This will create an `index.js` in the `assets/resources/lambda` directory. This is the what we will use in the Custom Resource.

## Custom Resource Provider

To create the Custom Resource we will use [`CustomResourceProvider`](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.CustomResourceProvider.html). This is different from [`Provider`](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.custom_resources.Provider.html) which is what is normally used within a CDK.

```typescript
const customResourceProvider = CustomResourceProvider.getOrCreateProvider(
  this,
  'Custom::Resource',
  {
    codeDirectory:
      'node_modules/cdk-custom-resource-construct-example/assets/resources/lambda',
    runtime: CustomResourceProviderRuntime.NODEJS_18_X,
    timeout: Duration.seconds(60),
    policyStatements: [
      {
        Effect: 'Allow',
        Action: [
          'logs:CreateLogGroup',
          'logs:CreateLogStream',
          'logs:PutLogEvents',
        ],
        Resource: '*',
      },
    ],
  },
);
```

By using []`getOrCreateProvider`](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.CustomResourceProvider.html#static-getwbrorwbrcreatewbrproviderscope-uniqueid-props) we can ensure that the Lambda function is created only once even if it used multiple times. The `codeDirectory` used here is the output directory of the bundling. This is what will be used in the CDK that uses this Construct.

## Custom Resource

Finally, we will create the Custom Resource using the previously created Provider.

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

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

This Custom Resource will take a `prop` when called and return the result.

## Using the Custom Resource

To use this Construct, we will import the `CustomResourceExample`, implement it, and pass it a prop.

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

When used this way, the Custom Resource will deploy the Lambda, invoke it, and return the result to the calling CDK.

## Developing

It can be difficult to develop and test a Construct. [`yalc`](https://github.com/wclr/yalc) is a tool that can help with this by allowing us to "publish" locally. To use `yalc`, it should be installed as a `devDep` in the `.projenrc.ts` of the source Construct.

```typescript
  devDeps: ['yalc', 'esbuild'],
```

After building the construct using `yarn projen build`, you can use `yalc publish --push --sig` to push this package to the local store. This should result in an output similar to:

```bash
cdk-custom-resource-construct-example@0.0.0+80079907 published in store.
```

By adding `--sig` we can differentiate versions. In this example `+80079907` is the sig.

Next, you can create a project that uses this package. To do this, you can add the package with yalc: `yalc add cdk-custom-resource-construct-example`. This will add the package to the `package.json` file that can be used like any other package. If needed, you can use `yalc update`. The output should be similar to:

```bash
Package cdk-custom-resource-construct-example@0.0.0+80079907 added
```


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.

Updated CDK Construct with Custom Resources


I use [projen](https://github.com/projen/projen) for almost all of my projects because it allows me to not worry about all of the very necessary but tedious parts of a project - `.gitignore`, `.eslintrc.json`, GitHub Actions workflows, etc. However, I often find myself having both a front end and back end in the same repository. While projen and [GitHub Actions](https://github.com/features/actions) will automatically take care of upgrading dependencies in my main folder, I also want it to take care of dependencies in other parts of my project.

## Schedule

For the main folder dependencies, once a day upgrades is very aggressive. We can adjust that in our `.projenrc.js` file to weekly:

```javascript
const { UpgradeDependenciesSchedule } = require('projen/lib/javascript');

const project = new awscdk.AwsCdkTypeScriptApp({
  ...projectConfig,
  depsUpgradeOptions: {
    ignoreProjen: false,
    workflowOptions: {
      labels: ['auto-approve', 'auto-merge'],
      schedule: UpgradeDependenciesSchedule.WEEKLY,
    },
  },
});
```

This pushes our `upgrade` workflow out to [once a week](https://crontab.guru/#0_0_*_*_1):

```yaml
name: upgrade
on:
  workflow_dispatch: {}
  schedule:
    - cron: 0 0 * * 1
```

## Additional Actions

To add an action, we will once again edit our `.projenrc.js` file. This time we will add a workflow.

```javascript
const { JobPermission } = require('projen/lib/github/workflows-model');

const upgradeSite = project.github.addWorkflow('upgrade-site');
upgradeSite.on({ schedule: [{ cron: '0 0 * * 1' }], workflowDispatch: {} });
```

This will create a new workflow on the same schedule as the existing `upgrade` workflow.

Next, we will add a job that will:

- Install dependencies via `yarn`
- Upgrade dependencies
- Create a Pull Request

```javascript
upgradeSite.addJobs({
  upgradeSite: {
    runsOn: ['ubuntu-latest'],
    name: 'upgrade-site',
    permissions: {
      actions: JobPermission.WRITE,
      contents: JobPermission.READ,
      idToken: JobPermission.WRITE,
    },
    steps: [
      { uses: 'actions/checkout@v3' },
      {
        name: 'Setup Node.js',
        uses: 'actions/setup-node@v3',
        with: {
          'node-version': '16',
        },
      },
      {
        run: 'yarn install --check-files --frozen-lockfile',
        workingDirectory: 'site',
      },
      { run: 'yarn upgrade', workingDirectory: 'site' },
      {
        name: 'Create Pull Request',
        uses: 'peter-evans/create-pull-request@v4',
        with: {
          'token': '${{ secrets.' + AUTOMATION_TOKEN + ' }}',
          'commit-message': 'chore: upgrade site',
          'branch': 'auto/projen-upgrade',
          'title': 'chore: upgrade site',
          'body': 'This PR upgrades site',
          'labels': 'auto-merge, auto-approve',
          'author': 'github-actions <github-actions@github.com>',
          'committer': 'github-actions <github-actions@github.com>',
          'signoff': true,
        },
      },
    ],
  },
});
```

Adjust the `workingDirectory` as needed for any directory that has dependencies that can be upgraded.

## Result

Now, we will have a weekly GitHub Actions workflow that will upgrade dependencies for both our main folder, as well as a subfolder of our choosing. This can be used to help keep [Dependabot](https://github.com/dependabot/dependabot-core) alerts to a minimum by keeping up with security updates.

```yaml
name: upgrade-site
on:
  schedule:
    - cron: 0 5 * * 1
  workflow_dispatch: {}
jobs:
  upgradeSite:
    name: upgrade-site
    runs-on: ubuntu-latest
    permissions:
      actions: write
      contents: read
      id-token: write
    steps:
      - uses: actions/checkout@v3
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '16'
      - run: yarn install --check-files --frozen-lockfile
        working-directory: site
      - run: yarn upgrade
        working-directory: site
      - name: Create Pull Request
        uses: peter-evans/create-pull-request@v4
        with:
          token: ${{ secrets.PROJEN_GITHUB_TOKEN }}
          commit-message: 'chore: upgrade site'
          branch: auto/projen-upgrade
          title: 'chore: upgrade site'
          body: This PR upgrades site
          labels: auto-merge, auto-approve
          author: github-actions <github-actions@github.com>
          committer: github-actions <github-actions@github.com>
          signoff: true
```


This article will show you how to add custom GitHub Actions workflows with Projen

Custom GitHub Action workflows with projen


# CDK Websocket Server

In this demo, we see how to build a simple WebSocket server using Amazon Elastic Container Service with Fargate. This demo also includes an [Amazon CloudFront Distribution](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-working-with.html), [Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/application-load-balancer/), and [Auto Scaling group](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html). This will allow the server to scale up as needed while using TLS to secure the communication.

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

## ECS Fargate

## Docker Build

```Dockerfile
FROM --platform=linux/arm64 node:20
WORKDIR /usr/src/app
COPY . .
RUN yarn && yarn build
EXPOSE 8080
CMD [ "node", "dist/server.js" ]
```

The Docker build is a simple Typescript based server that runs on NodeJS. This Dockerfile will copy the contents of the source directory and use `tsc` to transpile the Typescript file into Javascript before running.

### Cluster and Auto Scaling Group

First we will create the cluster that our container will run in.

```typescript
this.cluster = new Cluster(this, "Cluster", {
  vpc: props.vpc,
  clusterName: "websocket-service",
});

const autoScalingGroup = new AutoScalingGroup(this, "AutoScalingGroup", {
  vpc: props.vpc,
  instanceType: new InstanceType("m6i.large"),
  machineImage: EcsOptimizedImage.amazonLinux2(),
  desiredCapacity: 1,
});

autoScalingGroup.role.addManagedPolicy(
  ManagedPolicy.fromAwsManagedPolicyName("AmazonSSMManagedInstanceCore")
);

const capacityProvider = new AsgCapacityProvider(this, "capacityProvider", {
  autoScalingGroup: autoScalingGroup,
});

this.cluster.addAsgCapacityProvider(capacityProvider);
```

This cluster is running in a newly created VPC and includes an Auto Scaling Group.

### Fargate Task Definition

Next, we will create a Fargate container that will run our WebSocket Server. This will consist of several configurations that need to work together.

```typescript
const webSocketTask = new FargateTaskDefinition(
  this,
  "WebSocketTaskDefinition",
  {
    memoryLimitMiB: 2048,
    cpu: 1024,
    runtimePlatform: {
      operatingSystemFamily: OperatingSystemFamily.LINUX,
      cpuArchitecture: CpuArchitecture.ARM64,
    },
    taskRole: websocketServiceRole,
  }
);
```

Here we are setting up the basics of our compute. This Task will use `ARM64` compute. All components must be configured to use the same type of compute.

### Fargate Container

Next we will set up our container.

```typescript
webSocketTask.addContainer("WebSocketContainer", {
  image: ContainerImage.fromAsset("src/resources/containerImage"),
  containerName: "websocket-service",
  portMappings: [{ containerPort: 8080, hostPort: 8080 }],
  logging: LogDrivers.awsLogs({
    streamPrefix: "websocket-service",
  }),
  healthCheck: {
    command: ["CMD-SHELL", "curl -f http://localhost:8080/health"],
    interval: Duration.seconds(30),
    timeout: Duration.seconds(30),
  },
  environment: {},
});
```

There are several key components here.

#### Port Mappings

In this example, we are using port `8080` on the container and host. Later we will see how to map the public facing port to this port.

#### Health Check

This container is also configured to perform periodic health checks to verify the container is running correctly. In this example, we are running a `curl` on the server.

### Fargate Service

Finally, we will create the Service using the previously created Task.

```typescript
const websocketService = new FargateService(this, "WebSocketService", {
  cluster: this.cluster,
  taskDefinition: webSocketTask,
  assignPublicIp: true,
  desiredCount: 1,
  vpcSubnets: { subnetType: SubnetType.PUBLIC },
  securityGroups: [webSocketServiceSecurityGroup],
  enableExecuteCommand: true,
});
```

With the Fargate created, we can tie this to an Application Load Balancer.

#### Security Group

To ensure that only the Application Load Balancer can make requests to the Fargate container, we will attach a Security Group to the Fargate Service and allow the Application Load Balancer Security Group access to it.

```typescript
const albSecurityGroup = new SecurityGroup(this, "ALBSecurityGroup", {
  vpc: props.vpc,
  description: "Security Group for ALB",
  allowAllOutbound: true,
});

webSocketServiceSecurityGroup.connections.allowFrom(
  new Connections({
    securityGroups: [albSecurityGroup],
  }),
  Port.tcp(8080),
  "allow traffic on port 8080 from the ALB security group"
);
```

## Application Load Balancer

```typescript
this.applicationLoadBalancer = new ApplicationLoadBalancer(
  this,
  "ApplicationLoadBalancer",
  {
    vpc: this.vpc,
    internetFacing: true,
  }
);
```

The Application Load Balancer is created and associated with the VPC.

### Target Group

```typescript
const webSocketTargetGroup = new ApplicationTargetGroup(
  this,
  "webSocketTargetGroup",
  {
    vpc: props.vpc,
    port: 8080,
    protocol: ApplicationProtocol.HTTP,
    targets: [websocketService],
    healthCheck: {
      path: "/",
      protocol: Protocol.HTTP,
      port: "8080",
    },
  }
);
```

First, we will create a Target Group. This is where traffic will be sent. Here we can see port `8080` as the port to send traffic to on the container. This corresponds to the port exposed on the Fargate container. This Target Group will forward requests to the Fargate Service. This Application Load Balancer also includes a health check. This health check is different from the previously created health check as the Application Load Balancer is initiating this check rather than the container itself.

### Listener

```typescript
const webSocketListener = props.applicationLoadBalancer.addListener(
  "webSocketListener",
  {
    port: 80,
    protocol: ApplicationProtocol.HTTP,
    open: true,
    defaultAction: ListenerAction.fixedResponse(403),
  }
);

webSocketListener.addAction("ForwardFromCloudFront", {
  conditions: [
    ListenerCondition.httpHeader(props.customHeader, [props.randomString]),
  ],
  action: ListenerAction.forward([webSocketTargetGroup]),
  priority: 1,
});
```

Next we will create a Listener. Here we can see the listener is listening on port `80`. This is where we made the conversion from port `80` to port `8080`. We are using Protocol `HTTP`. The server will upgrade this HTTP request to WebSocket when it is received.

### Actions

To [restrict access to the Application Load Balancer](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html) we will be adding a unique header to the CloudFront Distribution and a corresponding condition on the Application Load Balancer.

We do that here by creating a default action that responds with a `403`. This means that the Application Load Balancer will reject any request unless it includes a specific Header and Value. In this case, the Application Load Balancer will forward the request to the `webSocketTargetGroup`. We will be adding this Header and Value on the Origin of the CloudFront Distribution in the next step.

Note that the Application Load Balancer is using `HTTP` and not `HTTPS`. We will be enforcing `HTTPS` at the Cloudfront Distribution layer. Be only allowing traffic to our Application Load Balancer from our CloudFront Distribution, we can enforce `HTTPS` be used from the Client. This allows us to create a secure connection without a owning a domain that can be used to generate the certificate.

## Cloudfront Distribution

Finally, we will create our CloudFront Distribution. This will be used to provide TLS to our Application Load Balancer.

```typescript
const defaultOrigin = new LoadBalancerV2Origin(props.applicationLoadBalancer, {
  httpPort: 80,
  protocolPolicy: OriginProtocolPolicy.HTTP_ONLY,
  originId: "defaultOrigin",
});

this.distribution = new Distribution(this, "Distribution", {
  defaultBehavior: {
    origin: defaultOrigin,
    viewerProtocolPolicy: ViewerProtocolPolicy.HTTPS_ONLY,
    cachePolicy: CachePolicy.CACHING_DISABLED,
    allowedMethods: AllowedMethods.ALLOW_ALL,
    originRequestPolicy: OriginRequestPolicy.ALL_VIEWER,
  },
  defaultRootObject: "index.html",
  priceClass: PriceClass.PRICE_CLASS_100,
  logBucket: distributionLoggingBucket,
  enableLogging: true,
});
```

Here we are creating a CloudFront Distribution that only accepts HTTPS. This will create a certificate that is used by the Distribution. This Distribution will send that traffic to our Application Load Balancer on port `80`.

### Custom Header

In order to provide the security outlined above using Custom Headers and Values, we must add those Headers and Values to the Origination. Unfortunately, that feature does not existing natively in CDK. Therefore, we will use a Custom Resource to add the Headers and Values.

```typescript
new CustomResource(this, "customHeaderCustomResource", {
  serviceToken: customHeaderCustomResourceProvider.serviceToken,
  properties: {
    DistributionId: this.distribution.distributionId,
    Origins: [
      {
        OriginId: "defaultOrigin",
        CustomHeaders: [
          {
            HeaderName: props.customHeader,
            HeaderValue: props.randomString,
          },
        ],
      },
    ],
  },
});
```

Using the previously created Distribution, we will pass the information to our Custom Resource that will be added to the Distribution.

### Custom Resource

```typescript
const updatedOrigins = Distribution.DistributionConfig!.Origins!.Items!.map(
  (origin: any) => {
    const matchedOrigin = Origins.find((o: any) => o.OriginId === origin.Id);
    if (matchedOrigin) {
      return {
        ...origin,
        CustomHeaders: {
          Quantity: matchedOrigin.CustomHeaders.length,
          Items: matchedOrigin.CustomHeaders.map((header: any) => ({
            HeaderName: header.HeaderName,
            HeaderValue: header.HeaderValue,
          })),
        },
      };
    }
    return origin;
  }
);
```

Within the Custom Resource, we will `GetDistributionConfiguration` and match up the origin with the desired Header and Value. Using this updated configuration, we will `UpdateDistributionConfiguration`. Now, when a request is made to our CloudFront Distribution, it will add this Header and Value to the request to the Application Load Balancer. This, in turn, will forward the request to our Fargate Service.

## Results

We have now created an auto-scaling, load-balanced application that is secured with `HTTPS` using a CloudFront Distribution. This will allow you to build a secure WebSocket server that will automatically adapt to your traffic needs.

## Deployment

To deploy this demo, simply run:

```bash
yarn launch
```

## Removal

This demo does include services that can accumulate costs, so be sure to remove when not needed. To delete:

```bash
yarn cdk destroy
```

You may have to manually delete the Auto Scaling Group if it is not able to automatically delete.

## Repo

https://github.com/schuettc/cdk-websocket-server


This demo will show how to build and deploy a Fargate WebSocket server.  This application will automatically scale and use TLS to secure the connection.

Building and Deploying a WebSocket server with Fargate and CDK


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

In this demo, we see how to build a React based Websocket reader to get information from a Kinesis Data Stream to a client in real-time. This can be useful for viewing the contents of a Kinesis Data Stream.

## Components

### Websocket API

This demo uses an [Amazon API Gateway using WebSockets](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api.html). Three routes are configured in this API Gateway: $connect, $disconnect, and $default. Connect and Disconnect are used to control connections to the API Gateway. These requests are passed to the Lambda function and stored in the DynamoDB.

```typescript
this.webSocketApi = new WebSocketApi(this, "webSocketApi", {});

this.webSocketApi.addRoute("$connect", {
  integration: new WebSocketLambdaIntegration(
    "ConnectIntegration",
    this.lambdaHandler
  ),
});
this.webSocketApi.addRoute("$disconnect", {
  integration: new WebSocketLambdaIntegration(
    "DisconnectIntegration",
    this.lambdaHandler
  ),
});
this.webSocketApi.addRoute("$default", {
  integration: new WebSocketLambdaIntegration(
    "DefaultIntegration",
    this.lambdaHandler
  ),
});
```

### Lambda Handler

When the request is made to the Lambda function, the request is processed and information about the connection stored in the DynamoDB.

```typescript
export const handler: Handler = async (event) => {
  if (isAPIGatewayProxyEvent(event)) {
    // WebSocket connection and disconnection handling
    const connectionId = event.requestContext.connectionId;
    console.log('endpoint:  ' + process.env.API_GATEWAY_ENDPOINT);

    if (event.requestContext.eventType === 'CONNECT') {
      await ddbDocClient.send(
        new PutCommand({
          TableName: process.env.CONNECTION_TABLE,
          Item: { connectionId },
        }),
      );
      return { statusCode: 200 };
    } else if (event.requestContext.eventType === 'DISCONNECT') {
      await ddbDocClient.send(
        new DeleteCommand({
          TableName: process.env.CONNECTION_TABLE,
          Key: { connectionId },
        }),
      );
      return { statusCode: 200 };
    }
```

This information will be used when a Kinesis Data Stream record is used to [invoke the Lambda function](https://docs.aws.amazon.com/lambda/latest/dg/with-kinesis.html).

```typescript
this.lambdaHandler = new NodejsFunction(this, "lambdaHandler", {
  entry: "src/resources/handler/index.ts",
  runtime: Runtime.NODEJS_18_X,
  architecture: Architecture.ARM_64,
  timeout: Duration.seconds(60),
  role: lambdaHandlerRole,
  environment: {
    STREAM_NAME: props.kinesisDataStream.streamName,
    CONNECTION_TABLE: props.connectionTable.tableName,
    API_GATEWAY_ENDPOINT: `https://${this.webSocketApi.apiId}.execute-api.${this.webSocketApi.stack.region}.amazonaws.com/${this.webSocketStage.stageName}`,
  },
});

new EventSourceMapping(this, "eventSourceMapping", {
  target: this.lambdaHandler,
  eventSourceArn: props.kinesisDataStream.streamArn,
  startingPosition: StartingPosition.LATEST,
});
```

Here we see the Lambda function being created and `EventSourceMapping` used to trigger the Lambda when a record is added to the Kinesis Data Stream.

```typescript
  } else if (isKinesisStreamEvent(event)) {
    // Kinesis Data Stream processing
    for (const record of event.Records) {
      const kinesisData = Buffer.from(record.kinesis.data, 'base64').toString(
        'utf8',
      );
      console.log('Kinesis Record:', kinesisData);

      const connections = await ddbDocClient.send(
        new ScanCommand({ TableName: process.env.CONNECTION_TABLE }),
      );
      const postData = JSON.parse(kinesisData);

      if (connections.Items) {
        console.log('Connections: ' + JSON.stringify(connections.Items));
        for (const connection of connections.Items) {
          try {
            await apiGatewayManagementApi.send(
              new PostToConnectionCommand({
                ConnectionId: connection.connectionId,
                Data: new TextEncoder().encode(JSON.stringify(postData)),
              }),
            );
          } catch (error) {
            if (
              error instanceof Error &&
              'statusCode' in error &&
              error.statusCode === 410
            ) {
              // Remove stale connections
              await ddbDocClient.send(
                new DeleteCommand({
                  TableName: process.env.CONNECTION_TABLE,
                  Key: { connectionId: connection.connectionId },
                }),
              );
            }
          }
        }
      }
    }
  }
```

Now, when the Lambda is triggered by a KDS event, the Lambda will check if there are any active connections in the DynamoDB. If there are, the record will be written to the API Gateway.

### Client

In the client we will create a connection to the API Gateway so we can receive messages as they arrive.

```typescript
useEffect(() => {
  const ws = new WebSocket(WEB_SOCKET_URL + "/" + WEB_SOCKET_STAGE);

  ws.onopen = () => {
    console.log("Connected to WebSocket");
    setSocket(ws);
    setConnected(true);
  };

  ws.onmessage = (event) => {
    console.log("Received message:", event.data);
    const data: Message = JSON.parse(event.data);
    setMessages((prevMessages) => [...prevMessages, data]);
  };

  ws.onerror = (error: Event) => {
    console.error("WebSocket error:", error);
  };

  ws.onclose = () => {
    console.log("WebSocket connection closed");
    setSocket(null);
    setConnected(false);
  };

  return () => {
    if (ws) {
      ws.close();
    }
  };
}, []);
```

Once the client establishes a connection to the API Gateway, when a message is received, the data will be saved to State and displayed.

```typescript
return (
  <div className="header">
    {connected ? (
      <div style={{ color: "green" }}>WebSocket connected</div>
    ) : (
      <div style={{ color: "red" }}>WebSocket disconnected</div>
    )}
    <button onClick={clearMessages}>Clear</button>
    <div className="messages">
      <h2>Messages</h2>
      <ul className="message-list">
        {messages.map((message, index) => (
          <li key={index} className="message">
            <MessageItem message={message} />
          </li>
        ))}
      </ul>
      <AlwaysScrollToBottom />
    </div>
  </div>
);
```

## GitHub

This demo can be found here: https://github.com/schuettc/react-websocket-reader-for-kds

## Deploy

To deploy this demo:

```bash
yarn launch
```

## Cleanup

To destroy these components:

```bash
yarn cdk destroy
```


In this demo, we will be building a React based WebSocket reader that uses Amazon API Gateway to read data from a Kinesis Data Stream

All posts

Excluding files and directories from a CDK Bucket Deployment

Deploy a simple EC2 Instance via Cloudformation

Updated CDK Construct with Custom Resources

Custom GitHub Action workflows with projen

Building and Deploying a WebSocket server with Fargate and CDK

Creating a React based WebSocket reader for KDS