What is serverless in AWS - the honest definition and its limits

Serverless doesn't mean nobody is running a server. It means Amazon Web Services runs it, patches it, and hides it from you completely — you hand AWS a function, it executes on hardware you will never see or name, and you pay per invocation instead of by the hour. That is the honest definition. Here's the part almost nobody tells you upfront: the moment you flip on the one setting most teams reach for to fix serverless's biggest weakness — the split-second delay before a fresh function wakes up — you are paying for an idle, always-on server again. Just with extra steps and a fancier name.

Jake found out the hard way. Two weeks before a big weekend promotion, he asked the college kid who does his shop's website to add SMS appointment reminders to the booking form. "Don't worry," the kid said, "it's serverless — you only pay when someone actually uses it." Jake believed him. Then a $340 AWS bill landed for a form that maybe forty people used all month.

If you are new here, then you will not understand what is head and tail, so better start with learn AWS series linked on top of our page..

You can also Read:

• What is AWS Config? The clerk who records every change  
• What is Amazon Macie? The archivist who reads your buckets  
• What is AWS KMS? Who holds the keys to your data  
• What is AWS Secrets Manager? Passwords out of your code  
• What is AWS WAF? The bouncer for your website  
• What is Amazon Route 53? DNS in plain English 
• What is Amazon CloudFront? The copy of your site everywhere 
• What is Amazon ECS? Containers without the PhD  
• What is AWS Fargate? Servers you never see
• What is Amazon ECR? The shelf your images live on  
• What is Amazon EKS? Kubernetes, rented  

That gap — between what "serverless" promises and what it actually charges you for — is the whole subject of this post. Not the marketing definition. The one with the fine print left in, including the parts of serverless that changed in just the last few weeks, because AWS quietly loosened two of the limits everyone complains about most.

What "Serverless" Actually Means

Start with what AWS itself says, because it is more careful than most of the blogs repeating it: serverless computing lets you build and run applications without thinking about servers, because you never provision, scale, or manage any of the machines your code runs on. Notice the wording. It doesn't say "there are no servers." It says you don't have to think about them.

There absolutely are servers. Somewhere in an AWS data center, a physical machine — or more precisely, a slice of one, isolated from every other customer's workload — spins up, runs your ten lines of Python or Node.js, and either sits ready for the next request or gets torn down. You never see an IP address for it. You never SSH into it. You never patch its operating system at 2 a.m. because a security bulletin came out. AWS does all of that, and in exchange, you give up the ability to configure the machine at all: no choosing an OS version, no installing a custom kernel module, no tuning network settings on the box itself.

The formal, vendor-neutral way to say it: serverless is a cloud execution model where the provider dynamically manages the allocation and provisioning of compute resources, and pricing is based on the actual amount of resources consumed, rather than pre-purchased capacity. Every honest definition of serverless has three parts, and a service only earns the label if it has all three:

1. No server management. You never choose an instance type, patch an OS, or configure an auto-scaling group by hand.
2. Automatic, near-instant scaling. The platform adds capacity for the next request and removes it when demand drops, including scaling to exactly zero when nobody is using it.
3. Consumption-based billing. You are billed for requests and execution time (or database capacity units, or vCPU-seconds), not for a reserved block of "always on" hardware.

Drop any one of those three and you're describing something else. A t3.medium EC2 instance you manually resize is not serverless, even if you never SSH into it — you're still choosing the instance type, which fails rule one. A Docker container running 24/7 on a fixed-size ECS cluster is not serverless either — you're still paying for capacity whether or not a request ever arrives, which fails rule three. Even the phrase "serverless architecture" gets misused: a lot of teams call an app "serverless" the day they move it onto Lambda, while the database underneath is still a manually sized RDS instance sitting there 24 hours a day. That's a hybrid, not a serverless application, and the RDS bill will keep arriving no matter how quiet Lambda's invocation count gets.

The Two Halves of "Serverless": FaaS and BaaS

People use "serverless" as if it means one product. On AWS it's two overlapping categories, and mixing them up is where a lot of confused blog posts come from.

Function as a Service (FaaS)

This is AWS Lambda: you upload a small piece of code — a "function" — and attach it to a trigger. An object lands in an S3 bucket, an API call comes in through API Gateway, a message hits an SQS queue. Lambda spins up an isolated execution environment, runs your function, returns a result, and eventually tears the environment down. Lambda is a serverless compute service for running code without having to provision or manage servers, and you pay only for the compute time you actually consume. FaaS is the layer people mean when they say "serverless" without thinking about it — it's the closest thing to the old idea of "just my code, running," with everything else stripped away.

