AWS 143: Lambda versions, aliases and layers
Why this lesson matters
Publish immutable function versions, route stable aliases, perform controlled weighted releases, and use layers without hiding ungoverned dependencies.
What you will be able to do
By the end, you can:
- explain lambda versions, aliases and layers in plain language;
- locate the current service controls in the AWS Management Console;
- run the matching CloudShell or AWS CLI queries and explain every important field;
- draw the identity, network, data, failure, and monitoring path;
- choose the service from requirements and reject it when those requirements are absent;
- diagnose a failed or misleading result from evidence;
- state the cost owner and prove cleanup or a no-create result.
Before you start
- Use a personal AWS account only when its owner has approved the lesson. Do not use the root user for daily work.
- CloudShell is the default command environment. AWS028 explains CloudShell; AWS029 and AWS030 explain local AWS CLI installation and profiles.
- The course example Region is
ap-south-1. Global services and services with a required control Region are called out in their commands. - Run
aws sts get-caller-identityprivately. Redact the account number before sharing evidence. - Never paste access keys, passwords, secret values, private object data, presigned URLs, or full account-specific ARNs into a submission.
- This is a no-create lesson. Every Console action and AWS CLI command is read-only. Create the practical artifact locally.
- Console wording can change. Use the Console service search if a menu label has moved, then confirm the current field in the official documentation.
The core model
| Question | What it means in this lesson |
|---|---|
| Purpose | Publish immutable function versions, route stable aliases, perform controlled weighted releases, and use layers without hiding ungoverned dependencies. |
| Scope and boundary | The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Lambda versions, aliases, and layers. |
| Evidence of success | Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Lambda versions, aliases, and layers. |
| Cost model | Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design. |
| Safe rejection rule | Avoid invoking $LATEST in production or using layers as an untracked dumping ground for dependencies. |
How the request flows
+--------------------------+
| Published code version |
+--------------------------+
|
v
+-------------------------------------+
| Stable alias with optional weight |
+-------------------------------------+
|
v
+----------------------+
| Invocations |
+----------------------+
|
v
+-----------------------------------------+
| Version-specific metrics and rollback |
+-----------------------------------------+For Lambda versions, aliases, and layers, the important boundary is this: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Lambda versions, aliases, and layers. Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Lambda versions, aliases, and layers. That is why the lesson pairs the Console with CLI output and a practical artifact. One interface may hide a field, use a cached view, or be scoped differently. Matching evidence is stronger than a screenshot alone.
Architecture decision table
| Situation | Direction | Reason |
|---|---|---|
| Requirement matches | Use versions and aliases for reproducible release targets and fast routing rollback. | Select only after scope, behavior, security, recovery, operations, and price evidence agree. |
| Requirement does not match | Avoid invoking $LATEST in production or using layers as an untracked dumping ground for dependencies. | Rejecting an attractive service is a valid architecture result. |
| No create permission or cost approval | Use supplied evidence and local design work | Learning does not depend on creating an hourly resource. |
| Existing resource is unknown or unowned | Inspect only, then stop | Never change or delete a resource merely because it resembles a course example. |
Immutable release model
$LATEST is the mutable working version. Publishing captures eligible code and configuration into a numbered, immutable version; later edits require another version. An alias such as dev, staging or prod points to a published version and has its own ARN. Triggers, permissions, clients and provisioned concurrency should target the intended alias/qualified ARN so production does not silently follow $LATEST.
A weighted alias routes probabilistically between its primary version and one additional published version. Low request volumes can differ greatly from the configured percentage, so a canary needs enough samples and version-specific evidence. Both versions must satisfy current compatibility restrictions. Observe ExecutedVersion, logs, errors, duration, throttles and business outcomes - not aggregate alias success alone. Rollback repoints the alias to the known-good version; it does not delete forensic evidence.
Layers are immutable versioned ZIP dependencies mounted into the environment. They can centralize libraries, extensions or CA assets for ZIP functions, but introduce coupling: layer order/path, runtime/CPU architecture, transitive dependencies, license/SBOM, signing, vulnerabilities, sharing and package limits matter. Updating a layer does not alter consumers until each function references the new layer version. Container-image functions package dependencies in the image instead.
Record source commit, build digest, dependency lock/SBOM, runtime, architecture, configuration digest, layer-version ARNs and template for every release. Do not bake secrets into layers. Old versions consume code storage and may retain vulnerable artifacts; remove only artifacts not referenced by aliases, event sources, provisioned concurrency or rollback policy.
AWS Management Console, step by step
Sign in with the normal non-root learning identity. Write the expected starting state before opening the service.
- Use the Console service search and open Lambda, Functions, Versions, Aliases, and Layers; confirm the account and Region before reading the page.
- Inspect the supplied or owned resource's status, configuration, permissions, networking, encryption, monitoring, tags, and dependencies without changing it.
- Open the related metrics, logs, events, or history view and record one timestamped signal that would prove or disprove the expected behavior.
- Return to the resource list, clear filters, and record the final inventory. On the read-only track, do not choose Create, Save, or Delete.
CloudShell and AWS CLI, step by step
Start with a known caller and Region:
export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws configure listRedact the account part of the ARN in shared evidence. Now run the topic queries:
aws lambda list-versions-by-function --function-name replace-with-function-name --query 'Versions[].{Version:Version,Modified:LastModified,Description:Description}' --output table
aws lambda list-aliases --function-name replace-with-function-name --output table
aws lambda list-layers --output tableExpected interpretation
Versions are immutable snapshots of code and most configuration. Alias routing is deployment state; it still needs metrics, rollback criteria, and dependency compatibility.
Practical work
Design a 10 percent canary from version 6 to version 7. Name the alias, alarms, observation time, rollback command, layer version pin, and evidence retained.
Define pre-traffic tests, minimum sample size, p95/p99 duration, error/throttle and business-correctness abort thresholds. Prove both versions using ExecutedVersion; inject a version-7-only error and show rollback timing. Compare bundled dependencies, a layer and a container image. Include permission qualifiers, provisioned concurrency alignment, CodeDeploy/SAM automation and retention cleanup.
Diagnose this topic from its own evidence
If new code never runs, inspect invoked ARN/alias, routing and trigger qualifier before redeploying. If ratio looks wrong, compare sample count and ExecutedVersion; routing is probabilistic. Import errors after a layer change require runtime, architecture, path and dependency-order inspection. Provisioned-concurrency spillover during canary can mean capacity is attached to the wrong alias/version. Roll back first when thresholds fail, preserve evidence, then diagnose the immutable candidate.
Cost and cleanup
Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.
Knowledge check
- What operational purpose is this lesson solving?
Expected direction: Publish immutable function versions, route stable aliases, perform controlled weighted releases, and use layers without hiding ungoverned dependencies.
- Which scope or ownership boundary must be proved first?
Expected direction: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Lambda versions, aliases, and layers.
- What evidence is strong enough to accept the result?
Expected direction: Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Lambda versions, aliases, and layers.
- Which tempting design or shortcut must be rejected?
Expected direction: Avoid invoking $LATEST in production or using layers as an untracked dumping ground for dependencies.
- Which cost dimensions and retained resources need an owner?
Expected direction: Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.
Lesson acceptance
Pass when the learner distinguishes $LATEST, versions and aliases; runs a measured weighted release with version-specific alarms and rapid alias rollback; and pins/governs layers by version, runtime, architecture, SBOM and owner. Fail if production invokes $LATEST, aggregate metrics hide the canary, a layer is treated as auto-updating consumers, or artifacts are deleted without dependency checks.