What Serverless Actually Means
The term serverless is a slight misnomer: there are still servers, you just do not manage them. In a serverless model, your code is deployed as individual functions (in Function as a Service platforms like AWS Lambda, Vercel Functions, or Cloudflare Workers) or as containers that scale to zero when not in use (in Container as a Service platforms like Google Cloud Run or AWS Fargate). The key properties are: you do not provision or manage servers, instances scale automatically from zero to any number in response to demand, you pay per execution rather than per hour of server time, and the platform handles availability, patching, and fault tolerance. For AI product teams, this means you can deploy an AI processing endpoint, route user requests to LLMs, and handle intermittent traffic peaks without pre-provisioning capacity or paying for idle servers. The economic model is particularly appealing at the MVP stage when traffic is unpredictable and sometimes close to zero.
Cold Starts and Their Impact on AI Workloads
The most significant technical limitation of serverless for AI workloads is the cold start problem. When a serverless function has not been invoked recently, the platform needs to initialise a new execution environment before the function can run. This initialisation, loading the runtime, importing dependencies, and preparing the execution context, takes time: typically 100-500 milliseconds for lightweight functions, and potentially 1-3 seconds for functions with large dependencies. For AI products, cold starts are more significant than for traditional API endpoints because AI SDKs and model client libraries can be large. A Lambda function that imports the OpenAI SDK, a database client, and a vector search library might have a cold start of 1-2 seconds on top of the actual API call latency. For user-facing requests where response time matters, this can create a noticeably sluggish experience. Solutions include keeping functions warm with scheduled pings, using platforms with minimal cold start optimisation (Cloudflare Workers is extremely fast), or moving AI processing to a container-based platform (Cloud Run, Fly.io) that keeps instances warm while still scaling to zero.
Execution Duration Limits
Serverless functions have maximum execution duration limits that can constrain AI workloads. AWS Lambda allows up to 15 minutes. Vercel Functions allow up to 60 seconds on Pro plans. Cloudflare Workers have a 30-second CPU time limit. For simple AI API calls (a single LLM request, a search query against a vector database), these limits are not a constraint. A typical GPT-4o completion takes 2-15 seconds depending on output length. For more complex AI workloads, such as processing a long document through an LLM, running a multi-step agentic workflow, or fine-tuning retrieval pipelines, execution can exceed these limits. The standard solution is asynchronous processing: the serverless function receives the request, submits a job to a queue, and returns a job ID immediately. A separate background worker (a container that is not subject to function duration limits) processes the job and stores the result. The client polls for the result or receives it via a push mechanism. This hybrid approach uses serverless for the request-response interface and a container for long-running AI tasks.
Serverless Cost Model for AI Products
The serverless cost model is pay-per-invocation and pay-per-execution-time, measured in GB-seconds (memory allocated multiplied by execution duration). For low-traffic MVPs, this is typically cheaper than reserved server capacity because you pay nothing when there are no requests. Most serverless platforms offer a generous free tier. AWS Lambda's free tier includes 1 million invocations and 400,000 GB-seconds per month, which covers significant traffic for a lightweight AI endpoint. The cost model inverts at high traffic. If your AI endpoint is handling constant sustained traffic, you may be paying more per request in serverless than you would for a reserved container instance. At the traffic levels relevant to most MVPs, serverless is cost-effective. At scale, comparative pricing analysis against container-based options is worth doing. Note that the LLM API costs (OpenAI, Anthropic) will typically dwarf your serverless compute costs at any traffic level, so optimising inference cost is usually more impactful than optimising infrastructure cost.
Serverless for Different Parts of an AI Stack
Different components of an AI product stack are more or less suited to serverless. API routes that handle user requests and call external LLM APIs are a natural fit for serverless functions. The execution time is bounded by the LLM API response time (typically under 30 seconds for most requests), and the stateless nature of the request-response model fits the serverless execution model. Webhook handlers (receiving events from payment providers, email services, or third-party integrations) are excellent candidates for serverless because they receive sporadic traffic and need to respond quickly and reliably. Background AI processing (long document analysis, batch embeddings, model fine-tuning runs) is poorly suited to serverless duration limits and is better handled by containers. Static asset serving is better handled by a CDN rather than serverless functions. The practical architecture for most AI MVPs is a Next.js application on Vercel (which uses serverless functions for API routes by default) combined with a small number of containers for long-running AI tasks.
Serverless and GDPR in the UK Context
When using serverless functions, personal data passes through the cloud provider's infrastructure. Under UK GDPR, this constitutes international data transfer if the serverless platform operates outside the UK. AWS, Google Cloud, and Azure all offer UK and EU data residency options for their serverless platforms. Vercel operates data through AWS regions, and you can configure Edge Functions to run in EU regions. Cloudflare Workers can be configured with Smart Placement to prefer EU regions. If your AI product handles sensitive personal data (health information, financial data, or data about children), verifying that serverless executions occur within UK or EEA jurisdiction, and having a Data Processing Agreement with your serverless provider, is a GDPR compliance requirement. Most major providers have standard DPA templates available. SpeedMVPs configures data residency and DPA requirements as part of every MVP delivery for UK and EU clients.