Backend as a Service (BaaS)

This is everything around the function that also scales to zero and bills per use: a database like DynamoDB or Aurora Serverless, a queue like SQS, an event bus like EventBridge, storage like S3, authentication like Amazon Cognito, an API front door like API Gateway. None of these run "your code" the way Lambda does — you're consuming a managed service through an API call, not deploying a function — but they follow the same three rules above, so they earn the same label. A booking form like Jake's is really a small chain of BaaS pieces (API Gateway to receive the request, DynamoDB to store it, SNS to send the confirmation text) with a Lambda function stitching the steps together in the middle.

What "Serverless" Used to Mean, and What Changed

Both of those changes matter for this post specifically, because they are the two limits people complain about most — "serverless can't run long jobs" and "serverless databases still cost money when nobody's using them" — and AWS has been chipping away at both within the last twelve months. The limits below are still real. They're just not frozen in place, and a limit you read about in a two-year-old blog post might already be out of date by the time you hit it.

The Pricing Model — Honest, and Also a Trap

Here's how Lambda actually bills you, because "pay only for what you use" is true right up until it isn't. Two meters run at once:

"Duration" is memory allocated multiplied by wall-clock execution time, rounded up to the nearest millisecond. That interacts with memory in a way that surprises almost everyone the first time: raising a function's memory also raises its CPU proportionally, so a bigger, "more expensive per second" memory setting can finish the job faster and end up cheaper overall. At 1,769 MB you get one full vCPU; below that, your function is sharing a fraction of a core and can spend most of its billed duration simply waiting for CPU time instead of doing work. A function that's under-powered and takes four times as long to finish can cost roughly the same, or more, than a well-sized one — underpowering memory is one of the most common reasons a Lambda bill runs higher than expected.

For a small operation like Jake's booking form — a few thousand invocations a month, each running for a couple hundred milliseconds — that math works out to pennies. A function running at 512 MB for 200 milliseconds, called 5,000 times a month, uses roughly 500 GB-seconds of duration, comfortably inside the 400,000 GB-second free tier, and 5,000 requests against a million free ones. That part of the marketing is true. Where it stops being true is the optional extras layered on top of Lambda that do not follow "pay only when used" at all.

Limit #1: Cold Starts

A "cold start" is what happens when your function gets invoked and no execution environment is already sitting warm and ready. Lambda has to build one from scratch: download your code, start the runtime (Node.js, Python, Java, whatever you chose), and run your initialization code before your handler ever sees the request. That whole process — called the Init phase — is capped at 10 seconds by default, and it's on the critical path for that first request. Once the environment exists, it can be reused for the next request in milliseconds; that's a "warm start," and it's what most invocations actually get, because Lambda keeps unused environments around for a while before recycling them. Exactly how long a warm environment survives isn't something AWS publishes as a fixed number — it can range from a few minutes on a quiet function to several hours on one with steady traffic.

Cold starts vary wildly by language. Interpreted runtimes like Node.js and Python typically add somewhere from a few dozen milliseconds to low hundreds. Java and .NET, which have to boot a full virtual machine before your code runs, can add several seconds — long enough that a user staring at a spinner will notice. The size of your deployment package matters too: a lean function with a small dependency list starts faster than one bundling a heavy library it barely uses, because all of that code has to be unpacked before the Init phase can finish.

There are two real fixes, and they trade off against each other:

1. SnapStart — available for Java, and rolled out to Python and .NET as well. AWS takes an encrypted snapshot of your fully initialized execution environment the moment you publish a function version, and restores new environments from that snapshot instead of booting from scratch. It costs nothing extra and can cut Java cold starts from several seconds down to well under one. It only works on published versions and aliases, not on the always-changing $LATEST version, and it can't be combined with provisioned concurrency or with more than 512 MB of ephemeral storage on the same function.
2. Provisioned concurrency — you tell Lambda to keep a set number of environments pre-warmed at all times, ready to respond in double-digit milliseconds. It works for any runtime, but you cannot combine it with SnapStart on the same function version, and it's billed continuously — that's the always-on-server cost from the box above. If traffic bursts past the number you provisioned, the overflow requests get a normal cold start anyway, so it isn't a guarantee against cold starts, just a way of shrinking how often they happen.

