Lambda-GB-Second: why your Lambda duration cost moved

What Lambda-GB-Second means

Every invocation is billed for its duration times the function's configured memory. Duration covers the code in your handler and initialization code declared outside it ^{[lambda-pricing]}, and has been measured in 1 ms increments since December 2020, when AWS reduced the billing granularity "from 100ms down to 1ms" ^[lambda-1ms]. Memory can be set from 128 MB to 10,240 MB ^{[lambda-pricing]}.

A 128 MB function that runs for 200 ms uses 0.125 GB × 0.2 s = 0.025 GB-seconds. A million of those is 25,000 GB-seconds, $0.42 at the first-tier x86 rate. The same function at 1,024 MB with the same duration is 200,000 GB-seconds, $3.33. Both are before the free tier, which includes 400,000 GB-seconds and one million requests a month ^{[lambda-pricing]}.

The current US East (N. Virginia) rates per GB-second ^{[price-list-lambda]}:

• x86 (Lambda-GB-Second): $0.0000166667 for the first 6 billion, $0.000015 for the next 9 billion, $0.0000133334 above 15 billion
• Arm (Lambda-GB-Second-ARM): $0.0000133334 for the first 7.5 billion, $0.0000120001 for the next 11.25 billion, $0.0000106667 above 18.75 billion

The tiers apply to your aggregate monthly duration ^{[lambda-pricing]}. Requests are a separate line (Request), and Provisioned Concurrency has its own usage types, such as Lambda-Provisioned-Concurrency and Lambda-Provisioned-GB-Second ^{[price-list-lambda]}. In US East (N. Virginia) the usage type has no region prefix; elsewhere it does, for example APN1-Lambda-GB-Second in Asia Pacific (Tokyo) ^{[region-codes]}.

How to find it in Cost Explorer or your Cost and Usage Report

Cost Explorer. Filter Service to Lambda and group by Usage type. Usage quantity is in GB-seconds; compare it with the request count line to see whether duration per call or the number of calls changed.

Cost and Usage Report (CUR). Per function:

SELECT line_item_resource_id,
       line_item_usage_type,
       SUM(line_item_usage_amount)   AS gb_seconds,
       SUM(line_item_unblended_cost) AS cost
FROM   cur
WHERE  line_item_usage_type LIKE '%Lambda-GB-Second%'
GROUP  BY 1, 2
ORDER  BY cost DESC;

With resource IDs in the report, line_item_resource_id is the function's ARN. The pattern also matches the Arm and Provisioned Concurrency GB-second lines, which the usage type column tells apart. Your table and column names depend on how the export was set up.

CloudWatch. The function's Duration and Invocations metrics, and the billed duration and memory in each invocation's REPORT log line, show which of the two factors moved and when.

Typical causes of a growing line

• A memory increase. Doubling memory doubles GB-seconds unless the function also gets faster. Raising memory to fix a timeout or an out-of-memory error is a common source.
• Longer duration. A slower database, a third-party API that started timing out, or bigger payloads keep functions running, and waiting on a network call is billed like computing.
• More invocations, including ones you did not intend: retries on failure, a queue redelivering the same messages, or a function triggered by its own output. The article on Lambda retry storms covers these loops.
• Heavier initialization. Initialization code outside the handler is billed as duration too ^{[lambda-pricing]}, so a larger dependency bundle can add GB-seconds on every cold start.

Price history

CostPulse's price history (every version of the AWS Price List since 2015) has 2 like-for-like On-Demand price changes for Lambda-GB-Second and Lambda-GB-Second-ARM in AWS Lambda, shown below.

In US East (N. Virginia) the x86 rate shows no like-for-like change in the history. The two changes on record are regional: Canada (Central) moved from $0.0000167 to $0.0000166667 in a publication of March 28, 2018, a 0.1994% change that lined it up with the other regions' rate, and Asia Pacific (Osaka) fell 22.59% to the same rate in a publication of September 29, 2021. The history also shows a publication of November 12, 2025, effective October 2025, that changed the unit of these rates from "seconds" or "Second" to "Lambda-GB-Second" at the same prices. A tool that compares price list rows without checking the unit can report that as a price change; it was not one.

One row per publication, price and tier; regions that got the same old and new price are grouped. Each published date links to that publication's page in the AWS price change tracker. Published vs effective dates.

The history also has 39 rows for these usage types that are not like-for-like price changes, so they are not shown as cuts or increases: published 2025-11-12 (39: 39 where the unit or description was reworded at the same price).

What to do about it

1. Find the function with the CUR query above, then check whether its duration, its memory or its invocation count moved.
2. Right-size memory by measuring. More memory also brings more CPU ^{[lambda-pricing]}, so a higher setting can finish fast enough to cost less; a lower one can run long enough to cost more. Test a few settings against real traffic. The Lambda memory and Provisioned Concurrency article goes through the trade-off.
3. Consider Arm. The Arm rate in US East (N. Virginia) is lower per GB-second than x86 ^{[price-list-lambda]}, if your code and dependencies run on it.
4. Put timeouts and retry limits on calls to slow dependencies, so one bad upstream does not turn into hours of billed waiting.
5. Alert on the daily line. A retry loop or a recursive trigger can multiply invocations within hours; a daily alert catches it on day one rather than at month end.