Lambda のネットワーク帯域幅を Service Quotas で 3,000 Mbps に引き上げて実測してみた

Lambda のネットワーク帯域幅を Service Quotas で 3,000 Mbps に引き上げて実測してみた

VPC外の Lambda 関数のネットワーク帯域幅が、デフォルトの 625 Mbps から最大 3,000 Mbps まで、申請により拡張できるようになりました。Lambda のメモリを変えながら、iperf3 と S3 からのダウンロードでスループットを比較しました。
2026.09.13

はじめに

2026年8月、VPC外の AWS Lambda 関数のネットワーク帯域幅を最大 3,000 Mbps まで拡張できるアップデートがありました。

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

今回は、Service Quotas から引き上げを申請したオレゴン(3,000 Mbps)と、申請していない東京(625 Mbps)で、Lambda のメモリを変えながら iperf3 と S3 からの 1 GB ダウンロードでスループットを比較しました。

検証内容

クォータ引き上げ

帯域幅は Service Quotas の「Network bandwidth per execution environment」で管理されます。適用値を確認しました。

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."
    }
}

引き上げはリージョンごとに申請します。AWS が承認すると、そのリージョンの VPC外の関数すべてに適用されます。

申請も CLI から実行できます。

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

申請すると、サポートケースが自動で起票されます。今回のアカウントは AWS Enterprise Support の対象でした。

日時(UTC) 内容
2026-08-06 午後 Service Quotas から申請
2026-08-06 午後 ユースケースの確認依頼が届く
2026-08-07 午前 ユースケースを回答
2026-08-08 午後 引き上げが反映される

申請から反映まで約2日かかり、間にユースケースの確認が1往復ありました。回答した内容は次の3点です。

  • 目的は非本番環境での検証とベンチマークであり、本番ワークロードの制約を解消するためではない
  • 2026年8月5日に発表された帯域幅拡張の効果を、検証環境で実測して確認したい
  • 対象は特定の関数ではなくアカウント単位。検証は数日で終わるため、恒久的な引き上げは必要としない

申請は必ず通るとは限らず、調整に日数がかかることもあるので、検証や導入の予定に対して余裕をもって申請してください。

検証環境

  • Lambda: コンテナイメージ(public.ecr.aws/lambda/python:3.13 に iperf3 3.19.1 を追加)、arm64、VPC未接続、タイムアウト 300 秒。メモリを 1,024 / 2,048 / 3,072 / 5,120 / 8,192 / 10,240 MB に変えて測定しました
  • EC2(iperf3 サーバー): c8gn.large、Amazon Linux 2023 arm64、パブリックIP経由の TCP 5201
  • S3: 各リージョンに 1 GB(1,073,741,824 バイト)のオブジェクトを配置し、同一リージョンの Lambda からダウンロードしました

S3 の並列度10と iperf3 は各条件で3回測定し、表には中央値を載せています。単一ストリームは各条件で1回です。iperf3 は -t 10 -P 4(10秒間・並列4ストリーム)で実行しました。S3 は boto3 の TransferConfig でチャンクサイズを 16 MB としました。

サーバーには、Lambda 側の上限 3,000 Mbps より広い帯域を持つ c8gn.large を選びました。

インスタンスタイプ ベースライン ピーク vCPU
c8gn.large 6.25 Gbps 30 Gbps 2

同一VPC・同一AZ に配置した同タイプ2台の間では、単一ストリームで 9.54 Gbits/sec、並列4ストリームで 29.8 Gbits/sec を60秒間維持できることを確認しました。

オレゴンと東京にそれぞれ、次のテンプレートで c8gn.large をデプロイしました。

iperf3 サーバーの CloudFormation テンプレート
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

測定側の Lambda はコンテナイメージで作成しました。

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"]

ビルドして push し、関数を作成しました。メモリはデプロイ後に構成変更で切り替えました。

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

ハンドラーは iperf3 の実行、S3 のダウンロード、検証用オブジェクトのアップロード(mode: put)を兼ねます。以下は iperf3 と S3 ダウンロード部分の抜粋です。ダウンロードしたデータは捨てるシンクへ渡し、ディスクI/Oを測定対象から除外しました。

測定用 Lambda のハンドラー
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),
    }

ダウンロード対象の 1 GB オブジェクトは、ローカルからアップロードせず、同一リージョンの Lambda からマルチパートアップロードで作成しました。レスポンスの content_length が期待どおりであることも確認しました。

1 GB ダミーオブジェクトの作成
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"}

結果

メモリ別スループット

メモリを変えながら、Lambda から EC2 のパブリックIP宛に iperf3 で送信し、送信側のスループット(sum_sent)を取得しました。

Lambdaメモリ オレゴン(3,000 Mbps に引き上げ) 東京(625 Mbps のまま)
1,024 MB 653 Mbps 632 Mbps
2,048 MB 795 Mbps 630 Mbps
3,072 MB 1,084 Mbps 627 Mbps
5,120 MB 1,616 Mbps 630 Mbps
8,192 MB 2,380 Mbps 633 Mbps
10,240 MB 2,396 Mbps 628 Mbps

いずれも単一AZ・単一時点の計測です。

オレゴンは 2,048 MB から伸び始め、3,072〜8,192 MB ではほぼ比例して増加し、8,192 MB 以降は 2,400 Mbps 前後で横ばいになりました。東京は 1,024 MB から 10,240 MB まで横ばいでした。

S3転送

同じ構成で、同一リージョンの S3 から 1 GB のオブジェクトを並列度10と単一ストリームでダウンロードしました。

Lambdaメモリ オレゴン 並列10 オレゴン 単一 東京 並列10 東京 単一
1,024 MB 643 Mbps 662 Mbps 633 Mbps 609 Mbps
2,048 MB 811 Mbps 689 Mbps 620 Mbps 642 Mbps
3,072 MB 1,118 Mbps 677 Mbps 622 Mbps 640 Mbps
5,120 MB 1,741 Mbps 755 Mbps 622 Mbps 610 Mbps
8,192 MB 2,472 Mbps 770 Mbps 620 Mbps 643 Mbps
10,240 MB 2,976 Mbps 777 Mbps 618 Mbps 616 Mbps

オレゴンの 10,240 MB で 2,976 Mbps に達し、クォータの上限値 3,000 Mbps の 99% に相当します。オレゴンの並列度10では、1 GB のダウンロード所要時間が 1,024 MB の 13.36 秒から 10,240 MB の 2.89 秒へ短縮されました。

まとめ

VPC外 Lambda のネットワーク帯域幅は、申請により引き上げられるようになりました。引き上げたリージョンでは、メモリを増やすほどスループットが伸び、S3 からの並列ダウンロードではクォータの上限値に近い帯域が出ました。

メモリ割り当ての大きい Lambda 関数で、S3 から大容量のファイルを並列でダウンロードする処理では、転送時間の短縮が期待できます。追加費用は発生しませんが、転送を並列化できない場合は効果が小さいこともあります。転送時間の短縮を試みる場合は、まず検証環境でその効果を確認いただくことをおすすめします。

この記事をシェアする

AWSのお困り事はクラスメソッドへ

関連記事