
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


# Next.js SSR App Runner Deployment with CloudFront

This project demonstrates how to deploy a Next.js SSR application using AWS App Runner and CloudFront. It uses an AWS CDK to define and deploy the infrastructure. The project is managed with projen and includes several custom tasks to support the development process.

Update to: https://subaud.io/blog/next-js-app-runner-with-deployment

GitHub: https://github.com/schuettc/next-js-app-runner-deployment

## Architecture

The architecture consists of the following components:

- Next.js application
- AWS App Runner to host and run the Next.js application
- Amazon CloudFront as a content delivery network (CDN) in front of App Runner
- Lambda@Edge to rewrite headers and support dynamic routing
- Route53 ARecords for DNS
- AWS CDK to define and deploy the infrastructure
- GitHub actions for CI/CD

![Overview](/images/blog/updated-nextjs-app-runner-deployment-with-srr/NextJSAppCloudfront.png)

## Prerequisites

- AWS Account
- Node.js (version 18 or later)
- AWS CDK CLI
- Docker (for local development and testing)

## Getting Started

Clone the repository:

```bash
git clone https://github.com/schuettc/next-js-app-runner-deployment.git
cd next-js-app-runner-deployment
```

Install dependencies:

```bash
yarn
```

Deploy the stack:

```bash
yarn launch
```

## Project Structure

- `src/`: Contains the CDK infrastructure code
  - `appRunner.ts`: Defines the App Runner service
  - `cloudfront.ts`: Sets up the CloudFront distribution
  - `lambda.ts`: Creates the Lambda@Edge function
  - `route53.ts`: Defines the DNS records
  - `next-js-app-runner-deployment.ts`: Main stack definition
- `src/resources/app/`: Contains the Next.js application code

## Custom Origin Request Policy

This project implements a custom origin request policy for CloudFront, which is required when using App Runner as the origin. The policy allows specific headers to be forwarded to the origin:

```typescript:src/cloudfront.ts
    const customOriginRequestPolicy = new OriginRequestPolicy(
      this,
      'UserAgentRefererHeadersPolicy',
      {
        headerBehavior: OriginRequestHeaderBehavior.allowList(
          'User-Agent',
          'Referer',
        ),
      },
    );
```

This custom policy ensures that the `User-Agent` and `Referer` headers are forwarded to the App Runner service, which solves the 404 error that occurs when using AppRunner as the origin for a CloudFront distribution.

https://docs.aws.amazon.com/apprunner/latest/dg/request-route-404-troubleshoot.html

## Lambda@Edge for Header Rewriting

This project uses a Lambda@Edge function to rewrite headers, which is crucial for supporting dynamic routing in Next.js when using App Runner behind CloudFront. The function is associated with both the Origin Request and Viewer Request events in CloudFront.

Here's the Lambda@Edge function code:

```typescript:src/resources/lambdaEdge/index.ts
import { CloudFrontRequestEvent, CloudFrontRequestResult } from 'aws-lambda';

export const handler = async (
  event: CloudFrontRequestEvent,
): Promise<CloudFrontRequestResult> => {
  const request = event.Records[0].cf.request;
  const origin = request.origin?.custom;

  if (origin && origin.domainName) {
    request.headers.host = [{ key: 'Host', value: origin.domainName }];
  }

  return request;
};

```

This function rewrites the `Host` header to match the origin's domain name, ensuring that App Runner receives the correct host information. This is essential for Next.js to properly handle dynamic routes.

The Lambda@Edge function is associated with CloudFront in the following way:

```typescript
        edgeLambdas: [
          {
            functionVersion: lambdaEdgeFunction.function.currentVersion,
            eventType: LambdaEdgeEventType.ORIGIN_REQUEST,
          },
          {
            functionVersion: lambdaEdgeFunction.function.currentVersion,
            eventType: LambdaEdgeEventType.VIEWER_REQUEST,
          },
        ],
      },
```

By attaching this function to both the Origin Request and Viewer Request events, we ensure that the headers are properly rewritten for all incoming requests, allowing Next.js to handle dynamic routing correctly when deployed on App Runner behind CloudFront.

