Why Lambda's 15-Minute Limit Is 15 Minutes - The Rationale Hidden in Serverless Design Constraints
This article explains the current values of the various serverless limits, such as Lambda's maximum execution time of 15 minutes, memory limit of 10 GB, and payload of 6 MB, and how they affect architecture design. It does so from the perspectives of multi-tenant operation and the lifecycle of the execution environment.
Limits Are Design Decisions, Not Constraints
The first thing developers face when they start using Lambda is its various limits. Representative values are a maximum execution time of 15 minutes, 128 MB to 10,240 MB of memory, a 6 MB synchronous invocation payload, and a 250 MB deployment package (unzipped) (as of August 2026 / based on the official quota list). AWS has not disclosed how it decided these values. What follows is therefore not the official design rationale but the rationale that can be read from the perspectives of resource fairness in a multi-tenant environment, operational safety, and cost efficiency. Lambda is a multi-tenant service that runs the functions of many customers on the same physical infrastructure. If one function consumes resources without limit, it affects the functions of other customers. Limits are guardrails to prevent the "noisy neighbor problem", and at the same time they are intentional constraints that shape the serverless design paradigm. Precisely because there are limits, developers come to split processing into small units and design event-driven, loosely coupled architectures.
The History and Background of the 15-Minute Limit
When Lambda launched in 2014, the maximum execution time was only 60 seconds. It was extended to 5 minutes at re:Invent 2015 in October 2015, and raised to the current 15 minutes in October 2018. This gradual extension reflects the expansion of customer use cases and the progress of infrastructure optimization on the AWS side. However, no official material can be found in which AWS explains the basis for its decision on "why it stops at 15 minutes". The following is not a published design rationale but an organized look at how this limit works in practice. The first point is its relationship with the lifecycle of the execution environment. Lambda functions run in execution environments prepared on Firecracker-based MicroVMs, and these execution environments are reused across invocations but are not permanent. Having an upper limit on execution time naturally enforces a design that does not leave state on the local disk or in global variables. The second point is the perspective of failure detection and recovery. If a function keeps running for a long time, detecting deadlocks and infinite loops becomes difficult. The timeout can be set per invocation in the range of 1 second to 900 seconds (15 minutes), and it functions as a safety net that automatically terminates abnormal executions. The third point is cost predictability. Because Lambda charges for execution time, without an upper limit on execution time, an infinite loop caused by a bug leads to an unexpectedly high bill. The 15-minute limit guarantees that even in the worst case, the cost of a single execution stays within a predictable range. For processing that does not finish in 15 minutes, the standard approach is to split it and orchestrate it with Step Functions, or to delegate it to AWS Batch or Fargate tasks.
Launched in 2014, 15 minutes since 2018
What 10 GB of Memory and a 6 MB Payload Mean in Practice
The Lambda memory limit was raised from 3,008 MB to 10,240 MB (10 GB) in 2020. The memory setting is also linked to CPU allocation: at 1,769 MB, processing power equivalent to 1 vCPU is allocated, and at the upper limit of 10,240 MB, processing power equivalent to about 6 vCPUs. In other words, increasing memory is an operation that directly increases computing power as well. 10 GB is a practical upper limit that can cover machine learning inference, large-scale data transformation, and memory-intensive computation. The basis for drawing the line at 10,240 MB has not been published, so even if you come across an explanation that it was worked back from the configuration of the physical hosts, you should treat it as speculation. The payload limits are 6 MB for synchronous invocations and 256 KB for asynchronous invocations (as of August 2026). When you combine Lambda with API Gateway, you also need to keep in mind that the request/response payload limit on the API Gateway side is 10 MB. In addition, Base64 encoding increases binary data by about 33%, so the amount of original data you can actually carry is smaller than the nominal limit. Whether the 6 MB value was worked back from API Gateway's 10 MB has not been officially stated. In any case, when you handle large data, the "claim check pattern", which stores the data in S3 and passes only the object key to Lambda, is recommended. In asynchronous invocations, the request is first stored in a queue on the Lambda side and then passed to the function. The reason for the 256 KB limit has not been published, but it is officially explained that invocations go through a queue.
The Default Concurrency Limit of 1,000
The default concurrency per account for Lambda is 1,000 per Region (as of August 2026). This limit is a safeguard to prevent a new account from unintentionally running a large number of Lambda functions at the same time and incurring a high bill. This value can be raised through a quota increase request (the value you can reach after the increase is not published uniformly, and the request is reviewed according to your usage history and expected usage). The concurrency limit also plays the role of protecting not only Lambda but also the downstream services that Lambda connects to. For example, when Lambda connects to an RDS database, if concurrency is unlimited, it exceeds the maximum number of database connections. If you use RDS Proxy, you can mitigate this with connection pooling, but the concurrency limit itself functions as the first line of defense. If you set function-level reserved concurrency, you can prevent a specific function from eating up the concurrency capacity of other functions. For example, if you set a reserved concurrency of 500 for the function of an important API backend and 100 for a batch processing function, a surge in batch processing does not affect API performance.
Architecture Design That Makes Limits Work for You
The quality of an architecture changes greatly depending on whether you regard Lambda's limits as "inconvenient constraints" or as "design guidelines". The 15-minute limit encourages a design that splits processing into small units and orchestrates them with Step Functions. Step Functions Express Workflows can run for up to 5 minutes and Standard Workflows for up to 1 year, so you can build a workflow that is long-running as a whole while keeping each function within 15 minutes. The 6 MB payload limit encourages the claim check pattern, which uses S3 to pass data between functions, and as a result loose coupling between functions increases. The memory limit encourages a design that turns processing into streaming. Instead of loading a 10 GB file into memory at once, you can leave aggregation to Amazon Athena, read objects in parts with S3 Range GET requests or S3 Object Lambda, or stream record by record with Kinesis Data Streams. With these approaches, you can process large amounts of data with little memory. Also, S3 Select is no longer available to new customers, so it is no longer an option for new designs (as of August 2026). As a result, these limits lead developers toward scalable and highly fault-tolerant architectures. Without limits, developers would probably give in to the temptation to write giant monolithic functions.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
If this page and the official documentation disagree, treat the official documentation as authoritative.