AWS just raised Lambda's network bandwidth ceiling to 3,000 Mbps. It got a fraction of the attention the flashier launches did, which is a shame, because for the right workload this is the difference between a function that crawls and one that flies.
My site has an upload path that pushes files through Lambda into S3. So when I read this, my first thought was "great, my uploads will get faster." My second thought, after actually looking, was "no they won't, and it is worth explaining why." Because the interesting lesson here is not the new number. It is how to tell whether bandwidth was ever your bottleneck in the first place.
The thing nobody tells you about Lambda bandwidth
Here is the detail that reframes the whole announcement. On Lambda, network bandwidth is not a flat allowance. It scales with the memory you allocate to the function. A tiny 256MB function gets a modest slice of network. A big 3GB function gets a lot more.
That is not abstract for me. My backend function runs on a modest memory allocation, which is plenty for what it does. Which means the old ceiling only ever bit functions that were already large and already moving serious data, and mine is neither. If you are running a modest function like I am, you were never anywhere near the old limit, so the new one changes nothing for you. The headline number is real, but it is a ceiling most small functions never touched.
My actual upload path, and why bandwidth was a red herring
My site accepts uploads up to 50MB and streams them into S3 through the backend. When I set that up, the tuning that actually mattered had nothing to do with network throughput. I raised the request size limit, which had been capped at 10MB, up to 50MB. I adjusted the multipart parsing. I made sure the storage layer handled the larger payloads. Those were the real levers, and none of them were bandwidth.
The reason is simple. 50MB over even a modest Lambda network allocation moves in a fraction of a second. The time my users actually wait on an upload is dominated by other things entirely: their own connection speed pushing the file up to AWS, the multipart parsing, the write to S3, and if the function was cold, the cold start sitting in front of all of it. Raw Lambda-to-S3 bandwidth is a rounding error in that list. Bumping the ceiling to 3 Gbps does not touch a single one of my real costs. It is a faster top speed on a road where I was never near the limit.
How to actually find your bottleneck
This is the part worth keeping, because it applies to any function, not just mine. Do not guess. Look at your CloudWatch Duration metric and ask a simple question: does the time scale with payload size, or with something else? If a 5MB upload and a 45MB upload take roughly the same time, your bottleneck is fixed overhead like cold starts or connection setup, not bandwidth. If duration climbs steadily with file size and your function is memory-starved, then and only then is bandwidth, and the memory it scales with, a real lever.
The usual real bottlenecks on a path like mine, in the order they actually bite: cold starts, the client's own upload speed, payload size caps in the layers in front of Lambda, and memory-linked CPU. Raw egress bandwidth is near the bottom of that list for anything under a few hundred megabytes.
And if you do find bandwidth is your limit, the fix is often counterintuitive: raise the function's memory. More memory means more CPU and more network, so a memory bump can speed up a network-bound function even when it never uses the extra RAM. If I ever needed it, my lever would be raising the function's memory further, not chasing the bandwidth number directly.
What I am actually doing about it
Nothing, and that is the honest answer. This announcement is genuinely good for people running big, data-heavy functions who were pressed against the old ceiling. I am not one of them, and pretending otherwise to write a more exciting post would be dishonest.
But it was a useful nudge to go back and look at my upload path with fresh eyes and confirm where the time actually goes. That is the real value of a launch like this for a small project. Not the feature itself, but the excuse to measure instead of assume. Know your bottleneck before you celebrate a fix for one you never had. That habit will save you more time than any single AWS limit increase.