> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/continuous-delivery/3.0/use-deployments/overview-4/canary/rolling.md).

# 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 <a href="#what-you-will-learn" id="what-you-will-learn"></a>

* 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 <a href="#before-you-begin" id="before-you-begin"></a>

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

* **A Lambda service:** Go to [Lambda services](/continuous-delivery/3.0/use-deployments/overview-4/lambda-services.md) 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](/continuous-delivery/3.0/use-deployments/overview-4/lambda-services.md#alias-behavior) to review how the rolling deploy step handles aliases.
* **A Lambda infrastructure:** Go to [Lambda infrastructure](/continuous-delivery/3.0/use-deployments/overview-4/lambda-infrastructure.md) to connect an AWS account and region.

***

## How rolling deployments work <a href="#how-rolling-deployments-work" id="how-rolling-deployments-work"></a>

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 href="#configure-a-rolling-stage" id="configure-a-rolling-stage"></a>

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 <a href="#select-the-rolling-strategy" id="select-the-rolling-strategy"></a>

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 <a href="#configure-the-aws-lambda-rolling-deploy-step" id="configure-the-aws-lambda-rolling-deploy-step"></a>

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. |

{% hint style="info" %}
**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.
{% endhint %}

***

## Rolling deploy step output variables <a href="#rolling-deploy-step-output-variables" id="rolling-deploy-step-output-variables"></a>

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 <a href="#rollback" id="rollback"></a>

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 <a href="#complete-yaml-reference" id="complete-yaml-reference"></a>

<details>

<summary>Pipeline YAML</summary>

```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](/continuous-delivery/3.0/use-deployments/overview-4/lambda-infrastructure.md#stage-runtime) for the full list of options.

</details>

***

## Next steps <a href="#next-steps" id="next-steps"></a>

* Go to [Lambda canary deployment](/continuous-delivery/3.0/use-deployments/overview-4/canary.md) to gradually shift traffic and validate the new version before full promotion.
* Go to [Lambda services](/continuous-delivery/3.0/use-deployments/overview-4/lambda-services.md) to review function definition requirements.
* Go to [AWS Lambda Rolling Deploy step reference](/continuous-delivery/3.0/use-deployments/overview-4/lambda-canary-deploy/lambda-rolling-deploy.md) for the full field reference.
* Go to [AWS Lambda Rolling Rollback step reference](/continuous-delivery/3.0/use-deployments/overview-4/lambda-canary-deploy/lambda-rolling-rollback.md) for the rollback step reference.

{% @harness-feedback/feedback %}