Skip to content
Cloud Efficiency Hub

Overreliance on Lambda at Sustained Scale

The short version

Lambda is designed for simplicity and elasticity, but its pricing model becomes expensive at scale.

Igor Bareev

Sr TAM @ Amazon Web Services (AWS)

AWS service
AWS Lambda
Category
Compute
Reference
CER-0124
Type
Suboptimal Pricing Model

Explanation

Why the waste happens and who it affects.

When a function runs frequently (e.g., millions of invocations per day) or for extended durations, the cumulative cost may exceed that of continuously running infrastructure. This is especially true for predictable workloads that don't require the dynamic scaling Lambda provides.

Teams often continue using Lambda out of convenience or architectural inertia, without revisiting whether the workload would be more cost-effective on EC2, ECS, or EKS. This inefficiency typically hides in plain sight-functions run correctly and scale as needed, but the unit economics are no longer favorable.

Billing model

The pricing dimensions that drive this cost.

Lambda is billed per invocation and execution duration (GB-seconds), with costs increasing linearly as usage scales. While ideal for low-to-moderate workloads with bursty or unpredictable traffic, Lambda becomes cost-inefficient at sustained high volumes. In contrast, compute services like EC2, ECS, or EKS offer lower per-unit cost when provisioned for predictable, long-running workloads - even when accounting for idle time.

How to detect

6 checks to find it in your estate.

  • Identify Lambda functions with consistently high invocation counts or sustained concurrency
  • Analyze total monthly execution time and aggregate GB-seconds to estimate spend
  • Compare Lambda spend against equivalent cost modeling for EC2, ECS, or EKS
  • Determine whether the workload pattern is predictable and steady enough to justify reserved or container-based compute
  • Assess whether cold start latency or fine-grained autoscaling is still required
  • Review whether any past evaluations have been made regarding migration to alternative architectures

How to fix

4 ways to remove the waste.

  • Establish thresholds for Lambda usage that trigger cost-efficiency reviews
  • Evaluate total Lambda cost versus equivalent EC2/ECS/EKS workloads
  • Before replatforming, evaluate Compute Savings Plans for Lambda and Lambda Managed Instances (EC2-based pricing plus a management fee, with Savings Plans and Reserved Instances applying to the EC2 portion) for steady high-volume functions; replatform long-running or consistently triggered workloads to containerized or instance-based compute where these fall short
  • Incorporate architecture re-evaluation into regular FinOps or infrastructure reviews for high-throughput functions

Documentation

Vendor references for pricing and configuration.