Set up routing

After you define your AWS and Lambda information, set up routing to your Lambda function in a RouteTable Gloo resource.

Create a route table

Create a RouteTable resource to ensure that Gloo Gateway directs all requests on a specific path to your Lambda function. For more information on how to configure a route table, see the routing guides or API reference documentation.

apiVersion: networking.gloo.solo.io/v2
kind: RouteTable
metadata:
  name: 
  namespace: 
spec:
  # Domain to apply routing to
  hosts:
    - 
  # Select a virtual gateway you previously created
  virtualGateways:
    - name: 
      namespace: 
      cluster: 
  http:
    # Route for the Lambda function
    - name: 
      # Prefix matching
      matchers:
      - uri:
          prefix: 
      # Forwarding directive
      forwardTo:
        destinations:
        - awsLambda:
            # Reference to the CloudProvider resource
            cloudProvider:
              name: 
              namespace: 
              cluster: 
            # Name of the function, which is the lambdaFunctionName in the CloudResources config
            function: 
            # Version of the function to call. Defaults to $LATEST. For more info, see https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_RequestSyntax
            qualifier: 
            options:
              # Style of communication (SYNCH|ASYNCH).
              # For more info, see https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_RequestSyntax
              invocationStyle: 
              # Control transformations that Gloo Gateway applies to the request to the function.
              # For more info, see the "Request and response payloads" doc page.
              requestTransformation: 
              # Control transformations that Gloo Gateway applies to the response from the function.
              # For more info, see the "Request and response payloads" doc page.
              responseTransformation: 

Example

This route table ensures that all requests to the example.com/test-lambda path are routed by the gateway to your Lambda function.

apiVersion: networking.gloo.solo.io/v2
kind: RouteTable
metadata:
  name: test-lambda-route
  namespace: gloo-mesh
spec:
  hosts:
    - example.com
  virtualGateways:
    - name: istio-ingressgateway
      namespace: bookinfo
  http:
    - name: test-lambda-route
      labels:
        route: lambda
      matchers:
      - uri:
          prefix: /test-lambda
      forwardTo:
        destinations:
        - awsLambda:
            cloudProvider:
              name: aws-provider
              namespace: gloo-mesh
              cluster: $CLUSTER_NAME
            function: test-lambda

Test routing to your Lambda

  1. Get the hostname of your ingress gateway to test the /test-lambda route.

    export INGRESS_GW_IP=$(kubectl get svc -n gloo-mesh-gateways istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
    echo $INGRESS_GW_IP
    
  2. Send a request to the Lambda endpoint to verify that the request is successfully resolved by the gateway. This example command sends the request to the /test-lambda path.

    curl -vik https://${INGRESS_GW_IP}:443/test-lambda -H "host: www.example.com:443"
    

Allow requests to only specific Lambda route tables

Optionally allow gateway routing to only specific types of Lambda routes. This method can be useful when you have a large number of route tables, and want to ensure that the gateway allows traffic requests to only a subset of the available routes based on the Lambda properties (such as the function name, account, or location) or based on the invocation properties (the assumed IAM role). Traffic requests to routes that do not match the properties that you specify result in an error.

Route filtering is enabled through the allowedRoutes setting in either the VirtualGateway resource, or the main RouteTable in a delegated route table setup.

Virtual gateways

You can specify the following filters in the allowedRouteTables.allowedRoutes section of a VirtualGateway resource. These filters support regular expressions.

...
  listeners:
    - port:
        number: 80
      allowedRouteTables:
        - host: '*.foo.com'
          selector:
            workspace: foo-ws
          allowedRoutes:
          # Within the route tables, route requests only to routes that match these filters
          - cloudProvider:
              aws:
                # Route only to functions that exist in the following AWS account ID(s)
                accountIds:
                  - 
                # Route only to functions with the following name(s)
                lambdaFunctions:
                  - 
                # Route only to functions in the following AWS region(s)
                regions:
                  - 
                # Route only to functions that reference a CloudProvider with the following AWS IAM role(s)
                iamRoles:
                  - 

In this example virtual gateway, the following fields filter how a request is being routed:

apiVersion: networking.gloo.solo.io/v2
kind: VirtualGateway
metadata:
  name: my-gateway
  namespace: some-config-namespace
  labels:
    workspace.solo.io/exported: 'true'
spec:
  workloads:
    - selector:
        labels:
          app: my-gateway-controller
  listeners:
    - port:
        number: 80
      allowedRouteTables:
        - host: '*.foo.com'
          selector:
            workspace: foo-ws
          allowedRoutes:
          - cloudProvider:
              aws:
                lambdaFunctions:
                  - backend-function-.*
                iamRoles:
                  - dev-team-B-.*
                regions:
                  - us-east-2

Delegated route tables

If you use delegated route tables for your Lambda functions, you can specify the following matchers in the delegate.allowedRoutes section of your main route table resource. These matchers support regular expressions.

...
  http:
  - delegate:
      routeTables:
        - labels:
            table: myapp
      sortMethod: TABLE_WEIGHT
      allowedRoutes:
      - cloudProvider:
          aws:
            # Route only to functions that exist in the following AWS account ID(s)
            accountIds:
              - 
            # Route only to functions with the following name(s)
            lambdaFunctions:
              - 
            # Route only to functions in the following AWS region(s)
            regions:
              - 
            # Route only to functions that reference a CloudProvider with the following AWS IAM role(s)
            iamRoles:
              - 

In this example main route table, the gateway only routes requests to sub-tables when:

apiVersion: networking.gloo.solo.io/v2
kind: RouteTable
metadata:
  name: delegate-weight
  namespace: global
spec:
  hosts:
    - 'one.solo.io'
  virtualGateways:
    - name: istio-ingressgateway
      namespace: bookinfo
  http:
  - delegate:
      routeTables:
        - labels:
            table: myapp
      sortMethod: TABLE_WEIGHT
      allowedRoutes:
      - cloudProvider:
          aws:
            lambdaFunctions:
              - backend-function-.*
            iamRoles:
              - dev-team-B-.*
            regions:
              - us-east-2

Apply request and response transformations

When a workload in your Gloo Gateway environment sends a request to your Lambda function, Gateway applies a default transformation to the payload. When the function returns the response, Gloo Gateway also expects specific fields in the response payload. When you use these default payload formats, your Lambda must be coded to accept and return the Gloo Gateway format. You can also disable all request and response transformations, and apply custom transformations by using transformation policies.

For more information, see Request and response payloads.

Preparing for Lambda cold starts

When you invoke a new function in AWS Lambda, you might notice significant latency, or a cold start, as Lambda downloads your code and prepares the execution environment. The latency can vary from under 100ms to more than 1 second. The chances of a cold start increase if you write the function in a programming language that takes a long time to start up a VM, such as Java. For more information, see the AWS blog.

Cold start latency might result in 500-level server error responses. To mitigate the latency effects, you can apply a Gloo RetryTimeoutPolicy, such as the following example.

apiVersion: resilience.policy.gloo.solo.io/v2
kind: RetryTimeoutPolicy
metadata:
  name: retry-lambda
  namespace: gloo-mesh
spec:
  applyToRoutes:
    - route:
        labels:
          route: lambda 
  config:
    retries:
      attempts: 5 
      perTryTimeout: 10s
      retryOn: "5xx,unavailable,cancelled,retriable-status-codes"

For more information about timeout and retry settings, see the RetryTimeoutPolicy documentation.