--- layout: docs page_title: Invoke Services from Lambda Functions description: >- This topic describes how to invoke services in the mesh from Lambda functions registered with Consul. --- # Invoke Services from Lambda Functions This topic describes how to invoke services in the mesh from Lambda functions registered with Consul. ~> **Lambda-to-mesh functionality is currently in beta**: Functionality associated with beta features are subject to change. You should never use the beta release in secure environments or production scenarios. Features in beta may have performance issues, scaling issues, and limited support. ## Introduction The following steps describe the process: 1. Deploy the destination service and mesh gateway. 1. Deploy the Lambda extension layer. 1. Deploy the Lambda registrator. 1. Write the Lambda function code. 1. Deploy the Lambda function. 1. Invoke the Lambda function. You must add the `consul-lambda-extension` extension as a Lambda layer to enable Lambda functions to send requests to mesh services. Refer to the [AWS Lambda documentation](https://docs.aws.amazon.com/lambda/latest/dg/invocation-layers.html) for instructions on how to add layers to your Lambda functions. The layer runs an external Lambda extension that starts a sidecar proxy. The proxy listens on one port for each upstream service and upgrades the outgoing connections to mTLS. It then proxies the requests through to [mesh gateways](/docs/connect/gateways#mesh-gateways). ## Prerequisites You must deploy the destination services and mesh gateway prior to deploying your Lambda service with the `consul-lambda-extension` layer. ### Deploy the destination service There are several methods for deploying services to Consul service mesh. The following example configuration deploys a service named `static-server` with Consul on Kubernetes. ```yaml kind: Service apiVersion: v1 metadata: # Specifies the service name in Consul. name: static-server spec: selector: app: static-server ports: - protocol: TCP port: 80 targetPort: 8080 --- apiVersion: v1 kind: ServiceAccount metadata: name: static-server --- apiVersion: apps/v1 kind: Deployment metadata: name: static-server spec: replicas: 1 selector: matchLabels: app: static-server template: metadata: name: static-server labels: app: static-server annotations: 'consul.hashicorp.com/connect-inject': 'true' spec: containers: - name: static-server image: hashicorp/http-echo:latest args: - -text="hello world" - -listen=:8080 ports: - containerPort: 8080 name: http serviceAccountName: static-server ``` ### Deploy the mesh gateway The mesh gateway must be running and registered to the Lambda function’s Consul datacenter. Refer to the following documentation and tutorials for instructions: - [Mesh Gateways between Datacenters](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters) - [Mesh Gateways between Admin Partitions](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-partitions) - [Mesh Gateways between Peered Clusters](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-peers) - [Connect Services Across Datacenters with Mesh Gateways](https://developer.hashicorp.com/consul/tutorials/developer-mesh/service-mesh-gateways) ## Deploy the Lambda extension layer The `consul-lambda-extension` extension runs during the `Init` phase of the Lambda function execution. The extension retrieves the data that the Lambda registrator has been configured to store from AWS Parameter Store and creates a lightweight TCP proxy. The proxy creates a local listener for each upstream defined in the `CONSUL_SERVICE_UPSTREAMS` environment variable. The extension periodically retrieves the data from the AWS Parameter Store so that the function can process requests. When the Lambda function receives a shutdown event, the extension also stops. 1. Download the `consul-lambda-extension` extension from [releases.hashicorp.com](https://releases.hashicorp.com/): ```shell-session curl -o consul-lambda-extension__linux_amd64.zip https://releases.hashicorp.com/consul-lambda//consul-lambda-extension__linux_amd64.zip ``` 1. Create the AWS Lambda layer in the same AWS region as the Lambda function. You can create the layer manually using the AWS CLI or AWS Console, but we recommend using Terraform: ```hcl resource "aws_lambda_layer_version" "consul_lambda_extension" { layer_name = "consul-lambda-extension" filename = "consul-lambda-extension__linux_amd64.zip" source_code_hash = filebase64sha256("consul-lambda-extension__linux_amd64.zip") description = "Consul service mesh extension for AWS Lambda" } ``` ## Deploy the Lambda registrator Configure and deploy the Lambda registrator. Refer to the [registrator configuration documentation](/docs/lambda/registration/automate#configuration) and the [registrator deployment documentation](/docs/lambda/registration/automate#deploy-the-lambda-registrator) for instructions. ## Write the Lambda function code Refer to the [AWS Lambda documentation](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html) for instructions on how to write a Lambda function. In the following example, the function calls an upstream service on port `2345`: ```go package main import ( "context" "io" "fmt" "net/http" "github.com/aws/aws-lambda-go/lambda" ) type Response struct { StatusCode int `json:"statusCode"` Body string `json:"body"` } func HandleRequest(ctx context.Context, _ interface{}) (Response, error) { resp, err := http.Get("http://localhost:2345") fmt.Println("Got response", resp) if err != nil { return Response{StatusCode: 500, Body: "Something bad happened"}, err } if resp.StatusCode != 200 { return Response{StatusCode: resp.StatusCode, Body: resp.Status}, err } defer resp.Body.Close() b, err := io.ReadAll(resp.Body) if err != nil { return Response{StatusCode: 500, Body: "Error decoding body"}, err } return Response{StatusCode: 200, Body: string(b)}, nil } func main() { lambda.Start(HandleRequest) } ``` ## Deploy the Lambda function 1. Create and apply an IAM policy that allows the Lambda function’s role to fetch the Lambda extension’s data from the AWS Parameter Store. The following example, creates an IAM role for the Lambda function, creates an IAM policy with the necessary permissions and attaches the policy to the role: ```hcl resource "aws_iam_role" "lambda" { name = "lambda-role" assume_role_policy = < 1. Configure and deploy the Lambda function. Refer to the [Lambda extension configuration](#lambda-extension-configuration) reference for information about all available options. There are several methods for deploying Lambda functions. The following example uses Terraform to deploy a function that can invoke the `static-server` upstream service using mTLS data stored under the `/lambda_extension_data` prefix: ```hcl resource "aws_lambda_function" "example" { … function_name = "lambda" role = aws_iam_role.lambda.arn tags = { "serverless.consul.hashicorp.com/v1alpha1/lambda/enabled" = "true" } variables = { environment = { CONSUL_MESH_GATEWAY_URI = var.mesh_gateway_http_addr CONSUL_SERVICE_UPSTREAMS = "static-server:2345:dc1" CONSUL_EXTENSION_DATA_PREFIX = "/lambda_extension_data" } } layers = [aws_lambda_layer_version.consul_lambda_extension.arn] ``` 1. Run the `terraform apply` command and Consul automatically configures a service for the Lambda function. ### Lambda extension configuration Define the following environment variables in your Lambda functions to configure the Lambda extension. The variables apply to each Lambda function in your environment: | Variable | Description | Default | | --- | --- | --- | | `CONSUL_MESH_GATEWAY_URI` | Specifies the URI where the mesh gateways that the plugin makes requests are running. The mesh gateway should be registered in the same Consul datacenter and partition that the service is running in. For optimal performance, this mesh gateway should run in the same AWS region. | none | | `CONSUL_EXTENSION_DATA_PREFIX` | Specifies the prefix that the plugin pulls configuration data from. The data must be located in the following directory:
`“${CONSUL_EXTENSION_DATA_PREFIX}/${CONSUL_SERVICE_PARTITION}/${CONSUL_SERVICE_NAMESPACE}/”` | none | | `CONSUL_SERVICE_NAMESPACE` | Specifies the Consul namespace the service is registered into. | `default` | | `CONSUL_SERVICE_PARTITION` | Specifies the Consul partition the service is registered into. | `default` | | `CONSUL_REFRESH_FREQUENCY` | Specifies the amount of time the extension waits before re-pulling data from the Parameter Store. Use [Go `time.Duration`](https://pkg.go.dev/time@go1.19.1#ParseDuration) string values, for example, `”30s”`.
The time is added to the duration configured in the Lambda registrator `sync_frequency_in_minutes` configuration. Refer to [Lambda registrator configuration options](/docs/lambda/registration/automate#lambda-registrator-configuration-options). The combined configurations determine how stale the data may become. Lambda functions can run for up to 14 hours, so we recommend configuring a value that results in acceptable staleness for certificates. | `“5m”` | | `CONSUL_SERVICE_UPSTREAMS` | Specifies a comma-separated list of upstream services that the Lambda function can call. Specify the value as an unlabelled annotation according to the [`consul.hashicorp.com/connect-service-upstreams` annotation format](/docs/k8s/annotations-and-labels#consul-hashicorp-com-connect-service-upstreams) in Consul on Kubernetes. For example, `"[service-name]:[port]:[optional-datacenter]"` | none | ## Invoke the Lambda function If _intentions_ are enabled in the Consul service mesh, you must create an intention that allows the Lambda function's Consul service to invoke all upstream services prior to invoking the Lambda function. Refer to [Service Mesh Intentions](/docs/connect/intentions) for additional information. There are several ways to invoke Lambda functions. In the following example, the `aws lambda invoke` CLI command invokes the function: ```shell-session $ aws lambda invoke --function-name lambda /dev/stdout | cat ```