For years, the standard advice on Lambda network bandwidth was to not count on it. If a workload moved a lot of data — bulk exports, media processing, large file transfers — the playbook said skip Lambda and provision Fargate or EC2 instead, because Lambda’s network throughput couldn’t keep up. On August 6, 2026, AWS changed that math: Lambda functions running outside a VPC now scale network bandwidth with memory, up to 3,000 Mbps. AWS called enough attention to it to feature it again in the August 10 Weekly Roundup.
That’s not a technical footnote. It’s a shift in what “serverless-first” can reasonably cover, and it’s worth a few minutes of your architecture roadmap.
Where Teams Have Been Over-Provisioning “Just for the Network”
Talk to enough engineering teams and you’ll hear a version of the same story: a data-moving job — an ETL step, a nightly export, a media transcode hand-off — started as a Lambda function, hit a network throughput wall, and got migrated to a Fargate task or a standing EC2 instance. Not because the compute needed it. Because the network did.
The problem with that migration is it rarely stops at “move this one job.” Once a team stands up a Fargate cluster or an EC2 fleet for one data-heavy workload, it becomes the default landing spot for the next one, and the one after that. What started as a targeted workaround for a network limitation quietly becomes a second compute platform your team has to patch, monitor, right-size, and staff for — running well below capacity most of the day because the job it was built for only runs a few times an hour.
The Cost Case for Lambda Network Bandwidth
Lambda’s pricing model — pay for what you invoke, nothing for idle time — is well understood; the full breakdown is on the AWS Lambda pricing page, with function configuration details in the AWS Lambda documentation. What’s less obvious is how much operational overhead disappears with it. No cluster to patch. No task definitions to maintain. No capacity planning for a workload that runs in bursts. When the network throughput objection goes away for a given job, the case for keeping it on Lambda gets a lot easier to make to whoever owns the infrastructure budget.
The comparison point here is AWS Fargate, which remains a perfectly good platform — it’s just no longer the automatic answer the moment a workload looks data-heavy. For teams re-evaluating their architecture roadmap this quarter, the reasonable move isn’t “migrate everything back to Lambda.” It’s “stop assuming Fargate by default and check the numbers on the next data-moving job before you provision anything.”
There’s also a headcount angle worth naming plainly. Every extra platform a team runs — even a well-managed one — is another thing someone has to know how to operate, patch, and debug at 2 AM. A smaller infrastructure footprint isn’t just cheaper on the AWS bill; it’s cheaper in the “who do we need on call and how deep does their expertise need to be” sense too. That’s a real cost, and it rarely shows up on the invoice.
Where This Still Doesn’t Replace a VPC-Bound Architecture
This increase applies specifically to Lambda functions configured outside a VPC. If your data pipeline needs to reach a private database, an internal API, or anything else that requires VPC placement for security or compliance reasons, this improvement doesn’t apply to that function — VPC-attached Lambda functions use a different networking path with its own characteristics. That’s not a knock on the feature; it’s a scope boundary your architects need to flag before anyone promises a throughput number in a planning meeting.
In practice, this means the decision tree gets one more branch, not a simpler one: does the workload need VPC access? If no, and it moves a lot of data, Lambda just became a much stronger default. If yes, the calculus around VPC networking, NAT gateways, and ENI provisioning hasn’t changed, and Fargate or EC2 may still be the right call for reasons that have nothing to do with raw throughput.
What to Ask Before the Next Planning Cycle
None of this requires a big migration announcement or a slide with a scary red-to-green chart. It requires three questions in your next architecture review, aimed at whoever owns infrastructure spend and whoever owns the roadmap:
First, which of our current Fargate or EC2 workloads exist specifically because a Lambda function couldn’t move data fast enough — not because of compute, memory, runtime, or compliance requirements, but network throughput alone? Second, of those, which ones actually need VPC placement, and which don’t? That split determines what’s even eligible for this change. Third, for the eligible ones, what does a real benchmark say, run against your actual data shapes rather than a vendor’s marketing numbers?
That’s a half-day exercise for an engineering lead, not a quarter-long initiative. The output is a short list of workloads worth re-architecting, ranked by how much idle infrastructure they’re currently costing you.
What This Means for Your Roadmap
The risk in ignoring this update isn’t dramatic — nothing breaks. The risk is opportunity cost: continuing to pay for and operate infrastructure that was provisioned to solve a problem that no longer exists for a growing set of workloads. That’s worth a line item in the next architecture review: identify the Fargate or EC2 workloads that exist purely because a Lambda function couldn’t move data fast enough, check whether they run outside a VPC requirement, and get real benchmark numbers before deciding whether they belong back on serverless.
None of this is a mandate to rip anything out this week. It’s a prompt to stop treating “Lambda can’t handle data-heavy work” as settled fact when AWS just spent real engineering effort proving otherwise for a meaningful slice of use cases. The teams that revisit that assumption early get a cheaper, simpler stack. The teams that don’t just keep paying rent on infrastructure they no longer need.
At Enkompass (enkompass.net), this is our home turf. We help teams figure out exactly which workloads belong on serverless and which don’t — and we build event-driven systems that scale to zero and bill like it. 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.