Ctrlk
Sign UpGet a DemoContact Us
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Lambda services

Configure AWS Lambda services in Harness — function definitions, alias definitions, and artifact sources.

A Harness service for AWS Lambda holds the function definition, an optional alias definition for canary deployments, and the artifact source that points to your function code. Services are independent of pipelines; configure one and reuse it across stages and pipelines.

What you will learn

  • How to create an AWS Lambda service in Harness.

  • How to configure function definitions and alias definitions.

  • Which artifact source types are supported and how to configure each one.

Before you begin

  • AWS connector: A connector with an IAM role that has AWSLambda_FullAccess and AmazonS3ReadOnlyAccess (or AmazonEC2ContainerRegistryReadOnly for ECR). Go to AWS IAM permissions to review the required policies.

  • Function artifact: A ZIP file in an S3 bucket, or a container image in ECR.

Create a Lambda service

  1. Go to Deployments, expand the drop-down, and select Services under Resources.

  2. Click + New Service.

  3. In the Create service panel, select AWS Lambda from the Deployment Target drop-down.

  4. Harness auto-generates a name and ID. You can change both.

  5. Under Storage, select Inline (Harness stores the service configuration) or a Git repository.

  6. Add a function definition, an optional alias definition, and an artifact source as described below.

  7. Click Create.

Add a function definition

A function definition tells Harness the configuration of the Lambda function to create or update: its name, handler, runtime, memory, and timeout. Harness reads this file at deploy time and applies it to the function in AWS.

Click + Add under AWS Lambda Function Definition and configure the manifest store.

Field
Description

Manifest Identifier

A unique ID for this definition within the service.

Source

Where the definition file is stored. Supports Harness Code, GitHub, Git, GitLab, Bitbucket, Azure Repos, and AWS S3.

Repository

The repository that contains the file. Not shown for Bitbucket when using a repo-level connector — the repository is baked into the connector.

Fetch

Branch to track a branch head, or Commit to pin to a specific SHA.

File Path

Path to the YAML file from the root of the repository.

Function definition YAML

The format of the function definition file depends on how the function is packaged.

ZIP package (S3, Artifactory, Nexus)

Use this format when your artifact is a ZIP file. The handler and runtime fields are required because Lambda needs to know how to invoke the code inside the ZIP.

Field
Required
Description

functionName

Yes

The Lambda function name to create or update.

handler

Yes

The function entry point, for example index.handler.

runtime

Yes

The Lambda runtime identifier, for example nodejs18.x or python3.11.

memorySize

No

Memory allocated to the function in MB. Default is 128.

timeout

No

Maximum execution time in seconds. Default is 3, maximum is 900.

role

No

ARN of the IAM execution role. If omitted, Harness uses the role on the existing function.

environment

No

Environment variables to set on the function.

layers

No

List of Lambda layer ARNs to attach.

Example ZIP function definition

Container image (ECR)

Use this format when your artifact is a container image from ECR. Image functions do not have a handler or runtime — those are defined inside the container. The role field is required because Harness cannot infer it from the image.

Field
Required
Description

functionName

Yes

The Lambda function name to create or update.

packageType

Yes

Must be Image.

role

Yes

ARN of the IAM execution role.

memorySize

No

Memory allocated to the function in MB. Default is 128.

timeout

No

Maximum execution time in seconds. Default is 3, maximum is 900.

environment

No

Environment variables to set on the function.

Example container image function definition

For container image functions, define functionName and role as service variables so the definition stays portable across environments.

Service variables for ECR functions

When using a container image, add functionName and role as service variables (under Metadata → Variables). Reference them in the function definition as <+serviceVariables.functionName> and <+serviceVariables.role>.

For ZIP functions, add functionName and runtime as service variables and reference them the same way.

Add a function alias definition

An alias definition tells Harness the alias name to create or update during deployment. How it behaves depends on the deployment strategy:

  • Canary: Required. The canary deploy step creates a weighted alias to split traffic between the previous and new versions. Without an alias definition, the canary deploy step cannot route traffic and the pipeline fails.

  • Rolling: Optional. When present, the rolling deploy step updates the alias to point to the new version at 100% weight after publishing it. When absent, the rolling deploy completes without creating or modifying any alias.

