Lambda network bandwidth has been the quiet asterisk hanging over every “serverless versus containers” argument for years. As of August 6, 2026, AWS Lambda functions now support scalable network bandwidth, and it’s a real fix to one of the platform’s oldest limitations — not a marketing footnote. AWS reiterated it days later in the August 10 Weekly Roundup, which is usually a sign the feature is expected to see real adoption, not just a changelog entry nobody reads.
Let’s get into how the scaling curve works, how to tune memory for throughput instead of just compute, how to benchmark it yourself, and where the constraint that everyone’s going to gloss over actually bites.
What Actually Changed
For most of Lambda’s life, network throughput sat outside your control. You could crank memory to 10 GB and get proportionally more vCPU, but the network pipe felt fixed regardless of size — which is exactly why “Lambda isn’t good for data-heavy work, go use Fargate” became conventional wisdom. It wasn’t wrong, it was just incomplete: the compute scaled, the network didn’t, and for I/O-bound work that’s the part that mattered.
Now bandwidth scales the same way CPU has for years: as a function of allocated memory, for functions running outside a VPC. That last qualifier matters enough that it gets its own section below, so hold that thought.
The Lambda Network Bandwidth Curve
The published anchor points are 625 Mbps at 2 GB of memory, scaling up to 3,000 Mbps at 10 GB — Lambda’s memory ceiling. That’s roughly a 4.8x throughput increase across a 5x memory range, which tells you the relationship is close to linear across that band. If you already have a mental model for memory-to-vCPU scaling, you can reuse it here almost directly.
Memory Allocated Approx. Network Bandwidth
2048 MB 625 Mbps
4096 MB ~1,250 Mbps
6144 MB ~1,875 Mbps
8192 MB ~2,500 Mbps
10240 MB 3,000 Mbps (max)
Treat the midpoints as directional. AWS hasn’t published an exact formula for every increment, and the honest move is to benchmark your own function rather than trust a napkin table — including this one. Full configuration details live in the AWS Lambda documentation.
Tuning Memory for Throughput, Not Just Compute
This is the part that requires a mindset shift. Most teams size Lambda memory by watching CPU-bound execution time and stopping once the duration curve flattens out. That approach quietly under-provisions any function that spends most of its wall-clock time waiting on network I/O — downloading from S3, streaming to another service, shipping large payloads between functions.
If your function’s execution time is dominated by transfer time rather than compute time, bumping memory past your “CPU sweet spot” can still pay off, because you’re buying bandwidth, not cycles. A function that’s 80% idle CPU waiting on an S3 download at 8 GB of memory might finish meaningfully faster at 10 GB, even though the extra vCPU does nothing for it. Profile duration against both memory and payload size before you settle on a number — and remember that Lambda pricing is metered on GB-seconds, so a faster transfer at higher memory can end up cost-neutral or even cheaper than a slow transfer at low memory.
Benchmarking Your Own Functions
Don’t take AWS’s numbers, or mine, on faith. Write a function that streams a known-size object to or from S3, times it, and sweep memory settings. Something like this gets you real numbers fast:
import time
import boto3
s3 = boto3.client("s3")
BUCKET = "your-benchmark-bucket"
KEY = "test-object-5gb.bin"
def handler(event, context):
start = time.perf_counter()
resp = s3.get_object(Bucket=BUCKET, Key=KEY)
total_bytes = 0
for chunk in resp["Body"].iter_chunks(chunk_size=8 * 1024 * 1024):
total_bytes += len(chunk)
elapsed = time.perf_counter() - start
mbps = (total_bytes * 8 / 1_000_000) / elapsed
return {
"memory_mb": context.memory_limit_in_mb,
"elapsed_sec": round(elapsed, 2),
"throughput_mbps": round(mbps, 1),
}
# Sweep memory settings and re-invoke
for mem in 2048 4096 6144 8192 10240; do
aws lambda update-function-configuration \
--function-name bandwidth-benchmark \
--memory-size $mem
sleep 5
aws lambda invoke --function-name bandwidth-benchmark \
--payload '{}' /tmp/out-$mem.json
cat /tmp/out-$mem.json
done
Run each memory tier a handful of times to smooth out cold-start noise, and use a large enough object (multi-GB) that the transfer, not connection setup, dominates the timing. This is the same rigor you’d apply to any capacity planning exercise — don’t skip it because the feature sounds good on paper.
The Non-VPC Constraint You Can’t Ignore
Here’s the catch that’s easy to miss if you skim the announcement: this bandwidth increase applies to Lambda functions configured outside a VPC. Functions attached to a VPC take a different networking path entirely — traffic routes through elastic network interfaces (ENIs) attached to your VPC’s subnets, with its own throughput characteristics and constraints that this announcement doesn’t touch.
If your data-moving function needs to reach an RDS instance, an internal service, or anything else that requires VPC placement, this specific improvement isn’t the lever you’re pulling. That doesn’t make VPC-bound Lambda bad — it just means the calculus is different, and you should verify your function’s actual networking mode before you promise a stakeholder a throughput number you read in a blog post (including this one).
Where This Actually Matters
The practical upside shows up anywhere a non-VPC function moves meaningful bytes: pulling large objects from S3 for processing, writing bulk exports back out, streaming media for transcoding hand-offs, or shuttling data between services in an event-driven pipeline. None of that is new work for Lambda — it’s work Lambda was previously bad at because the network pipe couldn’t keep up with the compute. That gap is now considerably narrower, and for teams that reflexively reached for Fargate the moment a job looked data-heavy, it’s worth re-testing the assumption rather than repeating it out of habit.
It’s also worth being honest about what this doesn’t fix. The 15-minute execution ceiling hasn’t moved, so a genuinely massive transfer — hundreds of gigabytes in a single shot — still won’t fit inside one invocation even at 3,000 Mbps. Chunk it across invocations orchestrated by Step Functions, or accept that some jobs are still better suited to a long-running container. And because higher memory tiers cost more per GB-second, the win isn’t automatic — a function that finishes faster at 10 GB isn’t necessarily cheaper than the same function running longer at 4 GB. Run the numbers for your actual payload sizes before you standardize on a memory setting across a fleet of functions.
At Enkompass (enkompass.net), this is our home turf. We spend our days tuning event-driven, serverless systems that scale to zero and bill like it — including squeezing exactly this kind of throughput out of Lambda instead of reaching for a bigger hammer. If you’d rather have seasoned cloud people handle it instead of learning the hard way at 2 AM, let’s talk. Reach out through our contact page or call us directly at +1-828-436-5667 — we’ll help you turn this from a someday-project into a done-deal.