<h2 id="content"><a href="#content" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>Content</h2>
<ul>
<li><a href="#introduction">Introduction</a></li>
<li><a href="#existing-versioning">Existing versioning</a>
<ul>
<li><a href="#immutable-versions">Immutable Versions</a></li>
<li><a href="#understanding-latest">Understanding $LATEST</a></li>
</ul>
</li>
<li><a href="#understanding-the-lambda-arn">Understanding the Lambda ARN</a></li>
<li><a href="#pros-and-cons">Pros and Cons</a>
<ul>
<li><a href="#static-versioning-qualified-arn">Static versioning qualified ARN</a></li>
<li><a href="#dynamic-versioning---latest-unqualified-arn">Dynamic versioning $LATEST</a></li>
</ul>
</li>
<li><a href="#what-makes-aws-lambda-alias-different-">What makes AWS Lambda Alias different ?</a></li>
<li><a href="#aws-lambda-alias-example">AWS Lambda Alias Example</a></li>
<li><a href="#aws-lambda-alias-iam-gotcha">AWS Lambda Alias IAM Gotcha</a></li>
<li><a href="#advanced-deployments">Advanced deployments</a>
<ul>
<li><a href="#traffic-shifting-configuration">Traffic shifting</a></li>
<li><a href="#aws-codedeploy">AWS Codedeploy</a></li>
</ul>
</li>
<li><a href="#conclusion">Conclusion</a></li>
</ul>
<h2 id="introduction"><a href="#introduction" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>Introduction</h2>
<p>AWS Lambda Alias is a feature that makes it easier to manage your Lambda function versions.</p>
<p>It works by creating a “container” which points to a published version of your Lambda function.</p>
<p>There are several benefits to this.</p>
<p><strong>Benefits:</strong></p>
<ul>
<li>You can have safer deployments in your Software Development Lifecycle (SDLC)</li>
<li>You can have dynamic references Lambda function versions</li>
</ul>
<p>In this guide, we will talk about the existing versioning strategies used by AWS Lambda then look at why Lambda alias is a better choice.</p>
<p>Let’s dive right in.</p>
<h2 id="existing-versioning"><a href="#existing-versioning" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>Existing versioning</h2>
<h3 id="immutable-versions"><a href="#immutable-versions" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>Immutable versions</h3>
<p>By default, when you publish changes on your Lambda function, it creates a new version.</p>
<p>This new version is considered to be immutable, meaning that you cannot change it’s identifier (ARN) or the function code once it is published.</p>
<h3 id="understanding-latest"><a href="#understanding-latest" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>Understanding $LATEST</h3>
<p>In addition to the immutability of the versions, AWS Lambda automatically promotes the latest version to a default alias <code class="language-">$LATEST
</code>.</p>
<p>This is important to understand the later sections when we start to discuss the AWS resource identifier (ARN) used when referencing a lambda resource.</p>
<h2 id="understanding-the-lambda-arn"><a href="#understanding-the-lambda-arn" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>Understanding the Lambda ARN</h2>
<p>Within AWS, each resource can be identified with an unique resource identifier (ARN).</p>
<p>With Lambda, it is the same but it does has some subtle differences.</p>
<p>Lambda separates the AWS resource identifier (ARN) into two types:</p>
<ul>
<li><strong>Qualified ARN</strong> - versioned</li>
<li><strong>Unqualified ARN (Default)</strong> - does not include version (points to <code class="language-">$LATEST
</code> alias)</li>
</ul>
<p>It is important to distinguish between the two because it will determine which lambda function version they will reference.</p>
<p>When you use a <strong>”qualified ARN”</strong>, you are referencing a specific version of lambda.</p>
<p>While, the <strong>”unqualified ARN”</strong> is a reference to the latest version of lambda function (this is done via the <code class="language-">$LATEST
</code> alias).</p>
<p>The difference is quite subtle but it is important to make the distinction because you may reference a lambda ARN and then have it change when someone else makes a new code change.</p>
<p>Each of these have their respective pros and cons which we will discuss in the next section.</p>
<p><strong>Example (qualified ARN):</strong></p>
<div class="remark-highlight"><pre class="language-sh"><code>arn:aws:lambda:aws-region:acct-id:function:myFunction:42
</code></pre></div>
<p><strong>Example (unqualified ARN):</strong></p>
<div class="remark-highlight"><pre class="language-sh"><code>arn:aws:lambda:aws-region:acct-id:function:myFunction
</code></pre></div>
<blockquote class="common">
 ⚠️ An <b>Unqualified Lambda ARN</b> will always point to the latest published version via the <b>$LATEST</b> alias
