re:Growth 2025 大阪で「re:Growth 2025 - Lambdaの常識はどう変わる？！re:Invent 2025 before after」というタイトルで登壇しました #AWSreInvent #cmregrowth
リテールアプリ共創部@大阪の岩田です。
2025/12/10に開催されたre:Growth 2025 大阪にて「Lambdaの常識はどう変わる？！re:Invent 2025 before after」というテーマで主にLambda Managed InstancesとLambda durable functionsについて登壇させて頂きました。
登壇資料
Lambda Managed Instances
ざっくり言うとECS Managed Instances のLambda版です。サーバーレスなサービスであるLambdaはサーバーの存在を意識せずに利用可能です。これはサーバーレスアーキテクチャの最大のメリットではあるものの、一方でコンピューティング環境の仕様を細かく制御したいという要件には対応できませんでした。Lambda実行環境の基盤となるEC2インスタンスのCPUは最新世代かもしれないし、最新世代ではないかもしれません。俗に言う「Lambdaガチャ」とか「Fargateガチャ」という言葉はこの仕様に起因するものです。
今回登場したLambda Managed Instancesを利用するとLambda実行環境の基盤となるEC2インスタンスを特定のインスタンスタイプに指定したり、逆に特定のインスタンスタイプを除外したりできます。これにより、常に最新世代CPUのインスタンスを使いたいとか、常にNWスループットの高いインスタンスを使いたいといった要望にも応えられるようになりました。
GPUは使えるのか？？
後述しますがLambda Managed Instancesを利用する場合、Lambda実行環境の分離にFirecrackerは利用されません。これまでLambdaではGPUがサポートされていませんでしたが、これはFirecrackerがGPUをサポートしていないという制約によるものと推測されます。
Firecrackerを使わないという仕様とインスタンスタイプを指定できるという仕様を踏まえると、「ついにLambdaでGPUが使えるようになるのか？！」と期待するところですが、今のところGPUが使えるのかは不明です。g5g.xlarge等、何パターンかGPUインスタンスを指定してLambda Managed Instancesの利用を試みたものの今のところ全て失敗しています。全インスタンスタイプを網羅的に試したわけではないので、起動できるGPUインスタンスもあるかもしれないですが、今のところGPUインスタンスの起動は確認できていません。また、今のところ公式ドキュメント上でも起動できる/できないインスタンスタイプの記載が見つけられていません。
そのうち仕様が明らかになるはずなので、もしGPUインスタンスが起動できそうなら追って検証したいと思います。
ちなみにベアメタルインスタンスについても私が試した範囲では起動が確認できていません。
アーキテクチャの違い
Lambda Managed Instancesを利用する場合、実行環境のアーキテクチャや同時実行に関するモデルは通常のLambda環境と異なります。
通常のLambdaであればFirecrackerのMicroVM毎に1つのLambda実行環境が作成されます。1つのLambda実行環境が同時に処理するユーザーリクエストは最大で1つまでです。1つのLambda実行環境が同時に複数のリクエストを処理することはありません。
Lambda Managed Instancesを利用する場合、FirecrackerのMicroVMによるセキュリティ境界は存在しません。代わりに、EC2上で稼働するLambda実行環境のコンテナがセキュリティ境界となります。また、1つのLambda実行環境が複数のユーザーリクエストを同時に処理する点も特徴です。
ユーザーリクエストの実際の処理は、Lambda実行環境内のプロセスやスレッドが担当します。処理方式はランタイムによって異なり、例えばNode.jsの場合はワーカースレッドがリクエストを処理します。この仕組みのため、process.on()は利用できないなどの制約があります。
この同時実行モデルの違いからRuntime Init・Extension Initの実行単位がFunction Initの実行単位と異なることに注意が必要です。
こういった特性から従来のLambda実行環境ではできなかったようなアーキテクチャも実現できます。
逆に従来の処理では問題が発生するようなケースもあります。
コード修正無しに単純に実行環境を変更すると不具合を引き起こす可能性もあるので注意が必要です。
スケールアウトについて
Lambda実行環境の基盤となるEC2のスケールアウトはCPU使用率に基づいたスケールアウトポリシーを手動で作成するか、もしくは自動でAWSにお任せする形になります。同時実行数やリクエスト数に応じたスケールアウトは現状設定できません。スケールアウト時にはEC2インスタンスが起動することになるため、Lambdaのコールドスタートと比較すると速度は劣ります。そのため突発的なスパイクアクセスが発生するようなワークロードには向かず、予測可能なワークロードでの利用が推奨されます。
コストの考え方
コストについてはアイドル状態であってもEC2のランニングコストが発生することに注意が必要です。さらに通常のEC2インスタンスの料金に加えてAWSがEC2インスタンスを管理するための15%の追加コストも発生します。最低3台のEC2インスタンスを起動する必要があるという仕様とも相まって、発生するコストの最低ラインが通常のLambdaよりは大きくなります。
一方でSPやRIによる恩恵が受けやすいというメリットや、コンピューティング時間に対する課金が発生しないというメリットもあり、ある程度リクエスト数が多い環境であればLambda Managed Instancesを利用することでコスト削減につながる可能性があります。
Fargateとの住み分け
これまでの内容を振り返ってみるとLambda Managed Instancesは従来のLambdaよりFargateに近い特性を持っていると考えられます。Fargateとの住み分けをどのように考えるべきかですが、Lambdaの魅力はなんといっても多数のAWSサービスとの統合です。AWSのサービスをフル活用した構成であればFargateよりもLambda Managed Instancesを採用した方がイベントドリブンなアーキテクチャは実現しやすいでしょう。反対にALB配下でWeb APIを稼働させたいといったシンプルなユースケースであればFargateで十分だと思います。
Lambda durable functions
続いてLambda durable functionsに関する話です。こちらもざっくり説明するとStep Functions相当の処理がLambda単体で組めるようになったというアップデートで、以下のような操作に対応しています。
- map
- parallel
- step
- wait
- wait_for_callback
- wait_for_condition
注意事項
便利な機能であることは間違いないですが、実装にあたってはdurable functionsの仕様理解が求められます。
例えばですが、Lambda Function自体のタイムアウト値の上限は15分のままだとか、リトライ時はチェックポイント直後から処理が再開されるわけではなく、コードの先頭から処理が再開されるといった仕様を理解しておかないと、思わぬ不具合を発生させるリスクがあります。
GitHub上に参考情報多数
実装にあたっては公式SDKのリポジトリに含まれるサンプルコードを参考にするのが良いです。
テスト用のライブラリも提供されており、公式ドキュメントでもテストコードの実装方法について解説されています。
Testing Lambda durable functions - AWS Lambda
テスト用のライブラリを活用することでDurable Operation同士の連携がsmallテストとしてテストできるというのはStep Functionsと比較して優位なポイントになってくると思います。実装フェーズにおいてもDurable OperationのレスポンスをTypeScriptやPythonで型付けしてやればケアレスミスを未然防止しやすくなるはずです。
コストはどうなる？
気になるコストについてですが、waitなどの操作によって待機している間はLambdaのコンピューティング料金が0になるというのが最大のメリットです。一方でDurable Operationに対しての課金、実行ログの書き込み・保存に対しての課金が発生することには注意が必要です。
以下の記事でAthenaのクエリ実行結果をポーリングする処理をdurable functionsで書き換えてみたのですが、実行したクエリが大して時間のかからないものだったので、逆にコストが高くなるという結果になりました。
既存実装をdurable functionsに置き換えれば常にコストメリットが出るというわけではないので、その点は注意しておきましょう。
まとめ
re:Invent 2025周辺のアップデートによって、またLambdaで実現できることが増えました。これにより、従来はLambdaが採用し辛かった場面であってもLambdaが採用できるようになりました。
最新の動向を追いかけながら、常に最適なアーキテクチャを選定できるようにしたいですね！！
