Lambda rolling deployment

Deploy a new Lambda function version and shift all traffic to it immediately using a basic rolling strategy.

A Lambda rolling deployment publishes a new function version and routes all traffic to it in a single step. There is no gradual traffic shift; the new version handles 100% of invocations as soon as it is published. If the step fails, Harness rolls back to the previous version automatically.

---

What you will learn

• How a Lambda rolling deployment works and when to use it.

• How to configure the Rolling Deploy step and its output variables.

• How rollback works for rolling deployments.

---

Before you begin

Before you configure a rolling stage, make sure you have the following in place:

• A Lambda service: Go to Lambda services to set up a service with a function definition and an artifact source. An alias definition is optional for rolling deployments; go to Alias behavior to review how the rolling deploy step handles aliases.

• A Lambda infrastructure: Go to Lambda infrastructure to connect an AWS account and region.

---

How rolling deployments work

Harness publishes the updated function code and configuration as a new Lambda version, then immediately routes all traffic to it. There is no gradual traffic shift.

The exact behavior depends on whether your service includes an alias definition:

• Without an alias definition: The deploy step publishes a new version and updates the function. Invocations that use an unqualified function name or ARN immediately hit the new version.

• With an alias definition: The deploy step publishes a new version and updates the named alias to point to it at 100% weight. Invocations that use the alias continue working without change; they just resolve to the new version.

When to use rolling:

• You want the simplest deployment path with no traffic splitting.

• The function is non-critical or your validation happens before deployment (for example, in a prior pipeline stage).

• You do not need to observe the new version on a subset of production traffic before full promotion.

---

Configure a rolling stage

A rolling stage requires two kinds of configuration: selecting the strategy and then configuring the deploy step Harness adds to the stage canvas.

Select the rolling strategy

When creating a new stage, step 4 of the stage wizard asks you to choose a deployment strategy. Select AWS Lambda Rolling Deploy Strategy from the list.

Harness automatically adds one step to the stage canvas.

---

Configure the AWS Lambda Rolling Deploy step

Click the AWS Lambda Rolling Deploy step to open its configuration panel.

The step has two sections whose values are derived automatically from your service and infrastructure:

Service Configuration (auto-populated from the service)

Field	Value	Description
Function Definition	${{serviceOutput.manifests.awsLambdaFunction.paths}}	Path to the function definition manifest. Harness resolves this at runtime from the service.
Function Alias	${{serviceOutput.manifests.awsLambdaAlias.paths}}	Path to the alias definition manifest. Populated only when your service includes an AwsLambdaFunctionAliasDefinition manifest. Leave empty to skip alias management.

Infrastructure Configuration (auto-populated from the infrastructure)

Field	Value	Description
AWS Connector	Select a connector	The AWS connector used to authenticate to Lambda.
AWS Region	${{infra.region}}	Resolved automatically from the infrastructure definition.

ECR image functions

When your artifact is a container image from ECR, the function definition uses packageType: Image — there is no handler or runtime field. For these functions, define functionName and role as service variables in the service configuration. The runtime output variable will be empty after the deploy step completes.

When your artifact is a ZIP file from S3, Artifactory, or Nexus, define runtime and functionName as service variables.

---

Rolling deploy step output variables

After the rolling deploy step completes, the following output variables are available for downstream steps and expressions:

Variable	Expression	Description
functionName	<+pipeline.stages.<stage-id>.steps.awsLambdaRollingDeployStep.output.outputVariables.functionName>	The name of the deployed Lambda function.
version	<+pipeline.stages.<stage-id>.steps.awsLambdaRollingDeployStep.output.outputVariables.version>	The version number published by this deployment.
runtime	<+pipeline.stages.<stage-id>.steps.awsLambdaRollingDeployStep.output.outputVariables.runtime>	The Lambda runtime identifier (empty for container image functions).
functionArn	<+pipeline.stages.<stage-id>.steps.awsLambdaRollingDeployStep.output.outputVariables.functionArn>	The full ARN of the deployed function version.

In the CEL expression syntax supported by the unified pipeline format, use ${{pipeline.stages.<stage-id>.steps.awsLambdaRollingDeployStep.output.outputVariables.<variable>}} instead.

---

Rollback

Rollback is triggered by the on-failure: block in the stage configuration — without it, the rollback steps are never invoked regardless of failure. The pipeline YAML in the reference section below includes the required on-failure: block.

When the rolling deploy step fails, Harness runs the AWS Lambda Rolling Rollback step. The rollback step reads state from the last successful execution of this stage, not from the failed run. This means it restores the function to the version that was last confirmed working.

What the rollback does:

• Re-deploys the function to the version number captured before the last successful deploy started.

• If the service includes an alias definition, the rollback step also repoints that alias back to the restored version at 100% weight.

A rolling deploy fully replaces the function, so rollback must re-deploy the previous version to restore state. This is different from canary rollback, which only resets alias weights because the previous version was never removed from the alias.

The rollback step has only Infrastructure Configuration — the previous version is already published in AWS and no service inputs are needed:

Field	Value	Description
AWS Connector	Select a connector	The AWS connector used to authenticate to Lambda.
AWS Region	${{infra.region}}	Resolved from the infrastructure definition.

---

Complete YAML reference

Pipeline YAML

pipeline:
  name: Lambda Rolling Deploy
  id: lambdaRollingDeploy
  clone:
    disabled: true
  stages:
    - name: Stage
      id: stage
      service: <your-service-id>
      environment:
        id: <your-environment-id>
        deploy-to: <your-infrastructure-id>
      steps:
        - name: AWS Lambda Rolling Deploy
          id: awsLambdaRollingDeployStep
          template:
            uses: awsLambdaRollingDeployStep
      rollback:
        - group:
            steps:
              - name: AWS Lambda Rolling Rollback
                id: awsLambdaRollingRollbackStep
                template:
                  uses: awsLambdaRollingRollbackStep
      on-failure:
        errors: all
        action: stage-rollback
      runtime:
        kubernetes:
          namespace: <your-delegate-namespace>
          connector: <your-k8s-connector>
          automount-service-token: true
          pull: always

The runtime.kubernetes block shows one example of running step containers on a Kubernetes cluster via your delegate. Set namespace and connector to match your delegate's Kubernetes namespace and cluster connector. You can also select Harness Cloud or Delegate as the runtime — go to Stage runtime for the full list of options.

---

Next steps

• Go to Lambda canary deployment to gradually shift traffic and validate the new version before full promotion.

• Go to Lambda services to review function definition requirements.

• Go to AWS Lambda Rolling Deploy step reference for the full field reference.

• Go to AWS Lambda Rolling Rollback step reference for the rollback step reference.