Lambda's Long-Standing 625 Mbps Ceiling Gets Lifted
AWS raised the network bandwidth ceiling for AWS Lambda on August 5, 2026. Functions outside a virtual private cloud (VPC) configured with 2 GB of memory or more can now access bandwidth that scales with their memory setting. The range runs from 625 Mbps at 2 GB up to 3,000 Mbps at 10 GB. The feature is available at no additional charge.
The previous hard limit was 625 Mbps for all non-VPC functions regardless of memory. As data volume and performance requirements grow, that fixed ceiling constrained data transfer speeds to and from an execution environment. Teams processing large external datasets, sometimes terabytes per run, felt that constraint directly in execution time and per-invocation billing.
What Actually Changes in Your Function's Behavior
This is a bandwidth-per-execution-environment change, not a concurrency change. Each individual Lambda execution environment now has access to more network throughput when memory is configured at or above 2 GB. Lambda already allocates CPU in proportion to memory. Bandwidth now follows the same proportional model, starting at 2,048 MB and reaching a maximum of up to 3,000 Mbps at 10,240 MB. Concurrency scaling behavior is separate and unchanged.
The practical effect is faster ingestion of external data into the function for processing. If a function pulls a large payload from Amazon S3, an external API, or another data source before doing its work, the time spent waiting on that transfer shrinks. Shorter execution times translate to lower Lambda charges, since billing is duration-based.
This feature applies only to functions outside a VPC. Functions running inside a VPC are not eligible. That boundary matters for teams whose architecture mixes VPC and non-VPC functions: only the non-VPC side of that split benefits from the higher throughput.
The Opt-In Step You Need to Take
The feature is not on by default. To enable it, submit a request through AWS Service Quotas under the "Network bandwidth per execution environment" quota. Once AWS approves the request, bandwidth scales automatically based on your function's memory configuration for all eligible non-VPC functions in your account. No further action is required after approval.
The feature is available at no additional charge in all commercial AWS Regions.
What Platform Owners and Application Teams Should Do Now
For cloud platform owners, the first question is whether any non-VPC Lambda functions are memory-constrained today because higher memory was not justified by CPU or execution time, even though larger data volumes would benefit. If a function pulls terabytes from external sources and runs at 2 GB or more, the quota request is worth filing immediately.
For application teams running latency-sensitive data processing workloads, the second question is whether current memory settings align with the new bandwidth curve. Memory can be set between 128 MB and 10,240 MB in 1-MB increments. A function currently set to 4 GB to get more CPU might now also justify that memory purely on network throughput grounds, since both benefits arrive together.
For security and architecture leaders, the VPC boundary deserves explicit review. If a workload's data source is private or requires controlled routing, that function should be inside a VPC regardless of this change, and it will not benefit from the higher bandwidth ceiling. If the function is legitimately outside a VPC and pulling from public or AWS-native sources, the quota request is low-risk and the performance upside is real.
The Lambda quotas documentation shows the current bandwidth quota entry and is the reference point for confirming the limit in your account after the request is approved. File the quota request, confirm approval, then measure actual throughput against your previous baseline to determine whether a memory adjustment further up the curve is worth the incremental cost.