Engineering guides / Angular applications and AWS infrastructure
By Arte Soft engineering · 24 October 2026
Lambda cold starts: investigate before buying warm capacity
A slow first request is often called a cold start before anyone has checked where time was spent. Lambda initialization can contribute, but dependency loading, network access and a database connection may explain more of the delay. An investigation should distinguish those causes and relate them to the user’s actual latency requirement before adding recurring infrastructure cost.
Collect timings with enough context
Measure initialization and invocation separately where the runtime exposes them. Include function version, memory setting, runtime, package size and concurrent demand. Compare a freshly initialized environment with subsequent requests using the same representative payload. Trace external calls rather than attributing their elapsed time to Lambda itself. A request arriving after idle time is useful evidence, but it is not the only relevant scenario: scaling during a burst may create new environments too. Keep the distribution of results rather than selecting the fastest or slowest run to support a preferred solution.
Find the expensive initialization
Inspect work performed before the handler can do anything useful. Large dependency graphs, unnecessary imports and eagerly created clients can add delay. Some reusable clients belong outside the handler; other expensive work should happen only when needed. Evaluate the memory and runtime configuration using measured results because available compute affects execution behavior. Check whether a networking or database change is required before altering packaging. The report should connect each proposed change to an observed portion of the critical path. Avoid a broad rewrite based on a generic list of cold-start tips that may not fit this function.
Compare costed alternatives
A smaller deployment artifact or reduced initialization work can be inexpensive to maintain. Provisioned capacity may help appropriate workloads but adds configuration and cost. Different compute patterns can be more suitable for strict latency objectives or long-lived connections. Model alternatives using request frequency, concurrency and the business effect of a slow request. Deliver a timing breakdown, a tested change where practical and a comparison of operational tradeoffs. Acceptance should use a declared percentile or representative scenario, not the vague promise that the function will always be fast under every possible traffic spike.
Report the baseline conditions alongside the results, including the period of observation. An occasional initialization delay on an infrequent administrative task may deserve a different response from the same delay in the first step of a customer checkout.
Prevent the next unexplained regression
Add a lightweight way to observe initialization and dependency time after release. Document which package or configuration changes should trigger a repeat measurement. Arte Soft’s own software provides a practical product context, but performance claims for your workload require your own traces and fixtures. Send the function configuration, a reproducible slow operation and any existing logs with sensitive fields removed. A focused investigation can reveal whether cold starts are material at all. That conclusion is valuable even when the right recommendation is to fix a downstream query or leave an already adequate function alone.
Relevant Arte Soft work
GPT Realtime Assistant — our own product is our own product or engineering project. It provides context for the work we discuss here; it is not a claim of identical results for every client deployment.
Sources and further reading
Need help with Lambda latency investigation?
Send the current app, system or brief, the behaviour you need and your constraints. We can agree a discovery, implementation or repair scope with concrete acceptance criteria.
Discuss this with Arte Soft