AWS Version and Release Management: Labels, Branches, and Aliases

This study guide focuses on the critical skill of managing application versions and releases across various AWS services. Mastering how to use labels, aliases, and branches is essential for implementing robust CI/CD pipelines, performing rollbacks, and managing multi-environment deployments (Dev, Test, Prod).

---

Learning Objectives

By the end of this module, you should be able to:

• Differentiate between immutable versions and mutable aliases/labels.
• Configure Lambda Aliases for traffic shifting and canary deployments.
• Implement API Gateway Stages and Stage Variables for environment-specific routing.
• Manage AWS Amplify branches to automate front-end environment provisioning.
• Apply container tagging strategies for consistent ECS/EKS deployments.

Key Terms & Glossary

• Immutable Version: A read-only snapshot of code or configuration that cannot be changed once created (e.g., Lambda Version 5).
• Alias/Label: A pointer or symbolic name that refers to a specific version (e.g., the "PROD" alias pointing to Version 5).
• Traffic Shifting: The process of gradually moving request traffic from an old version to a new version (Canary deployment).
• Stage Variable: A key-value pair in API Gateway used to dynamically change backend behavior based on the deployment stage.
• Blue/Green Deployment: A strategy where two identical environments (Blue for old, Green for new) run simultaneously to ensure zero-downtime transitions.

The "Big Idea"

The core philosophy of AWS release management is decoupling the consumer from the implementation. By using labels (like Lambda Aliases or API Gateway Stages), consumers always point to a stable name (e.g., api.example.com/prod), while developers can swap the underlying versions or branch code without breaking the connection. This enables safe testing and instantaneous rollbacks.

Formula / Concept Box

Hierarchical Outline

1. Lambda Versioning and Aliases
   • Versions: Created via PublishVersion. Includes code + configuration.
   • Aliases: Pointers to a version. Supports Routing Configuration (e.g., 90% to v1, 10% to v2).
2. API Gateway Environment Management
   • Stages: Logical references to a deployment (e.g., prod or dev).
   • Stage Variables: Used in integration URIs (e.g., arn:aws:lambda:...:${stageVariables.functionName}).
3. Container Release Management
   • ECR Tags: Use immutable tags in production to prevent "latest" tag drift.
   • Task Definitions: Reference specific image tags for deterministic scaling.
4. AWS Amplify Branching
   • Branch Mapping: Connect main branch to the production URL and develop to the staging URL.
   • Feature Branching: Auto-provisioning temporary environments for Pull Requests.

Visual Anchors

Lambda Traffic Shifting (Canary)

Multi-Environment Pipeline Flow

\begin{tikzpicture}[node distance=2cm, every node/.style={rectangle, draw, fill=blue!10, text width=2.5cm, align=center, rounded corners}] \node (code) {CodeCommit$Branch: main)}; \node (build) [right of=code, xshift=2cm] {CodeBuild$Tag: v1.2)}; \node (deploy) [right of=build, xshift=2cm] {CodeDeploy$Alias: PROD)};

\end{tikzpicture}

Definition-Example Pairs

• Term: Stage Variables

  • Definition: Values defined at the API Gateway Stage level that act as environment variables for the API.
  • Example: Defining a variable lambdaAlias as "PROD" on the production stage. The API calls MyFunction:${stageVariables.lambdaAlias}, ensuring the production API always hits the production Lambda code.

• Term: Amplify Feature Branching

  • Definition: The ability to automatically create a unique URL and backend environment for every new Git branch.
  • Example: A developer creates branch feature-login. Amplify detects this, deploys a temporary frontend at https://feature-login.d123.amplifyapp.com, and deletes it when the branch is merged.

Worked Examples

Example 1: Updating a Lambda Function Safely

Scenario: You have a critical Lambda function. You need to deploy a bug fix without risking downtime.

1. Publish: Upload new code and call PublishVersion. AWS assigns it Version 12.
2. Test: Invoke arn:aws:lambda:region:acc:function:my-func:12 directly to verify the fix.
3. Update Alias: Update the PROD alias to point to Version 12 using the CLI: aws lambda update-alias --function-name my-func --name PROD --function-version 12.
4. Verification: If errors spike, immediately update the alias back to Version 11.

Example 2: API Gateway Routing with Stage Variables

Scenario: You want one API definition to point to two different DynamoDB tables based on the URL.

1. Configure Stages: Create stages dev and prod.
2. Set Variables: In dev, set tableName = "DevTable". In prod, set tableName = "ProdTable".
3. Mapping: In your integration (e.g., a Lambda function or Direct Service Integration), use ${stageVariables.tableName} in the request template.

Checkpoint Questions

1. Question: Can you modify the code of a Lambda Function Version after it has been published?
2. Question: How do you implement a 10% canary deployment using Lambda?
3. Question: If you delete an API Gateway Stage, what happens to the underlying Deployments?
4. Question: In AWS Amplify, how do you protect your production environment from unauthorized changes via Git?

▶Click to see Answers

1. No. Versions are immutable. You must publish a new version for any changes.
2. Answer: Use a Lambda Alias with routing-config. Set the AdditionalVersionWeights property to point 0.1 (10%) of traffic to the new version.
3. Answer: The Deployments remain in history, but the Stage URL becomes invalid. You can re-create a stage and point it back to any existing Deployment.
4. Answer: Connect the main branch to the production environment and enable "Branch Protection" in your Git provider. Use Amplify's "Webhooks" or "Conditional Deploys" to ensure only reviewed code reaches production.

[!TIP] For the DVA-C02 exam, remember that Aliases are used for Lambda traffic shifting, while Stage Variables are the primary way to manage environment-specific metadata in API Gateway.