Lambda の S3 Files で、バケットからの直読みを関数ごとに有効・無効へ指定できるようになった。既定ではメモリ512MB以上の関数だけが直読みの対象で、有効時は1MB以上のファイルだけがバケットから読まれる。
1MB direct read を有効にしたときバケットから直読みされるファイルサイズの下限 AWS の What's New（2026年9月11日）に「1 MB 以上のファイルはバケットから直接読み、それ未満は高性能ストレージ経由」と記載。無効時はサイズを問わず高性能ストレージ経由。
メモリ512MB未満の Lambda 関数が S3 Files からファイルを読むとき、サイズが大きくても経路は high-performance storage 側になる。S3 バケットからの直読み（direct read）は、512MB以上のメモリを割り当てた関数にだけ既定で開く経路だからだ。AWS の What’s New に、この直読みを関数ごとに明示的に有効・無効へ指定する設定が載った。メモリサイズとの結び付きは、ここで切れる。
関係するのは S3 Files を Lambda から読んでいる関数だけだ。読み取り性能のためにメモリを積んでいたなら、その理由は一つ減る。反対に、レイテンシを詰めたい関数なら、メモリが512MB以上でも直読みを切って、読み取りをすべて high-performance storage に寄せられる。
| direct read | 1MB以上のファイル | 1MB未満のファイル | 発表文が挙げる狙い |
|---|---|---|---|
| 有効 | S3 バケットから直読み | high-performance storage 経由 | 大きな読み取りのスループット最大化 |
| 無効 | high-performance storage 経由 | high-performance storage 経由 | 最小レイテンシ |
出典：AWS「AWS Lambda now supports direct read configuration for Amazon S3 Files」
設定は二択だが、効き方は読むファイルのサイズ分布で決まる。1MB 未満のファイルしか扱わない関数では、有効にしても経路は変わらない。1MB 以上のファイルを読む関数では、有効・無効によってその読み取り経路が変わる。
S3 Files 自体は、低レイテンシなら高性能ストレージ、大きな読み取りの高スループットならバケット直読みと、操作ごとに適した側へ自動で振り分けると発表文は説明している。今回の設定はその上で、関数がどちらから読むかを指定する手段として置かれた。自動の振り分け基準と、有効時に示される1MB の閾値がどう噛み合うのかまでは書かれていない。
発表文は既定の説明を現在形のまま残している。「既定では、Lambda は512MB以上のメモリを設定した関数についてのみ、S3 バケットからの直読みをサポートする」（訳）という一文だ。追加されたのは、この既定とは独立に有効・無効を指定できる手段であり、既定そのものが書き換わったとは述べられていない。明示的に設定しない関数が従来どおり動くかは断定できないが、文面からは512MB の線が残ると読むのが自然だ。ここは推測になる。
発表文は、直読みを制御できない状態ではアプリケーション要件に合わせて読み取り性能を最適化できないと説明している。S3 Files と Lambda の利用例として、スケールするデータ処理パイプラインと、状態を持つエージェント型ワークロードを挙げている。どちらで direct read を有効にするかは、実際に読むファイルサイズと、スループット・レイテンシのどちらを優先するかで判断する。
利用できるのは AWS の全商用リージョンと、AWS GovCloud (US-East)、AWS GovCloud (US-West) だ。対象外として Asia Pacific (New Zealand)、Middle East (Bahrain)、Middle East (UAE) が発表文に明記されている。
設定手段は AWS Management Console、AWS CLI、AWS SDK、AWS CloudFormation。追加料金は、標準の Lambda と S3 Files の料金を超えては発生しないと書かれている。設定に使うパラメータ名や CloudFormation のプロパティ名は、What’s New の本文には出てこない。
S3 Files を読む関数を持っているなら、確認項目は次のとおり。
S3 Files を使っていない関数には、この設定の出番はない。使っている関数でも、効き方が構成条件で分かれるのは Lambda では珍しくない。非同期と ESM で長時間タイムアウトが使える件と同じで、自分の関数がどちらの側にいるかを先に確かめたほうが早い。