Click + Add under AWS Lambda Function Alias Definition and configure the manifest store using the same fields as the function definition.

Alias definition YAML

Field
Required
Description

functionName

Yes

The Lambda function name, must match the function definition.

name

Yes

The alias name to create or update, for example live.

description

No

A description of the alias.

Example alias definition

ZIP artifact canary: alias required

If your artifact is a ZIP file (S3, Artifactory, or Nexus) and you are using the canary strategy, add an alias definition to the service before running the pipeline. Without one, the canary deploy step has no alias name to target and the pipeline fails.

ECR container image canary deployments do not require an alias definition — the canary deploy step manages the alias automatically.

Alias behavior

The rolling deploy step reads the service's manifest list at runtime and acts on what it finds:

Service manifests
What the rolling deploy step does

Function definition only

Publishes a new version; no alias is created or updated.

Function definition + alias definition

Publishes a new version; creates or updates the named alias to point to the new version at 100% weight.

The alias definition type in Harness is AwsLambdaFunctionAliasDefinition. Go to Add a function alias definition to configure the alias.

Rolling vs. canary with an alias

Both rolling and canary can use an alias, but they behave differently. A rolling deploy sets the alias to 100% of the new version in one step. A canary deploy splits traffic across versions using a weighted alias and promotes gradually.

Alias and artifact type requirements

The canary deploy step behaves differently depending on whether your function artifact is a ZIP package or a container image from ECR.

Artifact type
Alias definition required
Execution path

ZIP (S3, Artifactory, Nexus)

Yes — add an AwsLambdaFunctionAliasDefinition manifest to the service

Manifest fetch → Harness rendering → artifact download → canary deploy → traffic shifts

Container image (ECR)

No — the canary deploy step manages the alias automatically

Manifest fetch → canary deploy → traffic shifts (rendering and download steps are skipped)

For ZIP artifacts, the canary deploy step reads the alias manifest to determine the alias name and creates a weighted alias with that name. Without the manifest, the step has no alias name to target and the pipeline fails.

For ECR image functions, there is no ZIP to download and no manifest to render. The canary deploy step handles alias management internally without requiring a declared alias manifest in the service. The service only needs a function definition manifest (AwsLambdaFunctionDefinition).

Add an artifact source

The artifact source points to the function code package. Harness fetches it at deploy time and uploads it to Lambda.

Click + Add under Artifact source and select a type.

Use this type for a function packaged as a ZIP file stored in S3.

Field
Description

Connector

A Harness AWS connector with AmazonS3ReadOnlyAccess.

Region

The AWS region where the S3 bucket is located.

Bucket Name

The name of the S3 bucket.

File Path

The path to the ZIP file within the bucket, for example lambda-functions/function.zip.

Use this type for a function packaged as a container image stored in ECR.

Field
Description

Connector

A Harness AWS connector with AmazonEC2ContainerRegistryReadOnly.

Region

The AWS region where the ECR repository is located.

Image Path

The repository name, for example my-lambda-image.

Tag

The image tag. Supports a fixed value, runtime input (<+input>), or an expression.

Field
Description

Connector

A Harness Artifactory connector.

Repository

The Artifactory repository name.

Artifact Directory

The path to the directory containing the artifact.

Artifact Details

Select Value and enter the artifact name, or select Regex to match by pattern.

Advanced service options

Expand Metadata at the bottom of the service panel to access additional configuration:

  • Config Files: Attach configuration files such as properties files or scripts. Harness makes these available to the delegate at deploy time.

  • Variables: Define service-level variables for use in pipeline expressions. Reference them as:

    • CEL: ${{serviceVariables.<name>}}

    • JEXL: <+serviceVariables.<name>>

Use an existing service

When you configure a stage, select Existing in the Choose service panel. Use the Project, Organization, and Account tabs to select from the appropriate scope. Only AWS Lambda services appear when your stage deployment type is AWS Lambda.

Next steps

  • Go to Lambda infrastructure to configure environments and infrastructure definitions.

  • Go to Overview to review canary and rolling strategy options.

PreviousAWS Lambda
NextLambda infrastructure

Last updated

Was this helpful?