AWS

AWS Lambda: Outbound Network Bandwidth Now Scales to 3 Gbps for 10 GB Functions

AWS Lambda outbound bandwidth scales to 3 Gbps for 10 GB functions. Review VPC egress, NAT sizing, monitoring, and treat Bedrock additions as a policy signal.

September 3, 2026·3 min read·AI researched · AI written · AI reviewed

AWS just made Lambda a serious network first-class citizen: outbound bandwidth now scales with memory all the way to 3,000 Mbps for 10 GB functions. That single change flips a lot of assumptions about serverless performance, cost, and risk.

For years Lambda bandwidth was a reasonable constraint — functions were small, chatty or CPU-bound, and teams treated them like ephemeral compute with light egress. Increasing the ceiling from the hundreds of Mbps you see at lower memory sizes up to 3,000 Mbps at 10 GB changes the calculus: a single Lambda can now saturate multi-gigabit links to S3, databases, and internal APIs. Expect both big wins and nasty surprises.

First, the wins. Data-intensive tasks that previously required EC2, Fargate, or batch fleets suddenly fit naturally into serverless. Think high-throughput S3 ingest, streaming transformations into data lakes, or fast parallelized API callers where function concurrency replaces fleet management. For teams that prize operational simplicity, Lambda becomes a straightforward way to parallelize network-bound work without managing servers.

Now the problems platform teams must solve immediately.

The NAT and egress bottleneck problem

Most VPC-based Lambdas still route egress through NAT Gateways, Transit Gateways, VPC Endpoints, or customer firewalls. A 3 Gbps-capable function multiplied by hundreds or thousands of concurrent executions will exceed many teams' NAT throughput and ephemeral port assumptions fast. NAT Gateway capacity is billed and can become a single availability and cost axis.

If you rely on a shared NAT or a small fleet of firewalls, expect connection failures, unexpected latency, and big egress bills. The right mitigations are the same you'd use for any heavy network client: prefer VPC endpoints for S3 and DynamoDB when possible, consider per-subnet or dedicated egress capacity, and audit ephemeral port usage and connection churn. Ephemeral port exhaustion and rapid connection turnover are real operational risks at this scale.

Observability and security

When functions can push gigabits, network observability becomes non-optional. VPC Flow Logs, VPC Traffic Mirroring, and high-cardinality metrics should be part of your pipeline so you can attribute egress and spot noisy functions. Higher throughput also increases the blast radius for data exfiltration if credentials are misused — treat runtime secrets, IAM policies, and least-privilege controls accordingly.

EKS Distro and on-prem parity

This week also brought refreshed EKS Distro builds across supported Kubernetes versions and updated component images. Notable component updates include Bottlerocket, govmomi, and cert-manager. These matter for TLS issuance, cluster lifecycle tooling, and CVE remediation in hybrid and edge clusters.

If you run EKS Anywhere or EKS-D on-prem, this release narrows drift between managed EKS control planes and your on-prem stack. Prioritize testing CRD compatibility and controller behavior against the new components — cert-manager upgrades in particular can change webhook timings and certificate renewal behavior in subtle ways.

Amazon Bedrock adds model and web search capabilities

On the AI front, Bedrock expanded support for additional model providers and added web-search capabilities for some models. These capabilities are exposed through the Bedrock APIs, preserving a single control plane for security, governance, and cost controls that enterprises expect.

This is overdue and the right call. Enterprises don't want separate governance planes for every big model vendor; they want a single control plane that enforces VPC, logging, and model auditing. Bedrock doing that for additional providers and web search will stop a lot of teams from building brittle, ad-hoc wrappers.

Final thought

Two simple action items you haven't done yet: (1) audit your VPC egress topology and NAT sizing with the assumption a single function can go multi-gig; and (2) treat Bedrock's model additions as a signal that multi-provider model governance is now a baseline expectation. If you ignore the network and governance implications, this week's features will bite you — not for technical reasons, but because you assumed serverless was always light.

Sources

aws-lambdaeks-distroamazon-bedrockserverless-networking
← All articles
AWS

Amazon Bedrock AgentCore Adds Server-side Web Search, Payments, and Long-lived Runtimes

Bedrock AgentCore adds server-side web search, payments, long-lived runtimes and memory ingestion — forcing platform teams to rethink IAM and billing governance.

Sep 1, 2026·3mamazon-bedrockagentcore
AWS

Amazon Bedrock adds OpenAI-style APIs and cross-Region inference routing

Bedrock adds OpenAI-style Responses and Chat-like APIs plus regional vs global inference routing, altering latency, routing and governance trade-offs.

Aug 31, 2026·3mamazon-bedrockopenai-compatible
AWS

Amazon EKS now supports multiple external OIDC providers per cluster

Amazon EKS now supports multiple external OIDC providers per cluster, enabling per-workload trust boundaries and requiring issuer lifecycle, audit, and ML infra planning now.

Aug 30, 2026·3mamazon-eksamazon-bedrock