メインコンテンツに移動
How to be a Developer

テクニカルインストラクターと学ぶ AWS Lambda 関数のバージョンとエイリアス

2025-09-04 | Author : 杉本圭太

はじめに

テクニカルインストラクターの杉本圭太です !
最近読んで面白かった漫画は「RIOT」です。

AWS Lambda にはバージョンエイリアスという機能があり、Lambda 関数の柔軟なリリースを行うために役立ちます !

公式ドキュメントの説明は端的にまとめられているので、どのように使うとメリットがあるのかをいまいち理解できていないという方もいるかもしれません !

そこでトレーニング中にも受講者からよく聞かれるこれらの機能について、私なりに描いた図と共に使用例やメリット、注意点などを紹介していきます !

Lambda 関数の基本を知りたい方は、はじめに 「AWS Lambda 関数の実行の仕組みを知ろう !」 の連載を読んでみてください !


X ポスト »
| Facebook シェア » | はてブ »

Missing alt text value

builders.flash メールメンバー登録

builders.flash メールメンバー登録で、毎月の最新アップデート情報とともに、AWS を無料でお試しいただけるクレジットコードを受け取ることができます。

今すぐ登録 »

Lambda 関数のバージョン

Lambda 関数は、とある時点の関数の状態 (ライブラリを含めてパッケージしたコード、レイヤーや環境変数の設定など) にバージョンを付けて管理できる機能があります。バージョンは同じ関数に対して何度も作成でき、作成するたびに 1, 2, 3... と順に番号が振られて管理されます。

しかしそれとは別に Lambda 関数には「$LATEST」というバージョンが必ず用意されています。これは文字通り現在デプロイされている Lambda 関数の最新のコードを指し示すものですが、みなさんは意識しなくても使用できます。なぜかというと Lambda 関数の実行 (呼び出し) をする場合、明示的にバージョンを指定しなければ「$LATEST」が実行されるからです。

Lambda 関数は InvokeInvokeWithResponseStream の API で実行します。これらの API では FunctionName というパラメーターに実行したい Lambda 関数の名前もしくは ARN を指定します。例えば呼び出し元と同じアカウントかつ同じリージョンにある「my-function」という Lambda 関数を実行したい場合は、FunctionName に「my-function」と指定すると「$LATEST」が実行されるということです。もしくは「arn:aws:lambda:us-west-2:123456789012:function:my-function」のような ARN を指定しても良いです。

Missing alt text value

Lambda 関数のバージョンを作成

では Lambda 関数のバージョンを作成してみましょう。そのためには PublishVersion の API を使用するのですが、コンソールからであれば数クリックでこの API を呼び出して新しいバージョンを作成できます。これにより「$LATEST」のコードや設定値などの状態がそのままスナップショットされ、バージョン番号が振られて保管されます。対象の Lambda 関数で初めてバージョンを作成すると、番号 1 のバージョンが作成されます。

このバージョンを実行したい場合は「arn:aws:lambda:us-west-2:123456789012:function:my-function:1」のように、関数名の後に「:」をつけてバージョンを指定します。

Missing alt text value

Lambda 関数の呼び出し側でバージョンまで指定した場合の課題

Lambda 関数のトリガーとして Amazon API Gateway や Amazon S3 を設定する場合、呼び出す Lambda 関数を「$LATEST」にしていると、Lambda 関数の変更が即時に呼び出しているサービスの挙動に影響します。「$LATEST」の指定をしないことで、Lambda 関数の変更タイミングと呼び出す側への反映のタイミングを別々に制御できます。

しかし Lambda 関数の呼び出し側でバージョンまで指定してしまうと、Lambda 関数のコードや設定値を修正した後は毎回呼び出し側でも指定するバージョンを変更する手間がかかってしまうという課題は残ります。

呼び出し側では「$LATEST」ではなくバージョンを指定してイミュータブルな Lambda 関数を実行したい、しかし意図した Lambda 関数の更新があれば呼び出し側の手間をかけずに切り替えたい、そんなわがままな要望を叶えてくれるのが次に紹介するエイリアスという機能です !

Missing alt text value

Lambda 関数のエイリアス

エイリアスは Lambda 関数ごとに設定できる特定のバージョンを指すポインタです。そのためエイリアスは先にバージョンを用意しておかないと作成できません。例えばバージョンを 3 つ用意している状態で、エイリアス「live」を作成してバージョン 2 を指すという使い方ができます。

Missing alt text value

エイリアスの利点

