A Rust runtime for AWS Lambda


Rust Runtime for AWS Lambda

Build Status

This package makes it easy to run AWS Lambda Functions written in Rust. This workspace includes multiple crates:

  • Docs lambda-runtime is a library that provides a Lambda runtime for applications written in Rust.
  • Docs lambda-http is a library that makes it easy to write API Gateway proxy event focused Lambda functions in Rust.
  • Docs lambda-extension is a library that makes it easy to write Lambda Runtime Extensions in Rust.
  • Docs lambda-runtime-api-client is a shared library between the lambda runtime and lambda extension libraries that includes a common API client to talk with the AWS Lambda Runtime API.

Getting started

The easiest way to start writing Lambda functions with Rust is by using Cargo-Lambda. This Cargo subcommand provides several commands to help you in your journey with Rust on AWS Lambda.

You can install cargo-lambda with a package manager like Homebrew:

brew tap cargo-lambda/cargo-lambda
brew install cargo-lambda

Or by compiling it from source:

cargo install cargo-lambda

See other installation options in the cargo-lambda documentation.

Your first function

To create your first function, run cargo-lambda with the subcomand new. This command will generate a Rust package with the initial source code for your function:

cargo lambda new YOUR_FUNCTION_NAME

Example function

If you'd like to manually create your first function, the code below shows you a simple function that receives an event with a firstName field and returns a message to the caller.

use lambda_runtime::{service_fn, LambdaEvent, Error};
use serde_json::{json, Value};