What it looks like when this goes wrong: intermittent, unexplained latency spikes that show up only on the first request after a quiet period — a chatbot that feels instant during a demo and sluggish the moment traffic goes idle for ten minutes, then picks back up. If your CloudWatch metrics show a small percentage of invocations with duration several times higher than the rest, and those spikes cluster right after gaps in traffic, that's a cold start pattern, not a code bug.

The popular advice you'll see everywhere — "just ping your function every five minutes to keep it warm" — is worth naming as wrong. A scheduled ping keeps one execution environment warm. It does nothing for the second, third, or hundredth concurrent request, which each get their own fresh environment. It also quietly burns through your free tier and adds a line item to your bill for a fix that doesn't actually fix concurrency-driven cold starts. Use SnapStart or provisioned concurrency; don't build a cron job to fake it.

Limit #2: Execution Time Ceilings

Every Lambda function has a configurable timeout: a maximum number of seconds it's allowed to run before AWS kills it, defaulting to 3 seconds and adjustable in 1-second increments. For years the absolute ceiling was 15 minutes (900 seconds), full stop, for every function regardless of how it was triggered. That's still true for synchronous invocations — the kind where something is actively waiting on a response, like a user's browser calling your API.

As of this September, that changed for a specific slice of workloads. On the newer Lambda Managed Instances capacity mode, asynchronous invocations and event-source-mapping invocations — things triggered by an SQS queue, a Kinesis stream, or DynamoDB Streams, where nothing is blocking on an immediate reply — can now run for up to 90 minutes, a 6x increase from the old 15-minute wall. AWS built this specifically for data processing, media transcoding, financial simulations, and AI inference jobs that used to force teams to re-architect around Lambda's old ceiling. Your initialization code is still capped at 15 minutes even on Managed Instances, and synchronous calls still stop at 15 minutes flat. The extended timeout also applies to Lambda durable functions — a checkpoint-and-replay model where a multi-step workflow can pause, record its progress, and resume after a failure without redoing completed work; a durable execution invoked asynchronously can, in principle, span up to a year in total, stitched together from many individual invocations rather than one continuous 900-second run.

There's a second, smaller ceiling most people don't hit until they build an API: Amazon API Gateway's default integration timeout is 29 seconds. If your Lambda function is still running when API Gateway hits that wall, the caller gets an HTTP 504 error, even if your function would have finished successfully a few seconds later. As of mid-2024 this quota can be raised above 29 seconds for regional and private REST APIs through a Service Quotas request, though raising it can require lowering your account's throttle quota, and it doesn't apply to HTTP APIs or WebSocket APIs at all.

Ethan's take on this one is blunt: "Teams file a support ticket asking AWS to raise the 900-second timeout on a standard function. That ticket goes nowhere, because it's not a quota, it's a wall. The fix was never a bigger number — it's Step Functions breaking the job into stages, or moving the job off Lambda entirely onto Fargate or a real EC2 box where there's no ceiling at all." A job that genuinely needs to run for six continuous hours doing one thing was never a Lambda job, no matter how the timeout number moves.

Limit #3: Your Function Forgets Everything

Lambda functions are deliberately, permanently stateless. AWS's own architectural guidance is explicit on this: systems should either not require state, or should offload it, so that between client requests there is no dependence on data stored locally on disk or in memory — because that's what lets any available function instance handle any request and lets the whole system scale horizontally without coordination.

In practice, that means a few concrete things. Local file system access, child processes, and anything else your code writes only exist for the lifetime of that one execution environment — and that environment might be reused for the next request, or it might be torn down and never seen again; you cannot rely on which. Every function does get a small scratch space, up to 512 MB by default in the /tmp directory (10,240 MB max if you configure more ephemeral storage), but it is explicitly non-persistent. Anything that needs to survive between invocations — a user's session, a counter, a cached value everyone should see — has to be written to a real storage service outside the function: DynamoDB, S3, ElastiCache, RDS.

This is the single biggest mental adjustment for anyone coming from a traditional server, where "just keep it in a global variable" was normal. In Lambda, that global variable might survive for the next ten requests on a warm environment, then vanish without warning the moment AWS decides to recycle it. Code that quietly depends on in-memory state working "most of the time" is one of the most common sources of intermittent, hard-to-reproduce serverless bugs — a rate limiter counting requests in a local variable, for instance, will look like it's working in testing and then quietly reset itself in production every time a new environment spins up, letting through exactly the burst of traffic it was supposed to block.

