Lambda Versions and Aliases: Manage Deployment Lifecycle (2026)

Lambda versions and aliases are how you manage different states of your Lambda functions over time, letting you deploy, test, and roll back code safely.

Here’s a Lambda function in action, showing how a request flows through its versions and aliases:

{
  "functionName": "my-cool-function",
  "version": "1",
  "alias": "prod",
  "payload": {
    "message": "Hello, world!"
  },
  "response": {
    "statusCode": 200,
    "body": "{\"processed_message\": \"Hello, world! processed by v1\"}"
  }
}

This JSON represents a simplified request and response. When you invoke my-cool-function via the prod alias, it’s actually pointing to a specific version of the function’s code. Let’s say prod is currently pointing to version 1. The payload is the input, and the response is what the function returns after executing code from version 1.

The core problem Lambda versions and aliases solve is safe deployment and lifecycle management for serverless functions. Without them, every deployment is a "big bang" event, potentially breaking all users of the function.

Here’s how it works internally:

Versions: Every time you publish a new version of your Lambda function’s code, Lambda creates an immutable snapshot. This snapshot is assigned a unique version number (e.g., $LATEST, 1, 2, 3). $LATEST is a special pointer that always refers to the most recently uploaded code, but it’s not immutable and shouldn’t be used for production traffic. Actual versions, like 1, 2, are immutable.
Aliases: An alias is a named pointer that can be configured to point to a specific Lambda function version. You can create multiple aliases, such as dev, staging, prod, beta. You then configure your downstream services (API Gateway, other Lambdas, SQS queues) to invoke your function via an alias, not a specific version.

This separation is key. You can have prod alias pointing to version 2, and staging alias pointing to version 3. When you want to test version 3 in production, you update the prod alias to point to version 3. This is an atomic operation. If version 3 has issues, you can immediately switch the prod alias back to version 2 (or any other published version) within seconds, achieving a rollback.

The exact levers you control are:

Publishing a Version: Each time you update your function code and click "Publish new version," Lambda creates a new, immutable version.
Creating/Updating Aliases: You can create new aliases or update existing ones to point to any published version. For example, to point the prod alias to version 5:
```
aws lambda update-alias --function-name my-cool-function --name prod --function-version 5
```
Traffic Shifting (with Lambda’s deployment strategies): For more advanced canary deployments, you can configure an alias to send a percentage of traffic to a new version while the rest goes to the old one. This is done via the console or aws lambda create-alias / aws lambda update-alias with --routing-config. For example, to send 10% of traffic to version 6 and 90% to version 5 for the prod alias:
```
aws lambda update-alias --function-name my-cool-function --name prod --function-version 6 --routing-config '{"AdditionalVersionWeights":{"5":0.9}}'
```
(Note: This example is conceptual and the exact CLI parameters might differ slightly based on specific AWS CLI versions; the console is often easier for this).

One of the most powerful, yet often overlooked, aspects of aliases is their ability to manage weighted traffic distribution. This isn’t just about pointing an alias to one version. You can configure an alias to route a percentage of incoming requests to one version and the remaining percentage to another. For instance, you could set your prod alias to send 90% of traffic to version 4 and 10% to version 5. This allows for gradual rollouts and canary deployments. If the 10% of traffic hitting version 5 experiences errors, you can immediately revert the alias’s weights, or even remove version 5 entirely from the alias’s routing configuration, without interrupting service for the majority of users.

The next concept you’ll likely encounter is managing the lifecycle of these versions and aliases, particularly when dealing with CI/CD pipelines and cleaning up older, unused versions.