I tried raising Lambda's network bandwidth to 3,000 Mbps via Service Quotas and measured it in practice

Introduction

In August 2026, there was an update that allows expanding the network bandwidth of AWS Lambda functions outside a VPC up to 3,000 Mbps.

https://aws.amazon.com/about-aws/whats-new/2026/08/aws-lambda-network-bandwidth/

This time, we compared throughput using iperf3 and 1 GB downloads from S3 while varying Lambda memory, between Oregon (3,000 Mbps), where we submitted a quota increase request via Service Quotas, and Tokyo (625 Mbps), where we did not submit a request.

What We Tested

Quota Increase

Bandwidth is managed under "Network bandwidth per execution environment" in Service Quotas. We checked the applied value.

aws service-quotas get-service-quota \
  --service-code lambda \
  --quota-code L-14320ECE \
  --region us-west-2

{
    "Quota": {
        "ServiceCode": "lambda",
        "ServiceName": "AWS Lambda",
        "QuotaCode": "L-14320ECE",
        "QuotaName": "Network bandwidth per execution environment",
        "Value": 3000.0,
        "Unit": "Megabits/Second",
        "Adjustable": true,
        "GlobalQuota": false,
        "QuotaAppliedAtLevel": "ACCOUNT",
        "Description": "The maximum sustained network bandwidth, in megabits per second, for a Lambda function's execution environment that is not attached to a VPC."
    }
}

Increase requests are submitted per region. Once AWS approves them, they apply to all functions outside a VPC in that region.

Requests can also be submitted via CLI.

aws service-quotas request-service-quota-increase \
  --service-code lambda \
  --quota-code L-14320ECE \
  --desired-value 3000 \
  --region us-west-2

When a request is submitted, a support case is automatically created. The account used this time was covered by AWS Enterprise Support.

It took approximately 2 days from submission to application, with one round-trip for use case confirmation in between. The following three points were provided in the response:

• The purpose is validation and benchmarking in a non-production environment, not to remove constraints on production workloads
• We want to measure the effect of the bandwidth expansion announced on August 5, 2026, in a test environment
• The scope is account-wide rather than specific functions. The testing will be completed within a few days, so a permanent increase is not required

Requests are not guaranteed to be approved and may take several days to process, so please submit requests well in advance of your testing or deployment schedule.

Test Environment

• Lambda: Container image (public.ecr.aws/lambda/python:3.13 with iperf3 3.19.1 added), arm64, no VPC attachment, 300-second timeout. Memory was varied across 1,024 / 2,048 / 3,072 / 5,120 / 8,192 / 10,240 MB for measurements
• EC2 (iperf3 server): c8gn.large, Amazon Linux 2023 arm64, TCP 5201 via public IP
• S3: A 1 GB (1,073,741,824 bytes) object was placed in each region and downloaded from Lambda in the same region

S3 with concurrency 10 and iperf3 were each measured 3 times per condition, with the median shown in the table. Single stream was measured once per condition. iperf3 was run with -t 10 -P 4 (10 seconds, 4 parallel streams). For S3, chunk size was set to 16 MB using boto3's TransferConfig.

We selected c8gn.large for the server, which has a bandwidth wider than the Lambda-side limit of 3,000 Mbps.

Between two instances of the same type placed in the same VPC and same AZ, we confirmed that 9.54 Gbits/sec with a single stream and 29.8 Gbits/sec with 4 parallel streams could be sustained for 60 seconds.

We deployed c8gn.large in both Oregon and Tokyo using the following template.

Parameters:
  VpcId:
    Type: AWS::EC2::VPC::Id
  SubnetId:
    Type: AWS::EC2::Subnet::Id
  InstanceType:
    Type: String
    Default: c8gn.large
  AmiId:
    Type: AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>
    Default: /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-arm64

Resources:
  ServerSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: iperf3 server - TCP 5201 only, no SSH
      VpcId: !Ref VpcId
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 5201
          ToPort: 5201
          CidrIp: 0.0.0.0/0
          Description: iperf3 from Lambda (dynamic source IP)

  ServerRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: ec2.amazonaws.com
            Action: sts:AssumeRole
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore

  ServerInstanceProfile:
    Type: AWS::IAM::InstanceProfile
    Properties:
      Roles:
        - !Ref ServerRole

  ServerInstance:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: !Ref AmiId
      InstanceType: !Ref InstanceType
      IamInstanceProfile: !Ref ServerInstanceProfile
      SubnetId: !Ref SubnetId
      SecurityGroupIds:
        - !GetAtt ServerSecurityGroup.GroupId
      UserData:
        Fn::Base64: |
          #!/bin/bash
          dnf install -y iperf3
          cat > /etc/systemd/system/iperf3.service <<'UNIT'
          [Unit]
          Description=iperf3 server
          After=network-online.target

          [Service]
          ExecStart=/usr/bin/iperf3 --server --port 5201
          Restart=always

          [Install]
          WantedBy=multi-user.target
          UNIT
          systemctl daemon-reload
          systemctl enable --now iperf3

