TIL: How provisioned concurrency billing actually works (and how I got burned).

I've been operating under a significant misconception regarding provisioned concurrency billing on AWS Lambda, an assumption that proved to be quite costly last month. I consider myself reasonably well-versed in serverless cost optimization, but I made a classic error in conflating "provisioned concurrency" with "warm starts are free." I wanted to share a detailed breakdown of my misunderstanding and the subsequent financial impact, complete with a comparison of my mental model versus the actual billing logic, in hopes that others can avoid this particular pitfall.

My incorrect assumption was structured as follows:
* **Primary Belief:** Enabling provisioned concurrency simply pre-initializes a defined number of execution environments, ensuring low-latency cold starts for those environments. I believed the cost was primarily for the allocation and readiness of those environments, with the actual execution billed normally under the standard Lambda request and duration pricing.
* **Consequence:** I reasoned that for functions with sporadic but latency-sensitive traffic, I could set a small amount of provisioned concurrency (e.g., 2-5) as a "buffer" to handle sudden bursts without paying the cold-start penalty, and that the cost would be marginal.

The reality, which I discovered only upon delving into the detailed billing report after a surprisingly high invoice, is fundamentally different. The actual billing model operates on two concurrent charges:

1. **Provisioned Concurrency Allocation Charge:** This is the fee for the *prepared capacity itself*, calculated per GB-second and hour, based on the amount of memory you have configured for your function and the number of provisioned instances you have allocated. This clock starts ticking as soon as you enable it, regardless of invocation volume.
2. **Standard Lambda Execution Charge:** This is applied *on top of* the allocation charge. When a request is served by a provisioned concurrency environment, you still pay for the request count and the execution duration, just as you would for a standard warm start.

The critical financial implication I had missed is this: **You are effectively paying twice for the same GB-seconds of compute when the function is invoked.** You pay once for having the environment ready (the allocation charge), and you pay again for the execution time that utilizes that pre-warmed environment. My strategy of using provisioned concurrency as a "just-in-case" buffer for sporadic functions was therefore economically irrational.

To illustrate the cost difference, here is a simplified comparison for a 2048MB function with sporadic traffic:

| Scenario | Monthly Cost Driver | Approximate Monthly Cost (us-east-1) |
| :--- | :--- | :--- |
| **My Model (Incorrect):** 2 provisioned concurrency, ~100K invocations, avg 500ms duration. | Primarily execution charges, with minor allocation fee. | ~$15.50 |
| **Actual Billing:** 2 provisioned concurrency, ~100K invocations, avg 500ms duration. | **Allocation charge ($72.80)** + **Execution charges ($15.50)**. | **~$88.30** |

The provisioned concurrency allocation charge became the dominant line item, exceeding the execution cost by a factor of nearly five. The takeaway is now painfully clear: provisioned concurrency is not a mere "warm start guarantee." It is a capacity reservation tool, most financially justifiable for predictable, sustained high-volume workloads where the latency requirement is strict and the alternative would be paying the standard cold-start duration penalties on a large percentage of invocations. For my use case of irregular, bursty traffic, it was a severe miscalculation. I have since moved to alternative strategies for managing latency, such as optimized initialization code and scheduled warming functions, and am reevaluating the true break-even point for this feature.