AWS

AWS Lambda increases non‑VPC network bandwidth to 3 Gbps for 2 GB+ functions

AWS Lambda now offers up to 3 Gbps for non-VPC functions with 2GB+ memory, pushing teams to rethink VPC placement, egress controls, and where inference runs.

August 12, 2026·3 min read·AI researched · AI written · AI reviewed

AWS just raised the usable network pipe for non‑VPC Lambdas to 3 Gbps for functions with 2 GB or more of memory. That single change — explicit, numeric, and immediately usable — is the sort of infrastructure nudge that changes architectures more than marketing blurbs ever do.

What matters practically: if your workloads move large blobs, stream video, or do model inference that ships dozens to hundreds of MB per request, a non‑VPC Lambda with 2 GB+ can now hit ~3 Gbps. That makes serverless a first‑class option for data‑plane work you would previously have parked on EC2 instances, sidecar proxies, or VPC‑attached functions that required ENIs and NAT traversal.

The implication is simple and blunt: put throughput‑sensitive Lambdas outside the VPC when you can. Non‑VPC Lambdas don’t attach ENIs and avoid VPC egress plumbing that can add latency or throughput constraints; they also sidestep some of the VPC‑related cold‑start surface. AWS giving a hard number (≈3 Gbps) lets you reason about tail latency and throughput in capacity planning instead of guessing.

That said, this is not a free lunch. Non‑VPC functions sit outside VPC controls: they aren’t governed by your VPC security groups, won’t generate VPC flow logs, and won’t be visible to appliances inside the VPC. If your security model depends on central egress gateways, transit VPCs, or DPI performed inside the VPC, moving high‑bandwidth traffic outside the VPC will break those guarantees. Treat this as a new trust boundary and map where observability or policy enforcement will be lost.

AWS is also making managed GPU and accelerator options more attractive by simplifying managed paths and fee structures for GPU and Trainium/Inferentia workloads on managed cluster services. That reduces the operational premium of running inference and training on managed EKS/ECS modes versus operating bespoke GPU fleets, and will push more teams toward managed cluster modes for model ops.

On the AI front, Bedrock continues to expand agent features, integrations (including search and retrieval), and policy/automation tooling. The pattern is clear: AWS is productizing agentic workflows that combine retrieval, reasoning, and action. That's powerful, but it also amplifies the attack surface — agents that can call services, fetch data, and refine policies change your operational model.

Two practical architecture signals emerge from these announcements:

  • Move high‑throughput, short‑lived data processing out of the VPC when possible. The throughput win is now deterministic; design for egress costs and observability elsewhere.
  • Lean on managed AI and GPU services for inference and training. Simpler managed offerings and lower operational overhead make managed cluster modes materially more attractive than DIY GPU fleets.

This is the right direction from AWS: give measurable, network‑level capacity and make managed GPU/accelerator paths easier to use. But teams that treat these as purely operational upgrades and don't revisit security, egress, and audit models will pay for it. If your platform still assumes all critical egress goes through a VPC appliance, your observability and compliance controls are about to be blind to a new class of high‑volume traffic.

Last point — agentic Bedrock features plus higher serverless throughput are converging. Expect serverless functions to become the default execution and integration layer for agents and inference pipelines: fast networked Lambdas fetching data, calling Bedrock agents, and streaming results back. That reduces engineering friction, but it creates a composite system where one misconfigured agent or an unexpected burst in Lambda egress can cascade across inference, billing, and audit trails.

If you operate platform or infra teams, do two things this week: map where high‑bandwidth Lambdas would remove awkward VPC plumbing, and simultaneously map the audit/egress controls you'll lose if you move them. AWS handed you a bigger pipe and easier managed GPU paths — if you don't redesign around the new trust boundaries, that advantage will turn into a production incident you didn't see coming.

Sources

aws-lambdaserverless-networkingamazon-bedrockamazon-eks
← All articles
AWS

Amazon Bedrock AgentCore: managed EC2 runtimes, Web Search filters, S3 File API multi-agent pattern, and Lambda bandwidth

Bedrock AgentCore adds managed persistent EC2 runtimes; Web Search gets domain and date filters; S3 File API enables multi-agent coordination—update IAM and ops.

Aug 23, 2026·3mamazon-bedrockagentcore
AWS

Amazon Bedrock agent runtimes and payments: persistent instances, spend controls, and operational guidance

Amazon Bedrock added persistent agent runtimes and a payments orchestration layer. Platform teams must urgently apply IAM, network, and billing controls.

Aug 22, 2026·3mamazon-bedrockbedrock-agents
AWS

Amazon Bedrock AgentCore runtime instances and temporal session policies

Amazon Bedrock AgentCore adds persistent runtime instances and temporal session policies, shifting orchestration, security, and cost boundaries for platform teams.

Aug 21, 2026·3mamazon-bedrockbedrock-agentcore