Serverless Challenges: Cold Starts, Limits and Cost Surprises

The main serverless challenges on AWS and Azure fall into six areas: cold starts, hard limits, database connections, cost surprises, audit, and data residency. Each has a known guardrail. Several of those guardrails are settings you choose before launch.

Teams weighing serverless drawbacks want to know which ones to plan for and which to accept. This article covers functions run on AWS or Azure, for IT leads in India and the GCC. It is not a build guide or a price comparison. For the build steps, see an order of work for building your first function-based service. Every figure in it comes from the provider’s own documentation.

Serverless Challenges Start With Cold Starts

Scale to zero saves spend while nothing runs, and it adds a start delay when the next request arrives. That delay is the first thing users notice.

Why a Function Starts Cold

A cold start is the delay while the platform prepares a new instance before the first request runs. It happens when a function has been idle. It also happens when a burst of traffic needs more instances than are already running.

For a background job that nobody waits on, the delay rarely matters. For a customer-facing call, such as a payment confirmation or a login, it shows up as a slow first response. Decide for each function which of the two it is.

Functions also keep no state between runs. A new instance starts empty. The platform may also deliver one event twice, for example after a failure, a timeout or a queue retry. In our recommendation, write each handler so that a second run of the same event does no harm. For the basic meaning of function as a service, the glossary page has the full definition.

Keeping Instances Warm Has a Cost

Keeping instances warm trades latency for standing spend. A warm instance or a scheduled ping avoids the delay. It also brings back the idle cost that serverless was meant to remove.

Tuning steps differ by runtime and sit outside this article. For AWS, see the Lambda tuning steps by runtime in our Lambda guide. Our Azure Functions guide covers the Azure side.

The Limits That Bite in Production

Hard limits set the shape of a design before anyone writes code. A job that does not fit inside the run-time ceiling has to be split, queued, or moved elsewhere. For where it should move, see the seven questions that decide where an application should run. If it moves to containers on clusters the team runs itself, plan for the upgrade, backup and on-call work those clusters bring.

Concurrency means requests handled at the same moment, and it is a limit to plan for before launch. The figures below are as of November 2026.

AWS Lambda Limits as of November 2026

AWS’s Lambda quotas page sets the ceilings for standard functions.

• Run time: 900 seconds (15 minutes). Functions on Lambda Managed Instances allow up to 5,400 seconds (90 minutes) for asynchronous invocations. On Managed Instances, the same limit applies to event source mappings other than Amazon MQ and Amazon DocumentDB.
• Memory: 128 MB to 10,240 MB, in 1-MB steps.
• Payload: 6 MB each for the request and the response on a synchronous call. An asynchronous call, however, allows 1 MB. Streamed responses follow a different limit.
• Concurrency: 1,000 concurrent executions per Region by default, shared by every function in the account in that Region. New accounts start with a lower quota, which AWS raises as usage grows.

When a Region runs out of concurrency, Lambda throttles new requests. A synchronous caller gets a throttling error, and an asynchronous event goes back to a queue to be retried later. One busy function can therefore starve the others, which is why a cap per function matters (see the guardrails below).

Azure Functions Limits as of November 2026

On Azure, the plan sets the limits, and the plan choice itself is covered in our Azure Functions guide. Microsoft’s Azure Functions hosting page marks the Consumption plan as legacy and names Flex Consumption for new serverless function apps. It also states that Linux Consumption retires on 30 September 2028.

For Flex Consumption, these figures apply:

• Scale out: up to 1,000 instances, with a default limit of 100 instances. The limit applies to each group of functions that scale together. A regional memory quota for the subscription can also stop scale-out sooner.
• Timeout: 30 minutes by default, and unbounded as a maximum.
• HTTP response: an HTTP triggered function must respond within 230 seconds.

The legacy Consumption plan has different scale and timeout limits, so read the row of the table for the plan you run.

Database Connections Under Burst Load

A burst of traffic can drain a database connection pool, because each function instance opens its own connections. If hundreds of instances start together and each opens a few connections, the database sees a flood it was not sized for.

On AWS, a database proxy sits between the functions and the database. Amazon RDS Proxy sets up a connection pool and reuses the connections in it. Connections it is unable to serve at once from the pool are queued or throttled. The database then sees a steadier load, at the price of some added latency.

On Azure, the legacy Consumption plan limits outbound connections to 600 active (1,200 total) per instance, with no global limit. Microsoft advises reusing one shared client across invocations on every plan, instead of opening a new connection on every call.

