> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Navigating Concurrency Cold Starts and Other Enhancements for Lambda > Guide to AWS Lambda concurrency, cold starts, memory tuning, and practical patterns to reduce latency, manage scaling, and optimize cost Welcome. This guide explains AWS Lambda concurrency, cold starts, memory tuning, and practical patterns to reduce latency and cost. It preserves the original diagrams and keeps the same sequence so you can follow the visual flow while reading the improved explanation. Cold starts occur when Lambda provisions a new execution environment (a container or micro-VM). During a cold start, Lambda must download your code, initialize the execution environment, run any static initialization code, and finally invoke the handler. Once initialized, that environment may be reused for subsequent invocations (warm starts), which skip the heavy initialization step. A presentation slide titled "Cold Start and Latency" showing a four-step flow: download your code, start a new execution environment, execute initialization code, and execute handler code, each with an icon. A colored bar highlights "Cold start duration" versus "Invocation duration" and a caption notes cold starts increase latency. Cold starts increase end-to-end latency because initialization must complete before your handler runs. Warm starts reuse the already-initialized execution environment, so invocation latency is limited to handler execution and any per-invocation logic. A slide titled "Warm Start and Latency" showing a timeline of four steps in a function start-up: "Download your code," "Start new execution environment," "Execute initialization code," and "Execute handler code." A green bar labeled "Warm Start" and a red/orange bar labeled "Invocation duration" run along the time axis beneath the steps. In steady production workloads cold starts are often uncommon (commonly \<1% of invocations), but frequency and latency depend on runtime languages, package sizes, initialization code, and traffic patterns. Cold-start latency can range from a few hundred milliseconds to multiple seconds for large binaries or heavy initialization. A presentation slide titled "Cold Start Frequency" showing a "PRODUCTION" box and stating cold starts occur in "<1% of invocations." The slide is copyrighted by KodeKloud. Lambda internally optimizes environment reuse and often keeps environments warm for several minutes (commonly around 5–15 minutes) when it detects continued usage. You can reduce cold starts further with several approaches described below. Key patterns and controls * Provisioned concurrency: keeps a specified number of execution environments initialized and ready, eliminating cold-start latency for those environments. * Reserved concurrency: caps maximum concurrent environments for a function to control parallelism and protect downstream resources. * Asynchronous buffering (SQS / SNS / EventBridge): smooths bursts by queueing or routing events so Lambda can process messages at a controlled rate. * Memory tuning: increasing memory increases CPU and network bandwidth, often reducing execution time and potentially lowering overall cost. For more on provisioned concurrency, see the AWS docs: [https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html) A timeline diagram titled "Code Updates and Configuration Changes" showing two AWS Lambda function invocations before and after a function code update. Colored bars indicate cold start duration (blue) and invocation duration (orange). Lambda execution environments handle only one request at a time. When multiple requests arrive concurrently, Lambda scales by creating additional execution environments — each new environment may incur a cold start. Smoothing traffic spikes and staggering bursts improves reuse and reduces cold-start storms. A slide titled "Understanding invocation patterns: Simultaneous Request" showing six parallel AWS Lambda invocations, each with a blue cold-start segment followed by an orange invocation duration. A small legend at the bottom right explains the colors and a time axis runs across the top. Asynchronous invocation patterns * Use SQS, SNS, or EventBridge to decouple producers from Lambda consumers. * SQS buffers messages; Lambda polls the queue and scales, smoothing sudden input bursts. * EventBridge and SNS provide asynchronous delivery semantics and retries. * With SQS or other queueing, messages persist until processed, which reduces the need for immediate capacity and prevents over-provisioning. When you configure reserved concurrency for a function, the reserved value is the maximum number of concurrent execution environments Lambda will use for that function. This guarantees capacity for critical functions but also caps scaling. A timeline diagram titled "Understanding Invocation Patterns: Asynchronous Request With Reserved Currency Of 1" showing an AWS Lambda cold start (blue) followed by sequential orange invocation blocks numbered 1–6 along a time axis, with a legend for cold start and invocation duration. If your application tolerates relaxed latency, combining asynchronous processing and reserved concurrency helps maintain steady throughput without large cold-start storms. Provisioned concurrency removes cold-start latency for the configured environments but adds cost. Use it where low, predictable latency is required (for example, user-facing endpoints), and consider combining it with autoscaling and careful traffic management. Memory and CPU trade-offs Memory allocation is the primary performance control for Lambda: raising memory also increases CPU and network resources. Lambda supports memory sizes from 128 MB to 10,240 MB (10 GB), adjustable in 1 MB increments. The default is 128 MB. A slide titled "Overview of Memory Configuration in AWS Lambda" with an illustration of a monitor/chip and gears. It notes the memory range (128 MB to 10,240 MB) and the default setting (128 MB). Increasing memory often reduces execution time by providing more CPU cycles, which can reduce the total billed duration even though the per-millisecond cost is higher. Depending on your workload, a larger configuration can be cheaper overall because it finishes faster. A line chart titled "Cost vs. Performance Trade-off" showing execution time (blue) and execution cost (orange) plotted against Lambda power (MB). The blue curve (execution time) dips then rises at the highest memory, while the orange curve (cost) falls steeply as memory increases. Use automated tools like the Lambda Power Tuning tool to run experiments across memory settings and identify the best cost-performance point: [https://github.com/alexcasalboni/aws-lambda-power-tuning](https://github.com/alexcasalboni/aws-lambda-power-tuning) Practical tips to minimize cold-start impact * Specialize functions: split large or multi-purpose functions into smaller, single-purpose functions so each has minimal initialization work. * Selective importing: import only the modules you need. Heavy, monolithic libraries increase init time. * Reuse connections: create service or database clients during static initialization so they persist across invocations. * Lazy load when possible: defer expensive initialization until it’s actually needed by the handler. * Avoid global mutable state for per-invocation data: use local variables inside the handler to prevent state leakage between invocations. Static initialization (init code) runs only during cold starts and is often the biggest contributor to cold-start latency. Keep init code small and efficient. Example: reasonable static initialization and a handler in Python ```python theme={null} import os import json import cv2 import logging import boto3 # Static initialization: create clients and configure logging once s3 = boto3.client("s3") logger = logging.getLogger() logger.setLevel(logging.INFO) def lambda_handler(event, context): logger.info("Starting handler") # Example: S3 event structure — get object metadata from the event input_bucket_name = event["Records"][0]["s3"]["bucket"]["name"] file_key = event["Records"][0]["s3"]["object"]["key"] output_bucket_name = os.environ["OUTPUT_BUCKET_NAME"] output_file_key = file_key.replace(".jpg", ".png") logger.info("Input bucket: %s", input_bucket_name) logger.info("Output bucket: %s", output_bucket_name) # Handler logic continues... ``` Best practices summary (when to use each technique) | Technique | When to use | Notes / Links | | - | - | - | | Provisioned concurrency | User-facing, low-latency endpoints | `https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html` | | Reserved concurrency | Protect downstream systems or cap function scale | Use to guarantee/limit concurrency | | Asynchronous (SQS/EventBridge/SNS) | Jobs that can be processed eventually or tolerate retries | SQS buffers bursts; EventBridge and SNS offer delivery semantics | | Memory tuning | CPU-bound or short-running functions that benefit from faster execution | Use power tuning: `https://github.com/alexcasalboni/aws-lambda-power-tuning` | | Code/Init optimizations | Reduce cold-start duration | Split functions, selective imports, lazy loading | A presentation slide titled "Best Practices for Reliability and Business Continuity." It shows five numbered cards with icons listing: Specialization of Functions, Selective Importing, Efficient Database Connection Management, Lazy Loading, and Scope Management. Combine memory tuning, init-code minimization, appropriate concurrency controls, and asynchronous patterns to optimize Lambda for latency, throughput, and cost. Monitor real traffic patterns and run experiments to find the best trade-offs for your workload. References and further reading * AWS Lambda runtimes and execution environment: [https://docs.aws.amazon.com/lambda/latest/dg/runtimes.html](https://docs.aws.amazon.com/lambda/latest/dg/runtimes.html) * Provisioned concurrency: [https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html) * Lambda concurrency configuration: [https://docs.aws.amazon.com/lambda/latest/dg/configuration-concurrency.html](https://docs.aws.amazon.com/lambda/latest/dg/configuration-concurrency.html) * Lambda Power Tuning (tool): [https://github.com/alexcasalboni/aws-lambda-power-tuning](https://github.com/alexcasalboni/aws-lambda-power-tuning) Thanks for reading. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.