Memory size and architecture drive the cost

AWS Lambda cost optimization

Lambda bills for GB-seconds, so memory size is the price dial. Over-provisioned memory and functions still on x86 are the two most common, and most fixable, sources of Lambda waste.

Why the waste happens

  • Memory is set high once and never revisited, so every invocation pays for capacity it does not use.
  • Functions run on x86 when arm64 (Graviton) would run the same code for about 20 percent less.
  • A high-volume function is a few milliseconds slower than it needs to be, multiplied across millions of invocations.
  • Old functions and versions linger, and generous timeouts hide inefficiency.

How to spot it

  • Functions whose configured memory is well above their observed maximum memory used.
  • x86 functions whose runtime and dependencies support arm64.
  • High-invocation functions where a small duration or memory change moves real money.
  • Functions with no recent invocations, and stale published versions.

The fix

  • Right-size memory to the point where cost per invocation is lowest (power-tuning finds it quickly).
  • Switch functions to arm64 (Graviton) where the runtime supports it.
  • Trim timeouts to realistic values and remove unused functions and versions.
  • For steady high-concurrency functions, tune provisioned concurrency rather than over-allocating memory.

Find every Lambda issue in one scan

Cloud Cost Analyzer flags over-provisioned Lambda functions by comparing configured memory to what invocations actually use, and surfaces arm64 migration candidates, with a cost estimate for each.

$ cca scan --provider aws

Read-only, runs in about 5 minutes. Free tier, no credit card.

Lambda cost FAQ

Does more Lambda memory cost more?+

Lambda bills for GB-seconds, so doubling memory doubles the cost per millisecond of run time. More memory also gives more CPU, so a function can sometimes finish faster and offset the increase. The goal is the memory setting where total cost per invocation is lowest, which power-tuning identifies.

Is arm64 (Graviton) Lambda cheaper?+

Yes. Running a function on arm64 is typically about 20 percent cheaper than x86 for the same workload, and often as fast or faster. If your runtime and dependencies support arm64, switching is a configuration change.

How do I right-size a Lambda function?+

Compare configured memory to the maximum memory actually used, then test a few memory settings to find the one with the lowest cost per invocation. Cloud Cost Analyzer flags functions configured well above their real usage.

More cost guides

NAT Gateways

Idle gateways and avoidable data-processing charges, one per AZ.

RDS databases

Over-provisioned classes, non-Graviton, and Multi-AZ on non-prod.

EBS volumes

Orphaned volumes, old snapshots, and gp2 you never moved to gp3.

Load balancers

ALBs and NLBs with no targets or near-zero traffic, still billing.

S3 storage

Cold data sitting in Standard with no lifecycle policy.

EC2 instances

Idle and oversized instances, previous-gen types, 24/7 dev boxes.

Aurora

Oversized instances, Serverless v1, and I/O-Optimized breakevens.

ElastiCache

Idle cache clusters and oversized, non-Graviton nodes.

CloudFront

Idle distributions and price classes wider than your audience.

DynamoDB

On-demand billing on steady workloads, and unused indexes.

See what you are overpaying for

Point a read-only CLI at your account and get a ranked fix list with dollar amounts. Free tier, no credit card.