AWS DVA-C02 Drill: Lambda Version Aliases - Weighted Routing vs. Deployment Strategies

Jeff’s Note

#

Jeff’s Note

“Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.”

“For DVA-C02 candidates, the confusion often lies in mixing deployment orchestration tools (CodeDeploy) with native Lambda versioning features. In production, this is about knowing exactly which AWS service primitives handle traffic distribution versus which tools automate the deployment process. Let’s drill down.”

The Certification Drill

#

Scenario

#

StreamWave, a video processing platform, is rolling out enhanced thumbnail generation logic to their AWS Lambda function. The development team maintains two active function versions: the stable PROD alias pointing to version 12, and the experimental DEV alias pointing to version 14. The Lead Developer needs to create a STAGING environment that can invoke both the production-ready code (v12) and the new candidate code (v14) simultaneously to conduct live traffic comparison testing before full promotion.

The Requirement:

#

Configure a staging environment for the Lambda function that can handle invocations to both the development version and the production version with controlled traffic distribution.

The Options

#

• A) Create a weighted alias that references the production version of the function and the updated version of the function.
• B) Add a Network Load Balancer. Add the production version of the function and updated version of the function as targets.
• C) Use AWS CodeDeploy to create a linear traffic shifting deployment.
• D) Create a tag for the Lambda function that contains the production version and updated version of the code.

Correct Answer

#

Option A.

Quick Insight: The Native Lambda Feature Imperative

#

For Developers: Lambda weighted aliases are a first-class versioning feature that operates at the invocation layer. Unlike deployment automation tools (CodeDeploy) or infrastructure routing (NLB), weighted aliases use the RoutingConfig parameter in the CreateAlias or UpdateAlias API to split traffic between two specific Lambda versions—no external orchestration required.

Content Locked: The Expert Analysis

#

You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?

The Expert’s Analysis

#

Correct Answer

#

Option A: Create a weighted alias that references the production version of the function and the updated version of the function.

The Winning Logic

#

Lambda weighted aliases are purpose-built for precisely this scenario. Here’s why this is the developer-centric solution:

1. Native Lambda Feature: The RoutingConfig parameter in the alias configuration allows you to specify two Lambda versions with percentage weights (e.g., 90% to PROD/v12, 10% to DEV/v14).

2. Invocation-Level Distribution: When clients invoke the STAGING alias, Lambda’s internal routing automatically distributes requests according to the weights—no external load balancer or deployment tool required.

3. API Implementation:

   aws lambda update-alias \
     --function-name StreamWaveProcessor \
     --name STAGING \
     --routing-config AdditionalVersionWeights={"14"=0.10} \
     --function-version 12
   

   This routes 90% traffic to version 12 (primary) and 10% to version 14.

4. Developer Control: You can adjust weights via UpdateAlias API calls without redeploying code—ideal for canary testing or A/B experiments.

5. CloudWatch Integration: Lambda automatically emits metrics per version (Invocations, Errors, Duration) allowing precise comparison.

The Trap (Distractor Analysis):

#

• Why not B (Network Load Balancer)?

  • Lambda functions are not valid NLB targets. NLBs operate at OSI Layer 4 (TCP/UDP) and target IP addresses or instances—Lambda uses event-driven invocations via the Lambda API, not persistent TCP connections. This option reveals a fundamental misunderstanding of Lambda’s invocation model.

• Why not C (AWS CodeDeploy linear deployment)?

  • CodeDeploy for Lambda automates the process of creating weighted aliases and shifting traffic over time (linear/canary patterns), but it’s deployment orchestration, not the underlying mechanism. The question asks to “configure a staging environment,” not “automate a production deployment.” CodeDeploy is overkill and introduces unnecessary complexity for a simple multi-version testing scenario. More critically, CodeDeploy manages blue/green transitions—it doesn’t create a persistent staging alias that simultaneously invokes two versions.

• Why not D (Tags)?

  • Lambda tags are key-value metadata for resource organization and cost allocation. They have zero runtime impact on invocation routing. You cannot “invoke a tag” or use tags to control traffic distribution. This is a category error.

The Technical Blueprint

#

# Step 1: Publish new Lambda version (development code)
aws lambda publish-version \
  --function-name StreamWaveProcessor \
  --description "Enhanced thumbnail generation v14"
# Output: "Version": "14"

# Step 2: Create weighted STAGING alias
aws lambda create-alias \
  --function-name StreamWaveProcessor \
  --name STAGING \
  --function-version 12 \
  --routing-config '{"AdditionalVersionWeights": {"14": 0.10}}'

# Step 3: Invoke the STAGING alias (Lambda routes 90% to v12, 10% to v14)
aws lambda invoke \
  --function-name StreamWaveProcessor:STAGING \
  --payload '{"videoId": "test123"}' \
  response.json

# Step 4: Monitor version-specific metrics
aws cloudwatch get-metric-statistics \
  --namespace AWS/Lambda \
  --metric-name Duration \
  --dimensions Name=FunctionName,Value=StreamWaveProcessor Name=Resource,Value=StreamWaveProcessor:12 \
  --start-time 2025-01-24T00:00:00Z \
  --end-time 2025-01-24T23:59:59Z \
  --period 3600 \
  --statistics Average

# Step 5: Adjust weights dynamically (increase to 50/50)
aws lambda update-alias \
  --function-name StreamWaveProcessor \
  --name STAGING \
  --routing-config '{"AdditionalVersionWeights": {"14": 0.50}}'

Key Developer Notes:

• The AdditionalVersionWeights map specifies secondary version weights. The remaining percentage (100% - sum of weights) goes to the primary version specified in --function-version.
• Alias ARNs remain constant (arn:aws:lambda:region:account:function:StreamWaveProcessor:STAGING), making this transparent to API Gateway or EventBridge integrations.
• X-Ray Integration: If active tracing is enabled, X-Ray subsegments will show invocation paths per version.

The Comparative Analysis

#

Real-World Application

#

Exam Rule

#

“For the DVA-C02 exam, when you see ’traffic distribution between two Lambda versions’ + ‘staging environment’, immediately think weighted alias. CodeDeploy is for automating deployments, not for manually configuring test environments.”

Real World

#

“In production at scale, we often use CodeDeploy’s CodeDeployDefault.LambdaLinear10PercentEvery1Minute preset to automate the weighted alias updates and rollback logic. However, for ad-hoc developer testing or persistent staging environments, manually creating weighted aliases gives you surgical control without the deployment pipeline overhead. We once debugged a memory leak by routing 5% of production traffic to a patched version via a weighted alias—no deployment, no risk, just live data validation.”

Developer Pro Tip:
Combine weighted aliases with Lambda function URLs or API Gateway stage variables to create ephemeral test endpoints:

# API Gateway stage variable pointing to weighted alias
aws apigateway update-stage \
  --rest-api-id abc123 \
  --stage-name staging \
  --patch-operations op=replace,path=/variables/lambdaAlias,value=STAGING

Stop Guessing, Start Mastering

#

Disclaimer

This is a study note based on simulated scenarios for the AWS DVA-C02 exam. StreamWave is a fictional company created for educational purposes. All technical implementations reflect AWS best practices as of January 2025.