AWS just changed a hard assumption about Lambda networking: functions running outside a VPC now get scalable bandwidth tied to memory size — 625 Mbps at 2 GB, rising to about 3 Gbps at 10 GB. That's a real throughput curve, not marketing-speak, and it matters more than most teams realize.
Why this actually matters
For years the common pattern for high-throughput or low-latency Lambda egress was "put the function in a VPC and manage ENIs/NAT or use sidecars/proxies" — mostly because non‑VPC functions felt like best-effort networking with opaque limits. That led teams into complex designs: ENI cold-start penalties, NAT gateway bills, or sidecar proxies to consolidate connections and control TLS termination.
Now you can reasonably pick a non‑VPC Lambda with larger memory and expect predictable raw bandwidth up to ~3 Gbps. That reduces architectural pressure to shove every outbound heavy‑IO function into a VPC and avoids many of the ENI/attachment scaling headaches. In short: it makes serverless first-class for higher‑throughput workloads.
What changed (technical details)
- Bandwidth scaling applies to functions running outside a VPC when memory is 2 GB or higher.
- At 2 GB you get ~625 Mbps; the curve continues up to roughly 3 Gbps at 10 GB.
- AWS published these numbers alongside other compute and runtime updates; check the official Lambda docs for the exact published bandwidth curve and region availability.
The practical implications for platform teams
This is the right call from AWS. The alternative was continued user engineering — brittle NAT topologies, unscalable ENI counts, or fabricating proxy layers that carry state, complexity, and cost. With bandwidth tied to memory, teams gain a predictable lever to tune egress performance without changing network topology.
That said, this will bite teams that built implicit assumptions into observability and cost models:
- Egress cost and billing: higher throughput on non‑VPC functions can increase data transfer and downstream service load. If you optimized for ENI/NAT aggregation to reduce egress calls, your cost model needs revisiting.
- Concurrency vs bandwidth: memory scales bandwidth per invocation, but concurrency multiplies aggregate throughput. Load tests must model both axes to avoid surprising downstream saturation.
- Security and control: removing a VPC doesn't eliminate the need for egress controls. If you relied on VPC route tables, inspection appliances, or VPC‑level firewalling, moving a function out of the VPC changes your enforcement plane.
Runtimes and Bedrock: small but directional
Alongside the networking change, AWS noted runtime and compute updates that make adopting newer language releases easier for teams standardizing runtimes or base images. Amazon Bedrock also received feature updates around retrieval and policy automation; if you build retrieval‑augmented agents or policy-driven automation, the Bedrock changes are worth evaluating.
Regional rollouts
AWS's "What's New" and service documentation indicate expanded availability for additional instance families and features in more regions. If you were waiting on a specific region for an instance type or capability, check the regional availability table in the console.
No EKS changes were confirmed in the last week.
Where this pushes teams next
Runbooks and load tests. Revisit observability dashboards to capture per‑invocation bandwidth expectations and correlate memory size with egress patterns. If you still route Lambdas through VPC NAT primarily for throughput reasons, stop — unless you need the VPC for policy enforcement. If you need both control and throughput, expect to combine non‑VPC functions with network‑level enforcement (for example, service proxies, WAFs, or dedicated egress controls) rather than ENI‑heavy designs.
If you want historical context on Lambda tradeoffs and sandboxing choices, my previous look at Lambda MicroVMs covers why AWS keeps evolving execution boundaries: /article/aws-lambda-microvms-vm-level-sandboxing-1mb-async-payloads/.
Final take: this is a quietly important change. It doesn't reshape cloud computing on its own, but it removes a common engineering footgun and flips a cost/complexity tradeoff in favor of serverless. Teams that adapt quickly will simplify networks and shave operational corners; teams that don't will keep paying for fragile VPC plumbing they no longer need.