Key Takeaways
- Serverless removes server sizing, not performance work. The provider documents limits, and a load test is how you find out where your own function, database and gateway meet them.
- Three risks deserve a test before anything else: cold starts, concurrency throttling, and the downstream database or API that every function instance hits at once.
- This is the short argument for why to test. The measurement method is in the serverless performance testing guide, and the reading of results is in how serverless changes performance testing.
Why does serverless still need performance testing?
Serverless still needs performance testing because scaling is automatic but bounded, and the bounds are yours to discover. The provider adds execution environments as requests arrive, subject to documented quotas and scaling rates, and your code still has to initialize, call other services and finish in time. None of that is visible in a unit test or a single request, so the first time it shows up is under real traffic unless you simulate that traffic first.
The claim that “serverless scales for you” is true as far as it goes. It does not cover the database behind the function, a third-party API with its own rate limit, or the extra latency of a request that lands on a new execution environment.
Which three risks should you test first?
Start with the three below. Each has a concrete, provider-documented basis for AWS Lambda, read from the AWS documentation on 2026-10-23; the same questions apply to Azure Functions and Cloud Run with their own numbers, which the guide lists.
1. Cold starts. AWS says cold starts typically occur in under 1% of invocations and range from under 100 ms to over 1 second, and are more common in development and test functions because those run less often. A small share of requests is slow, so an average hides it and a high percentile shows it. Test with idle gaps and a burst afterwards, and report cold and warm latency separately.
2. Concurrency throttling. By default a Lambda account has a limit of 1,000 concurrent executions across all functions in a Region, shared on demand, and functions throttle when it runs out. There is also a requests-per-second cap equal to 10 times the account concurrency, which matters for very fast functions. Concurrency is roughly requests per second times average duration in seconds, so you can estimate where your own peak sits before you run the test. Also check that your test does not exhaust the pool other production functions need.
3. The downstream dependency. Each concurrent invocation is a separate execution environment, so a burst can open hundreds of database connections or call a rate-limited API at a rate it never saw before. Run the test against the real database and API, not mocks, and watch connection errors and latency there as well as on the function.
How is the test itself different?
Use traffic that looks like your events, not a constant loop. A steady request rate keeps environments warm and hides cold starts, so include quiet periods and sudden ramps. Estimate the cost of the run first, because invocations are billed like production traffic. The detailed steps, with the cold-start tagging and the limits for Azure Functions and Cloud Run, are in the serverless testing guide, and the spike testing post covers the burst shapes.
To run the traffic, LoadFocus load tests hit your function’s HTTP endpoint from 25 cloud regions, with response-time percentiles in the results (loadfocus.com/load-testing, read 2026-10-23). It has no serverless-specific features documented, so the cold/warm split comes from your own script or response headers.
Frequently Asked Questions
Do serverless functions need load testing if the provider scales them?
Yes. The provider scales within documented limits, and your function, database and gateway have their own limits. A load test shows where the first of them is reached.
How common are cold starts on AWS Lambda?
AWS documents that they typically occur in under 1% of invocations, with durations from under 100 ms to over 1 second. Your own rate depends on traffic pattern, runtime and package size, so measure it with a burst after an idle period.
What is the default Lambda concurrency limit?
The AWS documentation states 1,000 concurrent executions per Region across all functions in an account by default, with a quota increase available on request. Check your own account with aws lambda get-account-settings, because the quota can differ.
Is the cost of a serverless load test a problem?
It can be, because usage is billed per request and compute time. Multiply the planned invocations and memory-seconds by the provider’s current prices before running, and include logging and downstream services.
Sources
- AWS Lambda documentation: Understanding Lambda Event Function scaling, docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html (read 2026-10-23)
- AWS Lambda documentation: Understanding the Lambda execution environment lifecycle, docs.aws.amazon.com/lambda/latest/dg/lambda-runtime-environment.html (read 2026-10-23)
- LoadFocus load testing page, loadfocus.com/load-testing (read 2026-10-23)
