@aws-cdk/aws-lambda-go-alpha 2.162.1-alpha.0 → 2.163.1-alpha.0

package/.jsii

@@ -8,7 +8,7 @@
     "url": "https://aws.amazon.com"
   },
   "dependencies": {
-    "aws-cdk-lib": "^2.162.1",
+    "aws-cdk-lib": "^2.163.1",
     "constructs": "^10.0.0"
   },
   "dependencyClosure": {
@@ -3882,7 +3882,7 @@
   },
   "name": "@aws-cdk/aws-lambda-go-alpha",
   "readme": {
-    "markdown": "# Amazon Lambda Golang Library\n<!--BEGIN STABILITY BANNER-->\n\n---\n\n![cdk-constructs: Experimental](https://img.shields.io/badge/cdk--constructs-experimental-important.svg?style=for-the-badge)\n\n> The APIs of higher level constructs in this module are experimental and under active development.\n> They are subject to non-backward compatible changes or removal in any future version. These are\n> not subject to the [Semantic Versioning](https://semver.org/) model and breaking changes will be\n> announced in the release notes. This means that while you may use them, you may need to update\n> your source code when upgrading to a newer version of this package.\n\n---\n\n<!--END STABILITY BANNER-->\n\nThis library provides constructs for Golang Lambda functions.\n\nTo use this module you will either need to have `Go` installed (`go1.11` or later) or `Docker` installed.\nSee [Local Bundling](#local-bundling)/[Docker Bundling](#docker-bundling) for more information.\n\nThis module also requires that your Golang application is\nusing a Go version >= 1.11 and is using [Go modules](https://golang.org/ref/mod).\n\n## Go Function\n\nDefine a `GoFunction`:\n\n```ts\nnew go.GoFunction(this, 'handler', {\n  entry: 'lambda-app/cmd/api',\n});\n```\n\nBy default, if `entry` points to a directory, then the construct will assume there is a Go entry file (i.e. `main.go`).\nLet's look at an example Go project:\n\n```bash\nlambda-app\n├── cmd\n│   └── api\n│       └── main.go\n├── go.mod\n├── go.sum\n├── pkg\n│   ├── auth\n│   │   └── auth.go\n│   └── middleware\n│       └── middleware.go\n└── vendor\n    ├── github.com\n    │   └── aws\n    │       └── aws-lambda-go\n    └── modules.txt\n```\n\nWith the above layout I could either provide the `entry` as `lambda-app/cmd/api` or `lambda-app/cmd/api/main.go`, either will work.\nWhen the construct builds the golang binary this will be translated `go build ./cmd/api` & `go build ./cmd/api/main.go` respectively.\nThe construct will figure out where it needs to run the `go build` command from, in this example it would be from\nthe `lambda-app` directory. It does this by determining the [mod file path](#mod-file-path), which is explained in the\nnext section.\n\n### mod file path\n\nThe `GoFunction` tries to automatically determine your project root, that is\nthe root of your golang project. This is usually where the top level `go.mod` file or\n`vendor` folder of your project is located. When bundling in a Docker container, the\n`moduleDir` is used as the source (`/asset-input`) for the volume mounted in\nthe container.\n\nThe CDK will walk up parent folders starting from\nthe current working directory until it finds a folder containing a `go.mod` file.\n\nAlternatively, you can specify the `moduleDir` prop manually. In this case you\nneed to ensure that this path includes `entry` and any module/dependencies used\nby your function. Otherwise bundling will fail.\n\n## Runtime\n\nThe `GoFunction` can be used with either the `GO_1_X` runtime or the provided runtimes (`PROVIDED`/`PROVIDED_AL2`).\nBy default it will use the `PROVIDED_AL2` runtime. The `GO_1_X` runtime does not support things like\n[Lambda Extensions](https://docs.aws.amazon.com/lambda/latest/dg/using-extensions.html), whereas the provided runtimes do.\nThe [aws-lambda-go](https://github.com/aws/aws-lambda-go) library has built in support for the provided runtime as long as\nyou name the handler `bootstrap` (which we do by default).\n\n## Dependencies\n\nThe construct will attempt to figure out how to handle the dependencies for your function. It will\ndo this by determining whether or not you are vendoring your dependencies. It makes this determination\nby looking to see if there is a `vendor` folder at the [mod file path](#mod-file-path).\n\nWith this information the construct can determine what commands to run. You will\ngenerally fall into two scenarios:\n\n1. You are using vendoring (indicated by the presence of a `vendor` folder)\n   In this case `go build` will be run with `-mod=vendor` set\n2. You are not using vendoring (indicated by the absence of a `vendor` folder)\n   If you are not vendoring then `go build` will be run without `-mod=vendor`\n    since the default behavior is to download dependencies\n\nAll other properties of `lambda.Function` are supported, see also the [AWS Lambda construct library](https://github.com/aws/aws-cdk/tree/main/packages/aws-cdk-lib/aws-lambda).\n\n## Environment\n\nBy default the following environment variables are set for you:\n\n* `GOOS=linux`\n* `GOARCH`: based on the target architecture of the Lambda function\n* `GO111MODULE=on`\n\nUse the `environment` prop to define additional environment variables when go runs:\n\n```ts\nnew go.GoFunction(this, 'handler', {\n  entry: 'app/cmd/api',\n  bundling: {\n    environment: {\n      HELLO: 'WORLD',\n    },\n  },\n});\n```\n\n## Local Bundling\n\nIf `Go` is installed locally and the version is >= `go1.11` then it will be used to bundle your code in your environment. Otherwise, bundling will happen in a [Lambda compatible Docker container](https://gallery.ecr.aws/sam/build-go1.x) with the Docker platform based on the target architecture of the Lambda function.\n\nFor macOS the recommended approach is to install `Go` as Docker volume performance is really poor.\n\n`Go` can be installed by following the [installation docs](https://golang.org/doc/install).\n\n\n## Docker\n\nTo force bundling in a docker container even if `Go` is available in your environment, set the `forceDockerBundling` prop to `true`. This is useful if you want to make sure that your function is built in a consistent Lambda compatible environment.\n\nUse the `buildArgs` prop to pass build arguments when building the bundling image:\n\n```ts\nnew go.GoFunction(this, 'handler', {\n  entry: 'app/cmd/api',\n  bundling: {\n    buildArgs: {\n      HTTPS_PROXY: 'https://127.0.0.1:3001',\n    },\n  },\n});\n```\n\nUse the `bundling.dockerImage` prop to use a custom bundling image:\n\n```ts\nnew go.GoFunction(this, 'handler', {\n  entry: 'app/cmd/api',\n  bundling: {\n    dockerImage: DockerImage.fromBuild('/path/to/Dockerfile'),\n  },\n});\n```\n\nUse the `bundling.goBuildFlags` prop to pass additional build flags to `go build`:\n\n```ts\nnew go.GoFunction(this, 'handler', {\n  entry: 'app/cmd/api',\n  bundling: {\n    goBuildFlags: ['-ldflags \"-s -w\"'],\n  },\n});\n```\n\nBy default this construct doesn't use any Go module proxies. This is contrary to\na standard Go installation, which would use the Google proxy by default. To\nrecreate that behavior, do the following:\n\n```ts\nnew go.GoFunction(this, 'GoFunction', {\n  entry: 'app/cmd/api',\n  bundling: {\n    goProxies: [go.GoFunction.GOOGLE_GOPROXY, 'direct'],\n  },\n});\n```\n\nYou can set additional Docker options to configure the build environment:\n\n ```ts\nnew go.GoFunction(this, 'GoFunction', {\n  entry: 'app/cmd/api',\n  bundling: {\n      network: 'host',\n      securityOpt: 'no-new-privileges',\n      user: 'user:group',\n      volumesFrom: ['777f7dc92da7'],\n      volumes: [{ hostPath: '/host-path', containerPath: '/container-path' }],\n   },\n});\n```\n\n## Command hooks\n\nIt is  possible to run additional commands by specifying the `commandHooks` prop:\n\n```text\n// This example only available in TypeScript\n// Run additional commands on a GoFunction via `commandHooks` property\nnew go.GoFunction(this, 'handler', {\n  bundling: {\n    commandHooks: {\n      // run tests\n      beforeBundling(inputDir: string): string[] {\n        return ['go test ./cmd/api -v'];\n      },\n      // ...\n    },\n  },\n});\n```\n\nThe following hooks are available:\n\n* `beforeBundling`: runs before all bundling commands\n* `afterBundling`: runs after all bundling commands\n\nThey all receive the directory containing the `go.mod` file (`inputDir`) and the\ndirectory where the bundled asset will be output (`outputDir`). They must return\nan array of commands to run. Commands are chained with `&&`.\n\nThe commands will run in the environment in which bundling occurs: inside the\ncontainer for Docker bundling or on the host OS for local bundling.\n\n## Additional considerations\n\nDepending on how you structure your Golang application, you may want to change the `assetHashType` parameter.\nBy default this parameter is set to `AssetHashType.OUTPUT` which means that the CDK will calculate the asset hash\n(and determine whether or not your code has changed) based on the Golang executable that is created.\n\nIf you specify `AssetHashType.SOURCE`, the CDK will calculate the asset hash by looking at the folder\nthat contains your `go.mod` file. If you are deploying a single Lambda function, or you want to redeploy\nall of your functions if anything changes, then `AssetHashType.SOURCE` will probably work.\n\n\nFor example, if my app looked like this:\n\n```bash\nlambda-app\n├── cmd\n│   └── api\n│       └── main.go\n├── go.mod\n├── go.sum\n└── pkg\n    └── auth\n        └── auth.go\n```\n\nWith this structure I would provide the `entry` as `cmd/api` which means that the CDK\nwill determine that the protect root is `lambda-app` (it contains the `go.mod` file).\nSince I only have a single Lambda function, and any update to files within the `lambda-app` directory\nshould trigger a new deploy, I could specify `AssetHashType.SOURCE`.\n\nOn the other hand, if I had a project that deployed multiple Lambda functions, for example:\n\n```bash\nlambda-app\n├── cmd\n│   ├── api\n│   │   └── main.go\n│   └── anotherApi\n│       └── main.go\n├── go.mod\n├── go.sum\n└── pkg\n    ├── auth\n    │   └── auth.go\n    └── middleware\n        └── middleware.go\n```\n\nThen I would most likely want `AssetHashType.OUTPUT`. With `OUTPUT`\nthe CDK will only recognize changes if the Golang executable has changed,\nand Go only includes dependencies that are used in the executable. So in this case\nif `cmd/api` used the `auth` & `middleware` packages, but `cmd/anotherApi` did not, then\nan update to `auth` or `middleware` would only trigger an update to the `cmd/api` Lambda\nFunction.\n\n## Docker based bundling in complex Docker configurations\n\nBy default the input and output of Docker based bundling is handled via bind mounts.\nIn situtations where this does not work, like Docker-in-Docker setups or when using a remote Docker socket, you can configure an alternative, but slower, variant that also works in these situations.\n\n ```ts\nnew go.GoFunction(this, 'GoFunction', {\n  entry: 'app/cmd/api',\n  bundling: {\n       bundlingFileAccess: BundlingFileAccess.VOLUME_COPY,\n   },\n});\n```\n"
+    "markdown": "# Amazon Lambda Golang Library\n<!--BEGIN STABILITY BANNER-->\n\n---\n\n![cdk-constructs: Experimental](https://img.shields.io/badge/cdk--constructs-experimental-important.svg?style=for-the-badge)\n\n> The APIs of higher level constructs in this module are experimental and under active development.\n> They are subject to non-backward compatible changes or removal in any future version. These are\n> not subject to the [Semantic Versioning](https://semver.org/) model and breaking changes will be\n> announced in the release notes. This means that while you may use them, you may need to update\n> your source code when upgrading to a newer version of this package.\n\n---\n\n<!--END STABILITY BANNER-->\n\nThis library provides constructs for Golang Lambda functions.\n\nTo use this module you will either need to have `Go` installed (`go1.11` or later) or `Docker` installed.\nSee [Local Bundling](#local-bundling)/[Docker Bundling](#docker-bundling) for more information.\n\nThis module also requires that your Golang application is\nusing a Go version >= 1.11 and is using [Go modules](https://golang.org/ref/mod).\n\n## Go Function\n\nDefine a `GoFunction`:\n\n```ts\nnew go.GoFunction(this, 'handler', {\n  entry: 'lambda-app/cmd/api',\n});\n```\n\nBy default, if `entry` points to a directory, then the construct will assume there is a Go entry file (i.e. `main.go`).\nLet's look at an example Go project:\n\n```bash\nlambda-app\n├── cmd\n│   └── api\n│       └── main.go\n├── go.mod\n├── go.sum\n├── pkg\n│   ├── auth\n│   │   └── auth.go\n│   └── middleware\n│       └── middleware.go\n└── vendor\n    ├── github.com\n    │   └── aws\n    │       └── aws-lambda-go\n    └── modules.txt\n```\n\nWith the above layout I could either provide the `entry` as `lambda-app/cmd/api` or `lambda-app/cmd/api/main.go`, either will work.\nWhen the construct builds the golang binary this will be translated `go build ./cmd/api` & `go build ./cmd/api/main.go` respectively.\nThe construct will figure out where it needs to run the `go build` command from, in this example it would be from\nthe `lambda-app` directory. It does this by determining the [mod file path](#mod-file-path), which is explained in the\nnext section.\n\n### mod file path\n\nThe `GoFunction` tries to automatically determine your project root, that is\nthe root of your golang project. This is usually where the top level `go.mod` file or\n`vendor` folder of your project is located. When bundling in a Docker container, the\n`moduleDir` is used as the source (`/asset-input`) for the volume mounted in\nthe container.\n\nThe CDK will walk up parent folders starting from\nthe current working directory until it finds a folder containing a `go.mod` file.\n\nAlternatively, you can specify the `moduleDir` prop manually. In this case you\nneed to ensure that this path includes `entry` and any module/dependencies used\nby your function. Otherwise bundling will fail.\n\n## Runtime\n\nThe `GoFunction` can be used with either the `GO_1_X` runtime or the provided runtimes (`PROVIDED`/`PROVIDED_AL2`).\nBy default it will use the `PROVIDED_AL2` runtime. The `GO_1_X` runtime does not support things like\n[Lambda Extensions](https://docs.aws.amazon.com/lambda/latest/dg/using-extensions.html), whereas the provided runtimes do.\nThe [aws-lambda-go](https://github.com/aws/aws-lambda-go) library has built in support for the provided runtime as long as\nyou name the handler `bootstrap` (which we do by default).\n\n## Dependencies\n\nThe construct will attempt to figure out how to handle the dependencies for your function. It will\ndo this by determining whether or not you are vendoring your dependencies. It makes this determination\nby looking to see if there is a `vendor` folder at the [mod file path](#mod-file-path).\n\nWith this information the construct can determine what commands to run. You will\ngenerally fall into two scenarios:\n\n1. You are using vendoring (indicated by the presence of a `vendor` folder)\n   In this case `go build` will be run with `-mod=vendor` set\n2. You are not using vendoring (indicated by the absence of a `vendor` folder)\n   If you are not vendoring then `go build` will be run without `-mod=vendor`\n    since the default behavior is to download dependencies\n\nAll other properties of `lambda.Function` are supported, see also the [AWS Lambda construct library](https://github.com/aws/aws-cdk/tree/main/packages/aws-cdk-lib/aws-lambda).\n\n## Environment\n\nBy default the following environment variables are set for you:\n\n* `GOOS=linux`\n* `GOARCH`: based on the target architecture of the Lambda function\n* `GO111MODULE=on`\n\nUse the `environment` prop to define additional environment variables when go runs:\n\n```ts\nnew go.GoFunction(this, 'handler', {\n  entry: 'app/cmd/api',\n  bundling: {\n    environment: {\n      HELLO: 'WORLD',\n    },\n  },\n});\n```\n\n## Local Bundling\n\nIf `Go` is installed locally and the version is >= `go1.11` then it will be used to bundle your code in your environment. Otherwise, bundling will happen in a [Lambda compatible Docker container](https://gallery.ecr.aws/sam/build-provided.al2023) with the Docker platform based on the target architecture of the Lambda function.\n\nFor macOS the recommended approach is to install `Go` as Docker volume performance is really poor.\n\n`Go` can be installed by following the [installation docs](https://golang.org/doc/install).\n\n\n## Docker\n\nTo force bundling in a docker container even if `Go` is available in your environment, set the `forceDockerBundling` prop to `true`. This is useful if you want to make sure that your function is built in a consistent Lambda compatible environment.\n\nUse the `buildArgs` prop to pass build arguments when building the bundling image:\n\n```ts\nnew go.GoFunction(this, 'handler', {\n  entry: 'app/cmd/api',\n  bundling: {\n    buildArgs: {\n      HTTPS_PROXY: 'https://127.0.0.1:3001',\n    },\n  },\n});\n```\n\nUse the `bundling.dockerImage` prop to use a custom bundling image:\n\n```ts\nnew go.GoFunction(this, 'handler', {\n  entry: 'app/cmd/api',\n  bundling: {\n    dockerImage: DockerImage.fromBuild('/path/to/Dockerfile'),\n  },\n});\n```\n\nUse the `bundling.goBuildFlags` prop to pass additional build flags to `go build`:\n\n```ts\nnew go.GoFunction(this, 'handler', {\n  entry: 'app/cmd/api',\n  bundling: {\n    goBuildFlags: ['-ldflags \"-s -w\"'],\n  },\n});\n```\n\nBy default this construct doesn't use any Go module proxies. This is contrary to\na standard Go installation, which would use the Google proxy by default. To\nrecreate that behavior, do the following:\n\n```ts\nnew go.GoFunction(this, 'GoFunction', {\n  entry: 'app/cmd/api',\n  bundling: {\n    goProxies: [go.GoFunction.GOOGLE_GOPROXY, 'direct'],\n  },\n});\n```\n\nYou can set additional Docker options to configure the build environment:\n\n ```ts\nnew go.GoFunction(this, 'GoFunction', {\n  entry: 'app/cmd/api',\n  bundling: {\n      network: 'host',\n      securityOpt: 'no-new-privileges',\n      user: 'user:group',\n      volumesFrom: ['777f7dc92da7'],\n      volumes: [{ hostPath: '/host-path', containerPath: '/container-path' }],\n   },\n});\n```\n\n## Command hooks\n\nIt is  possible to run additional commands by specifying the `commandHooks` prop:\n\n```text\n// This example only available in TypeScript\n// Run additional commands on a GoFunction via `commandHooks` property\nnew go.GoFunction(this, 'handler', {\n  bundling: {\n    commandHooks: {\n      // run tests\n      beforeBundling(inputDir: string): string[] {\n        return ['go test ./cmd/api -v'];\n      },\n      // ...\n    },\n  },\n});\n```\n\nThe following hooks are available:\n\n* `beforeBundling`: runs before all bundling commands\n* `afterBundling`: runs after all bundling commands\n\nThey all receive the directory containing the `go.mod` file (`inputDir`) and the\ndirectory where the bundled asset will be output (`outputDir`). They must return\nan array of commands to run. Commands are chained with `&&`.\n\nThe commands will run in the environment in which bundling occurs: inside the\ncontainer for Docker bundling or on the host OS for local bundling.\n\n## Additional considerations\n\nDepending on how you structure your Golang application, you may want to change the `assetHashType` parameter.\nBy default this parameter is set to `AssetHashType.OUTPUT` which means that the CDK will calculate the asset hash\n(and determine whether or not your code has changed) based on the Golang executable that is created.\n\nIf you specify `AssetHashType.SOURCE`, the CDK will calculate the asset hash by looking at the folder\nthat contains your `go.mod` file. If you are deploying a single Lambda function, or you want to redeploy\nall of your functions if anything changes, then `AssetHashType.SOURCE` will probably work.\n\n\nFor example, if my app looked like this:\n\n```bash\nlambda-app\n├── cmd\n│   └── api\n│       └── main.go\n├── go.mod\n├── go.sum\n└── pkg\n    └── auth\n        └── auth.go\n```\n\nWith this structure I would provide the `entry` as `cmd/api` which means that the CDK\nwill determine that the protect root is `lambda-app` (it contains the `go.mod` file).\nSince I only have a single Lambda function, and any update to files within the `lambda-app` directory\nshould trigger a new deploy, I could specify `AssetHashType.SOURCE`.\n\nOn the other hand, if I had a project that deployed multiple Lambda functions, for example:\n\n```bash\nlambda-app\n├── cmd\n│   ├── api\n│   │   └── main.go\n│   └── anotherApi\n│       └── main.go\n├── go.mod\n├── go.sum\n└── pkg\n    ├── auth\n    │   └── auth.go\n    └── middleware\n        └── middleware.go\n```\n\nThen I would most likely want `AssetHashType.OUTPUT`. With `OUTPUT`\nthe CDK will only recognize changes if the Golang executable has changed,\nand Go only includes dependencies that are used in the executable. So in this case\nif `cmd/api` used the `auth` & `middleware` packages, but `cmd/anotherApi` did not, then\nan update to `auth` or `middleware` would only trigger an update to the `cmd/api` Lambda\nFunction.\n\n## Docker based bundling in complex Docker configurations\n\nBy default the input and output of Docker based bundling is handled via bind mounts.\nIn situtations where this does not work, like Docker-in-Docker setups or when using a remote Docker socket, you can configure an alternative, but slower, variant that also works in these situations.\n\n ```ts\nnew go.GoFunction(this, 'GoFunction', {\n  entry: 'app/cmd/api',\n  bundling: {\n       bundlingFileAccess: BundlingFileAccess.VOLUME_COPY,\n   },\n});\n```\n"
   },
   "repository": {
     "directory": "packages/@aws-cdk/aws-lambda-go-alpha",
@@ -4409,6 +4409,6 @@
       "symbolId": "lib/types:ICommandHooks"
     }
   },