それだけだとバージョンを直接指定すれば良いように思えますが、エイリアスによって以下のことができるようになります。

  • エイリアスが指すバージョンはいつでも変更できる
  • エイリアスは 2 つのバージョンを同時に指すことができ、さらに実行する割合に加重をかけられる

「エイリアスが指すバージョンはいつでも変更できる」ことにより、Lambda 関数を呼び出す側はターゲットとしてエイリアスを指定したままで実行する Lambda 関数のバージョンを変更できます。そのため Lambda 関数の更新をリリースするときに、呼び出し側のリソースに変更を加えずに対応できます。

またリリース内容によってではありますが、切り替えたバージョンで問題があることがわかった場合にすぐに以前のバージョンへ戻すこともできます。

Missing alt text value

カナリアリリース

さらに「エイリアスは 2 つのバージョンを指すことができ、加重をかけて実行できる」ことにより、新しくリリース予定の Lambda 関数にいきなり入れ替えるのではなく 10 % の確率で実行させて様子を見るなどもできます。これにより新しいバージョンに問題があれば影響範囲が少ないうちにすぐ切り戻すことができますし、ある程度動本番環境で作確認をした上で新しいバージョンへの完全切り替えの判断ができたりなど柔軟な対応ができます。こういったリリースをカナリアリリースと呼びます。

このような仕組みを入れることでリリースが複雑になる可能性もあるため必ず取り入れた方が良いかは状況によりますが、機能があることを知っておくことで設計時の選択肢は広がりますね !

また 2025 年 5 月 16 日に AWS CodePipeline のアクションからこの機能が使える ようにもなりました !

Missing alt text value

Lambda 関数のバージョンとエイリアスを使用した際の注意点

これらの機能に関わらず便利だからといって色んな機能を使用しすぎると複雑性が増えてしまい、却ってミスを増やしてしまうこともあります。何か機能を取り入れる場合は「本当に必要か」「トレードオフになることはないか」などを検討しておきましょう ! ここではいくつか Lambda 関数のバージョンとエイリアスを使用する場合の注意点を挙げておきます φ(•ᴗ•๑)

本番環境とそれ以外の AWS アカウントを分離する

状況によりますが、現在は AWS Well-Architected Framework の中に「SEC01-BP01 アカウントを使用してワークロードを分ける」が記載されている通り、本番環境とそれ以外は AWS アカウントを分けての分離が強く推奨とあります。

エイリアスの機能によりシングルアカウントで環境を分けるという使い方を思いつくかもしれませんが、シングルアカウントはセキュリティの観点での分離以外にクォータの問題や請求の管理の課題なども考えられます。そのためこれから始めるのであれば、環境はエイリアスで分けるのではなく AWS アカウントで分けるようにして、CI/CD の仕組みを用意して同じ構成を別のアカウントにデプロイできるような構成をまず検討してみてください。

エイリアスで重みをつけて複数バージョンを指定する場合、処理結果が異なるバージョンを混在させない

Lambda 関数が返す結果がバージョンを変えることで異なる場合、エイリアスで重みをつけて複数のバージョンを紐付けるのが向かない場合もあります。例えばレスポンスに新しパラメーターが追加される場合などを考えてみましょう。エイリアスではセッションごとにバージョンを出し分けることが現状できないため、アクセスするたびに 10% の確率で新しく追加されたパラメーターが表示されるなどになってしまうと挙動が予想できません。呼び出し側で問題がないように作っておけば良いですが、ユーザーに見える情報がリクエストするたびに変わるような状況であれば混在は避けた方が良いかもしれません。

重みづけが上手く使える場面としては、結果は同じだけどコード内のロジックの最適化をした場合や、外部ライブラリのバージョンだけを上げるみたいな場面でなどがあります。

バージョンを混在させるのがまずい場合はエイリアスが指す新しいバージョンに一気に切り替える必要があるため、テスト用の AWS アカウントなどでしっかりとテストをしてから本番の AWS アカウントでリリースできるようにしましょう !

バージョンの切り戻し (ロールバック) をする場合、リリースによる影響内容や切り戻しの手順を確認しておく

Lambda 関数に限った話ではないですが、リリースの切り戻しをする場合はそれによって問題が発生しないかを事前に確認して手順を確立しておきましょう !
とくに Lambda 関数ではエイリアスとバージョンを使うことで簡単に切り戻しができてしまうからこそ注意が必要です。