Limit #4: Vendor Lock-In, the Honest Version

"Vendor lock-in" gets thrown around as a scare word, so it's worth being precise about what actually locks you in and what doesn't. Your Lambda function's code — the logic itself — is usually portable. A Node.js or Python handler doesn't know or care that it's running on AWS; you could, with effort, run the same logic on Azure Functions or Google Cloud Functions.

What locks you in is everything around the function: the specific event format API Gateway hands your function, the IAM permission model, the exact trigger configuration for an S3 or DynamoDB Streams event, and — the biggest one — how deeply your application depends on AWS-specific managed services like DynamoDB, Step Functions, or EventBridge that have no drop-in equivalent elsewhere. A serverless architecture built with a dozen tightly integrated AWS services isn't hard to leave because the code is bad; it's hard to leave because the whole point was letting AWS manage things you'd otherwise have to build yourself, and "portable" and "someone else manages it for you" pull in opposite directions.

Limit #5: Debugging a System You Can't SSH Into

On a traditional server, when something goes wrong, you log in, run a debugger, attach to the live process, and watch it in real time. Lambda blocks that entirely by design: inbound network connections to the execution environment are refused, and low-level debugging system calls like ptrace are blocked outright as part of the platform's tenant-isolation model. You cannot attach a debugger to a live Lambda invocation the way you would to a process on your own box.

What you get instead is observability after the fact, not interaction during the fact: logs, metrics, and distributed traces shipped automatically to Amazon CloudWatch and AWS X-Ray. That's genuinely good for understanding patterns across thousands of invocations — which function is slow, which one is erroring, how a request moved through five different services — but it's a fundamentally different workflow than stepping through code line by line while it happens. Teams moving from EC2 or on-premises servers to Lambda for the first time consistently underestimate how much this changes their debugging habits, especially for the kind of "why did this one specific request behave strangely" question that's easy to chase down interactively and much harder to reconstruct from logs alone.

Distributed systems make this worse, not because serverless is uniquely bad at it, but because a single user action can now fan out across API Gateway, a Lambda function, a DynamoDB table, and an SQS queue — four separate places a failure could originate, instead of one server's error log. The practical fix most teams land on is disciplined structured logging from day one — logging a consistent request ID through every function and service a single action touches — because without it, tracing a single failed booking through four AWS services after the fact turns into guesswork.

Limit #6: Concurrency and Throttling

Automatic scaling has a ceiling too, even though it's marketed as limitless. Every AWS account gets a default concurrent-execution quota of 1,000 across all functions in a Region — the number of invocations that can be running at literally the same instant — and while that can be raised into the tens of thousands on request, it doesn't raise itself. Payloads are capped too: 6 MB for a synchronous invocation, 256 KB for an asynchronous one, and the deployment package itself is limited to 50 MB zipped for direct upload (250 MB unzipped including layers).

Hit the concurrency limit and Lambda doesn't queue your request politely — it throttles it, returning an error, and the caller has to handle that retry logic itself. This is where serverless quietly reintroduces a "noisy neighbor" problem, except the noisy neighbor is you: one function with a bug that causes it to loop or hang can eat your entire account's concurrency budget, starving every other function in the same Region of capacity to run, even ones that have nothing to do with the misbehaving one. A single-Region concurrency pool shared across every function in your account is not something most teams realize until the day it bites them.

The defense is a setting called reserved concurrency — capping how much of the shared pool one specific function is allowed to consume, so a runaway loop in your image-resizing function can't starve the checkout function sitting next to it. It's the closest thing serverless has to putting a fence around one noisy tenant in a shared apartment building, and it costs nothing extra to set.

Beyond Lambda: Serverless Databases, Containers, and Orchestration

"Serverless" isn't only about running code. AWS extends the same three rules — no provisioning, automatic scaling, pay for use — across most of its stack now:

Amazon DynamoDB (on-demand mode)

A fully managed NoSQL database with no servers to provision. In on-demand capacity mode, DynamoDB scales read and write throughput instantly, without any capacity planning on your part, and you're billed per request rather than for reserved throughput. There's no query joins or relational modeling, though — it's the right fit for simple, high-scale lookups, not for complex relational queries across multiple tables.

