miruky

Posted on Sep 13

Move a Lambda Alias Between Two Published Versions

#aws #lambda #serverless #tutorial

Introduction

Hi, I'm miruky.

Deploying code to $LATEST overwrites the mutable working copy of an AWS Lambda function. A numbered version locks its code and most configuration, while an alias gives callers a stable qualifier that can be moved to another published version. With automatic runtime management, AWS can still update the managed runtime beneath a published version; the handler code used here remains locked.

This Console run publishes a blue response as version 1, changes $LATEST to green, and publishes version 2. The alias miruky-ufbptfhvyhrsnlef initially returns blue and returns green after one alias edit.

The exercise uses three short Lambda invocations and a small CloudWatch log group. Check the current Lambda and CloudWatch pricing terms before running it.

1. Prepare the execution role and log group

This run keeps Lambda, the function log group, and every invocation in us-east-1; IAM itself is global.

The header confirms United States (N. Virginia) while the Lambda Console is in English. This fixes the Regional context before any Lambda or CloudWatch resource is created.

In IAM, create a role named miruky-wdecwpodyckyfbhd. Choose AWS service, select Lambda, and attach the AWS managed policy AWSLambdaBasicExecutionRole.

The role list shows the generated name and the Lambda service use case. That trust relationship allows the Lambda service to assume the role when the function runs.

The permissions table separately confirms that AWSLambdaBasicExecutionRole is attached. Splitting the trust and permissions evidence keeps account-specific policy data outside both images.

In CloudWatch Logs, confirm that miruky-zztahpchtfhkqnmz does not already exist. Create that log group in us-east-1 and set its retention to 1 day.

The log-group row shows miruky-zztahpchtfhkqnmz with retention set to 1 day. Its ARN and creation timestamp remain outside the crop.

These supporting resources are deliberately separate. The role lets Lambda write logs, while the short retention prevents this tiny validation log from being kept indefinitely.

2. Create the function and publish version 1

Open AWS Lambda, search for miruky-qyufvjidgkxukqrb, and confirm there is no exact match. Choose Create function, select Author from scratch, and use that generated name with the supported Python 3.14 runtime.

The function-settings crop shows miruky-qyufvjidgkxukqrb and Python 3.14 without extending into the permissions area.

Under Permissions, choose Use an existing role and select miruky-wdecwpodyckyfbhd.

The saved function configuration shows miruky-wdecwpodyckyfbhd as the execution role. Role ARNs and account-derived values stay outside the image; the default x86_64 architecture is checked privately.

After creation, open Monitoring and operations tools, edit Logging configuration, and select custom log group miruky-zztahpchtfhkqnmz. Replace the starter code with this version:

def lambda_handler(event, context):
    # Return the invoked version so the alias target is visible in the response.
    return {
        "release": "blue",
        "function_version": context.function_version,
    }

Choose Deploy. The code is still $LATEST, so it remains editable at this point.

The editor shows the deployed blue release value and context.function_version. Publishing this mutable working state will lock the handler code in a numbered version; the unqualified invocation in section 4 later confirms that the working qualifier is $LATEST.

Open Versions, choose Publish new version, enter blue response, and publish. In this validation, Lambda returned version 1.

The Versions page lists version 1 with the blue response description. Lambda version numbers increase monotonically and are not reused, so the number shown by the successful publication is part of the evidence rather than an assumed default.

3. Change the working copy and publish version 2

Return to $LATEST, change only the release value from blue to green, and choose Deploy again.

def lambda_handler(event, context):
    # Return the invoked version so the alias target is visible in the response.
    return {
        "release": "green",
        "function_version": context.function_version,
    }

The mutable editor now differs only at the release value, which is green. Version 1 remains unchanged while this working copy is deployed.

Publish another version with description green response. Lambda should create version 2, while version 1 keeps its original code.

The list now contains published versions 1 and 2 with their blue and green descriptions. The separate rows are the two eligible alias targets.

Lambda will not publish a duplicate snapshot if $LATEST has not changed since the previous publication. The one-value code change makes the two versions intentionally distinct.

4. Point the alias at version 1

Open Aliases, choose Create alias, and enter miruky-ufbptfhvyhrsnlef. Select version 1, leave Weighted alias unconfigured, and save.

The alias creation confirmation shows miruky-ufbptfhvyhrsnlef pointing to version 1. Because the form was saved without an additional weighted version, every alias invocation should reach the blue snapshot.

Before invoking the alias, return to the unqualified function, verify that the qualifier is $LATEST, open Test, and create one Private test event named miruky-nblpmshjvzfslryd with an empty JSON object:

{}

Invoke $LATEST once.

The response-only crop shows release green and function version $LATEST. The event editor, execution details, and request ID stay outside the image. That result is expected for an unqualified invocation, but it does not prove where the alias points.

Now open Aliases, choose miruky-ufbptfhvyhrsnlef, and open Test from that qualified view.

The qualifier-only crop shows miruky-ufbptfhvyhrsnlef instead of the unqualified working-copy qualifier immediately before the invocation. Function metadata and account-derived values stay outside the image.

Invoke the same saved private event.

The separate response-only crop shows release blue and function version 1. Request IDs and execution-log details are excluded.

The paired results make the qualifier boundary visible: $LATEST bypasses the alias, while the selected alias reaches its configured published version.

5. Move the same alias to version 2

Return to the alias configuration and choose Edit. Change Version from 1 to 2, keep Weighted alias unconfigured, and save without renaming the alias.

The saved configuration keeps the alias name unchanged and shows version 2. No additional weighted version was configured, so only the version pointer moved.

Invoke the same private test event through the alias again. The response should now contain "release": "green" and "function_version": "2".

The qualifier-only crop again shows miruky-ufbptfhvyhrsnlef instead of the unqualified working-copy qualifier immediately before the later invocation. This check prevents the next response from being mistaken for another unqualified working-copy test.

The separate response-only crop shows release green and function version 2. Together with the qualified-view evidence, that result proves the cutover without relying on invocation logs.

The caller-facing alias name did not change; only its version pointer moved. Published version 1 also remains available until that version, or the entire function, is deleted.

Wrap-up

The function's mutable $LATEST was published as two distinct numbered code snapshots. The alias returned blue from version 1; after one configuration change, it returned green from version 2.

Aliases separate a stable function qualifier from a specific release. Weighted aliases can extend the same mechanism to a two-version canary, but this run used a full cutover so the observed version was deterministic.

Thanks for reading this far.

See you in the next one.

Disclosure: This article was written with AI assistance and independently verified against the linked primary sources and observed results.

DEV Community