Lambda のネットワーク帯域幅を Service Quotas で 3,000 Mbps に引き上げて実測してみた
はじめに
2026年8月、VPC外の AWS Lambda 関数のネットワーク帯域幅を最大 3,000 Mbps まで拡張できるアップデートがありました。
今回は、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 から大容量のファイルを並列でダウンロードする処理では、転送時間の短縮が期待できます。追加費用は発生しませんが、転送を並列化できない場合は効果が小さいこともあります。転送時間の短縮を試みる場合は、まず検証環境でその効果を確認いただくことをおすすめします。