Aurora Serverless

An on-demand, autoscaling configuration of Amazon Aurora, billed in Aurora Capacity Units per second, that now scales all the way down to zero ACUs during periods of inactivity — closing the old complaint that a "serverless" database never actually stopped billing. It supports MySQL- and PostgreSQL-compatible engines and works well for unpredictable, intermittent, or multi-tenant workloads, including a writer instance and multiple readers within the same cluster, and it can be mixed with traditional provisioned Aurora instances in that same cluster if you need one predictable, always-on piece alongside the elastic part.

AWS Fargate

Fargate runs Docker containers on Amazon ECS or EKS without you ever provisioning an EC2 instance underneath them. It's the honest answer to "I need serverless, but Lambda's 15-minute ceiling and stateless model don't fit my app." Fargate has no execution time limit at all, and it's a much better fit for long-running services, background workers, or anything packaged as a container image. You still pay per second while the task runs, so it isn't free when idle the way Lambda's true pay-per-invocation model is — but it's genuinely serverless in the sense that matters: no server to patch, size, or manage, and each task runs in its own isolated boundary, with its own dedicated CPU and memory that nothing else shares.

AWS Step Functions

A visual workflow orchestrator that sequences multiple Lambda invocations, and other AWS service calls, into a single state machine. This is the standard answer to Lambda's 15-minute wall: instead of one giant function, you break a long job into stages, each staying comfortably under its own timeout, while Step Functions tracks overall progress, retries failed steps, and can run the whole workflow for far longer than any single Lambda invocation would allow.

When Serverless Is the Right Call

When Serverless Is the Wrong Call

Say plainly what serverless cannot do well, because pretending otherwise is how teams end up fighting the platform instead of using it. Skip Lambda functions for:

• Long, continuous compute jobs — a video render or batch job that needs to run for hours straight belongs on Fargate or EC2, not chunked awkwardly to fit a 15- or 90-minute window.
• Steady, high-volume, predictable workloads — if you know you'll run 500 million invocations every month like clockwork, a reserved or provisioned server frequently beats per-invocation billing on raw cost.
• Anything that needs to hold a persistent, low-latency connection — a WebSocket-heavy real-time app, a long-lived database connection pool, or anything expecting the same "machine" to answer every request.
• Workloads where you need to control the exact runtime environment at the kernel level, or run privileged system calls Lambda's isolation model blocks by design.

If you don't know which category a workload falls into, Ethan's rule of thumb is simple: "If you can draw the job as a single event triggering a short, self-contained piece of work, it's a Lambda job. If you have to explain it as a 'process' or a 'service that stays up,' it was never a Lambda job." He's also blunt about the workloads that fall in between: "A background worker that runs on and off all day, every day, doing the same predictable amount of work — that's the one people get wrong most. It looks event-driven, so they build it serverless, then discover a fixed-size box would've cost them a third as much for the exact same output."

Jake's Shop, Rebuilt Honestly

Back to that $340 bill. Ethan walked through Jake's AWS account with him, and it wasn't Lambda invocations — forty bookings a month barely register against the free tier. It was provisioned concurrency, switched on for a "demo day" a month earlier so a potential investor wouldn't see a cold-start delay, and never switched back off. Twenty pre-warmed environments, billed every second, for a form that got maybe two requests an hour.

"That's the whole lesson," Ethan told him. "Serverless didn't lie to you. You just turned on the one feature that makes it stop being serverless, and forgot it was still running." Jake turned provisioned concurrency off, set a CloudWatch billing alarm so it can't happen silently again, and switched the booking form's rare slow path over to SnapStart instead — the free fix, for the cost problem he actually had. He also capped reserved concurrency on the SMS-sending function at five, after Ethan pointed out that a typo in a phone number field could otherwise let one bad request retry itself into eating the shop's entire concurrency budget on a slow Saturday.

The booking form still runs on Lambda. It still scales to zero most nights. It still costs Jake next to nothing most months. The definition held up. It was the fine print underneath it that cost him $340, and reading that fine print is the entire point of this post.

Frequently Asked Questions

Does serverless mean there are no servers at all?

No. AWS still runs physical servers under every serverless service. "Serverless" describes what disappears from your job — provisioning, patching, and capacity planning — not what disappears from the data center.

Is AWS Lambda the same thing as serverless?