Outputs:
  InstanceId:
    Value: !Ref ServerInstance
  PublicIp:
    Value: !GetAtt ServerInstance.PublicIp

The Lambda function for measurement was created as a container image.

FROM public.ecr.aws/lambda/python:3.13

RUN dnf install -y iperf3 && dnf clean all && rm -rf /var/cache/dnf

COPY app.py ${LAMBDA_TASK_ROOT}/

CMD ["app.handler"]

We built and pushed it, then created the function. Memory was switched via configuration changes after deployment.

docker buildx build --provenance=false --sbom=false \
  --output type=image,oci-mediatypes=false,push=true \
  -t 123456789012.dkr.ecr.us-west-2.amazonaws.com/lambda-bw-test:latest .

aws lambda create-function \
  --function-name bw-test \
  --package-type Image \
  --code ImageUri=123456789012.dkr.ecr.us-west-2.amazonaws.com/lambda-bw-test:latest \
  --role arn:aws:iam::123456789012:role/lambda-bw-verify-exec \
  --architectures arm64 --memory-size 10240 --timeout 300 \
  --region us-west-2

aws lambda update-function-configuration \
  --function-name bw-test --memory-size 2048 --region us-west-2

The handler handles iperf3 execution, S3 downloads, and uploading test objects (mode: put). The following is an excerpt of the iperf3 and S3 download portions. Downloaded data is passed to a null sink to exclude disk I/O from measurement.

def run_iperf3(event, memory_mb):
    server_ip = event["server_ip"]
    duration = event.get("duration", 10)
    parallel = event.get("parallel", 4)
    cmd = [
        "/usr/bin/iperf3",
        "-c", server_ip,
        "-p", str(event.get("port", 5201)),
        "-t", str(duration),
        "-P", str(parallel),
        "-J",
    ]
    proc = subprocess.run(cmd, capture_output=True, text=True, timeout=duration + 60)
    result = json.loads(proc.stdout)
    sent = result.get("end", {}).get("sum_sent", {})
    return {
        "memory_mb": memory_mb,
        "sent_mbps": round(sent.get("bits_per_second", 0) / 1_000_000, 1),
        "retransmits": sent.get("retransmits"),
    }

def run_s3(event, memory_mb):
    config = TransferConfig(
        max_concurrency=event.get("concurrency", 10),
        multipart_chunksize=event.get("chunk_mb", 16) * 1024 * 1024,
        multipart_threshold=event.get("chunk_mb", 16) * 1024 * 1024,
        use_threads=event.get("concurrency", 10) > 1,
    )
    sink = NullSink()
    started = time.time()
    boto3.client("s3").download_fileobj(event["bucket"], event["key"], sink, Config=config)
    elapsed = time.time() - started
    return {
        "memory_mb": memory_mb,
        "bytes": sink.total,
        "elapsed_s": round(elapsed, 3),
        "mbps": round(sink.total * 8 / elapsed / 1_000_000, 1),
    }

The 1 GB object to be downloaded was not uploaded from a local machine, but was created via multipart upload from a Lambda function in the same region. We also verified that the content_length in the response was as expected.

aws s3api create-bucket --bucket lambda-bw-verify-usw2-example \
  --create-bucket-configuration LocationConstraint=us-west-2 --region us-west-2

aws lambda invoke --function-name bw-test --cli-binary-format raw-in-base64-out \
  --payload '{"mode":"put","bucket":"lambda-bw-verify-usw2-example","key":"dummy-1gb.bin","size_mb":1024,"part_mb":64}' \
  response.json --region us-west-2

{"mode": "put", "ok": true, "memory_mb": "10240", "bucket": "lambda-bw-verify-usw2-example", "key": "dummy-1gb.bin", "content_length": 1073741824, "elapsed_s": 9.93, "region": "us-west-2"}

Results

Throughput by Memory

We sent from Lambda to the EC2 public IP using iperf3 while varying memory, and obtained the sender-side throughput (sum_sent).

All measurements were taken in a single AZ at a single point in time.

Oregon started increasing from 2,048 MB, increased roughly proportionally from 3,072 to 8,192 MB, and leveled off at around 2,400 Mbps above 8,192 MB. Tokyo remained flat from 1,024 MB to 10,240 MB.

S3 Transfer

Using the same configuration, we downloaded a 1 GB object from S3 in the same region with concurrency 10 and a single stream.

Oregon at 10,240 MB reached 2,976 Mbps, equivalent to 99% of the quota limit of 3,000 Mbps. With Oregon at concurrency 10, the time required to download 1 GB was reduced from 13.36 seconds at 1,024 MB to 2.89 seconds at 10,240 MB.

Summary

The network bandwidth of Lambda functions outside a VPC can now be increased upon request. In regions where the increase was applied, throughput grew as memory increased, and parallel downloads from S3 achieved bandwidth close to the quota limit.

For Lambda functions with large memory allocations that download large files from S3 in parallel, reduced transfer times can be expected. No additional costs are incurred, but the benefit may be limited when transfers cannot be parallelized. If you are looking to reduce transfer times, we recommend first verifying the effect in a test environment.