async fn main() -> Result<(), Error> {
    let func = service_fn(func);

async fn func(event: LambdaEvent<Value>) -> Result<Value, Error> {
    let (event, _context) = event.into_parts();
    let first_name = event["firstName"].as_str().unwrap_or("world");

    Ok(json!({ "message": format!("Hello, {}!", first_name) }))

Building and deploying your Lambda functions

If you already have cargo-lambda installed in your machine, run the next command to build your function:

cargo lambda build --release

There are other ways of building your function: manually with the AWS CLI, with AWS SAM, and with the Serverless framework.

1. Cross-compiling your Lambda functions

By default, cargo-lambda builds your functions to run on x86_64 architectures. If you'd like to use a different architecture, use the options described below.

1.2. Build your Lambda functions

Amazon Linux 2

We recommend you to use Amazon Linux 2 runtimes (such as provided.al2) as much as possible for building Lambda functions in Rust. To build your Lambda functions for Amazon Linux 2 runtimes, run:

cargo lambda build --release --arm64

Amazon Linux 1

Amazon Linux 1 uses glibc version 2.17, while Rust binaries need glibc version 2.18 or later by default. However, with cargo-lambda, you can specify a different version of glibc.

If you are building for Amazon Linux 1, or you want to support both Amazon Linux 2 and 1, run:

# Note: replace "aarch64" with "x86_64" if you are building for x86_64
cargo lambda build --release --target aarch64-unknown-linux-gnu.2.17

2. Deploying the binary to AWS Lambda

For a custom runtime, AWS Lambda looks for an executable called bootstrap in the deployment package zip. Rename the generated executable to bootstrap and add it to a zip archive.

You can find the bootstrap binary for your function under the target/lambda directory.

2.2. Deploying with cargo-lambda

You can use cargo-lambda for simple function deployments. Once you've built your code with one of the options described earlier, use the deploy subcommand to upload your function to AWS:

cargo lambda deploy \
  --iam-role arn:aws:iam::XXXXXXXXXXXXX:role/your_lambda_execution_role

warning Make sure to replace the execution role with an existing role in your account!

This command will create a Lambda function with the same name of your rust package. You can change the name of the function by adding the argument at the end of the command:

cargo lambda deploy \
  --iam-role arn:aws:iam::XXXXXXXXXXXXX:role/your_lambda_execution_role \

info See other deployment options in the cargo-lambda documentation.

You can test the function with cargo-lambda's invoke subcommand:

cargo lambda invoke --remote \
  --data-ascii '{"command": "hi"}' \
  --output-format json \

2.2. Deploying with the AWS CLI

You can also use the AWS CLI to deploy your Rust functions. First, you will need to create a ZIP archive of your function. Cargo-lambda can do that for you automatically when it builds your binary if you add the output-format flag:

cargo lambda build --release --arm64 --output-format zip

You can find the resulting zip file in target/lambda/YOUR_PACKAGE/bootstrap.zip. Use that file path to deploy your function with the AWS CLI:

$ aws lambda create-function --function-name rustTest \
  --handler bootstrap \
  --zip-file fileb://./target/lambda/basic/bootstrap.zip \
  --runtime provided.al2 \ # Change this to provided.al if you would like to use Amazon Linux 1.
  --role arn:aws:iam::XXXXXXXXXXXXX:role/your_lambda_execution_role \
  --environment Variables={RUST_BACKTRACE=1} \
  --tracing-config Mode=Active

warning Make sure to replace the execution role with an existing role in your account!

You can now test the function using the AWS CLI or the AWS Lambda console

$ aws lambda invoke
  --cli-binary-format raw-in-base64-out \
  --function-name rustTest \
  --payload '{"command": "Say Hi!"}' \
$ cat output.json  # Prints: {"msg": "Command Say Hi! executed."}

Note: --cli-binary-format raw-in-base64-out is a required argument when using the AWS CLI version 2. More Information

2.3. AWS Serverless Application Model (SAM)

You can use Lambda functions built in Rust with the AWS Serverless Application Model (SAM). To do so, you will need to install the AWS SAM CLI, which will help you package and deploy your Lambda functions in your AWS account.

You will need to create a template.yaml file containing your desired infrastructure in YAML. Here is an example with a single Lambda function:

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31

    Type: AWS::Serverless::Function
      MemorySize: 128
      Architectures: ["arm64"]
      Handler: bootstrap
      Runtime: provided.al2
      Timeout: 5
      CodeUri: target/lambda/basic/

    Value: !Ref HelloWorldFunction
    Description: Name of the Lambda function

You can then deploy your Lambda function using the AWS SAM CLI:

sam deploy --guided

At the end, sam will output the actual Lambda function name. You can use this name to invoke your function:

$ aws lambda invoke
  --cli-binary-format raw-in-base64-out \
  --function-name HelloWorldFunction-XXXXXXXX \ # Replace with the actual function name
  --payload '{"command": "Say Hi!"}' \
$ cat output.json  # Prints: {"msg": "Command Say Hi! executed."}

2.4. Serverless Framework

Alternatively, you can build a Rust-based Lambda function declaratively using the Serverless framework Rust plugin.

A number of getting started Serverless application templates exist to get you up and running quickly:

  • a minimal echo function to demonstrate what the smallest Rust function setup looks like
  • a minimal http function to demonstrate how to interface with API Gateway using Rust's native http crate (note this will be a git dependency until 0.2 is published)
  • a combination multi function service to demonstrate how to set up a services with multiple independent functions

Assuming your host machine has a relatively recent version of node, you won't need to install any host-wide serverless dependencies. To get started, run the following commands to create a new lambda Rust application and install project level dependencies.

$ npx serverless install \
  --url https://github.com/softprops/serverless-aws-rust \
  --name my-new-app \
  && cd my-new-app \
  && npm install --silent

Deploy it using the standard serverless workflow:

# build, package, and deploy service to aws lambda
$ npx serverless deploy

Invoke it using serverless framework or a configured AWS integrated trigger source:

$ npx serverless invoke -f hello -d '{"foo":"bar"}'

2.5. Docker

Alternatively, you can build a Rust-based Lambda function in a docker mirror of the AWS Lambda provided runtime with the Rust toolchain preinstalled.

Running the following command will start an ephemeral docker container, which will build your Rust application and produce a zip file containing its binary auto-renamed to bootstrap to meet the AWS Lambda's expectations for binaries under target/lambda_runtime/release/{your-binary-name}.zip. Typically, this is just the name of your crate if you are using the cargo default binary (i.e. main.rs):

# build and package deploy-ready artifact
$ docker run --rm \
    -v ${PWD}:/code \
    -v ${HOME}/.cargo/registry:/root/.cargo/registry \
    -v ${HOME}/.cargo/git:/root/.cargo/git \

With your application build and packaged, it's ready to ship to production. You can also invoke it locally to verify is behavior using the lambci :provided docker container, which is also a mirror of the AWS Lambda provided runtime with build dependencies omitted:

# start a docker container replicating the "provided" lambda runtime
# awaiting an event to be provided via stdin
$ unzip -o \
    target/lambda/release/{your-binary-name}.zip \
    -d /tmp/lambda && \
  docker run \
    --rm \
    -v /tmp/lambda:/var/task \

# provide an event payload via stdin (typically a json blob)

# Ctrl-D to yield control back to your function

Local development and testing

Testing your code with unit and integration tests

AWS Lambda events are plain structures deserialized from JSON objects. If your function handler uses the standard runtime, you can use serde to deserialize your text fixtures into the structures, and call your handler directly:

fn test_my_lambda_handler() {
  let input = serde_json::from_str("{\"command\": \"Say Hi!\"}").expect("failed to parse event");
  let context = lambda_runtime::types::Context::default();

  let event = lambda_runtime::types::LambdaEvent::new(input, context);

  my_lambda_handler(event).expect("failed to handle event");

If you're using lambda_http to receive HTTP events, you can also create http_lambda::Request structures from plain text fixtures:

fn test_my_lambda_handler() {
  let input = include_str!("apigw_proxy_request.json");

  let request = lambda_http::request::from_str(input)
    .expect("failed to create request");

  let response = my_lambda_handler(request).expect("failed to handle request");

Cargo Lambda

Cargo Lambda provides a local server that emulates the AWS Lambda control plane. This server works on Windows, Linux, and MacOS. In the root of your Lambda project, run the subcommand cargo lambda start to start the server. Your function will be compiled when the server receives the first request to process. Use the subcommand cargo lambda invoke to send requests to your function. The start subcommand will watch your function's code for changes, and it will compile it every time you save the source after making changes.

You can read more about how cargo lambda start and cargo lambda invoke work on the project's README.

Lambda Debug Proxy

Lambdas can be run and debugged locally using a special Lambda debug proxy (a non-AWS repo maintained by @rimutaka), which is a Lambda function that forwards incoming requests to one AWS SQS queue and reads responses from another queue. A local proxy running on your development computer reads the queue, calls your Lambda locally and sends back the response. This approach allows debugging of Lambda functions locally while being part of your AWS workflow. The Lambda handler code does not need to be modified between the local and AWS versions.


lambda_runtime is a library for authoring reliable and performant Rust-based AWS Lambda functions. At a high level, it provides lambda_runtime::run, a function that runs a tower::Service<LambdaEvent>.

To write a function that will handle request, you need to pass it through service_fn, which will convert your function into a tower::Service<LambdaEvent>, which can then be run by lambda_runtime::run.

AWS event objects

This project does not currently include Lambda event struct definitions. Instead, the community-maintained aws_lambda_events crate can be leveraged to provide strongly-typed Lambda event structs. You can create your own custom event objects and their corresponding structs as well.

Custom event objects

To serialize and deserialize events and responses, we suggest using the serde library. To receive custom events, annotate your structure with Serde's macros:

use serde::{Serialize, Deserialize};
use serde_json::json;
use std::error::Error;

#[derive(Serialize, Deserialize)]
pub struct NewIceCreamEvent {
  pub flavors: Vec<String>,

#[derive(Serialize, Deserialize)]
pub struct NewIceCreamResponse {
  pub flavors_added_count: usize,

fn main() -> Result<(), Box<Error>> {
    let flavors = json!({
      "flavors": [

    let event: NewIceCreamEvent = serde_json::from_value(flavors)?;
    let response = NewIceCreamResponse {
        flavors_added_count: event.flavors.len(),


Supported Rust Versions (MSRV)

The AWS Lambda Rust Runtime requires a minimum of Rust 1.54, and is not guaranteed to build on compiler versions earlier than that.


See CONTRIBUTING for more information.


This project is licensed under the Apache-2.0 License.

  • Match error handling to other runtimes

    Match error handling to other runtimes

    The format of error messages returned by the runtime is hard to work with at the client end.


      "errorType": "alloc::boxed::Box<dyn std::error::Error+core::marker::Sync+core::marker::Send>",
      "errorMessage": "LambdaError { msg: \"cust error\", source: \"somewhere in code\", code: InvalidInput }"

    It is produced by this code in https://github.com/awslabs/aws-lambda-rust-runtime/blob/f40461785625d8ac23e7c248367b1d724ef2b5ba/lambda/src/lib.rs#L216

    Err(e) => EventErrorRequest {
                    diagnostic: Diagnostic {
                        error_message: format!("{:?}", e),
                        error_type: type_name_of_val(e).to_owned(),

    with help from

    fn type_name_of_val<T>(_: T) -> &'static str {

    Proposed change

    1. Log the error message, probably via error! so that it appears in CloudWatch.
    2. Serialise e into JSON instead of Debug output ({:?}).
    3. Allow to set error type and fall back on std::any::type_name if none was provided.

    Here are examples of what other runtimes are producing:

    • C#: https://docs.aws.amazon.com/lambda/latest/dg/csharp-exceptions.html
    • Go: https://docs.aws.amazon.com/lambda/latest/dg/golang-exceptions.html
    • Java: https://docs.aws.amazon.com/lambda/latest/dg/java-exceptions.html
    • NodeJS: https://docs.aws.amazon.com/lambda/latest/dg/nodejs-exceptions.html


    I'm not 100% sure how it all can be implemented yet. Just wondering if this is a problem that impacts others and is worth looking into.

    opened by rimutaka 35
  • /lib64/libc.so.6: version `GLIBC_2.18' not found

    /lib64/libc.so.6: version `GLIBC_2.18' not found

    I'm building the lambda on Ubuntu with the basic example you've provided in the README. It builds without any errors but if I upload and test it on aws in crashes with:

      "errorType": "Runtime.ExitError",
      "errorMessage": "RequestId: c24d34ab-f4a9-11e8-a9b7-d5cbfb363674 Error: Runtime exited with error: exit status 1"

    The log output is:

    START RequestId: c24d34ab-f4a9-11e8-a9b7-d5cbfb363674 Version: $LATEST
    /var/task/bootstrap: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by /var/task/bootstrap)
    END RequestId: c24d34ab-f4a9-11e8-a9b7-d5cbfb363674
    REPORT RequestId: c24d34ab-f4a9-11e8-a9b7-d5cbfb363674	Duration: 61.35 ms	Billed Duration: 100 ms 	Memory Size: 128 MB	Max Memory Used: 12 MB	
    RequestId: c24d34ab-f4a9-11e8-a9b7-d5cbfb363674 Error: Runtime exited with error: exit status 1
    opened by Dgame 34
  • Lambda with Async/Await

    Lambda with Async/Await

    This PR is a simplification of the Lambda Runtime for Rust. You can now write a Lambda function similar to the following:

    use lambda::lambda;
    use serde_json::Value;
    type Error = Box<dyn std::error::Error + Send + Sync + 'static>;
    async fn main(event: Value) -> Result<Value, Error> {
        let _ = lambda::context();

    These are the high-level changes:

    • Async/await is the primary interface within a Lambda function. While Lambda does not support concurrent invocations in a single container (concurrency is the responsibility of Lambda-the-service), async/await does allow for concurrent calls to other services.
    • Functions no longer need to return a LambdaError, as the the stabilization of std::any::type_name removed the need for a Lambda-specific error type.
    • Lambda functions can be created and started through the #[lambda] annotation. Note that starting a futures executor is still necessary. In the above example, this is handled through the #[tokio::main] macro.
    • The execution context is not an argument to the handler. Instead, it is a task-local, which is similar to a thread local, but specific to a future instead of a thread. The task local can be fetched through free function lambda::context().

    Advanced Usage

    The Handler Trait

    For greater control over a handler, this PR provides a Handler trait. It is defined as:

    pub trait Handler<A, B> {
        /// Errors returned by this handler.
        type Err;
        /// The future response value of this handler.
        type Fut: Future<Output = Result<B, Self::Err>>;
        /// Process the incoming event and return the response asynchronously.
        fn call(&mut self, event: A) -> Self::Fut;

    This is not implemented in this PR yet, but I'd like to provide a blanket implementation of tower::Service, which would provide compatibility with Tower's rich ecosystem of middleware. In particular, this would enable the use of tracing for rich logging and trace reporting.

    Without Macros

    For those that prefer to not make use of the #[lambda] macro, a Lambda function can be started with the following code:

    use lambda::handler_fn;
    type Error = Box<dyn std::error::Error + Send + Sync + 'static>;
    async fn main() -> Result<(), Error> {
        let func = handler_fn(func);
    async fn func(event: String) -> Result<String, Error> {

    Remaining Work

    For this PR to land, there are some additional bits of work needed:

    • Update documentation to show the usage of this runtime, especially some of the more advanced features.
    • Guide customers to only build against the x86_64-unknown-linux-musl target. The glibc in the Lambda execution environment is too old to run Rust executables.
    • Convert Executor::run (see lambda/src/lib.rs) to a stream so that Lambda functions can be easily unit-tested in-memory. By converting it to a stream, limiting execution via SteamExt::take or stream-cancel becomes much easier.
    • Provide examples (beyond this library's unit tests) of how to test a Lambda function.
    • Provide examples of using the runtime with tokio-compat and Rusoto, if Rusoto doesn't support async/await prior to this PR landing.
    • Figure out how to support http-based Lambdas through the #[lambda] macro. I think an attribute like #[lambda::http] dispatching to an Executor::run_http method is the best approach until specialization is stable.
    • Release tracing/AWS X-Ray integration.

    cc: @softprops @iliana @sapessi.

    opened by davidbarsky 30
  • State of release

    State of release

    Hey all, would it be possible to cut a release at the current master commit level or similar? As long as it's post #111 that should work.

    Coming in as a new user I was confused between the differing formats in the examples source and in the docs. It didn't help that the examples source (which is the correct way to do things) doesn't compile with the latest version of the crate. Once the dependency is renamed to lambda = { git = "https://github.com/awslabs/aws-lambda-rust-runtime/", branch = "master" } everything works for the new syntax.

    I can try and provide documentation and examples improvements PRs but if the maintainers could cut a release I think that'd go a long way to usability.

    enhancement question 
    opened by ajpauwels 29
  • Documentation for Various Lambda Use-Cases

    Documentation for Various Lambda Use-Cases

    I currently have a Lambda in Rust using the Python 3 binding using the excellent ilianaw/rust-crowbar crate.

    I also spent a lot of time creating internal serde mappings for various data types, but the majority of this work is on a private repository.

    What isn't clear here in the documentation is whether it's possible to catch all of the various use-cases that Lambdas can perform. My particular use case is using a Lambda for:

    My Lambda essentially acts as an event bus allowing me to do just about everything a typical web application would need to do, and it's awesome. I had to do a lot of very strange things to get a build environment that mimicked the official Lambda runtime environment, so it's cool to see that now it's possible to just build an entirely statically linked binary using musl :+1:

    What is not clear in the existing documentation is how to integrate all of these services inside of this new Rust-native Lambda runtime. Can I use a single Rust Lambda function to address all of the use cases listed above, or is this only for API Gateway endpoints?

    I've seen that in other issues, Tower is listed as a potential replacement for Hyper here, and that would be great! Basically I'd like to take advantage of native HTTP server libraries/frameworks for intelligent request routing and yet still be able to handle SNS/SES/CloudWatch/etc. events within the same Rust Lambda function. If all of this is possible, can the documentation be updated to reflect this and provide guidance on how to use it?

    opened by naftulikay 28
  • awkward HandlerError requirements

    awkward HandlerError requirements

    I'm finding that, in practice, the new HandlerError' type constraints may have made error handling hard/awkward to satisfy for users

    common cases I run into is trying to represent a foreign crate type for with lambda_runtime_errors::LambdaErrorExt. Since the Fail crate is becoming more common I think that's okay, but still rough if the foreign crates error type sticks to the standard library error type

    I find myself often cluttering map_err(HandlerError::new) code with this

    // I don't control the Err type of foo_bar as its defined in another crate
    // so I can't impl lambda_runtime_errors::LambdaErrorExt for ThatError { ... }
    foo_bar(input).map_err(HandlerError::new)? // fails to compile because no impl for lambda_runtime_errors::LambdaErrorExt

    This is unfortunate for users because often these are simple hello world integrate xxx with lambda cases where the majority of the code written is satisfying the trait constraints on errors and not the code what brings business value.

    I understand why this constraint exists but I want to revisit the value for users this is providing vs what its costing to author lambdas.

    I've ran into this enough that I wanted to reopen the floor for alternative options.

    opened by softprops 25
  • avoid static lifetime requirement for handler functions

    avoid static lifetime requirement for handler functions

    I would like to remove the requirement of having 'static bounds on the handler generics if possible. This would make it easier to pass in shared resources that have been setup/created before creating the handler and avoid a bunch of cloning.

    It seems like a tokio::spawn is used to produce a future here: https://github.com/awslabs/aws-lambda-rust-runtime/blob/d3ff4352c4b0e64fb46af2ca425db39211237e26/lambda-runtime/src/lib.rs#L160-L162

    By taking a guess, I would assume that the reason is to catch a panic when generating the future (the JoinHandle is immediately awaited and nothing else seems to be going on). I might very well be wrong here, so if the reason for using a tokio::spawn has to do with something else, please correct me.

    Since tokio::spawn requires both the future and the output to be 'static, all the handler generics needs to be bounded by 'static. This makes it quite cumbersome to use shared resources. Consider:

    let client = SharedClient::try_from("Shared Client 1 (perhaps a database)")?;
    let client_ref = &client;
    lambda_runtime::run(handler_fn(|event: Request, ctx: Context| async move {
        let command = event.command;
        Ok::<Response, Error>(client_ref.response(ctx.request_id, command))

    This would not compile, as client_ref is not 'static. To me it would make sense if you were able to do some initial setup (e.g. database clients/initializing env-configs etc) before calling run.

    I was thinking it would be possible to remove the static requirements by removing tokio::spawn? Perhaps it can be replaced with a catch_unwind?

    I have been experimenting a bit here (I added an example as well): https://github.com/rasviitanen/aws-lambda-rust-runtime/commit/9f9b6746f89eda39f95b149c8fca699c4bcd1203 Would this work or would it result in other problems I have not considered?

    PS great work on the 0.3 release! :)

    opened by rasviitanen 21
  • Added error handling for #241, interim, broken

    Added error handling for #241, interim, broken

    Issue #, if available: #241, relates to PR #242

    Description of changes:

    Added my changes from #242 on top of David's changes in this branch.

    1. The build is broken - lambda-http examples fail to compile.
    2. The lambda examples (basic, hello, etc) compile, run, but return an error as a result and DO NOT LOG ANYTHING at all.

    For example, hello-without-macro-tracing.rs has these 2 lines:


    so it should at least log Hello. It doesn't.

    This line returns an error for a test: Err(simple_error::SimpleError::new("simple error").into()).


      "errorType": "&alloc::boxed::Box<dyn std::error::Error+core::marker::Sync+core::marker::Send>",
      "errorMessage": "simple error"

    Trace in CloudWatch:

    START RequestId: 01e6ec13-33c2-40a7-b467-a37b1cbc17f0 Version: $LATEST
     TRACE hyper::proto::h1::conn: Conn::read_head
     DEBUG hyper::proto::h1::io: read 444 bytes
     TRACE hyper::proto::h1::role: Response.parse([Header; 100], [u8; 444])
     TRACE hyper::proto::h1::role: Response.parse Complete(418)
     DEBUG hyper::proto::h1::io: parsed 7 headers
     DEBUG hyper::proto::h1::conn: incoming body is content-length (26 bytes)
     TRACE hyper::proto::h1::decode: decode; state=Length(26)
     DEBUG hyper::proto::h1::conn: incoming body completed
     TRACE hyper::proto::h1::conn: maybe_notify; read_from_io blocked
     TRACE want: signal: Want    
     TRACE hyper::proto::h1::conn: flushed({role=client}): State { reading: Init, writing: Init, keep_alive: Idle }
     TRACE want: signal: Want    
     TRACE hyper::proto::h1::conn: flushed({role=client}): State { reading: Init, writing: Init, keep_alive: Idle }
     TRACE hyper::client::pool: put; add idle connection for ("http",
     DEBUG hyper::client::pool: pooling idle connection for ("http",
     TRACE want: signal: Want    
     TRACE hyper::proto::h1::conn: flushed({role=client}): State { reading: Init, writing: Init, keep_alive: Idle }
     TRACE hyper::client::pool: take? ("http", expiration = Some(90s)
     DEBUG hyper::client::pool: reuse idle connection for ("http",
     TRACE hyper::proto::h1::role: Client::encode method=POST, body=Some(Known(125))
     DEBUG hyper::proto::h1::io: flushed 306 bytes
     TRACE hyper::proto::h1::conn: flushed({role=client}): State { reading: Init, writing: KeepAlive, keep_alive: Busy }
     TRACE hyper::proto::h1::conn: Conn::read_head
     DEBUG hyper::proto::h1::io: read 130 bytes
     TRACE hyper::proto::h1::role: Response.parse([Header; 100], [u8; 130])
     TRACE hyper::proto::h1::role: Response.parse Complete(114)
     DEBUG hyper::proto::h1::io: parsed 3 headers
     DEBUG hyper::proto::h1::conn: incoming body is content-length (16 bytes)
     TRACE hyper::proto::h1::decode: decode; state=Length(16)
     DEBUG hyper::proto::h1::conn: incoming body completed
     TRACE hyper::proto::h1::conn: maybe_notify; read_from_io blocked
     TRACE want: signal: Want    
     TRACE hyper::proto::h1::conn: flushed({role=client}): State { reading: Init, writing: Init, keep_alive: Idle }
     TRACE want: signal: Want    
     TRACE hyper::proto::h1::conn: flushed({role=client}): State { reading: Init, writing: Init, keep_alive: Idle }
     TRACE hyper::client::pool: put; add idle connection for ("http",
     DEBUG hyper::client::pool: pooling idle connection for ("http",
     TRACE want: signal: Want    
     TRACE hyper::proto::h1::conn: flushed({role=client}): State { reading: Init, writing: Init, keep_alive: Idle }
     TRACE hyper::proto::h1::dispatch: client tx closed
     TRACE hyper::proto::h1::conn: State::close_read()
     TRACE hyper::proto::h1::conn: State::close_write()
     TRACE hyper::proto::h1::conn: flushed({role=client}): State { reading: Closed, writing: Closed, keep_alive: Disabled }
     TRACE hyper::proto::h1::conn: shut down IO complete
     TRACE mio::poll: deregistering handle with poller    
     TRACE want: signal: Closed    
     TRACE hyper::client::pool: pool closed, canceling idle interval
    END RequestId: 01e6ec13-33c2-40a7-b467-a37b1cbc17f0
    REPORT RequestId: 01e6ec13-33c2-40a7-b467-a37b1cbc17f0	Duration: 39.60 ms	Billed Duration: 100 ms	Memory Size: 128 MB	Max Memory Used: 34 MB	Init Duration: 39.10 ms	
    Unknown application error occurred

    As you can see, neither info!("Hello!") nor simple error messages are there.

    I am not sure what other changes are intended for lib.rs and what state it is in, so it's better if @davidbarsky takes a look first.


    1. Make it compile
    2. Retest all examples
    3. Update examples/README.md with the new input/output
    4. Explain the relationship between LOG and TRACING in the readme.

    By submitting this pull request

    • [x] I confirm that my contribution is made under the terms of the Apache 2.0 license.
    • [x] I confirm that I've made a best effort attempt to update all relevant documentation.
    opened by rimutaka 21
  • Panic at 'Could not retrieve next event'

    Panic at 'Could not retrieve next event'

    I thought maybe it was something in my code but I get the same panic with the example here: https://docs.rs/crate/lambda_runtime/0.2.0

    START RequestId: 967aad3f-eaaa-4946-bc51-dc717f81aa71 Version: $LATEST
    thread 'main' panicked at 'Could not retrieve next event', /Users/redacted/.cargo/registry/src/github.com-1ecc6299db9ec823/lambda_runtime_core-0.1.0/src/runtime.rs:266:17
    stack backtrace:
       0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
                 at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
       1: std::sys_common::backtrace::_print
                 at src/libstd/sys_common/backtrace.rs:71
       2: std::panicking::default_hook::{{closure}}
                 at src/libstd/sys_common/backtrace.rs:59
                 at src/libstd/panicking.rs:211
       3: std::panicking::default_hook
                 at src/libstd/panicking.rs:227
       4: std::panicking::rust_panic_with_hook
                 at src/libstd/panicking.rs:491
       5: std::panicking::begin_panic
       6: <lambda_runtime_core::runtime::Runtime<Function, EventError>>::get_next_event
       7: <lambda_runtime_core::runtime::Runtime<Function, EventError>>::get_next_event
       8: <lambda_runtime_core::runtime::Runtime<Function, EventError>>::get_next_event
       9: <lambda_runtime_core::runtime::Runtime<Function, EventError>>::get_next_event
      10: <lambda_runtime_core::runtime::Runtime<Function, EventError>>::get_next_event
      11: lambda_runtime_core::runtime::start_with_config
      12: bootstrap::main
      13: std::rt::lang_start::{{closure}}
      14: std::panicking::try::do_call
                 at src/libstd/rt.rs:59
                 at src/libstd/panicking.rs:310
      15: __rust_maybe_catch_panic
                 at src/libpanic_unwind/lib.rs:102
      16: std::rt::lang_start_internal
                 at src/libstd/panicking.rs:289
                 at src/libstd/panic.rs:398
                 at src/libstd/rt.rs:58
      17: main
    END RequestId: 967aad3f-eaaa-4946-bc51-dc717f81aa71
    REPORT RequestId: 967aad3f-eaaa-4946-bc51-dc717f81aa71	Duration: 1050.16 ms	Billed Duration: 1100 ms 	Memory Size: 128 MB	Max Memory Used: 26 MB	
    RequestId: 967aad3f-eaaa-4946-bc51-dc717f81aa71 Error: Runtime exited with error: exit status 101
    opened by LeakyBucket 18
  • async support

    async support

    Issue #14

    The main loop has been converted into a future::LoopFn, who takes ownership on the Runtime. Now it is possible to use async code inside lambdas.

    By submitting this pull request

    • [X] I confirm that my contribution is made under the terms of the Apache 2.0 license.
    • [X] I confirm that I've made a best effort attempt to update all relevant documentation.
    opened by nappa85 17
  • async support

    async support

    Given that the runtime is built on top of tokio, I think it would be useful to be able to provide async handler functions.

    Happy to contribute this if there is interest from your side!

    EDIT: Support for tower via the tower-service crate could also be interesting.

    opened by srijs 17
  • Check body length limits to avoid memory overflow

    Check body length limits to avoid memory overflow

    We use hyper::body::to_bytes in a few places to read incoming requests.

    In theory, if we don't check the size of the body, it's possible to cause memory overflow issues on the Lambda execution. In reality, each execution is sandboxed, so there is no real impact for these kind of attacks beyond the current request.

    I wonder if there's any reasonable change that could improve the code here, or even if it's necessary.

    Reference: https://docs.rs/hyper/latest/hyper/body/fn.to_bytes.html#note

    opened by calavera 0
  • [RFC] Macro for generating multiple ZIPs for multiple handlers

    [RFC] Macro for generating multiple ZIPs for multiple handlers

    It is a best practice to have a Lambda function be single-purpose and to stitch multiple functions together to compose a larger application. That makes each Lambda function more easy to implement, test, scale, and operate. I imagine that most users adopting this best practice still want to write a single package with several contained functions, for instance with multiple APIs that make up a service.

    Today the user of this crate has to write multiple main methods/files to achieve this. And each of those main methods will do lots of the same stuff - set up logging, initialize static dependencies, fetch creds, and ultimately set up the runtime with a handler method. To encourage Rust runtime users to adopt this best practice, I propose a macro that automates some of this.

    Not exactly sure how this would work or what the developer experience would be, but throwing this out as an initial proposal for comment:

    use lambda_http::{run, service_fn, Body, Error, Request, Response};
    /// The handler for an HTTP GET
    async fn get_handler(_event: Request) -> Result<Response<Body>, Error> {
        let resp = Response::builder()
            .header("content-type", "text/html")
            .body("Hello GET request".into())
    /// The handler for an HTTP PUT
    async fn put_handler(_event: Request) -> Result<Response<Body>, Error> {
        let resp = Response::builder()
            .header("content-type", "text/html")
            .body("Hello PUT request".into())
    /// The `main_multifunction` macro will generate multiple main methods (perhaps in their own modules?), one per declared
    /// handler.  For each it will insert the shared code in the main method below and will pass in the associated handler as the
    /// `handler` argument.  This way the developer can share common setup code and doesn't have to rewrite the main method
    /// N times.
    async fn main(handler: impl Fn(LambdaEvent<A>) -> Fut) -> Result<(), Error> {
    opened by greenwoodcm 3
  • Confused about documentation

    Confused about documentation

    Hello, I was preparing a lambda function in rust using this runtime but I found a difference between the readme in this project and the documentation by aws at (https://docs.aws.amazon.com/sdk-for-rust/latest/dg/lambda.html). The readme suggests the use of the service_fn function while the aws docs make use of the handler_fn function.

    Can you please explain which is the best way? Thanks, Frank

    opened by franksl 2
  • Headers (User-Agent) containing non UTF-8 are not well handled (502 http error)

    Headers (User-Agent) containing non UTF-8 are not well handled (502 http error)

    In one of my projects, created ages ago (prior to going async) I could handle the issue by myself:

    use lambda_http::{
      Body, Request, Response,
    // snipped
        // Call handler function based on path
        fn run(&self, req: Request, ctx: Context) -> Result<Response<Body>, Error> {
            let user_agent = req
                .map_or("(no user agent)", |ua| {
                    ua.to_str().unwrap_or("(non utf-8 user-agent)")

    I could then handle bad headers by simply ignoring them or return a 400 status code.

    I should and will upgrade my code to version 0.6.0 but I can check that this is failing still in lambda_runtime even before it is made available for my code.


      "requestContext": {
          "elb": {
              "targetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/my-target-group/6d0ecf831eec9f09"
      "httpMethod": "OPTIONS",
      "path": "",
      "queryStringParameters": {},
      "headers": {
          "accept": "application/json",
          "content-type": "application/json",
          "host": "my-app-287742195.eu-west-3.elb.amazonaws.com:443",
          "user-agent": "Beno\xEEt's User-Agent",
          "x-amzn-trace-id": "Root=1-5bdb40ca-556d8b0c50dc66f0511bf520",
          "x-forwarded-for": "",
          "x-forwarded-port": "443",
          "x-forwarded-proto": "https",
          "origin": "example.com"
      "isBase64Encoded": false,
      "body": ""

    Testing the above payload gives the error:

    cargo lambda start &
    cargo lambda invoke --data-file test.json
    Error: Error("invalid escape", line: 14, column: 27)
    [Finished running. Exit status: 1]

    I could check the same behavior on a real lambda instance to which I sent an actual request and not a crafted payload as above.

    curl https://example.com/myaws-fsafs/test --header "User-Agent: Beno`echo -ne '\xEE'`t's User-Agent"
    help wanted 
    opened by bburnichon 11
  • v0.7.2(Jan 3, 2023)

    What's Changed

    • Added IntoResponse implementation for (StatusCode, IntoResponse) by @mustafasegf in https://github.com/awslabs/aws-lambda-rust-runtime/pull/573
    • Add tracing span with request id to the handler by @llgerard in https://github.com/awslabs/aws-lambda-rust-runtime/pull/577
    • make RequestContext serializable by @bnusunny in https://github.com/awslabs/aws-lambda-rust-runtime/pull/578
    • Release version 0.7.2 by @calavera in https://github.com/awslabs/aws-lambda-rust-runtime/pull/579

    New Contributors

    • @mustafasegf made their first contribution in https://github.com/awslabs/aws-lambda-rust-runtime/pull/573
    • @llgerard made their first contribution in https://github.com/awslabs/aws-lambda-rust-runtime/pull/577

    Full Changelog: https://github.com/awslabs/aws-lambda-rust-runtime/compare/v0.7.1-runtime...v0.7.2

    Source code(tar.gz)
    Source code(zip)
  • v0.7.1-lambda-http(Oct 28, 2022)

    What's Changed

    • Dedicated README for lambda_http by @ymwjbxxq in https://github.com/awslabs/aws-lambda-rust-runtime/pull/554
    • add x-ray trace id header in lambda-http by @twu-AWS in https://github.com/awslabs/aws-lambda-rust-runtime/pull/557
    • Bump patch version of lambda-http by @ysaito1001 in https://github.com/awslabs/aws-lambda-rust-runtime/pull/556

    New Contributors

    • @ymwjbxxq made their first contribution in https://github.com/awslabs/aws-lambda-rust-runtime/pull/554
    • @twu-AWS made their first contribution in https://github.com/awslabs/aws-lambda-rust-runtime/pull/557
    • @ysaito1001 made their first contribution in https://github.com/awslabs/aws-lambda-rust-runtime/pull/556

    Full Changelog: https://github.com/awslabs/aws-lambda-rust-runtime/compare/v0.7.0...v0.7.1-lambda-http

    Source code(tar.gz)
    Source code(zip)
  • v0.7.0(Oct 12, 2022)

    What's Changed

    • Check that lambda_https inner service is ready before calling it by @dcormier in https://github.com/awslabs/aws-lambda-rust-runtime/pull/538
    • Re-export external modules of publicly used types by @dcormier in https://github.com/awslabs/aws-lambda-rust-runtime/pull/542
    • Decode query paramters for ALB event source by @bnusunny in https://github.com/awslabs/aws-lambda-rust-runtime/pull/545
    • Update MSRV to 1.62 by @calavera in https://github.com/awslabs/aws-lambda-rust-runtime/pull/544
    • Updated aws_lambda_events dependency by @dcormier in https://github.com/awslabs/aws-lambda-rust-runtime/pull/541
    • Allow Adapter to be .boxed() by @dcormier in https://github.com/awslabs/aws-lambda-rust-runtime/pull/540

    New Contributors

    • @dcormier made their first contribution in https://github.com/awslabs/aws-lambda-rust-runtime/pull/538

    Full Changelog: https://github.com/awslabs/aws-lambda-rust-runtime/compare/v0.6.1...v0.7.0

    Source code(tar.gz)
    Source code(zip)
  • v0.6.2-lambda-http(Oct 6, 2022)

    What's Changed

    • Treat XML MIME type responses as text by @calavera in https://github.com/awslabs/aws-lambda-rust-runtime/pull/532
    • Add custom response header to force text encoding by @calavera in https://github.com/awslabs/aws-lambda-rust-runtime/pull/533
    • Treat YAML MIME type responses as text by @calavera in https://github.com/awslabs/aws-lambda-rust-runtime/pull/535

    Full Changelog: https://github.com/awslabs/aws-lambda-rust-runtime/compare/v0.6.1...v0.6.2-lambda-http

    Source code(tar.gz)
    Source code(zip)
  • v0.6.1(Sep 7, 2022)

    What's Changed

    • Fix paths with spaces in HTTP requests. by @calavera in https://github.com/awslabs/aws-lambda-rust-runtime/pull/516
    • Report error when we cannot deserialize the payload. by @calavera in https://github.com/awslabs/aws-lambda-rust-runtime/pull/520
    • Add with_request_context to RequestExt by @sgasse in https://github.com/awslabs/aws-lambda-rust-runtime/pull/523
    • Adding functionality to catch panics that occur both inside the runtime handler and in the Future it returns by @fermanjj in https://github.com/awslabs/aws-lambda-rust-runtime/pull/521

    New Contributors

    • @johan-smits made their first contribution in https://github.com/awslabs/aws-lambda-rust-runtime/pull/507
    • @greenwoodcm made their first contribution in https://github.com/awslabs/aws-lambda-rust-runtime/pull/511
    • @sgasse made their first contribution in https://github.com/awslabs/aws-lambda-rust-runtime/pull/524
    • @fermanjj made their first contribution in https://github.com/awslabs/aws-lambda-rust-runtime/pull/521

    Full Changelog: https://github.com/awslabs/aws-lambda-rust-runtime/compare/v0.6.0...v0.6.1

    Source code(tar.gz)
    Source code(zip)
  • v0.6.0(Jul 19, 2022)

    Breaking changes

    • Update Rust edition to 2021 in all crates: The minimum supported Rust version is 1.58.1
    • lambda-http: accept http_body::Body in responses

    What's Changed

    • Use raw_query_string to populate QueryStringParameters by @calavera in https://github.com/awslabs/aws-lambda-rust-runtime/pull/483
    • Reduce dependency features by @calavera in https://github.com/awslabs/aws-lambda-rust-runtime/pull/486
    • Ignore hosts from ALB health checks when they are not present by @calavera in https://github.com/awslabs/aws-lambda-rust-runtime/pull/495
    • Feature flags for lambda_http by @calavera in https://github.com/awslabs/aws-lambda-rust-runtime/pull/497
    • feat(lambda-http): accept http_body::Body in responses by @hugobast in https://github.com/awslabs/aws-lambda-rust-runtime/pull/491
    • Update Rust edition to 2021 by @calavera in https://github.com/awslabs/aws-lambda-rust-runtime/pull/501

    New Contributors

    • @lazear made their first contribution in https://github.com/awslabs/aws-lambda-rust-runtime/pull/437
    • @lukepfeiffer10 made their first contribution in https://github.com/awslabs/aws-lambda-rust-runtime/pull/464
    • @epompeii made their first contribution in https://github.com/awslabs/aws-lambda-rust-runtime/pull/477
    • @ZackKanter made their first contribution in https://github.com/awslabs/aws-lambda-rust-runtime/pull/485
    • @hugobast made their first contribution in https://github.com/awslabs/aws-lambda-rust-runtime/pull/491

    Full Changelog: https://github.com/awslabs/aws-lambda-rust-runtime/compare/v0.5.1...v0.6.0

    Source code(tar.gz)
    Source code(zip)
  • v0.5.2-lambda-http(May 9, 2022)

    What's Changed

    • Expose the raw http path coming from the lambda event. by @calavera in https://github.com/awslabs/aws-lambda-rust-runtime/pull/453
    • allow customized User_Agent for lambda runtime api client by @bnusunny in https://github.com/awslabs/aws-lambda-rust-runtime/pull/454
    • Document option to run functions locally. by @calavera in https://github.com/awslabs/aws-lambda-rust-runtime/pull/460
    • Fixed invalid architectures reference in the SAM snippet (#1) by @lukepfeiffer10 in https://github.com/awslabs/aws-lambda-rust-runtime/pull/464

    New Contributors

    • @lukepfeiffer10 made their first contribution in https://github.com/awslabs/aws-lambda-rust-runtime/pull/464

    Full Changelog: https://github.com/awslabs/aws-lambda-rust-runtime/compare/v0.5.1-runtime...v0.5.2-lambda-http

    Source code(tar.gz)
    Source code(zip)
  • v0.5.1-runtime(Mar 20, 2022)

    What's Changed

    • Call handler.poll_ready() before handler.call() by @lazear in https://github.com/awslabs/aws-lambda-rust-runtime/pull/437
    • Relax Send constraint in lambda-http by @fmonniot in https://github.com/awslabs/aws-lambda-rust-runtime/pull/442

    New Contributors

    • @lazear made their first contribution in https://github.com/awslabs/aws-lambda-rust-runtime/pull/437

    Full Changelog: https://github.com/awslabs/aws-lambda-rust-runtime/compare/v0.5.1...v0.5.1-runtime

    Source code(tar.gz)
    Source code(zip)
  • v0.5.1(Feb 26, 2022)

    What's Changed

    • Fix issue parsing WebSocket requests. by @calavera in https://github.com/awslabs/aws-lambda-rust-runtime/pull/433

    Full Changelog: https://github.com/awslabs/aws-lambda-rust-runtime/compare/v0.5.0...v0.5.1

    Source code(tar.gz)
    Source code(zip)
  • v0.5.0(Feb 20, 2022)

    Noteworthy changes


    • Remove Send bound in http's Handler by @fmonniot in https://github.com/awslabs/aws-lambda-rust-runtime/pull/344
    • fix: use correct name of lambda_runtime example by @Velfi in https://github.com/awslabs/aws-lambda-rust-runtime/pull/352
    • Remove seemingly unnecessary Req -> Parts -> Req conversion by @simonvandel in https://github.com/awslabs/aws-lambda-rust-runtime/pull/353
    • build: BREAKING CHANGE: upgrade tracing-[error|subscriber] by @seanpianka in https://github.com/awslabs/aws-lambda-rust-runtime/pull/358
    • Fixed cargo clippy warnings by @coltonweaver in https://github.com/awslabs/aws-lambda-rust-runtime/pull/359
    • make handler reference mutable by @Mdrbhatti in https://github.com/awslabs/aws-lambda-rust-runtime/pull/356
    • Expanded README on how to build for Amazon Linux 2 x86 or ARM, includ… by @coltonweaver in https://github.com/awslabs/aws-lambda-rust-runtime/pull/360
    • feat: inject user agent in Lambda runtime API calls by @nmoutschen in https://github.com/awslabs/aws-lambda-rust-runtime/pull/363
    • LambdaRequest lifetime fix by @jelmansouri in https://github.com/awslabs/aws-lambda-rust-runtime/pull/364
    • fix: null deserialization of stageVariables for sam local by @nmoutschen in https://github.com/awslabs/aws-lambda-rust-runtime/pull/366
    • fix: create a valid URL for REST APIs and ALBs when the host header i… by @nmoutschen in https://github.com/awslabs/aws-lambda-rust-runtime/pull/369
    • Removed references to type Error aliases in docs by @rimutaka in https://github.com/awslabs/aws-lambda-rust-runtime/pull/370
    • fix: add support for null/invalid type for headers by @nmoutschen in https://github.com/awslabs/aws-lambda-rust-runtime/pull/371
    • Lambda Extensions by @calavera in https://github.com/awslabs/aws-lambda-rust-runtime/pull/376
    • Remove unused dependencies by @calavera in https://github.com/awslabs/aws-lambda-rust-runtime/pull/381
    • fix: cargo fmt fix by @nmoutschen in https://github.com/awslabs/aws-lambda-rust-runtime/pull/378
    • feat: add integration tests stack by @nmoutschen in https://github.com/awslabs/aws-lambda-rust-runtime/pull/379
    • chore: stable fmt and clippy, set MSRV by @nmoutschen in https://github.com/awslabs/aws-lambda-rust-runtime/pull/383
    • fix: add client context and cognito identity to runtime context by @diceride in https://github.com/awslabs/aws-lambda-rust-runtime/pull/382
    • README.md: invoke lambda function with raw-in-base64-out by @david-perez in https://github.com/awslabs/aws-lambda-rust-runtime/pull/385
    • README.md: add newline to end of file by @david-perez in https://github.com/awslabs/aws-lambda-rust-runtime/pull/386
    • fix: add support for null/invalid type for multi-value-headers by @mbergkvist in https://github.com/awslabs/aws-lambda-rust-runtime/pull/387
    • fix: move clippy::cargo lint to warn level by @bahildebrand in https://github.com/awslabs/aws-lambda-rust-runtime/pull/388
    • Change examples to use tracing-subscriber for logging by @bahildebrand in https://github.com/awslabs/aws-lambda-rust-runtime/pull/389
    • Allow base paths in the runtime api uri by @calavera in https://github.com/awslabs/aws-lambda-rust-runtime/pull/393
    • Wrap incoming extension events in a struct by @calavera in https://github.com/awslabs/aws-lambda-rust-runtime/pull/394
    • Fix request query strings by @calavera in https://github.com/awslabs/aws-lambda-rust-runtime/pull/395
    • Added some missing fields to ApiGateway and ApiGatewayRequestContext by @vascokk in https://github.com/awslabs/aws-lambda-rust-runtime/pull/403
    • Implement tower::Service trait by @nmoutschen in https://github.com/awslabs/aws-lambda-rust-runtime/pull/401
    • feat(lambda-http): implement http_body::Body for lambda_http::body by @nmoutschen in https://github.com/awslabs/aws-lambda-rust-runtime/pull/406
    • docs(lambda-extension): update README by @nmoutschen in https://github.com/awslabs/aws-lambda-rust-runtime/pull/408
    • run lambda_runtime inside Lambda Extensions by @bnusunny in https://github.com/awslabs/aws-lambda-rust-runtime/pull/411
    • feat(lambda-extension): Logs API processor by @nmoutschen in https://github.com/awslabs/aws-lambda-rust-runtime/pull/416
    • Make errors implement Debug+Display by @calavera in https://github.com/awslabs/aws-lambda-rust-runtime/pull/418
    • feat(lambda-extension): make errors implement Debug+Display by @nmoutschen in https://github.com/awslabs/aws-lambda-rust-runtime/pull/419
    • chore: bump version to 0.5 by @nmoutschen in https://github.com/awslabs/aws-lambda-rust-runtime/pull/420
    • feat(lambda-http): add example with tower_http crate by @nmoutschen in https://github.com/awslabs/aws-lambda-rust-runtime/pull/425
    • Replace custom http events with aws_lambda_events by @calavera in https://github.com/awslabs/aws-lambda-rust-runtime/pull/426
    • Remove reference to unmaintained repository by @calavera in https://github.com/awslabs/aws-lambda-rust-runtime/pull/427
    • docs: revamp build & deployment section by @nmoutschen in https://github.com/awslabs/aws-lambda-rust-runtime/pull/428
    • fixes following v0.5.0 releases by @nmoutschen in https://github.com/awslabs/aws-lambda-rust-runtime/pull/429

    New Contributors

    • @fmonniot made their first contribution in https://github.com/awslabs/aws-lambda-rust-runtime/pull/344
    • @Velfi made their first contribution in https://github.com/awslabs/aws-lambda-rust-runtime/pull/352
    • @simonvandel made their first contribution in https://github.com/awslabs/aws-lambda-rust-runtime/pull/353
    • @seanpianka made their first contribution in https://github.com/awslabs/aws-lambda-rust-runtime/pull/358
    • @Mdrbhatti made their first contribution in https://github.com/awslabs/aws-lambda-rust-runtime/pull/356
    • @jelmansouri made their first contribution in https://github.com/awslabs/aws-lambda-rust-runtime/pull/364
    • @calavera made their first contribution in https://github.com/awslabs/aws-lambda-rust-runtime/pull/376
    • @diceride made their first contribution in https://github.com/awslabs/aws-lambda-rust-runtime/pull/382
    • @david-perez made their first contribution in https://github.com/awslabs/aws-lambda-rust-runtime/pull/385
    • @mbergkvist made their first contribution in https://github.com/awslabs/aws-lambda-rust-runtime/pull/387
    • @vascokk made their first contribution in https://github.com/awslabs/aws-lambda-rust-runtime/pull/403

    Full Changelog: https://github.com/awslabs/aws-lambda-rust-runtime/compare/v0.4.1...v0.5.0

    Source code(tar.gz)
    Source code(zip)
  • v0.4.1(Sep 8, 2021)

  • v0.3.1(Aug 5, 2021)


    • Removal of the 'static lifetime bound requirements on both lambda-http and lambda-runtime to allow for shared resources that exist in between invocations that land on the same Lambda Sandbox. See: https://github.com/awslabs/aws-lambda-rust-runtime/pull/333 and https://github.com/awslabs/aws-lambda-rust-runtime/pull/319
    • Addition of default header handling that was breaking local SAM CLI testing. See: https://github.com/awslabs/aws-lambda-rust-runtime/pull/332
    Source code(tar.gz)
    Source code(zip)
  • v0.3.0(Mar 12, 2021)


    New: Almost everything!

    • Heavy restructuring was done in order to simplify the runtime and to enable asynchronous handlers by default.

    • The lambda crate has been renamed to lambda_runtime, and the original lambda_runtime has been removed from the project. lambda_http remains the same.

    • The lambda_http crate now supports API Gateway HTTP API Lambda triggers.

    • Both lambda_runtime and lambda_http have noteworthy, breaking API changes. The following is a rough approximation of what a transition to the new runtime API will be:

      note: the runtime is based on std::future::Future based and relies on Tokio via Hyper.


      -use lambda_runtime::{error::HandlerError, lambda, Context};
      +use lambda_runtime::{handler_fn, Context};
      use serde_json::Value;
      +type Error = Box<dyn std::error::Error + Sync + Send + 'static>;
      -fn main() {
      -    lambda!(handler)
      +async fn main() -> Result<(), Error> {
      +    lambda_runtime::run(handler_fn(handler)).await?;
      +    Ok(())
      -fn handler(
      -    event: Value,
      -    _: Context,
      -) -> Result<Value, HandlerError> {
      +async fn handler(
      +    event: Value,
      +    _:Context
      +) -> Result<Value, Error> {

    Please refer to the examples in (lambda-runtime/examples; lambda-http/examples) for more detail.

    Source code(tar.gz)
    Source code(zip)
  • v0.2.0(Jan 25, 2019)


    • New: We created lambda_runtime_core crate that implements the runtime's main loop and supports handlers that accept and return Vec<u8>. (#53)
    • New: The primary lambda_runtime crate is a wrapper on top of the lambda_runtime_core handler (#53).
    • New: The lambda_http crate, which enables support for API Gateway or ALB requests, treating them as Request structs from the http crate (#18 by @softprops).
    • New: The lambda_runtime_errors crate introduces the LambdaErrorExt trait that enables the ability to specify custom errorType values for the Lambda Runtime API. The change also includes a companion derive crate that makes it easy to automatically generate LambdaErrorExt implementations for crate-local error types (#63).
    • Fix: Handlers can now return any error type (#54).
    • Fix: Support for closures as handlers (#19 by @srijs).
    • Fix: Multiple bug fixes and performance improvements (thanks @Sh4rK).
    Source code(tar.gz)
    Source code(zip)
Amazon Web Services - Labs
AWS Labs
Amazon Web Services - Labs
A Rust runtime for AWS Lambda

Rust Runtime for AWS Lambda This package makes it easy to run AWS Lambda Functions written in Rust. This workspace includes multiple crates: lambda-ru

Amazon Web Services - Labs 2.4k Dec 29, 2022
📦 🚀 a smooth-talking smuggler of Rust HTTP functions into AWS lambda

lando ?? maintenance mode ahead ?? As of this announcement AWS not officialy supports Rust through this project. As mentioned below this projects goal

Doug Tangren 68 Dec 7, 2021
A tool to run web applications on AWS Lambda without changing code.

AWS Lambda Adapter A tool to run web applications on AWS Lambda without changing code. How does it work? AWS Lambda Adapter supports AWS Lambda functi

AWS Samples 321 Jan 2, 2023
Aws-sdk-rust - AWS SDK for the Rust Programming Language

The AWS SDK for Rust This repo contains the new AWS SDK for Rust (the SDK) and its public roadmap. Please Note: The SDK is currently released as a dev

Amazon Web Services - Labs 2k Jan 3, 2023
Rs.aws-login - A command line utility to simplify logging into AWS services.

aws-login A command line utility to simplify logging into AWS accounts and services. $ aws-login use ? Please select a profile to use: › ❯ dev-read

Kevin Herrera 11 Oct 30, 2022
Rust Lambda Extension for any Runtime to preload SSM Parameters as 🔐 Secure Environment Variables!

?? Crypteia Rust Lambda Extension for any Runtime to preload SSM Parameters as Secure Environment Variables! Super fast and only performaned once duri

Custom Ink 34 Jan 7, 2023
The classic game Pong, written in lambda calculus, and a thin layer of Rust.

What? The good old game Pong, written in lambda calculus, and a thin layer of Rust. Why? I was bored. No, seriously, why? Everyone keeps saying that l

null 2 Aug 14, 2022
Examples of how to use Rust with Serverless Framework, Lambda, API Gateway v1 and v2, SQS, GraphQL, etc

Rust Serverless Examples All examples live in their own directories: project: there is nothing here, just a simple cargo new project_name with a custo

Fernando Daciuk 9 Dec 17, 2022
Serverless setup for activity pub (using lambda+dynamodb) in Rust

Serverless ActivityPub About This is an experiment to have free/cheaper activitypub instances running on AWS (making use of free tiers as much as poss

Conrad Ludgate 3 Dec 30, 2022
A lambda extension to hot reload parameters from SSM Parameter Store, Secrets Manager, DynamoDB, AppConfig

A lambda extension to hot reload parameters from SSM Parameter Store, Secrets Manager, DynamoDB, AppConfig

Jake Scott 7 Jun 12, 2022
Rust client for AWS Infinidash service.

AWS Infinidash - Fully featured Rust client Fully featured AWS Infinidash client for Rust applications. You can use the AWS Infinidash client to make

Rafael Carício 15 Feb 12, 2022
Rusoto is an AWS SDK for Rust

Rusoto is an AWS SDK for Rust You may be looking for: An overview of Rusoto AWS services supported by Rusoto API documentation Getting help with Rusot

null 2.6k Jan 3, 2023
Cookiecutter templates for Serverless applications using AWS SAM and the Rust programming language.

Cookiecutter SAM template for Lambda functions in Rust This is a Cookiecutter template to create a serverless application based on the Serverless Appl

AWS Samples 24 Nov 11, 2022
Ref Arch: Serverless GraphQL in Rust on AWS

A Whole Hog Reference Architecture for an Apollo Federation-Ready, Serverless, Rust-Based GraphQL Microservice on AWS using Cloud Development Kit (CDK)

Michael Edelman 3 Jan 12, 2022
Remote Secret Editor for AWS Secret Manager

Barberousse - Remote Secrets Editor About Usage Options Printing Editing Copying RoadMap 1.0 1.1 Future About A project aimed to avoid downloading sec

Mohamed Zenadi 18 Sep 28, 2021
Easy switch between AWS Profiles and Regions

AWSP - CLI To Manage your AWS Profiles! AWSP provides an interactive terminal to interact with your AWS Profiles. The aim of this project is to make i

KubeOps Skills 14 Dec 25, 2022
Simple fake AWS Cognito User Pool API server for development.

Fakey Cognito ?? Homepage Simple fake AWS Cognito API server for development. ✅ Implemented features AdminXxx on User Pools API. Get Started # run wit

naokirin 4 Aug 30, 2022
Postgres proxy which allows tools that don't natively supports IAM auth to connect to AWS RDS instances.

rds-iamauth-proxy rds-proxy lets you make use of IAM-based authentication to AWS RDS instances from tools that don't natively support that method of a

Gold Fig Labs Inc. 10 Nov 7, 2022
Managing schema for AWS Athena in GitOps-style

athena-rs Managing AWS Athena Schemas Installation $ cargo install --git https://github.com/duyet/athena-rs $ athena --help athena 0.1.0 Duyet <[email protected]

Duyet Le 3 Sep 25, 2022