Lambda is one serverless service — specifically, Function as a Service. Serverless also covers databases like DynamoDB and Aurora Serverless, container platforms like Fargate, and event/queue services like EventBridge and SQS, none of which run "your function code" the way Lambda does.

Why did my "pay only for what you use" bill go up when my traffic didn't?

The most common cause is provisioned concurrency left switched on, which bills continuously whether or not requests arrive. Check that setting first, then check for a runaway function stuck in a retry loop burning duration, or reserved concurrency set too high on a function that doesn't need it.

What is a cold start, in plain English?

It's the delay when a function has to be built from scratch — downloading your code and starting the runtime — before it can handle a request, instead of reusing an environment that's already warm from a previous invocation. It's most noticeable on a slow runtime like Java, and mostly invisible on Node.js or Python.

How long can a serverless function run before it times out?

Fifteen minutes is the hard ceiling for standard Lambda functions and for any synchronous invocation. Asynchronous or event-source-mapping invocations running on the newer Lambda Managed Instances capacity mode can now run up to 90 minutes, and durable multi-step workflows built on that model can span far longer in total by checkpointing progress across many invocations.

Can serverless functions keep data between requests?

Not reliably. Functions are designed to be stateless; local memory or disk storage may survive if the same environment happens to be reused, but that's never guaranteed. Anything that must persist belongs in DynamoDB, S3, or another storage service outside the function.

Is serverless cheaper than a regular server?

For bursty or low-volume traffic, usually yes, because you stop paying for idle capacity. For steady, high-volume, 24/7 traffic, a reserved or fixed-size server can end up cheaper, because per-invocation pricing has no volume ceiling working in your favor the way a flat monthly server cost does.

What is vendor lock-in with serverless, really?

It's less about your function code, which is often portable, and more about how deeply your architecture depends on AWS-specific managed services like DynamoDB, Step Functions, or EventBridge that don't have a drop-in equivalent on another cloud.

Can you run a database serverless?

Yes. DynamoDB in on-demand mode and Aurora Serverless (which can now scale down to zero database capacity units) both follow the same no-provisioning, pay-per-use model as Lambda.

Is serverless secure?

Each Lambda function runs in its own isolated execution environment, and AWS blocks inbound network connections and low-level debugging system calls to that environment by design. Security still depends on how you configure IAM permissions and what your code does with the data it receives — the platform isolation doesn't cover a poorly scoped permission policy.

Can I use serverless for a website that gets huge traffic spikes?

This is one of serverless's strongest use cases — automatic scaling handles the spike without any capacity planning on your part, up to your account's concurrency quota, which AWS will raise on request if you expect to exceed the default of 1,000 concurrent executions per Region.

What's the difference between serverless and containers?

A container you run yourself on a fixed-size server isn't serverless — you're still paying for that server whether it's busy or idle. AWS Fargate runs the same containers without you provisioning any server underneath, billed per second the task runs, which does qualify as serverless even though it isn't Lambda.

Do I need DevOps skills to run serverless?

Less than for traditional servers, since AWS handles patching and provisioning, but you still need to understand IAM permissions, monitoring through CloudWatch, and how to size memory and timeout settings correctly — those choices directly affect both cost and performance.

Can I debug a serverless function like a normal app?

Not with a live, attached debugger — Lambda blocks that by design. You debug after the fact using logs, metrics, and traces sent automatically to CloudWatch and AWS X-Ray, which is a different workflow than stepping through code interactively.

What happens if my serverless function gets more traffic than it can handle?

Lambda doesn't queue overflow requests politely once you hit your account's concurrency limit — it throttles them and returns an error, which your calling code needs to be ready to retry. Setting reserved concurrency on individual functions, and requesting a higher account-level concurrency quota ahead of an expected spike, are the two ways to reduce how often that happens.

Is serverless good for a small business like a phone or computer repair shop?

Often yes, and for exactly the reason marketing claims: a small shop's traffic is bursty and low-volume, so pay-per-invocation billing keeps costs near zero most months. The risk isn't the traffic pattern — it's an unwatched setting like provisioned concurrency quietly turning "pay per use" back into an always-on bill.

Revision note. Written September 2026. If a $340 bill just landed on your desk for a "serverless" project you were told was basically free, you're not imagining it, and you're not the first person this has happened to — the fix is usually one setting, not a rebuild.