Skip to content
Notifications
Clear all

Thoughts on the new Lambda pricing cut? Is it actually cheaper for spiky workloads?

1 Posts
1 Users
0 Reactions
2 Views
(@devops_grunt)
Estimable Member
Joined: 4 months ago
Posts: 159
Topic starter   [#18360]

AWS finally announcing a price cut for Lambda got my attention, but the devil is always in the details. They're reducing the GB-second price by 50% and the request price by 20%. On the surface, that's a big win, but I've been running the numbers for our typical spiky, event-driven workloads, and I'm not fully convinced the savings are universal.

The core of my skepticism is that the new pricing heavily favors *longer durations* because the per-ms billing is gone. It's now per-ms with a 1ms minimum charge, but the GB-second rate is halved. This creates a weird inversion. Let me show you a quick comparison I scripted for a 1GB function.

```python
# Old Pricing: $0.0000166667 per GB-second, $0.0000002 per request
# New Pricing: $0.0000083333 per GB-second, $0.00000016 per request

def calculate_cost(memory_mb, duration_ms, requests, old=True):
gb_seconds = (memory_mb/1024) * (duration_ms/1000) * requests
request_cost = requests * (0.0000002 if old else 0.00000016)
gb_cost = gb_seconds * (0.0000166667 if old else 0.0000083333)
return request_cost + gb_cost

# Scenario: 10k invocations, spiky, avg 100ms execution, 1024MB
cost_old = calculate_cost(1024, 100, 10000, old=True)
cost_new = calculate_cost(1024, 100, 10000, old=False)
print(f"Old Cost: ${cost_old:.4f}, New Cost: ${cost_new:.4f}, Savings: ${cost_old-cost_new:.4f}")
```

For truly short, spiky functions, the savings are marginal because the request cost reduction is small. The real benefit kicks in for functions that run for several seconds. So if your "spiky" workload consists of sub-100ms bursts, the celebration might be premature.

Where this gets interesting is for container image lambdas or functions doing heavier processing like data transformation or PDF generation. Those often run for 1-10 seconds. There, the GB-second cut dominates and you'll see a solid reduction.

The other hidden factor is Provisioned Concurrency. If you're using PC to combat cold starts on your spikes, your cost structure is already different. The price cut applies to the duration charges for PC as well, which is a definite win for that use case.

So, is it actually cheaper for spiky workloads?

* **Yes, if** your spikes involve functions with longer execution times (>500ms).
* **Barely, if** your spikes are ultra-short bursts of tiny functions.
* **Maybe not at all** if you're heavily optimized for sub-100ms and your bill was request-heavy. The 20% request reduction might not move the needle much.

It's a good move by AWS, but it's not a blanket win. You need to analyze your actual invocation patterns and duration histogram from CloudWatch. I'm rerunning our cost reports for the last quarter to see the projected impact. My initial take is it's a strategic price adjustment to make Lambda more competitive for longer-running, variable workloads, not just a gift to the event-driven microservices crowd.


Automate everything. Twice.


   
Quote