re:Growth 2025 札幌で Lambda の新機能について話しました #regrowth_sapporo #AWSreInvent
いわさです。
本日開催されたre:Growth 2025 札幌で Lambda の新機能についてお話させて頂きました。
飛行機遅延の関係で 12/7(日) に帰宅したのですが、なんと 12/8(月) に登壇。ふふ。
この記事ではスライドやイベントの様子を共有したいと思います。
登壇資料
発表スライドはこちらになります。
AWS re:Invent 2025 前後でアナウンスされた、Lambda のアップデートについてまとめつつ、以下の３つについてはユースケースがぱっとすぐにわからないところがあったので少し解説しています。
Multi Tenant Isolation Mode
マルチテナントアプリケーションではテナント分離性を求められることがよくあります。
例えばテナントAとテナントBが同じサービス内で動作する時、データやコンピューティングのリソース単位で分離（例：同じリソースを使わない）ことが求められる場合があります。
従来だとそういった場合はテナントごとに Lambda 関数を用意することがありました。
テナント数が数テナントであればこれでも運用できなくもないですが、1,000 や 10,000 のテナントとなるとかなりつらいです。
今回のアップデートでは Lambda の呼び出し時にテナント ID を指定することで、同一テナント ID であれば同じコンピューティングリソース上で動作し、別のテナント ID であれば新しい Lambda 環境が立ち上がります。
新しい環境が立ち上がるのでその場合はコールドスタートによる遅延が発生してしまいますが、テナント分離モードを有効化した Lambda 関数をひとつ作成して Invoke 時にテナントを意識するだけで、テナント分離要件を満たすことが出来るようになります。
ちょっとだけ追加料金が発生します。（関数に割り当てたメモリ量と使用する CPU アーキテクチャに応じた追加料金）
Lambda Managed Instances
Lambda Mnaaged Instances は Lambda 関数を実行する際に、従来のように AWS におまかせのどこかで動くのではなく、事前にユーザーがプロビジョニングした EC2 インスタンス群上で動かすことが出来ます。
これによって通常の Lambda 関数では利用できないコンピューティング要件を満たせるようになります。
例えば GPU インスタンスや、ネットワーク最適化インスタンスなどです。
また、Lambda の実行頻度が高くて常に一定以上の関数が動き続けているような環境の場合であれば、Lambda Managed Instances に切り替えて RI や SP を当てることでコスト削減につながる可能性があります。料金試算にあたってはプロビジョニングしたフリート上でどの程度の同時実行数が実現できるかやパフォーマンスへの影響点も把握する必要がありますが、試算してみたいですね。
ちなみにこの Lambda Managed Instances 用にプロビジョニングした EC2 は EC2 のコンソール上で参照することは出来るのですが操作は出来ません。
パッチ適用なども含めて AWS が管理するためです。
この Lambda Manged Instances 機能はクラメソ社内でも注目されているようで色々な派生ブログが誕生しています。
- Lambda Managed Instancesの実行環境と通常のLambda実行環境に差異があるのかOSコマンドで確認してみた #AWSreInvent | DevelopersIO
- Lambda Managed Instances環境固有のレースコンディションについて確認してみた #AWSreInvent | DevelopersIO
- Lambda Managed InstancesをTerraformでサクッと試してみる。 #AWSreInvent | DevelopersIO
- [小ネタ]Lambda Managed Instancesでは実行環境が「フリーズ」しないことを確認してみた #AWSreInvent | DevelopersIO
- AWS Lambda Managed Instances を AWS CDK で実装してみた | DevelopersIO
- Lambda Managed Instancesを利用する場合はRDS Proxyが不要になる？実行モデルの違いによるコネクションプーリングの考え方について検証してみた #AWSreInvent | DevelopersIO
Lambda Durable Functions
従来の Lambda 関数は実行時間の制限などがあり、大規模なサーバーレス処理やワークフローを実現したい場合は小さな Lambda 関数に分けた上で Step Functions などでオーケストレーションさせる必要がありましたが、Lambda Durable Functions はそのオーケストレーターの部分を Lambda 関数で担うことが出来る機能です。
Azure Durable Functions とほぼ同様の機能だなという印象ですが、エンティティ関数を実行することでチェックポイントを管理することが出来て、中止などからの再試行の際は完了済みチェックポイントをスキップさせて保存済みの出力結果を受け取って再開することが出来ます。
これによって長期間にわたって何度もリトライもできる耐久性の高いオーケストレーター関数を実装することができます。
Step Functions でもまぁ良さそうなのですが、複雑な処理だと Step Functions よりも使いなれた Lambda 関数で実装したほうが楽だし品質管理（テストなど）もしやすい面もあると思います。
この Durable Functions はサーバーレス開発方法が変わる可能性もあって、こちらも注目されており派生ブログが多いですね。
- [新機能] 最大1年間実行可能なAWS Lambda Durable Functionsがリリースされたので、公式のサンプルコードを試してみた！ #AWSreInvent | DevelopersIO
- AWS Lambda Durable Functionを使って簡単なAIワークフローを動かしてみた #AWSreInvent | DevelopersIO
- Durable Functionsの「最大1年間実行可能」の意味を確認してみた #AWSreInvent | DevelopersIO
- Durable FunctionsでSlackを使った承認ステップを実装してみた | DevelopersIO
- Durable FunctionsでAthenaのクエリ結果をポーリングする実装をコスト最適な形に書き換えてみた #AWSreInvent | DevelopersIO
- AWS Lambda Durable Functionで並列操作parallelをためしてみた #AWSreInvent | DevelopersIO
- AWS Lambda Durable Functionsでシステム間連携を実現するCallback機能を試してみた #AWSreInvent | DevelopersIO
- AWS SAM CLIのローカル実行でDurable Functionを使ってみました | DevelopersIO
- AWS CDKでLambda Durable Functionsがサポートされたので早速試してみた #AWSreInvent | DevelopersIO
新しいランタイムバージョンたち
Python 3.14、Java 25、Node.js 24 など新しいランタイムバージョンが利用可能になったほか、これまでプレビューだった Rust が一般利用できるようになりました。
さいごに
本日は re:Growth 2025 札幌で Lambda の新機能について話したので、資料や関連 URL を紹介させて頂きました。
お話したとおり、re:Invent 直前のブラックフライデーは狙い目だと覚えておきましょう。