## Deployment

The project includes a GitHub Actions workflow for automated deployments. When you push changes to the `main` branch, it will automatically deploy the updated stack to AWS.

To deploy manually:

1. Configure your AWS credentials
2. Run `yarn deploy`

### projen configuration

```typescript
const deploy = project.github?.addWorkflow("deploy");
deploy?.on({
  push: {
    branches: ["main"],
  },
  workflow_dispatch: {},
});

deploy?.addJobs({
  deploy: {
    runsOn: ["ubuntu-latest"],
    permissions: {
      contents: JobPermission.READ,
      id_token: JobPermission.WRITE,
    },
    steps: [
      { uses: "actions/checkout@v4" },
      {
        uses: "actions/setup-node@v4",
        with: {
          "node-version": "18",
        },
      },
      { run: "yarn install --frozen-lockfile" },
      {
        uses: "aws-actions/configure-aws-credentials@v4",
        with: {
          "aws-access-key-id": "${{ secrets.AWS_ACCESS_KEY_ID }}",
          "aws-secret-access-key": "${{ secrets.AWS_SECRET_ACCESS_KEY }}",
          "aws-region": "${{ secrets.AWS_REGION }}",
        },
      },
      { run: "npx cdk deploy --require-approval never" },
    ],
  },
});
```

## Server Side Rendering

This NextJS includes support for Server Side Rendering (SRR) through dynamic routes and API routes:

```typescript
export default function Post({ params }: { params: { id: string } }) {
  return (
    <div>
      <h1>Post {params.id}</h1>
      <p>This is a dynamic route for post with ID: {params.id}</p>
    </div>
  );
}
```

```typescript
import { NextResponse } from "next/server";

export async function GET() {
  return NextResponse.json({ message: "Hello from the API!" });
}

export async function POST(request: Request) {
  const body = await request.json();
  return NextResponse.json({ message: "Hello from the API!", data: body });
}
```

## Local Development

To run the Next.js application locally:

Navigate to the app directory:

```bash
cd src/resources/app
```

Install dependencies:

```bash
yarn
```

Start the development server:

```bash
yarn dev
```

