🍽️ レストランの席予約システムに例えると...
🏪 通常のレストラン（設定なし）
全ての席が早い者勝ち！
👤
👤
👤
👤
👤
👤
👤
👤
🪑
🪑
人気のお客さんが来ると、他の人は席に座れない可能性が...
🏪 予約席ありレストラン（設定あり）
重要なお客さん用に席を確保！
📋
📋
📋
👤
👤
👤
👤
🪑
🪑
🪑
重要なお客さんは必ず席を確保できる！
つまり...
Lambda の予約済み同時実行数とは、特定のLambda関数が「必ず使える実行枠」を事前に確保しておく仕組みです！
📊 Lambda での実際の仕組み
| 項目 | レストランの例 | Lambda の実際 |
|---|---|---|
| 席 / 実行環境 | レストランの席 | Lambda の同時実行環境 |
| お客さん | レストランのお客さん | Lambda へのリクエスト |
| 予約席 | VIP客用の確保された席 | 特定関数用の予約済み同時実行数 |
| 総席数 | レストランの総席数（50席） | AWSアカウントの同時実行上限（1000など） |
メリット
-
確実な実行保証
重要な関数が必ず動く -
予測可能な性能
レスポンス時間が安定 -
他関数の影響を回避
リソース競合を防止
注意点
-
コスト増加の可能性
使わない分も確保される -
全体の上限は変わらない
他の関数が使える枠が減る -
適切な設定が重要
過剰確保は無駄になる
設定方法
-
AWS Console
Lambda関数の設定から -
AWS CLI
put-provisioned-concurrency-config -
CloudFormation
IaCで管理も可能
🔄 Reserved Concurrency vs Provisioned Concurrency
よく混同される2つの機能ですが、実は 全く違う目的 の機能です！
📋 Reserved Concurrency
「席を確保」= 実行枠の上限設定
🏃♂️
お客さんが来てから席の準備開始
席は確保されているが、テーブルセッティングに時間がかかる
📋
📋
📋
- 実行枠の上限を設定
- 他の関数からリソースを保護
- コールドスタートは発生する
⚡ Provisioned Concurrency
「席の事前準備」= 実行環境の事前起動
✨
お客さんが来る前に席の準備完了
テーブルセッティング済み、すぐに座れる
⚡
⚡
⚡
- 実行環境を事前に起動
- コールドスタートを完全回避
- レスポンス時間が最速・最安定
🔗
2つの機能は組み合わせ可能！
Reserved Concurrency で実行枠を確保し、その中の一部をProvisioned Concurrency で事前起動することができます。
例：
Reserved Concurrency = 10、Provisioned Concurrency = 3
→ 10個の確保された実行枠のうち、3個は常時起動済み
→ 10個の確保された実行枠のうち、3個は常時起動済み
💰 コストと用途の比較
| 項目 | Reserved Concurrency | Provisioned Concurrency |
|---|---|---|
| 主な目的 | 実行枠の確保・制限 | コールドスタートの回避 |
| コスト | 無料（実行時のみ課金） | 有料（常時課金） |
| レスポンス時間 | コールドスタート有り | 常に高速 |
| 適用場面 | リソース保護、スロットリング | リアルタイムAPI、即応性重視 |
| 設定の複雑さ | シンプル | やや複雑（バージョン管理等） |
いつ使う？
Reserved Concurrency はリソース保護、Provisioned Concurrency は性能最適化。目的に応じて使い分けや組み合わせを検討しましょう。
🚀 まとめ
Lambda の予約済み同時実行数は、レストランの予約席のように
「重要な処理のために実行環境を事前確保する機能」
です。
適切に設定することで、安定したサービス提供が可能になります！