Lambdaの常識はどう変わる？！re:Invent 2025 before after

Transcript

1. リテールアプリ共創部 岩⽥智哉 Lambdaの常識はどう変わる？！ re:Invent 2025 before after

2. re:Invent参加歴 • 2018年 参加 • 2019年 参加 • 2020年〜2022年 コロナ禍のため不参加 • 2023年〜 靭帯断裂のため不参加 ⾃⼰紹介

   • 名前 ◦ 岩⽥智哉 • 好きなAWSサービス ◦ Lambda

3. • 2025/11/19 テナントの分離機能 ※今回は割愛 • 2025/12/1 Lambda Managed Instances •

   2025/12/2 Lambda durable functions re:Invent前後のLamba関連アップデート

4. Lambda Managed Instances

5. ざっくりいうと ECS Managed Instances の Lambda版 Lambda Managed Instances

6. • 基盤となるEC2インスタンスのCPUは最新世代かもしれない。 そうでないかもしれない • どのAZで起動するのか制御できない • どのAWSアカウントのLambda Functionと相乗りしているか 分からない ◦

   ノイジーネイバー問題も0ではないかも？ ▪ Firecrackerやcgroupsで影響は最⼩限になっているはず 通常Lambdaではサーバーの存在を意識しない

7. • インスタンスタイプを制御可能 ◦ 最新世代のCPU利⽤ ◦ ネットワーク最適化など Lambda Managed Instancesを利⽤する場合

8. GPUインスタンスは使え...る？のか？？？ Lambda Managed Instancesを利⽤する場合

9. ベアメタルインスタンスは使え...る？のか？？？ Lambda Managed Instancesを利⽤する場合

10. どのインスタンスタイプが使えるか詳細不明 • 今のところ上記リンクからドキュメントを⾒てもサポートされているイ ンスタンスタイプは明⽰的に記載されていない • GPUインスタンスやベアメタルインスタンスが起動できるか不明 ◦ いくつか試した範囲では起動を確認できず • t3.small等スペックの低いインスタンスは指定できず

    ◦ Lambda Functionのメモリ割り当ては最低2048Mから ◦ 1vCPUあたりのメモリ割り当ては2GiB,4GiB,8GiB

11. SSHやSSMで接続はできない Lambda Managed InstancesならOSを操作できる？？

12. アカウントA Lambda 実⾏環境 セキュリティ境界と同時実⾏モデルの違い(通常のLambda) Users ベアメタルEC2 インスタンス アカウントA Lambda 実⾏環境

    アカウントB Lambda 実⾏環境

13. セキュリティ境界と同時実⾏モデルの違い Users EC2 インスタンス アカウントA Lambda 実⾏環境 ワーカースレッド ワーカースレッド

14. ワーカースレッド 同時実⾏モデルの違い EC2 インスタンス Lambda Function A実⾏環境 ワーカースレッド /tmp Runtime

    InitとExtension Initは この単位で実⾏ Function Initはこの単位で実⾏

15. 従来はできなかったような使い⽅も

16. 既存のLambdaの実装をそのまま移⾏するのはリスクあり

17. • Lambda Managed InstancesではスケールアウトのためにEC2 インスタンスの追加起動が必要になる • 数百msでサクッとコールドスタートする通常のLambdaと⽐ 較するとスケールアウトは遅い • スパイクアクセスへの耐性は低い

    ◦ 予測可能なワークロードへの利⽤が推奨 実⾏モデルの違いからスケール速度にも違いが

18. • 今のところスケールアウトのポリシーは⾃動もしくはCPU使⽤ 率ベースのポリシーしか指定できない スケールアウトポリシー

19. 通常のLambda • リクエストに対する課⾦ • コンピューティング時間に対する課⾦ ◦ SP適⽤可能 ▪ 東京リージョンの場合最⼤ 15%

    OFF コストの違い Lambda Managed Instances • リクエストに対する課⾦ • EC2インスタンスの料⾦ ◦ SP適⽤可能 ▪ 東京リージョンの場合最⼤ 67% OFF ◦ RI適⽤可能！！ • AWSがEC2インスタンスを管理するた めの追加費⽤ ◦ パッチの⾃動適⽤等