Open [http://localhost:3000](http://localhost:3000) in your browser

## GitHub Updates with Projen

The project uses projen to manage the project and the Next.js application. We have replaced the default projen upgrade with a custom upgrade. This allows us to upgrade the dependencies for both the main project and the Next.js application in a single step.

```typescript
const upgradeWorkflow = project.github?.addWorkflow("upgrade");
upgradeWorkflow?.on({
  schedule: [{ cron: "0 0 * * 1" }],
  workflow_dispatch: {},
});

upgradeWorkflow?.addJobs({
  upgrade: {
    runsOn: ["ubuntu-latest"],
    permissions: {
      contents: JobPermission.WRITE,
      pullRequests: JobPermission.WRITE,
    },
    steps: [
      { uses: "actions/checkout@v4" },
      { uses: "actions/setup-node@v4", with: { "node-version": "18" } },
      { run: "yarn install" },
      { run: "npx projen upgrade:projen" },
      { run: "npx projen upgrade:nextjs" },
      {
        name: "Create Pull Request",
        uses: "peter-evans/create-pull-request@v6",
        with: {
          token: "${{ secrets.PROJEN_GITHUB_TOKEN }}",
          "commit-message": "chore: upgrade dependencies",
          branch: "projen-upgrade",
          title: "chore: upgrade dependencies",
          body: "This PR upgrades project dependencies, including projen and Next.js. Auto-generated by projen upgrade workflow.",
        },
      },
    ],
  },
});

project.addTask("upgrade:nextjs", {
  exec: ["cd src/resources/app", "yarn upgrade --latest", "cd ../../.."].join(
    " && "
  ),
});

project.addTask("upgrade:projen", {
  description: "Upgrade projen dependencies",
  steps: [
    { exec: "yarn upgrade projen @projen/awscdk-app-ts" },
    { exec: "npx projen" },
  ],
});
```

## Route 53 DNS Configuration

This project uses Amazon Route 53 to manage DNS records for the deployed application. The `Route53Resources` construct in `src/route53.ts` sets up the necessary DNS records to point your domain to the CloudFront distribution.

Two A records are created:

- One for the apex domain (e.g., example.com)
- One for the www subdomain (e.g., www.example.com)

Both A records are set up as alias records pointing to the CloudFront distribution:

```typescript
new ARecord(this, "AliasRecord", {
  zone: hostedZone,
  target: RecordTarget.fromAlias(new CloudFrontTarget(props.distribution)),
  recordName: `${props.domainName}.`,
});

new ARecord(this, "WWWAliasRecord", {
  zone: hostedZone,
  target: RecordTarget.fromAlias(new CloudFrontTarget(props.distribution)),
  recordName: `www.${props.domainName}.`,
});
```

This configuration ensures that both the apex domain and the www subdomain resolve to the CloudFront distribution, which in turn serves the Next.js application running on App Runner.

By using alias records, we benefit from Route 53's ability to automatically update the DNS records if the CloudFront distribution's domain name changes, without any manual intervention.

Make sure to update your domain's name servers to use the ones provided by your Route 53 hosted zone for this configuration to take effect.


Updated NextJS App deployed to App Runner with SSR and GitHub Actions


# Next.js App Runner Deployment with CloudFront

This project demonstrates how to deploy a Next.js application using AWS App Runner and CloudFront. It uses the AWS CDK to define and deploy the infrastructure. The project is managed with projen and includes several custom tasks to support the development process.

Please see update: [https://subaud.io/blog/updated-nextjs-app-runner-deployment-with-ssr](https://subaud.io/blog/updated-nextjs-app-runner-deployment-with-ssr)

## Architecture

The architecture consists of the following components:

1. A Next.js application
2. AWS App Runner to host and run the Next.js application
3. Amazon CloudFront as a content delivery network (CDN) in front of App Runner
4. AWS CDK to define and deploy the infrastructure

## Key Features

- Serverless deployment of a Next.js application using AWS App Runner
- CloudFront distribution with custom origin request policy
- Automated CI/CD pipeline using GitHub Actions
- Infrastructure as Code using AWS CDK

## Prerequisites

- AWS Account
- Node.js (version 18 or later)
- AWS CDK CLI
- Docker (for local development and testing)

## Getting Started

Clone the repository:

```bash
git clone https://github.com/schuettc/next-js-app-runner-deployment.git
cd next-js-app-runner-deployment
```

Install dependencies:

```bash
yarn
```

Deploy the stack:

```bash
yarn launch
```

## Project Structure

- `src/`: Contains the CDK infrastructure code
  - `appRunner.ts`: Defines the App Runner service
  - `cloudfront.ts`: Sets up the CloudFront distribution
  - `next-js-app-runner-deployment.ts`: Main stack definition
- `src/resources/app/`: Contains the Next.js application code

## Custom Origin Request Policy

This project implements a custom origin request policy for CloudFront, which is required when using App Runner as the origin. The policy allows specific headers to be forwarded to the origin:

```typescript:src/cloudfront.ts
    const customOriginRequestPolicy = new OriginRequestPolicy(
      this,
      'UserAgentRefererHeadersPolicy',
      {
        headerBehavior: OriginRequestHeaderBehavior.allowList(
          'User-Agent',
          'Referer',
        ),
      },
    );
```

This custom policy ensures that the `User-Agent` and `Referer` headers are forwarded to the App Runner service, which solves the 404 error that occurs when using AppRunner as the origin for a CloudFront distribution.

https://docs.aws.amazon.com/apprunner/latest/dg/request-route-404-troubleshoot.html

## Deployment

The project includes a GitHub Actions workflow for automated deployments. When you push changes to the `main` branch, it will automatically deploy the updated stack to AWS.

To deploy manually:

1. Configure your AWS credentials
2. Run `yarn deploy`

### projen configuration

```typescript
const deploy = project.github?.addWorkflow('deploy');
deploy?.on({
  push: {
    branches: ['main'],
  },
  workflow_dispatch: {},
});

deploy?.addJobs({
  deploy: {
    runsOn: ['ubuntu-latest'],
    permissions: {
      contents: JobPermission.READ,
      id_token: JobPermission.WRITE,
    },
    steps: [
      { uses: 'actions/checkout@v4' },
      {
        uses: 'actions/setup-node@v4',
        with: {
          'node-version': '18',
        },
      },
      { run: 'yarn install --frozen-lockfile' },
      {
        uses: 'aws-actions/configure-aws-credentials@v4',
        with: {
          'aws-access-key-id': '${{ secrets.AWS_ACCESS_KEY_ID }}',
          'aws-secret-access-key': '${{ secrets.AWS_SECRET_ACCESS_KEY }}',
          'aws-region': '${{ secrets.AWS_REGION }}',
        },
      },
      { run: 'npx cdk deploy --require-approval never' },
    ],
  },
});
```

## Local Development

To run the Next.js application locally:

Navigate to the app directory:

```bash
cd src/resources/app
```

Install dependencies:

```bash
yarn
```

Start the development server:

```bash
yarn dev
```

Open [http://localhost:3000](http://localhost:3000) in your browser

## GitHub Updates with Projen

The project uses projen to manage the project and the Next.js application. We have replaced the default projen upgrade with a custom upgrade. This allows us to upgrade the dependencies for both the main project and the Next.js application in a single step.

```typescript
const upgradeWorkflow = project.github?.addWorkflow('upgrade');
upgradeWorkflow?.on({
  schedule: [{ cron: '0 0 * * 1' }],
  workflow_dispatch: {},
});

upgradeWorkflow?.addJobs({
  upgrade: {
    runsOn: ['ubuntu-latest'],
    permissions: {
      contents: JobPermission.WRITE,
      pullRequests: JobPermission.WRITE,
    },
    steps: [
      { uses: 'actions/checkout@v4' },
      { uses: 'actions/setup-node@v4', with: { 'node-version': '18' } },
      { run: 'yarn install' },
      { run: 'npx projen upgrade:projen' },
      { run: 'npx projen upgrade:nextjs' },
      {
        name: 'Create Pull Request',
        uses: 'peter-evans/create-pull-request@v6',
        with: {
          'token': '${{ secrets.PROJEN_GITHUB_TOKEN }}',
          'commit-message': 'chore: upgrade dependencies',
          'branch': 'projen-upgrade',
          'title': 'chore: upgrade dependencies',
          'body':
            'This PR upgrades project dependencies, including projen and Next.js. Auto-generated by projen upgrade workflow.',
        },
      },
    ],
  },
});

project.addTask('upgrade:nextjs', {
  exec: ['cd src/resources/app', 'yarn upgrade --latest', 'cd ../../..'].join(
    ' && ',
  ),
});

project.addTask('upgrade:projen', {
  description: 'Upgrade projen dependencies',
  steps: [
    { exec: 'yarn upgrade projen @projen/awscdk-app-ts' },
    { exec: 'npx projen' },
  ],
});
```


NextJS App deployed to App Runner with GitHub Actions


[cdk-nag](https://github.com/cdklabs/cdk-nag) is a useful tool for enforcing best practices within a CDK stack. This can be combined with [jest](https://jestjs.io/) testing used in [projen](https://projen.io/) to ensure a compliant deployment.

## GitHub Repo

https://github.com/schuettc/cdk-nag-with-projen

## CDK Setup

After creating a basic projen project with something like `npx projen new awscdk-app-ts`, the `.projenrc.ts` file should be updated with `devDeps: ['cdk-nag']`. This will install `cdk-nag` as a [devDependency](https://docs.npmjs.com/specifying-dependencies-and-devdependencies-in-a-package-json-file).

Next, we will create a very basic CDK Stack:

```typescript
new Bucket(this, 'Bucket', {
  removalPolicy: RemovalPolicy.DESTROY,
  autoDeleteObjects: true,
  encryption: BucketEncryption.S3_MANAGED,
});
```

## Test Setup

By default, projen will run tests using the files in the `test` folder. In this case, we have created a `cdk-nag.test.ts` file that will be run during deployment.

Let's set up that file. First, we'll set up the basics by importing the Stack that we will be deploying. In this case, we will import the `CDKNagWithProjen` Stack from `../src/cdk-nag-with-projen` and test against that.

```typescript
import { AwsSolutionsChecks } from 'cdk-nag';
import { CDKNagWithProjen } from '../src/cdk-nag-with-projen';

describe('cdk-nag AwsSolutions Pack', () => {
  let stack: Stack;
  let app: App;

  beforeEach(() => {
    app = new App();
    stack = new CDKNagWithProjen(app, 'CDKNagWithProjen', {});

    outputStream = fs.createWriteStream('cdk-nag-output.txt');
  });

  afterEach(() => {
    outputStream.end();
  });
  ...
});
```

## Test without Suppressions

First, we'll run tests against the Stack without suppressions and write the output to a file.

```typescript
import { App, Aspects, Stack } from 'aws-cdk-lib';
import { Annotations, Match } from 'aws-cdk-lib/assertions';
import { AwsSolutionsChecks } from 'cdk-nag';

describe('cdk-nag AwsSolutions Pack', () => {
  ...
  test('Output all Warnings and Errors', () => {
    Aspects.of(stack).add(
      new AwsSolutionsChecks({
        verbose: true,
        logIgnores: false,
      }),
    );

    const warnings = Annotations.fromStack(stack).findWarning(
      '*',
      Match.stringLikeRegexp('AwsSolutions-.*'),
    );

    outputStream.write('All Warnings:\n');
    warnings.forEach((warning) => {
      outputStream.write(warning.entry.data);
    });

    const errors = Annotations.fromStack(stack).findError(
      '*',
      Match.stringLikeRegexp('AwsSolutions-.*'),
    );

    outputStream.write('All Errors:\n');
    errors.forEach((error) => {
      outputStream.write(error.entry.data);
    });
  });
}
```

Each of these warnings and errors will be written to the `cdk-nag-output.txt` file. This will record the results of `cdk-nag` without any suppressions. In this example, the results will look like this:

```text
All Warnings:
All Errors:
AwsSolutions-S1: The S3 Bucket has server access logs disabled. The bucket should have server access logging enabled to provide detailed records for the requests that are made to the bucket.
AwsSolutions-S10: The S3 Bucket or bucket policy does not require requests to use SSL. You can use HTTPS (TLS) to help prevent potential attackers from eavesdropping on or manipulating network traffic using person-in-the-middle or similar attacks. You should allow only encrypted connections over HTTPS (TLS) using the aws:SecureTransport condition on Amazon S3 bucket policies.
AwsSolutions-S10: The S3 Bucket or bucket policy does not require requests to use SSL. You can use HTTPS (TLS) to help prevent potential attackers from eavesdropping on or manipulating network traffic using person-in-the-middle or similar attacks. You should allow only encrypted connections over HTTPS (TLS) using the aws:SecureTransport condition on Amazon S3 bucket policies.
```

This test has no expectations so will throw no errors when running `yarn projen test` or during deployment. The results of these tests are only written to the `cdk-nag-output.txt` file.

## Add suppressions

If these errors are acceptable, we can add a suppression to `cdk-nag`. To do this, we'll create `nagSuppressions.ts`.

```typescript
import { Stack } from 'aws-cdk-lib';
import { NagSuppressions } from 'cdk-nag';

export function applySuppressions(stack: Stack): void {
  NagSuppressions.addStackSuppressions(stack, [
    {
      id: 'AwsSolutions-S1',
      reason: 'Suppressing S3 server access logging warning for demo purposes',
    },
    {
      id: 'AwsSolutions-S10',
      reason: 'Suppressing S3 bucket SSL requirement warning for demo purposes',
    },
  ]);
}
```

## Test with suppressions

Next, we'll run these tests again with suppressions.

```typescript
import { App, Aspects, Stack } from 'aws-cdk-lib';
import { Annotations, Match } from 'aws-cdk-lib/assertions';
import { AwsSolutionsChecks } from 'cdk-nag';
import { applySuppressions } from '../src/nagSuppressions';


describe('cdk-nag AwsSolutions Pack', () => {
  ...

  test('No unsuppressed Warnings or Errors after applying suppressions', () => {
    applySuppressions(stack);

    Aspects.of(stack).add(
      new AwsSolutionsChecks({
        verbose: true,
        logIgnores: false,
      }),
    );

    const unsuppressedWarnings = Annotations.fromStack(stack).findWarning(
      '*',
      Match.stringLikeRegexp('AwsSolutions-.*'),
    );

    expect(unsuppressedWarnings).toHaveLength(0);

    const unsuppressedErrors = Annotations.fromStack(stack).findError(
      '*',
      Match.stringLikeRegexp('AwsSolutions-.*'),
    );

    expect(unsuppressedErrors).toHaveLength(0);
  });
});
```

In this test, we are expecting `unsuppressedWarnings` and `unsuppressedErrors` to have a length of 0. If that is not the case, the tests will fail. If there are no warnings or errors, the result should look like this:

```text
$ npx projen test
👾 test | jest --passWithNoTests --updateSnapshot
 PASS  test/cdk-nag.test.ts
  cdk-nag AwsSolutions Pack
    ✓ Output all Warnings and Errors (220 ms)
    ✓ No unsuppressed Warnings or Errors after applying suppressions (51 ms)

------------------------|---------|----------|---------|---------|-------------------
File                    | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
------------------------|---------|----------|---------|---------|-------------------
All files               |     100 |      100 |     100 |     100 |
 cdk-nag-with-projen.ts |     100 |      100 |     100 |     100 |
 nagSuppressions.ts     |     100 |      100 |     100 |     100 |
------------------------|---------|----------|---------|---------|-------------------
Test Suites: 1 passed, 1 total
Tests:       2 passed, 2 total
Snapshots:   0 total
Time:        2.756 s, estimated 3 s
Ran all test suites.
```

## Result

With a projen project configured CDK stack with this setup, we can perform `cdk-nag` tests on the Stack, capture the results, suppress acceptable warnings and errors, and then deploy confidently.


In this demo we will see how to deploy and test a projen based project with cdk-nag

cdk-nag with projen


[Feature flags](https://docs.aws.amazon.com/cdk/v2/guide/featureflags.html) are a way to modify the deployment behavior of an AWS SDK deployment. These are potentially breaking, so use with caution. These feature flags are stored in the [context](https://docs.aws.amazon.com/cdk/v2/guide/context.html) of the CDK as key-value pairs.

For example:

```json
  "context": {
    "@aws-cdk/aws-ec2:uniqueImdsv2TemplateName": true
  },
```

Here we are setting a feature flag to tell the CDK to always use a unique launch template name. This is useful when [requiring imdsv2](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_ec2-readme.html#configuring-instance-metadata-service-imds) for an EC2 instance.

```typescript
    const ec2Instance = new Instance(this, 'Instance', {
      vpc: props.vpc,
      instanceType: InstanceType.of(InstanceClass.C7G, InstanceSize.MEDIUM),
      machineImage: ubuntuAmi,
      requireImdsv2: true,
      userData: userData,
      ...
    })
```

Without this feature flag enabled, you are likely to get an error similar to this:

```bash
Launch template name already in use. (Service: AmazonEC2; Status Code: 400; Error Code: InvalidLaunchTemplateName.AlreadyExistsException;
```

To add this feature flag to the `cdk.json` file when using [projen](https://projen.io/) we must modify the `.projenrc.ts` file.

```typescript
project.cdkConfig.json.addOverride('context', {
  '@aws-cdk/aws-ec2:uniqueImdsv2TemplateName': true,
});
```

This will add the necessary context to the `cdk.json` file and enable the [`uniqueImdsv2TemplateName`](https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/cx-api/FEATURE_FLAGS.md#aws-cdkaws-ec2uniqueimdsv2templatename) feature flag.

For a complete list of available feature flags available: https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/cx-api/FEATURE_FLAGS.md


Feature flags can be used to modify the deployment characteristics of a CDK deployment.  These feature flags can be enabled in projen by modifying the cdk.json file.

Adding feature flags to AWS CDK through runtime context with projen


# 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


> 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


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


Projen