-  "version": "2.162.1-alpha.0",
+  "version": "2.163.1-alpha.0",
   "fingerprint": "**********"
 }

package/README.md

@@ -124,7 +124,7 @@ new go.GoFunction(this, 'handler', {
 
 ## Local Bundling
 
-If `Go` is installed locally and the version is >= `go1.11` then it will be used to bundle your code in your environment. Otherwise, bundling will happen in a [Lambda compatible Docker container](https://gallery.ecr.aws/sam/build-go1.x) with the Docker platform based on the target architecture of the Lambda function.
+If `Go` is installed locally and the version is >= `go1.11` then it will be used to bundle your code in your environment. Otherwise, bundling will happen in a [Lambda compatible Docker container](https://gallery.ecr.aws/sam/build-provided.al2023) with the Docker platform based on the target architecture of the Lambda function.
 
 For macOS the recommended approach is to install `Go` as Docker volume performance is really poor.
 

package/lib/Dockerfile

@@ -1,6 +1,6 @@
 # The correct AWS SAM build image based on the runtime of the function will be
 # passed as build arg. The default allows to do `docker build .` when testing.
-ARG IMAGE=public.ecr.aws/sam/build-go1.x
+ARG IMAGE=public.ecr.aws/sam/build-provided.al2023
 FROM $IMAGE
 
 # set the GOCACHE

package/lib/function.js

@@ -69,7 +69,7 @@ class GoFunction extends lambda.Function {
 }
 exports.GoFunction = GoFunction;
 _a = JSII_RTTI_SYMBOL_1;
-GoFunction[_a] = { fqn: "@aws-cdk/aws-lambda-go-alpha.GoFunction", version: "2.162.1-alpha.0" };
+GoFunction[_a] = { fqn: "@aws-cdk/aws-lambda-go-alpha.GoFunction", version: "2.163.1-alpha.0" };
 /**
  * The address of the Google Go proxy
  */

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aws-cdk/aws-lambda-go-alpha",
-  "version": "2.162.1-alpha.0",
+  "version": "2.163.1-alpha.0",
   "description": "The CDK Construct Library for AWS Lambda in Golang",
   "main": "lib/index.js",
   "types": "lib/index.d.ts",
@@ -77,18 +77,18 @@
   },
   "license": "Apache-2.0",
   "devDependencies": {
-    "@aws-cdk/cdk-build-tools": "2.162.1-alpha.0",
-    "@aws-cdk/integ-runner": "2.162.1-alpha.0",
-    "@aws-cdk/integ-tests-alpha": "2.162.1-alpha.0",
-    "@aws-cdk/pkglint": "2.162.1-alpha.0",
+    "@aws-cdk/cdk-build-tools": "2.163.1-alpha.0",
+    "@aws-cdk/integ-runner": "2.163.1-alpha.0",
+    "@aws-cdk/integ-tests-alpha": "2.163.1-alpha.0",
+    "@aws-cdk/pkglint": "2.163.1-alpha.0",
     "@types/jest": "^29.5.12",
-    "aws-cdk-lib": "2.162.1",
+    "aws-cdk-lib": "2.163.1",
     "constructs": "^10.0.0"
   },
   "dependencies": {},
   "homepage": "https://github.com/aws/aws-cdk",
   "peerDependencies": {
-    "aws-cdk-lib": "^2.162.1",
+    "aws-cdk-lib": "^2.163.1",
     "constructs": "^10.0.0"
   },
   "engines": {