Navigation :

AWS Lambda integration

Use Gloo Gateway to route traffic requests directly to an Amazon Web Services (AWS) Lambda function.

The AWS Lambda integration in Gloo Gateway requires a Solo distribution of Istio for the gateway.

About

Serverless functions, such as Lambda functions, provide an alternative to traditional applications or services. The functions run on servers that you do not have to manage yourself, and you pay for only for the compute time you use. However, you might want to invoke your serverless functions from other services or apps, such as the Kubernetes workloads that run in clusters in your Gloo Gateway environment. By abstracting a Lambda as a type of destination in your Gloo Gateway environment, your workloads can send requests to the Lambda destination in the same way that you set up routing through Gloo Gateway to other types of destinations. Gloo Gateway does the work of assuming an AWS IAM role to invoke the actual Lambda function in your AWS account.

Gloo Gateway integration

Gloo Gateway supports multiple features to help you seamlessly invoke Lambda functions from your Gloo environment:

Permissions: To ensure that permissions to AWS Lambda are controlled, you can specify multiple levels of IAM roles for general AWS Lambda access, discovery of functions in an account, and invocation of specific functions.
Discovery: Gloo Gateway can automatically discover all of the functions in an AWS account and region, or if you apply discovery filters, a subset of the functions. Alternatively, you can disable discovery and choose individual functions for Gloo Gateway to access.
Routing: After Gateway discovers your functions, you can route to each function in the same way that you route to other destinations in a route table resource. Gloo Gateway assumes one of your AWS IAM roles to invoke the Lambda function.
Transformations: You can use Gloo Gateway in place of your AWS ALB or AWS API Gateway. The default transformation that Gloo Gateway applies adjusts the default request and response payloads for a smooth migration from AWS gateways to Gloo Gateway. You can also apply additional Gloo transformation policies, which allow you to customize the request and respone payloads for Lambda as needed.
Multitenancy: By using Gloo workspaces, you can separate Lambda discovery, IAM access, and function invocation by team in your Gateway environment.

Get started

Check out the following pages to integrate Lambda invocation in your Gloo environment.

Get started: Get started with invoking AWS Lambda functions in Gloo Gateway.

Configure AWS IAM permissions: Create IAM roles for Gloo Gateway service accounts to access, discover, and invoke Lambda functions.

Provide AWS account and Lambda details: Provide the details of your AWS account, the Lambda functions to access, and IAM roles to Gloo Gateway for function invocation and discovery.

Set up routing: Set up routing to your Lambda function in a RouteTable Gloo resource.

Manage multitenancy: Control which teams' workloads in your Gloo Gateway environment can discover and invoke specific Lambda functions.

Request and response payloads: Review default request and response payload formats, and transformations you can apply to the payload structure.

Known issues

In Gloo Gateway 2.3, the Gloo custom resources for the AWS Lambda integration are changed in the following breaking ways. If you used the AWS Lambda integration in 2.2, create copies of your existing CloudProvider, CloudResources, and any Lambda RouteTable resources and update the copies to the new format, which you apply during the migration from 2.2 to 2.3.

The CloudProvider and CloudResources CRs are moved from the networking.gloo.solo.io/v2 API group to the infrastructure.gloo.solo.io/v2 API group.
The logicalName field is removed from the CloudResources CR.
Routes for Lambda functions in RouteTable CRs now use a new destination type, awsLambda.
The WRAP_AS_API_GATEWAY, UNWRAP_AS_API_GATEWAY, and UNWRAP_AS_ALB transformation settings are removed from the RouteTable CR, as the transformation functionality from these settings is now included in the REQUEST_DEFAULT and RESPONSE_DEFAULT transformations.