20. • Lambda Managed Instancesでは3台のEC2インスタンスが必須 • コンピューティング料⾦がEC2のオンデマンド料⾦ + 管理料⾦に 変わるが、Lambdaのリクエスト料⾦は継続して発⽣ •

    RIやSPの割引率は魅⼒ • リクエスト数の多い環境でないとコストメリットは出ない コストはペイできる？？

21. • Lambdaの魅⼒は何と⾔っても多数のAWSサービスとの連携 • シンプルなWeb APIを作るだけならFargateで⼗分 • AWSサービスをフル活⽤するようなシステムではLambdaの特性 が活きてくる Fargateとの住み分けは？

22. Lambda durable functions

23. Lambda単体である程度 Step Functions相当の 処理が組めるように！！ Lambda durable functions

24. • 現時点ではオハイオリージョンでのみ利⽤可能 • ランタイムはPython(3.13,3.14)とNode.js(22.x,24.x)のみ対応 利⽤可能な環境は限定的 東京‧⼤阪リージョンはまだ！！

25. • map • parallel • step • wait • wait_for_callback

    • wait_for_condition durable functionsでできると

26. • Lambda Function⾃体のタイムアウトは最⼤15分のまま • 14分Sleepするstepを3回実⾏するとこうなる↓ 最⼤1年間実⾏可能？？

27. • リトライ時はコードの先頭から実⾏が再開される ◦ コールドスタートを伴う場合はinit処理も再実⾏される ◦ チェックポイントを設定した処理の結果をキャッシュから 取得して処理⾃体はスキップされる リトライ時はチェックポイント完了後から再開ではない

28. 公式SDKにサンプル多数 https://github.com/aws/aws-durable-execution-sdk-python-testing/tree/main/examples https://github.com/aws/aws-durable-execution-sdk-js/tree/main/packages/aws-durable-execution-sdk-js-examples

29. テスト⽤のライブラリも https://github.com/aws/aws-durable-execution-sdk-python-testing https://github.com/aws/aws-durable-execution-sdk-js/tree/main/packages/aws-durable-execution-sdk-js-testing

30. テスト容易性についてのStep Functionsとの⽐較 • 各Durable Operationのレスポンスに型付けしてケアレスミス を未然に防⽌できる • Durable Operation同⼠の連携をsmallテストでテスト可能 ◦

    例えばstepが複数回実⾏されても冪等な実装になっている か？など ◦ ユニットテストのコードがドキュメントとして機能する

31. • Durable Operations(Steps,Waits…) ◦ 100万操作あたり$8.00 • 実⾏ログの書き込み ◦ 1GBあたり$0.25 •

    実⾏ログの保持 ◦ 1GB & 1ヶ⽉あたり$0.15 ※Durable Operationのたびに実⾏ログを保存 コストはどうなる？

32. • durable functionsを利⽤するということは何らかのDurable Operation実⾏後にLambdaの再実⾏が発⽣するはず ◦ 1回だけInvokeしてポーリングする実装よりリクエスト回 数に対する課⾦は⼤きくなる • Durable Operation1回のコストは$0.000008

    ◦ これはx86、メモリ1GBのLambdaを約480ms実⾏するのと 同等のコスト durable functionsに置き換えるとコスト的に不利になるケースも ※同時実⾏数の削減などコスト以外にもメリットはある コストはどうなる？

33. まとめ

34. Before re:Invent2025 • ⼤規模なワークロードでLambdaを 採⽤するとコスト効率が悪い • Lambda Functionのオーケストレー ションにはStep Functions等のサー

    ビスが必要 re:Invent2025 Before‧After After re:Invent2025 • ⼤規模なワークロードでもコスト効 率よくLambdaが利⽤できるケース がある • Lambdaの機能だけでもLambda Functionのオーケストレーションが ある程度可能に
35. None