例えば新しいバージョンにすることで DynamoDB に新しい属性を追加したり取り出したりするような変更が入っている場合、切り戻し後はその属性を考慮していないコードに戻ってしまい、切り戻し前に追加されたデータにアクセスした時にエラーが発生してしまうなどがあれば簡単に切り戻しはできないかもしれません。可能であればそもそも切り戻しができるようにコードの更新やリリース手順を検討しておきつつ、切り戻しが想定されるのであれば本番環境でいきなり実施するのではなく、別の環境で切り戻しをした場合の影響確認まで検証しておけると安心感が増えます。

また切り戻し方法をどのようにするかも検討しておかないと、予期せぬ問題が発生するかもしれません。
例えば IaC で Lambda 関数のコードを管理し、リリース作業もパイプラインを使用するような CI/CD 環境が整っている場合を考えてみましょう。理想としては切り戻しもパイプラインから行うですが、パイプラインの実行に時間がかかる場合にはどうしても緊急対応として手動で切り替えないといけないという判断もあるかもしれません。他にもリポジトリの内容を切り戻してパイプラインを再実行した場合に、依存している外部ライブラリのバージョンを固定していなければ、以前と同じコードでビルドしても Lambda 関数のパッケージに含まれている内容が変わる可能性もあります。

もし総合的な判断でパイプライン以外からの切り戻しを行った場合は、コードのリポジトリで管理している状態と本番環境の状態がずれることになります。そうなると AWS CloudFormation や AWS CDK を使う場合であればその後のドリフトをどう解消するか、手動で変更したことにより意図しない影響が出ないかまでの検討が必要になる点は注意しておきましょう。

他にもパイプラインの実行に時間がかかりすぎるのでリポジトリの切り戻しだと対応しづらい場合は、緊急リリース用のためにすぐにリリースできるようなパイプラインを用意しておくという考えもあるので参考までに !

 

 

Provisioned Concurrency を使用している場合の切り替え時のコールドスタート

Lambda 関数には Provisioned Concurrency という機能があり、事前に Lambda 関数の実行環境を準備しておくことでコールドスタートを調整するのに役立ちます。ただしこの機能を使用している場合でエイリアスのバージョンを新しいものに一気に切り替えると、切り替え後のバージョンの実行環境が用意される前に大量にリクエストが来てしまい、リリース直後にコールドスタートが頻発する可能性があります。そのため Provisioned Concurrency を使用している場合は、リリース時にエイリアスで複数バージョンを混在させることでコールドスタートの軽減にも役に立ちます !
Provisioned Concurrency についてより知りたい方は、AWS Lambda Provisioned Concurrency Dive Deep & Practice の資料も参考になりますので確認してみてください !

過去バージョンの管理と削除

バージョンを残しておけるのは便利ですが、削除しないと使わないリソースがいつまでも残ったままになるので最大で残すバージョンの数や期限などを決めて管理しておきましょう。ただし AWS CloudFormation の DeletionPolicy や AWS CDK の RemovalPolicyRetain にしておかないとデプロイ後に残しておきたかった過去のバージョンも削除されてしまう可能性があるので、以前のバージョンが意図通り残せていることもテスト環境などから確認しておきましょう !

まとめ

注意点でも挙げたように実際には CI/CD のパイプラインにどのように組み込むか、ロールバックはどのような手順で行うかなどの運用を考える必要は出てきますが、知っておくと設計時に役立つ Lambda 関数のバージョンとエイリアスについて紹介をしました !

このようにテクニカルインストラクターは、自学だけではつまずきやすい部分などを含め、みなさんにより AWS を理解してもらいやすくなる工夫を日々行いながら クラスルームトレーニング を提供しております !
質問もリアルタイムでできるため分からない部分はとことんお付き合いしますし、ほとんどのコースには演習の時間も多くあるため学んだ内容を AWS 環境で実践できます !

AWS のトレーニングについてもっと知りたい方は、以下の連載記事も参考にどうぞ。

これまで自分で勉強してきたけど AWS を体系的に学ぶことでもっと詳しくなって業務で活用したい ! という方はぜひ AWS のトレーニングを受講してみてください !

筆者プロフィール

杉本 圭太
アマゾン ウェブ サービス ジャパン合同会社
トレーニングサービス本部 テクニカルインストラクター

テクニカルインストラクターとして、知識をつけることが目的ではなく実際に業務で活用できる力を得ることを目指したトレーニングを提供しています。自分自身が新しいことを知るのが好きなので、「AWS を知るのは面白い ! もっと学んでみよう !」と多くの方に感じてもらえる工夫を常に考えながら活動しています。

A person participates in a pottery workshop, smiling while shaping clay on a pottery wheel.