Summary

  • AWS has announced a direct-read choice for S3 Files that no longer depends solely on a Lambda function's memory setting.
  • Lower memory, successful execution and a cheaper read path are three different claims that need separate evidence.

A storage preference should not have to masquerade as a request for more computing resources. AWS's September 11 Lambda announcement separates explicit S3 Files direct-read selection from function memory size. For teams tuning file-based workloads, the useful change is a new degree of control—not a demonstrated reduction in cost.

The API offers AUTO, ENABLED and DISABLED settings, and documents a file-system fallback when a direct read fails. Keeping a workload running can be valuable. It also means a successful invocation is not, by itself, evidence that the intended read path carried the work.

One control separates; another coupling remains

Lambda still allocates CPU in proportion to configured memory. A team that uses the new option to reduce memory may therefore change both its storage preference and its computing resources. Any resulting duration change belongs in the comparison.

The elementary arithmetic is useful. If allocated memory halves while billed duration doubles, their product has not fallen. That is an illustration, not an AWS benchmark. Standard Lambda Functions billing includes requests and memory-weighted duration, so a smaller memory number cannot settle the savings question.

Storage adds a different set of meters. S3 Files distinguishes file-system data access from direct streams, which still incur S3 GET and metadata-read charges. Avoiding one kind of file-read charge is not the same as making the operation free. A buyer should compare the total cost of a correct completed task, including the storage activity it causes.

A setting is not a trace

The documentation also leaves a boundary worth recording. The launch announcement describes routing by file size, whereas the API description uses broader language for ENABLED, referring to all reads. Those descriptions should not be silently collapsed into one verified per-operation rule. No runtime test was performed for this report.

That does not erase the common point of the announcement and API: an explicit read preference is now exposed independently of memory. It does limit what can be concluded about the precise path taken by a mixed workload from the flag alone.

An application reading many small items and another streaming a large dataset need not choose the same setting. These are illustrative workload types, not measured customer outcomes. The team needs to see where time goes and which charges move. Otherwise a storage optimisation can become an unrecognised compute slowdown, or a successful fallback can conceal why a comparison changed.