Slide 1
Slide 1 text
リテールアプリ共創部
岩⽥智哉
Lambdaの常識はどう変わる？！
re:Invent 2025 before after
Slide 2
Slide 2 text
re:Invent参加歴
● 2018年 参加
● 2019年 参加
● 2020年〜2022年 コロナ禍のため不参加
● 2023年〜 靭帯断裂のため不参加
⾃⼰紹介
● 名前
○ 岩⽥智哉
● 好きなAWSサービス
○ Lambda
Slide 3
Slide 3 text
● 2025/11/19 テナントの分離機能 ※今回は割愛
● 2025/12/1 Lambda Managed Instances
● 2025/12/2 Lambda durable functions
re:Invent前後のLamba関連アップデート
Slide 4
Slide 4 text
Lambda Managed Instances
Slide 5
Slide 5 text
ざっくりいうと
ECS Managed Instances の
Lambda版
Lambda Managed Instances
Slide 6
Slide 6 text
● 基盤となるEC2インスタンスのCPUは最新世代かもしれない。
そうでないかもしれない
● どのAZで起動するのか制御できない
● どのAWSアカウントのLambda Functionと相乗りしているか
分からない
○ ノイジーネイバー問題も0ではないかも？
■ Firecrackerやcgroupsで影響は最⼩限になっているはず
通常Lambdaではサーバーの存在を意識しない
Slide 7
Slide 7 text
● インスタンスタイプを制御可能
○ 最新世代のCPU利⽤
○ ネットワーク最適化など
Lambda Managed Instancesを利⽤する場合
Slide 8
Slide 8 text
GPUインスタンスは使え...る？のか？？？
Lambda Managed Instancesを利⽤する場合
Slide 9
Slide 9 text
ベアメタルインスタンスは使え...る？のか？？？
Lambda Managed Instancesを利⽤する場合
Slide 10
Slide 10 text
どのインスタンスタイプが使えるか詳細不明
● 今のところ上記リンクからドキュメントを⾒てもサポートされているイ
ンスタンスタイプは明⽰的に記載されていない
● GPUインスタンスやベアメタルインスタンスが起動できるか不明
○ いくつか試した範囲では起動を確認できず
● t3.small等スペックの低いインスタンスは指定できず
○ Lambda Functionのメモリ割り当ては最低2048Mから
○ 1vCPUあたりのメモリ割り当ては2GiB,4GiB,8GiB
Slide 11
Slide 11 text
SSHやSSMで接続はできない
Lambda Managed InstancesならOSを操作できる？？
Slide 12
Slide 12 text
アカウントA
Lambda 実⾏環境
セキュリティ境界と同時実⾏モデルの違い(通常のLambda)
Users ベアメタルEC2 インスタンス
アカウントA
Lambda 実⾏環境
アカウントB
Lambda 実⾏環境
Slide 13
Slide 13 text
セキュリティ境界と同時実⾏モデルの違い
Users EC2 インスタンス
アカウントA Lambda 実⾏環境
ワーカースレッド
ワーカースレッド
Slide 14
Slide 14 text
ワーカースレッド
同時実⾏モデルの違い
EC2 インスタンス
Lambda Function A実⾏環境
ワーカースレッド
/tmp
Runtime InitとExtension Initは
この単位で実⾏
Function Initはこの単位で実⾏
Slide 15
Slide 15 text
従来はできなかったような使い⽅も
Slide 16
Slide 16 text
既存のLambdaの実装をそのまま移⾏するのはリスクあり
Slide 17
Slide 17 text
● Lambda Managed InstancesではスケールアウトのためにEC2
インスタンスの追加起動が必要になる
● 数百msでサクッとコールドスタートする通常のLambdaと⽐
較するとスケールアウトは遅い
● スパイクアクセスへの耐性は低い
○ 予測可能なワークロードへの利⽤が推奨
実⾏モデルの違いからスケール速度にも違いが
Slide 18
Slide 18 text
● 今のところスケールアウトのポリシーは⾃動もしくはCPU使⽤
率ベースのポリシーしか指定できない
スケールアウトポリシー
Slide 19
Slide 19 text
通常のLambda
● リクエストに対する課⾦
● コンピューティング時間に対する課⾦
○ SP適⽤可能
■ 東京リージョンの場合最⼤
15% OFF
コストの違い
Lambda Managed Instances
● リクエストに対する課⾦
● EC2インスタンスの料⾦
○ SP適⽤可能
■ 東京リージョンの場合最⼤
67% OFF
○ RI適⽤可能！！
● AWSがEC2インスタンスを管理するた
めの追加費⽤
○ パッチの⾃動適⽤等
Slide 20
Slide 20 text
● Lambda Managed Instancesでは3台のEC2インスタンスが必須
● コンピューティング料⾦がEC2のオンデマンド料⾦ + 管理料⾦に
変わるが、Lambdaのリクエスト料⾦は継続して発⽣
● RIやSPの割引率は魅⼒
● リクエスト数の多い環境でないとコストメリットは出ない
コストはペイできる？？
Slide 21
Slide 21 text
● Lambdaの魅⼒は何と⾔っても多数のAWSサービスとの連携
● シンプルなWeb APIを作るだけならFargateで⼗分
● AWSサービスをフル活⽤するようなシステムではLambdaの特性
が活きてくる
Fargateとの住み分けは？
Slide 22
Slide 22 text
Lambda durable functions
Slide 23
Slide 23 text
Lambda単体である程度
Step Functions相当の
処理が組めるように！！
Lambda durable functions
Slide 24
Slide 24 text
● 現時点ではオハイオリージョンでのみ利⽤可能
● ランタイムはPython(3.13,3.14)とNode.js(22.x,24.x)のみ対応
利⽤可能な環境は限定的
東京‧⼤阪リージョンはまだ！！
Slide 25
Slide 25 text
● map
● parallel
● step
● wait
● wait_for_callback
● wait_for_condition
durable functionsでできると
Slide 26
Slide 26 text
● Lambda Function⾃体のタイムアウトは最⼤15分のまま
● 14分Sleepするstepを3回実⾏するとこうなる↓
最⼤1年間実⾏可能？？
Slide 27
Slide 27 text
● リトライ時はコードの先頭から実⾏が再開される
○ コールドスタートを伴う場合はinit処理も再実⾏される
○ チェックポイントを設定した処理の結果をキャッシュから
取得して処理⾃体はスキップされる
リトライ時はチェックポイント完了後から再開ではない
Slide 28
Slide 28 text
公式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
Slide 29
Slide 29 text
テスト⽤のライブラリも
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
Slide 30
Slide 30 text
テスト容易性についてのStep Functionsとの⽐較
● 各Durable Operationのレスポンスに型付けしてケアレスミス
を未然に防⽌できる
● Durable Operation同⼠の連携をsmallテストでテスト可能
○ 例えばstepが複数回実⾏されても冪等な実装になっている
か？など
○ ユニットテストのコードがドキュメントとして機能する
Slide 31
Slide 31 text
● Durable Operations(Steps,Waits…)
○ 100万操作あたり$8.00
● 実⾏ログの書き込み
○ 1GBあたり$0.25
● 実⾏ログの保持
○ 1GB & 1ヶ⽉あたり$0.15
※Durable Operationのたびに実⾏ログを保存
コストはどうなる？
Slide 32
Slide 32 text
● durable functionsを利⽤するということは何らかのDurable
Operation実⾏後にLambdaの再実⾏が発⽣するはず
○ 1回だけInvokeしてポーリングする実装よりリクエスト回
数に対する課⾦は⼤きくなる
● Durable Operation1回のコストは$0.000008
○ これはx86、メモリ1GBのLambdaを約480ms実⾏するのと
同等のコスト
durable functionsに置き換えるとコスト的に不利になるケースも
※同時実⾏数の削減などコスト以外にもメリットはある
コストはどうなる？
Slide 33
Slide 33 text
まとめ
Slide 34
Slide 34 text
Before re:Invent2025
● ⼤規模なワークロードでLambdaを
採⽤するとコスト効率が悪い
● Lambda Functionのオーケストレー
ションにはStep Functions等のサー
ビスが必要
re:Invent2025 Before‧After
After re:Invent2025
● ⼤規模なワークロードでもコスト効
率よくLambdaが利⽤できるケース
がある
● Lambdaの機能だけでもLambda
Functionのオーケストレーションが
ある程度可能に
Slide 35
Slide 35 text
No content