Package Exports
- rust.aws-cdk-lambda
- rust.aws-cdk-lambda/dist/index.js
This package does not declare an exports field, so the exports above have been automatically detected and optimized by JSPM instead. If any package subpath is missing, it is recommended to post an issue to the original package (rust.aws-cdk-lambda) to support the "exports" field. If that is not possible, create a JSPM override to customize the exports field for this package.
Readme
Amazon Lambda Rust Library
This is an unofficial CDK library based on the Amazon Lambda Node.js and aws-lambda-rust Libraries.
It's intended for use with the new AWS CDK v2.
This library provides a construct for a Rust Lambda function.
It uses Docker and cross
under the hood, and follows best practices as outlined
in the official AWS documentation.
Rust Function
The RustFunction
construct creates a Lambda function with automatic bundling and compilation of Rust code.
Getting Started
Install the npm package:
$ npm i rust.aws-cdk-lambda
Use
cargo
to install rust-embedded/cross:$ cargo install cross
Install the x86_64-unknown-linux-musl toolchain with Rustup by running:
$ rustup target add x86_64-unknown-linux-musl
Finally, ensure you have Docker installed and running, as it will be used by cross
to compile Rust code for deployment.
Examples
You can find sample CDK apps built using Typescript or Node.js in the cdk-examples/ folder of the GitHub project repo.
Usage
First, import the construct:
import { RustFunction } from 'rust.aws-cdk-lambda';
Now define a RustFunction
:
new RustFunction(this, 'my-handler', {});
By default, the construct will use directory where cdk
was invoked as directory where Cargo files are located.
If no bin
or package
argument is passed in, it will default to the package name as defined in the main Cargo.toml
.
That is, the above usage should work for a project structure that looks like this:
.
├── Cargo.toml
└── src
└── main.rs
Alternatively, directory
and bin
can be specified:
new RustFunction(this, 'MyLambdaFunction', {
directory: '/path/to/directory/with/Cargo.toml',
// Optional
bin: 'my_lambda',
});
All other properties of lambda.Function
are supported, see also the AWS Lambda construct library.
How It Works
When bundling the code, the RustFunction
runs the following steps in order:
First it runs
cargo check
to confirm that the Rust code can compile. Note that this is an optional step, and can be disabled as mentioned below.Next it calls
cross build
, and passes in the--release
and--target
flags, so it compiles for a Lambda environment - which defaults to the x86_64-unknown-linux-musl target, as mentioned above.Finally, it copies the release app binary from the
target/
folder to a file namedbootstrap
, which the Lambda custom runtime environment looks for. It adds this new file under the build directory, which defaults to a.build/
folder under the directory wherecdk
was invoked.The directory path to the executable is then passed in to
lambda.Code.fromAsset
, which creates a zip file from the release binary asset.
Multiple Rust Lambdas
Assuming you have a CDK project with more than one Rust
lambda, there are a couple approaches - as outlined below -
that you can use to deploy with cdk
.
Multiple Binaries
Suppose your project layout looks like this:
.
├── Cargo.toml
└── src
└── bin
├── lambda1.rs
└── lambda2.rs
Here's one way to deploy that via cdk
:
new RustFunction(this, 'my-function-1', {
bin: 'lambda1',
});
new RustFunction(this, 'my-function-2', {
bin: 'lambda2',
});
You can find a more complete project structure in the rust-bins/ CDK sample project.
Multiple Packages
Suppose you use Workspaces in your Cargo project instead.
The full contents of the main Cargo.toml
would need to be updated
to look like this:
[workspace]
members = [
"lambda1",
"lambda2"
]
And your new project layout would now look similar to this:
.
├── Cargo.lock
├── Cargo.toml
├── lambda1
│ ├── Cargo.toml
│ └── src
│ ├── main.rs
│ └── utils.rs
└── lambda2
├── Cargo.toml
└── src
├── main.rs
└── utils.rs
Where the utils.rs
files are optional, but the point is that they can be imported by the lambda handler code in main.rs
if desired.
Now you will only need to update your CDK code to pass package
instead,
for each workspace member:
new RustFunction(this, 'MyFirstRustFunction', {
package: 'lambda1',
});
new RustFunction(this, 'MySecondRustFunction', {
package: 'lambda2',
});
You can find a more complete project structure in the rust-workspaces/ CDK sample project.
Rust Function Properties
Below lists some commonly used properties you can pass in to the RustFunction
construct.
Name | Description |
---|---|
target |
Build target to cross-compile to. Defaults to the target for Linux MUSL, x86_64-unknown-linux-musl . |
directory |
Entry point where the project's main Cargo.toml is located. By default, the construct will use directory where cdk was invoked as the directory where Cargo files are located. |
buildDir |
Default Build directory, which defaults to a .build folder under the project's root directory. |
bin |
Executable name to pass to --bin |
package |
Workspace package name to pass to --package |
setupLogging |
Determines whether we want to set up library logging - i.e. set the RUST_LOG environment variable - for the lambda function.The format defaults to warn,module_name=debug , which means that the default log level is warn , and the executable or library's log level is debug . |
Settings
Settings can be imported as follows:
import { Settings } from 'rust.aws-cdk-lambda';
Below are some useful global defaults which can be set for all Rust Lambda Functions in a CDK app.
Name | Description |
---|---|
BUILD_INDIVIDUALLY |
Whether to build each executable individually, either via --bin or --package . |
RUN_CARGO_CHECK |
Whether to run cargo check to validate Rust code before building it with cross . Defaults to true. |
DEFAULT_LOG_LEVEL |
Log Level for non-module libraries. Note that this value is only used when RustFunctionProps.setupLogging is enabled. Defaults to warn . |
MODULE_LOG_LEVEL |
Log Level for a module (i.e. the executable). Note that this value is only used when RustFunctionProps.setupLogging is enabled. Defaults to debug . |
workspace_dir |
Sets the root workspace directory. By default, the workspace directory is assumed to be the directory where cdk was invoked.This directory should contain at the minimum a Cargo.toml file which defines the workspace members. |