Lambda の 15 分制限はなぜ 15 分なのか - サーバーレスの設計制約に隠された合理性
Lambda の最大実行時間 15 分、メモリ上限 10 GB、ペイロード 6 MB など、サーバーレスの各種制限の現行値と、それがアーキテクチャ設計にどう影響するのかを、マルチテナント運用と実行環境のライフサイクルの観点から解説します。
制限は制約ではなく設計判断である
Lambda を使い始めた開発者が最初に直面するのが、各種の制限 (Limits) です。最大実行時間 15 分、メモリ 128 MB〜10,240 MB、同期呼び出しのペイロード 6 MB、デプロイパッケージ 250 MB (展開後) が代表的な値です (2026 年 8 月時点・公式のクォータ一覧に基づく)。AWS はこれらの値をどう決めたのかを公表していないため、以下で述べるのは公式の設計根拠ではなく、マルチテナント環境でのリソース公平性、運用の安全性、コスト効率という観点から読み取れる合理性です。Lambda は多数の顧客の関数を同一の物理インフラ上で実行するマルチテナントサービスです。1 つの関数が無制限にリソースを消費すると、他の顧客の関数に影響を与えます。制限は「ノイジーネイバー問題」を防ぐためのガードレールであり、同時にサーバーレスの設計パラダイムを形作る意図的な制約でもあります。制限があるからこそ、開発者は処理を小さな単位に分割し、イベント駆動で疎結合なアーキテクチャを設計するようになります。
15 分制限の歴史と背景
Lambda が 2014 年にローンチされた当初、最大実行時間はわずか 60 秒でした。2015 年 10 月の re:Invent 2015 で 5 分に延長され、2018 年 10 月に現在の 15 分へ引き上げられました。この段階的な延長は、顧客のユースケースの拡大と、AWS 側のインフラ最適化の進展を反映しています。ただし「なぜ 15 分で止まっているのか」について、AWS が決定の根拠を説明した公式資料は見つかりません。以下は公表された設計理由ではなく、この上限が実務でどう働くかという整理です。第 1 に、実行環境のライフサイクルとの関係です。Lambda の関数は Firecracker ベースの MicroVM 上に用意された実行環境で動き、この実行環境は呼び出しをまたいで再利用されるものの恒久的ではありません。実行時間に上限があることで、ローカルディスクやグローバル変数に状態を残さない設計が自然に強制されます。第 2 に、障害検知と復旧の観点です。関数が長時間実行され続けると、デッドロックや無限ループの検知が困難になります。タイムアウトは呼び出しごとに 1 秒から 900 秒 (15 分) の範囲で設定でき、異常な実行を自動的に終了させるセーフティネットとして機能します。第 3 に、コスト予測可能性です。Lambda は実行時間に対して課金されるため、実行時間に上限がないと、バグによる無限ループが予期しない高額請求につながります。15 分の上限は、最悪のケースでも 1 回の実行コストが予測可能な範囲に収まることを保証します。15 分で終わらない処理は、Step Functions で分割してオーケストレーションするか、AWS Batch や Fargate のタスクへ委譲するのが定石です。
メモリ 10 GB とペイロード 6 MB の実務上の意味
Lambda のメモリ上限は、2020 年に 3,008 MB から 10,240 MB (10 GB) に引き上げられました。メモリ設定は CPU の割り当てにも連動しており、1,769 MB で 1 vCPU 相当、上限の 10,240 MB では約 6 vCPU 相当の処理能力が割り当てられます。つまりメモリを増やす操作は、そのまま計算能力を増やす操作でもあります。10 GB は、機械学習の推論、大規模なデータ変換、メモリ集約型の計算処理をカバーできる実用的な上限です。なぜ 10,240 MB で線を引いたのかという算出根拠は公表されていないため、物理ホストの構成から逆算されたという説明を見かけても、それは推測として扱うべきです。ペイロードの上限は、同期呼び出しが 6 MB、非同期呼び出しが 256 KB です (2026 年 8 月時点)。API Gateway と組み合わせる場合は、API Gateway 側のリクエスト/レスポンスのペイロード上限が 10 MB であることも併せて意識する必要があります。加えてバイナリデータは Base64 エンコードで約 33% 増えるため、実際に運べる元データの量は数値上の上限より小さくなります。6 MB という値が API Gateway の 10 MB から逆算されたものかどうかは公式には示されていませんが、いずれにせよ大きなデータを扱う場合は、S3 にデータを保存し、Lambda にはオブジェクトキーだけを渡す「クレームチェックパターン」が推奨されます。非同期呼び出しでは、リクエストがいったん Lambda 側のキューに格納されてから関数へ渡されます。256 KB という上限の理由は公表されていませんが、呼び出しがキューを経由する方式であることは公式に説明されています。
同時実行数 1,000 のデフォルト制限
Lambda のアカウントあたりのデフォルト同時実行数は、リージョンごとに 1,000 です (2026 年 8 月時点)。この制限は、新規アカウントが意図せず大量の Lambda 関数を同時実行し、高額な請求が発生することを防ぐためのセーフガードです。この値は上限緩和リクエストにより引き上げが可能です (引き上げ後に到達できる値は一律には公表されておらず、利用実績や見込みに応じた審査となります)。同時実行数の制限は、Lambda だけでなく、Lambda が接続する下流のサービスを保護する役割も果たしています。たとえば、Lambda が RDS データベースに接続する場合、同時実行数が無制限だとデータベースの最大接続数を超えてしまいます。RDS Proxy を使用すれば接続プーリングで緩和できますが、同時実行数の制限自体が最初の防御線として機能しています。関数レベルの予約済み同時実行数 (Reserved Concurrency) を設定すれば、特定の関数が他の関数の同時実行枠を食い潰すことを防げます。たとえば、重要な API バックエンドの関数に 500 の予約済み同時実行数を設定し、バッチ処理の関数には 100 を設定すれば、バッチ処理の急増が API のパフォーマンスに影響しません。
制限を味方にするアーキテクチャ設計
Lambda の制限を「不便な制約」と捉えるか「設計のガイドライン」と捉えるかで、アーキテクチャの品質は大きく変わります。15 分制限は、処理を小さな単位に分割し、Step Functions でオーケストレーションする設計を促します。Step Functions の Express Workflow は最大 5 分、Standard Workflow は最大 1 年の実行が可能で、個々の関数を 15 分以内に収めたまま、全体としては長時間のワークフローを構成できます。6 MB のペイロード制限は、関数間のデータ受け渡しに S3 を使うクレームチェックパターンを促し、結果として関数間の疎結合性が高まります。メモリ制限は、処理をストリーミング化する設計を促します。10 GB のファイルを一括でメモリに読み込むのではなく、集計は Amazon Athena に任せる、S3 の範囲指定 (Range) 取得や S3 Object Lambda でオブジェクトを分割して読む、Kinesis Data Streams でレコード単位に流すといった方法を取れば、少ないメモリで大量のデータを処理できます。なお S3 Select は新規顧客向けの提供が終了しているため、新規設計の選択肢からは外れます (2026 年 8 月時点)。これらの制限は、結果的にスケーラブルで耐障害性の高いアーキテクチャへと開発者を導きます。制限がなければ、モノリシックな巨大関数を書いてしまう誘惑に負けるでしょう。
参考資料 (AWS 公式)
本ページの一次情報は AWS 公式サイトおよび公式ドキュメントです。最新の仕様 / 料金は次の公式ページで確認できます。
本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。