Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteAWS Lambda’s standard maximum runtime is 15 minutes per invocation, but runtime is only one of several constraints that can shape an application. Memory and temporary storage have fixed ranges, payload and deployment limits vary by invocation type and packaging method, and concurrency quotas are separate from how quickly a function can scale. The applicable limits depend on the Lambda feature, invocation path, AWS Region, and account; verify your current allocations in AWS Lambda quotas and test the complete event path.
Runtime and execution resources
Maximum execution time
A standard Lambda function can run for up to 900 seconds (15 minutes) per invocation. That ceiling can rule out work that must complete as one long-running execution; splitting a job into smaller tasks or using a different compute pattern may be necessary.
AWS Lambda Managed Instances have a longer maximum timeout—5,400 seconds (90 minutes)—for asynchronous invocations and event source mapping invocations, except those from Amazon MQ and Amazon DocumentDB. Synchronous Managed Instances invocations and initialization remain limited to 15 minutes. The 90-minute allowance is therefore a specific Managed Instances exception, not a general Lambda timeout.
Memory, CPU, temporary storage, and process ceilings
Lambda memory is configurable from 128 MB to 10,240 MB in 1 MB increments. CPU allocation increases in proportion to configured memory; AWS says 1,769 MB corresponds to the equivalent of one vCPU. This means memory configuration affects both available memory and compute capacity.
#1 Best Overall
Temporary /tmp storage can be configured from 512 MB to 10,240 MB. Standard execution environments are limited to 1,024 file descriptors and 1,024 execution processes or threads; AWS lists 4,096 file descriptors for Managed Instances. These limits matter for workloads with large intermediate files, many open connections or files, or high thread counts. Measure the workload at its realistic peak rather than assuming that a larger memory setting removes every resource constraint.
Payload and response limits
The maximum payload depends on how Lambda is invoked and whether the response is streamed. AWS documents the following limits:
| Invocation or transfer type | Documented limit |
|---|---|
| Synchronous request payload | 6 MB |
| Synchronous response payload | 6 MB |
| Synchronous streamed response | Up to 200 MB |
| Asynchronous invocation payload | 1 MB |
| Combined request line and header values | 1 MB |
For streamed responses, AWS lists uncapped bandwidth for the first 6 MB and a limit of 2 MB/s for the remainder. A larger stream allowance does not make every Lambda response path suitable for large transfers: the invocation method and its own limits still matter.
Large events can also increase memory consumption and processing time. AWS troubleshooting guidance notes that larger image inputs can cause functions to run out of memory, and recommends checking payload sizes and testing the largest expected inputs. A Lambda event-size limit is not the same as the size of an object stored in Amazon S3: a common design is to pass a reference to externally stored data rather than include the data itself in the event. See AWS Lambda troubleshooting guidance.
AWS lists network bandwidth of 625 Mbps per execution environment, with a possible increase through Service Quotas for functions that are not attached to a VPC. That figure is a documented quota, not a guarantee of application-level throughput; the invocation path and dependent services can impose other constraints.
Deployment package and code storage limits
Lambda has separate limits for direct ZIP uploads, expanded deployment contents, container images, and regional storage of Lambda-managed ZIP and layer code. They apply at different stages and should not be treated as one package-size cap.
Rank #3
| Packaging or storage constraint | Documented limit | Practical meaning |
|---|---|---|
| Direct ZIP upload through Lambda API/SDK or console | 50 MB | AWS directs users to Amazon S3 for larger uploads. |
| Unzipped deployment contents, including layers and custom runtimes | 250 MB | Expanded contents must fit; extensions also count toward the ZIP deployment limit. |
| Container image code package | 10 GB uncompressed | This is a separate packaging limit, not an increase to the ZIP limit. |
| Lambda-managed ZIP and layer code storage | 300 GB per Region | AWS says this quota cannot be increased; its quota guidance identifies self-managed S3 code storage as an option beyond it. |
Extensions run alongside function code and share its CPU, memory, and storage resources. A package that fits the deployment ceiling can still leave too little runtime capacity for the function if extensions consume a substantial share. Consult AWS’s quota documentation when choosing between ZIP and container packaging.
Concurrency, request rate, and scaling
Account concurrency is not the scaling rate
AWS lists a default account concurrency quota of 1,000 concurrent executions per Region, generally adjustable to tens of thousands. New accounts may have lower quotas. This is shared capacity across functions in the account and Region unless reserved concurrency settings allocate capacity.
Separately, AWS documents a per-function scaling rate of 1,000 additional execution environments every 10 seconds in each Region. The account concurrency quota describes the total simultaneous capacity available; the scaling rate describes how quickly new execution environments can be added when traffic rises. A sudden spike can therefore encounter a scaling constraint even when the account’s total quota is higher than current use. Requests can be throttled when demand exceeds available concurrency or capacity cannot be added quickly enough. See AWS Lambda scaling behavior.
Relate request rate to duration
For synchronous invocations, AWS says each execution environment can serve up to 10 requests per second. The total synchronous request rate is therefore tied to the function’s concurrency limit: AWS expresses it as 10 times that limit. In practice, needed concurrency depends on both request rate and average execution duration. A high request rate with slow executions occupies more environments than the same rate with short executions, so size capacity against both measures and the traffic pattern.
Control-plane and neighboring service quotas
Lambda’s management APIs have their own request-rate limits, separate from function invocation capacity. AWS lists 100 requests per second for GetFunction, 15 requests per second for GetPolicy, and 15 requests per second across the remainder of the control-plane APIs; AWS marks these limits as not increaseable. Automation that repeatedly queries or updates Lambda configuration can run into these API limits even when functions are not busy.
End-to-end applications can also hit limits in API Gateway, VPC, IAM, EFS, event sources, or downstream services. Lambda’s own quota is only one part of the path, so AWS recommends load testing the complete design to identify the actual bottleneck.
Best Value
Separate limits for specialized Lambda features
Durable Functions and Lambda Managed Instances have their own quota sections and behavior; their limits should not be applied to ordinary Lambda invocations. For example, AWS lists Durable Functions limits of 3,000 durable operations per execution and 100 MB of cumulative persisted execution data, both marked not increaseable. Check the quota section for the feature you are using rather than assuming the standard function limits describe it.
How to assess whether Lambda fits your workload
Evaluate the workload against the constraints that define its execution path:
- Longest individual task: establish whether the invocation is synchronous, asynchronous, or event-source mapped, and compare its required duration with the applicable timeout.
- Traffic and burst behavior: estimate peak request rate, average duration, required concurrency, and how much warm-up or throttling the application can tolerate.
- Largest event and response: identify the invocation mode and any streaming behavior; consider storing large data externally and passing a reference.
- Code footprint: account for expanded ZIP contents, layers, custom runtimes, extensions, container image size, and accumulated regional versions and layers.
- Runtime resources: measure memory, temporary disk, open files, threads, CPU needs, and network behavior using realistic inputs.
- Whole-system dependencies: include the quotas and capacity of event sources and downstream services, not only Lambda’s limits.
AWS describes Lambda as intended for “short-lived compute tasks that do not retain or rely upon state between invocations.” That design principle helps frame fit: a workload that needs long-lived state or a single execution beyond the applicable timeout may need to be decomposed or run on another compute service.
Check current quotas before changing the design
The figures above are AWS-published service quotas, not independent performance measurements. Regional allocations and account defaults can differ, and AWS quotas can change. In the AWS console, open Service Quotas, choose AWS services, then select Amazon Web Services Lambda to review the quotas and whether each is adjustable. A quota increase request does not establish that the application will meet its latency or throughput goals; validate the full event path and dependencies under representative load.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