</blockquote>
<h2 id="pros-and-cons"><a href="#pros-and-cons" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>Pros and Cons</h2>
<h3 id="static-versioning-qualified-arn"><a href="#static-versioning-qualified-arn" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>Static versioning (qualified ARN)</h3>
<div style="display:flex;justify-content:center;margin: 4em auto;">
<img src="/images/lambda-alias-qualified-alias.png" alt="lambda qualified alias" style="width:75%" />
</div>
<p>The biggest pro of static versioning is also it’s biggest con.</p>
<p>With static versioning, you do have more control over which version of the lambda function you will be pointing to.</p>
<p>This allows for safer deployments because you decide which versions are promoted in your infrastructure.</p>
<p>However, this also locks you in, and requires you make subsequent updates to any resources referencing it (ie api gateway, event source integrations).</p>
<p><strong>Pros:</strong></p>
<ul>
<li>Safe deployments</li>
</ul>
<p><strong>Cons:</strong></p>
<ul>
<li>Subsequent updates required for resources</li>
</ul>
<h3 id="dynamic-versioning---latest-unqualified-arn"><a href="#dynamic-versioning---latest-unqualified-arn" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>Dynamic versioning - $LATEST (unqualified ARN)</h3>
<div style="display:flex;justify-content:center;margin: 4em auto;">
<img src="/images/lambda-alias-unqualified-alias.png" alt="lambda unqualified alias" style="width:75%" />
</div>
<p>This is the opposite of static versioning where you have a lot of flexibility in terms of referencing the lambda function versions because it always gets updated via <code class="language-">$LATEST
</code>.</p>
<p>However, this workflow may be risky because you are automatically promoting any new version of your lambda function into a live environment without any testing.</p>
<p><strong>Pros:</strong></p>
<ul>
<li>Subsequent updates are not required for resources</li>
</ul>
<p><strong>Cons:</strong></p>
<ul>
<li>Risky deployments (latest versions are always used)</li>
</ul>
<p>In a typical Software development lifecycle (SDLC), ideally, you will go through the build and then do some testing then go live once you are ready.</p>
<p>So, is there a better choice ?</p>
<p>Yes, of course! This is where AWS Lambda alias comes in.</p>
<h2 id="what-makes-aws-lambda-alias-different-"><a href="#what-makes-aws-lambda-alias-different-" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>What makes AWS Lambda Alias different ?</h2>
<div style="display:flex;justify-content:center;margin: 4em auto;">
<img src="/images/lambda-alias-alias-dev.png" alt="lambda alias dev" style="width:75%" />
</div>
<p>AWS lambda alias is a custom named “container” that points to a specific version of your lambda function.</p>
<p>The version referenced in an alias can be updated at anytime.</p>
<p>This gives you the flexibility as well as the safety because you can promote a version whenever it is considered ready to go live.</p>
<p>In addition, any references to the alias will always point to a target version.</p>
<p>So, with this setup, there is no need to make updates to any other resource referencing the ARN!</p>
<p><strong>Pros:</strong></p>
<ul>
<li>Subsequent updates are not required for other resources</li>
<li>Safe deployments (you are in control of the reference)</li>
</ul>
<p>With the AWS Lambda alias, you get the best of both worlds!</p>
<h2 id="aws-lambda-alias-example"><a href="#aws-lambda-alias-example" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>AWS Lambda Alias example</h2>
<p>Here is an example of using the AWS lambda alias.</p>
<p>In your workflow, you can have separate stages (or alias) which can be:</p>
<ul>
<li><strong>dev</strong> - for development and testing purposes</li>
<li><strong>prod</strong> - for live environment</li>
</ul>
<div style="display:flex;justify-content:center;margin: 4em auto;">
<img src="/images/lambda-alias-alias-example.png" alt="lambda alias example" style="width:75%" />
</div>
<p>Then as you run your CI/CD, you can update each of the alias accordingly.</p>
<p>The workflows will depend on the CI tool.</p>
<p><strong>Using the AWS CLI, you can achieve this by running:</strong></p>
<div class="remark-highlight"><pre class="language-sh"><code>aws lambda update-alias \
    --function-name &quot;myFunction&quot; \
    --name &quot;prod&quot; \
    --function-version &quot;2&quot;