In Signisys’s working view, this problem shows up on the first load test sooner than on the design drawing.

Serverless Challenges in Cost: Surprises and Guardrails

Pay per use cuts idle spend and removes the ceiling on a bad day. A spike, a loop or a retry storm turns directly into spend, because each run is a charge. The cost side has two parts: where surprises come from, and what to set before launch.

Where Cost Surprises Come From

Three patterns explain how a surprise happens, and each one traces back to design.

• Recursive loops: a function that writes to the queue or bucket that triggers it.
• Retry storms: a failing downstream service that makes every caller retry at once.
• Traffic spikes: a campaign, a bot, or a scan that sends far more requests than planned.

AWS’s note on recursive loops warns that unintentional loops can result in unexpected charges. For supported services and SDKs only, Lambda stops a chain once a function has been invoked about 16 times in it. This detection is also on by default. Loops that run through other services are not caught.

These serverless drawbacks come from how pay-per-use meets error handling. This section attaches no rates to them. The shape of the risk matters more here than any figure.

Guardrails to Set Before Launch

Four guardrails contain these surprises. Set them in this order before the first release.

1. Reserved concurrency per Lambda function. It reserves a set number of concurrent instances for that function. It also stops the function from scaling past that number. That caps both the spend and the damage a loop can do.
2. A maximum instance count per Azure function app. On Flex Consumption the setting runs from 1 to 1,000. Set it too low and an HTTP app can reject requests, so pick it with a load test.
3. Alarms and budget alerts. AWS recommends CloudWatch alarms on unusual usage, such as a spike in concurrency or invocations. Add spend alerts too. AWS Budgets can alert on actual and forecast spend, and Microsoft Cost Management does the same job on Azure. Both lag behind usage. AWS Budgets data updates up to three times a day, and Azure budgets are checked every 24 hours. A fast loop can outrun either alert, while an alarm on usage reacts sooner.
4. Idempotent handlers. A handler that can run twice without doing double work makes retries safe. In our recommendation, it is the cheapest guardrail of the four.

Audit: Logs, Tracing and Identity per Function

Each function should leave its own trail in logs and traces. It should also carry its own identity, with the least access it needs. Without both, an incident review starts with guesswork.

On AWS, Lambda writes logs by default to a CloudWatch Logs group per function. The group is named /aws/lambda/ followed by the function name. X-Ray then builds a service map and searchable trace summaries from the trace data. On Azure, Azure Functions has built-in integration with Application Insights.

For identity, Lambda assumes an execution role for each function when it runs. On Azure, identity-based connections use managed identities for authentication, so no stored secret has to sit in the function’s settings.

In our recommendation, give each function its own role or identity, and grant it only the resources it touches. One shared broad role turns a single flawed function into access to everything the role can reach. Review the roles with the logs, since an auditor will ask who could do what, and who did.

Data Residency for India and the GCC

Pick the Region before the first function runs, because data, logs, traces and backups all land where the workload runs. Logs and traces count as data too.

As of November 2026, AWS lists these Regions near India and the GCC. Asia Pacific (Mumbai) does not require opt-in. Asia Pacific (Hyderabad), Middle East (Bahrain) and Middle East (UAE) are opt-in Regions, so an account has to enable each one before use. On Azure, Flex Consumption does not currently run in all regions. Check the list with the az functionapp list-flexconsumption-locations command before you pick an India or GCC region.

Lock-In and Skills Among Serverless Challenges

Lock-in and skills are real costs. They are trade-offs to accept with open eyes, and they sit outside the six areas above.

Among the disadvantages of serverless computing, lock-in comes from triggers, bindings and identity. These tie code to one provider’s event model. Business logic moves more easily than the wiring around it. Debugging also differs from a server. A request crosses several functions and queues, so the team needs skills in event-driven tracing.

A fit check helps before any build. For a single workload, a scored fit check is set out in the sheet that marks a workload as ready for functions. To pick an application style before choosing where code runs, see our comparison of monolith, microservices and serverless. For the delivery view, see functions built and run on AWS or Azure.

As a disclosure, Signisys provides application modernization and observability work. In addition, our DevOps and automation services team takes on this kind of review. A consultation checks your planned functions against limits, connections, cost guardrails, audit and residency. It promises no result or saving. No charge, with a fixed scope.

Serverless Challenges FAQ: Questions From IT Leads