Lambda で大きなデータを読み込む処理では、計算を速くしても、転送待ちが残ることがあります。2026年9月28日に公開された AWS の帯域拡張の解説は、この待ち時間をメモリ設定から見直すきっかけになります。

ただ、メモリを増やせば、そのまま速く、安くなるのでしょうか。帯域を利用できる条件、S3 からの読み方、実行時間と料金の関係をつなげると、試すべき関数と比較すべき数字が見えてきます。

Lambda の帯域拡張はクォータ承認から始まる

対象は、利用者の VPC に接続していない、メモリが 2,048 MB 以上の関数です。実行環境ごとの持続的なネットワーク帯域を拡張でき、10,240 MB では最大 3,000 Mbps に達します。ただし、メモリ設定の変更だけでは有効になりません。

まず Service Quotas の Network bandwidth per execution environment で引き上げを申請し、承認を受けます。その後にメモリ設定に応じた帯域が使える、という順序です。適用条件は Lambda のクォータ仕様でも確認できます。

この機能の提供告知は 2026年8月5日で、商用 AWS リージョンに追加料金なしで提供されています。9月28日の記事は、その使い方と測定例を掘り下げたものです。「追加料金なし」は帯域拡張機能についての説明であり、メモリ増量後も実行料金が同じ、という意味ではありません。

なお、ここでいう VPC 外は、利用者の VPC に接続していない構成を指します。Lambda 自体は標準でも AWS 管理の VPC 内で動きます。ネットワーク構成の説明を踏まえると、プライベートな接続先が必要な関数では、帯域だけを理由に VPC 接続を外す判断はできません。

S3 の並列読み込みで、増えた帯域を使う

帯域の上限が広がっても、データを取り出す側が追いつかなければ転送は速くなりません。S3 の性能ガイドは、複数接続へのリクエスト分散や、単一オブジェクトの異なるバイト範囲を並列取得する方法を案内しています。

AWS のサンプル実装には、分割済みオブジェクトを複数のワーカーで読む方式と、大きなオブジェクトをバイト範囲に分けて読む方式があります。関数を複数並べる並列化と、各関数の中で転送を並列化する設計を分けて考えると整理しやすいですね。

Python では、Boto3 の download_fileobj などの管理された転送に、AWS Common Runtime（CRT）を使う選択肢があります。Boto3 の転送設定では、TransferConfig の preferred_transfer_client に crt を指定できます。ただし、この設定を低水準の get_object による読み込みにも効くものとして扱ってはいけません。サンプルのバイト範囲方式は、並列リクエスト数を明示的に制御します。

並列数を増やす検証では、転送速度と一緒に S3 の 503 応答や再試行も見たいところです。接続を増やす目的は、待ち時間を減らすことです。リクエストの失敗が増えていれば、その設定が処理全体に効いているかを見直せます。

10 GB の測定例で見る、帯域と処理時間の違い

AWS が公開した測定例は、10 GB を 512 MB ずつ20個の処理に分ける構成です。ワーカーのメモリ設定を変えたときの、クエリ全体の経過時間は次のようになっています。測定条件と結果は、利用者の環境での性能保証ではありません。

ワーカーのメモリ	クエリ全体の経過時間（p50）
1,024 MB	7.113 秒
10,240 MB	2.640 秒

中央値の短縮率は約 62.9% です。従来の持続帯域 625 Mbps に対する最大帯域 3,000 Mbps の比率は 4.8 倍ですが、アプリケーション全体が同じ倍率で速くなるとは限らないことが分かります。

比較では CPU の変化も含まれます。Lambda のメモリ設定は CPU 割り当ても比例して増やすため、この結果をネットワークだけの効果として切り出すことはできません。自分の処理では、データ取得にかかった時間と、その後の加工・集約時間を分けて記録すると、次に改善する場所を判断しやすくなります。

メモリ増量の採否は、待ち時間と GB 秒を並べて決める

Lambda の料金では、実行時間に対する課金は割り当てメモリと課金対象時間に基づく GB 秒で決まります。同じリージョン・アーキテクチャ・料金単価で、実行時間の料金だけを比較するなら、基本となる関係は次のとおりです。

実行料金の比率 ≈ メモリの比率 × 課金対象時間の比率

たとえば、メモリを 1,024 MB から 10,240 MB へ10倍にする場合、同じ呼び出し数で実行料金を下げるには、課金対象時間の合計を元の10分の1未満にする必要があります。これは料金構造からの計算であり、先ほどのベンチマークの料金を推定したものではありません。並列処理の経過時間は、各ワーカーの課金対象時間の合計とは異なるためです。

検証ではまず現在のメモリ設定で比較用の値を取り、帯域拡張後も同じデータと並列数で測ります。そのうえでメモリを段階的に変え、利用者が待つ時間、各呼び出しの課金対象時間、全体の GB 秒を並べます。初回実行と再利用時を分け、p50 だけでなく遅い側の分布も見る、という比較方法が考えられます。

転送待ちが支配的な関数には、帯域拡張を試す理由があります。採用する設定は最大メモリとは限りません。必要な応答時間を満たす範囲で、並列化とメモリを組み合わせたときの総コストを比較することが、今回の変更を実務に生かす判断になります。

出典

• Title: Improving Lambda function latency with scalable network bandwidth
• URL: https://aws.amazon.com/blogs/compute/improving-lambda-function-latency-with-scalable-network-bandwidth/