</code></pre></div>
<h2 id="aws-lambda-alias-iam-gotcha"><a href="#aws-lambda-alias-iam-gotcha" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>AWS Lambda Alias IAM Gotcha</h2>
<p>There is a small gotcha with with AWS Lambda Alias, and it is related what you need to reference in your IAM permissions and policies.</p>
<ul>
<li><strong>Event source (API gateway, event triggers etc)</strong> - should reference the ARN of the lambda alias to provide invoke permissions</li>
<li><strong>Run time permissions (Access to S3, DB etc)</strong> - should reference the ARN of the lambda function</li>
</ul>
<div style="display:flex;justify-content:center;margin: 4em auto;">
<img src="/images/lambda-alias-IAM-permissions.png" alt="Lambda ARN reference difference when using an alias" style="width:75%" />
</div>
<blockquote class="common">
<b>Just keep this in mind when using AWS Lambda Alias</b> ❗️
</blockquote>
<h2 id="advanced-deployments"><a href="#advanced-deployments" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>Advanced deployments</h2>
<h3 id="traffic-shifting-configuration"><a href="#traffic-shifting-configuration" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>Traffic shifting configuration</h3>
<div style="display:flex;justify-content:center;margin: 4em auto;">
<img src="/images/lambda-alias-traffic-shifting.png" alt="lambda alias traffic shifting" style="width:75%" />
</div>
<p>There are also other benefits with using AWS Lambda alias, these include advanced deployment patterns which AWS offers natively.</p>
<p>By default, the AWS CLI for lambda supports traffic shifting (or weighted deployment) where you can split the traffic between two versions using a percentage (%).</p>
<p><strong>Using the AWS CLI, you can achieve this by running:</strong></p>
<div class="remark-highlight"><pre class="language-sh"><code>aws lambda update-alias \
    --function-name &quot;myFunction&quot; \
    --name &quot;prod&quot; \
    --function-version &quot;2&quot; \
    --routing-config AdditionalVersionWeights={&quot;2&quot;=0.1}
</code></pre></div>
<p><strong>This means 10% traffic will be shifted to version 2 while rest of the 90% will stay on version 1.</strong></p>
<h3 id="aws-codedeploy"><a href="#aws-codedeploy" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>AWS Codedeploy</h3>
<p>AWS Codedeploy also supports lambda releases with canary deployments where you can delegate deployment to codedeploy.</p>
<p>It will still make use the traffic shifting, however, the eventual goal is to shift 100% over to the target resource.</p>
<p>AWS Codedeploy also supports automatic rollback based on cloudwatch metrics during the canary rollout phase.</p>
<h2 id="conclusion"><a href="#conclusion" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>Conclusion</h2>
<p>To recap, AWS Lambda alias bridges the gap between the existing solutions using static and dynamic versioning.</p>
<p>This allows for flexibility the version promotion hence the safety in the deployments.</p>
<p>Finally, any references to the lambda ARN do not need to be updated when using an alias!</p>
<p>This makes it a much better choice in general, you get the best of both worlds!</p>
<p><strong>Here is a quick summary of the versioning strategies:</strong></p>
<div style="display:flex;justify-content:center;margin: 4em auto;">
<img src="/images/lambda-alias-versioning-comparison-v2.png" alt="Lambda Alias versioning comparison" />
</div>
<p>That’s all, I hope that was helpful!</p>


Understand the pro and cons of the different lambda versioning strategies

Jerry Chang

Go Back

The ultimate guide to AWS Lambda Alias

Enjoy the content ?