Direct S3 Reads or File-System Storage? Benchmark Lambda Before Switching

A new Lambda control does not remove the old engineering problem: you still have to prove which read path is better for your workload. On September 11, 2026, AWS published AWS Lambda now supports direct read configuration for Amazon S3 Files, announcing explicit enable/disable control for S3 Files direct reads independent of Lambda memory size. AWS says the default behavior continues to use a 512 MB memory boundary, while explicit control lets operators choose direct reads or file-system storage. The announcement also says files of 1 MB or larger can be read directly from the S3 bucket when direct read is enabled.

That sounds simple until you compare the live documentation. The S3 Files performance guide, accessed September 15, 2026, describes large reads of at least 1 MiB, not files of at least 1 MB. The Lambda S3 Files configuration guide, also accessed September 15, 2026, still says direct reads are supported only for functions with 512 MB or more. Those are material discrepancies, not editorial trivia.

The right response is not to guess which sentence will win. It is to build a reversible, workload-specific benchmark for Lambda S3 Files direct reads that separates memory and CPU effects from read-path effects, validates content and permissions, and produces an enable, disable, or hold decision with cost evidence attached.

Define the workload decision before choosing a read path

A Lambda direct read benchmark should start with an operating question, not with a toggle. Write down the workload that will be judged: what files are read, how much of each file is consumed, how frequently those reads occur, whether reads are sequential or sparse, how much concurrency is normal, and what correctness means. A batch transformer that scans 64 MiB from each object has a different decision surface from an API function that opens thousands of small configuration files.

Do the same for service objectives. Define the latency statistic that matters: median, p95, p99, deadline-miss rate or job completion time, and assign a budget owner for any added compute or storage cost. The benchmark is incomplete if the performance engineer can declare “faster” while the FinOps partner cannot say whether the improvement is affordable.

Treat “keep the current behavior” as a first-class outcome. That is standard change-control discipline, consistent with broader cloud development practices: make the change earn its way into production rather than assuming a new control must be used.

The contract should also name the rollback condition. A useful statement is: “We will retain the existing path unless the candidate path meets content-equivalence, permission, latency and cost gates under representative load.” That wording prevents the experiment from becoming a search for evidence supporting a predetermined migration.

Separate the announcement from unresolved documentation

The first readiness task is source reconciliation. As of the September 15, 2026 research cutoff, AWS documentation does not present one perfectly consistent story. The September 11 AWS announcement says explicit direct-read control is independent of function memory, while the live Lambda S3 Files guide still says direct reads are supported only with 512 MB or more. The announcement says “files 1 MB or larger”; the S3 Files performance page says “large reads >= 1 MiB.”

Do not normalize those statements into a single threshold. The S3 Files MB vs MiB issue is real: one is decimal megabytes versus binary mebibytes, and one source refers to file size while the other refers to an individual read operation. In a benchmark near the boundary, both distinctions can change which cases are exercised.

The AWS S3FilesConfig API reference, accessed September 15, 2026, documents S3FilesConfig.DirectS3Read with valid values AUTO, ENABLED and DISABLED. AUTO keeps the 512 MB behavior, while explicit states override the memory-based choice. That resolves the existence of an API member, but not every console, command-line interface or infrastructure-as-code workflow. A readiness dossier should record what has actually been verified rather than filling gaps with plausible syntax.

A further source tension surfaced during verification. The S3FilesConfig API reference describes ENABLED as enforcing reads directly from the S3 bucket, whereas the September 11 AWS announcement says that, when direct read is enabled, files 1 MB or larger are read directly and smaller files are served through high-performance storage. This article does not resolve that wording by inference. Include small-file cases and corroborating path evidence before treating ENABLED as semantically proven for production.

Memory-independent control versus the older support statement

The operational consequence is straightforward: do not use memory changes as a proxy for the new control. The September 11 AWS announcement says explicit control is independent of memory; the older Lambda S3 Files guide, accessed September 15, 2026, says direct reads are supported only from 512 MB upward. Until the guide is reconciled, a test below 512 MB is a documentation-validation case as well as a performance case.

File size in MB versus read size in MiB

The AWS announcement’s 1 MB file-size wording and the performance guide’s 1 MiB read-size wording should become separate fixture dimensions. One megabyte is 1,000,000 bytes; one mebibyte is 1,048,576 bytes. More importantly, a 32 MiB file read in 256 KiB chunks is not the same experimental condition as a 32 MiB file read in 2 MiB chunks. The benchmark must vary both file size and requested read size rather than pretending the source language is interchangeable.

Inventory the current function and storage path

Before changing anything, create a snapshot of the deployed baseline. Record the Lambda function version or alias, memory, architecture, runtime, region, Virtual Private Cloud configuration, S3 Files file system and access point, mount path, security groups, execution role, object set, and the source revision that produced the function code. The objective is reproducibility: another engineer should be able to tell what “baseline” meant after the service has changed twice.

According to the Lambda S3 Files configuration guide, accessed September 15, 2026, AWS currently requires an S3 file system and mount targets in the same account and region as the Lambda function, a Lambda function in the same Virtual Private Cloud as the mount target, and network paths permitting Network File System traffic on port 2049 between the function and mount targets. Those are documented prerequisites, not benchmark recommendations.

Keep deployed evidence separate from documentation defaults. For example, “memory = 1024 MB from GetFunctionConfiguration” is deployed evidence. “AUTO uses a 512 MB boundary” is documented product behavior. Do not merge those into one statement such as “the function is therefore using direct reads” without path evidence.

Versioned capture should fit the same discipline used in infrastructure-from-code delivery: configuration changes belong in reviewable, reproducible artifacts, even when the immediate experiment is controlled manually.

Design a controlled read-path experiment

The proposed experiment is a factorial comparison, not a production benchmark result. This serverless I/O benchmark design is intentionally structured to expose Lambda memory CPU confounding instead of hiding it inside a single before-and-after test. No measurements were collected for this article. The factors are read-path treatment, memory tier, file size, read size, access state and concurrency. Repeated observations within each cell let you estimate distribution shape rather than reporting one fast run.

Use at least two memory settings if your workload could realistically operate at both, but compare direct-read treatments only within the same memory setting. A compact design might use 256 MB and 1024 MB to exercise below/above the documented default boundary, while keeping code, architecture, region and fixtures identical. Those values are proposed test points, not AWS recommendations.

Randomize or interleave treatment order where practical. Running all “disabled” trials at 09:00 and all “enabled” trials after lunch risks time-dependent infrastructure noise. Preserve the full configuration and treatment label with every observation. If a run cannot be tied to an exact configuration state, discard it.

Choose repetition counts from variance, not convenience. Start with a pilot large enough to reveal obvious instability, then size the main run so each matched cell has enough observations to estimate the percentile used by the workload contract. Keep retries visible: an automatic application retry can convert a storage failure into a long successful invocation and distort both latency and cost. Record attempts separately from logical requests.

For concurrent-load controls, use a fixed arrival schedule or a closed-loop worker count and log the achieved concurrency. Do not compare one treatment under a steady 20-reader plateau with another under a burst that briefly reaches 200. If the platform throttles, queues, or scales differently during a run, keep that event in the dataset and classify it rather than silently trimming it away.

Hold memory and CPU allocation constant within a comparison

Lambda memory is a confounder because AWS allocates CPU in proportion to configured memory. The AWS Lambda memory guide, accessed September 15, 2026, documents a range from 128 MB to 10,240 MB and states that 1,769 MB corresponds to roughly one vCPU.

Therefore, “256 MB with direct read disabled” versus “1024 MB with direct read enabled” cannot isolate read-path impact. Direct read memory configuration must remain fixed inside each paired comparison. Any duration difference could come from CPU, memory pressure, networking, decompression, parsing, checksumming or application work. Change one treatment at a time.

Separate first access, warm access and concurrent access

Define first-access operationally rather than claiming you have cleared every cache in the system. A defensible label is “first observed benchmark access after creating a fresh fixture key or otherwise establishing the documented precondition.” Warm access can mean repeated reads of the same immutable fixture within a controlled run. Concurrent access should specify the exact number of simultaneous readers and arrival pattern.

Do not write “cold cache” unless you can prove which cache is cold. The S3 Files performance guide, accessed September 15, 2026, documents longer initial access when metadata or small-file data must be imported. First access is therefore a meaningful state, but it does not prove that every Lambda, kernel, network or service-side cache has been reset.

Choose file and read fixtures that expose the boundary

Synthetic fixtures are preferable for the initial experiment because they remove business-data variability and privacy risk. Generate deterministic binary content, record each file’s exact byte length and SHA-256 checksum, and read known ranges. The fixture set should deliberately straddle 1,000,000 bytes and 1,048,576 bytes so the MB versus MiB wording is tested rather than hand-waved.

Also decouple file size from request size. Include large files read in small chunks and large files read in large chunks. If the performance guide’s read-size wording governs routing, those cases may behave differently despite identical file size. If the announcement’s file-size wording governs the Lambda integration, that distinction may surface differently. The experiment exists to observe, not to pre-select the interpretation.

Those are proposed tests, not vendor-prescribed thresholds. Preserve fixture immutability during a comparison. The S3 Files troubleshooting guidance, accessed September 15, 2026, says recently modified data can be served through the high-performance layer while synchronization proceeds, so writing to fixtures between treatments can change the path you are trying to isolate.

Add offsets as another fixture attribute when the application performs ranged access. Reading 2 MiB from the beginning of an 8 MiB file is not necessarily equivalent, experimentally, to four non-contiguous 512 KiB reads across the same file. The decision record should therefore preserve both logical bytes consumed and the sequence of read calls. That detail helps distinguish “large-file workload” from “large-read workload.”

The same principle appears in good database integration practices: test with controlled data state and understand what the abstraction is doing underneath rather than attributing every latency change to application code.

Verify permissions and the effective configuration

A read-path experiment is invalid if one treatment silently lacks permissions. The Lambda S3 Files configuration guide, accessed September 15, 2026, states that mounting S3 Files requires s3files:ClientMount; read-write connections additionally need s3files:ClientWrite. For direct S3 reads, it lists s3:GetObject and s3:GetObjectVersion.

The S3FilesConfig API reference, accessed September 15, 2026, adds an important behavior: if a direct read fails, Lambda automatically falls back to reading through the file system. That makes permission verification more important, not less. A successful application read does not by itself prove the intended path was used.

Use a read-only prerequisite checklist before changing the setting:

• Capture the execution role and policy versions used by the benchmark function.

• Confirm the fixture prefix is readable through both intended paths without broadening production permissions merely to make the test pass.

• Read back the effective Lambda configuration after every treatment change rather than trusting the submitted request.

• Record file-system, bucket, access-point, VPC and security-group identities with each run.

• Stop if authorization behavior differs between treatments in a way the workload would not accept.

The S3FilesConfig API reference confirms S3FilesConfig.DirectS3Read; however, this article intentionally does not invent console labels, command-line switches or CloudFormation property syntax that were not independently verified at the cutoff. The security posture should follow least-privilege principles consistent with Zero Trust cloud architecture, but that internal reading does not replace AWS documentation for the feature itself.

Measure correctness, latency and resource use together

Latency without correctness is not a result. Every invocation should record the fixture identifier, bytes requested, bytes returned, checksum or content digest, read-phase duration, total handler duration, treatment, memory, access state, concurrency, and success/failure status. If parsing or transformation follows the read, time the read phase separately so application CPU work does not hide path differences.

For Lambda storage performance testing, also retain the platform-reported duration and memory-related telemetry you normally use for the function. The Lambda memory guide documents that increasing memory also increases CPU allocation, so CPU-sensitive post-read work can change the overall handler duration even when storage time is identical.

The S3 Files performance specifications, accessed September 15, 2026, publish metrics including DataReadBytes, DataWriteBytes, MetadataReadBytes and MetadataWriteBytes. Those are useful context, but a documented service ceiling or metric is not the same as measured performance of one Lambda workload.

Use consistent timing boundaries. Start the read timer immediately before the application issues the first filesystem read and stop after the requested bytes are available to the process. If language buffering or decompression is part of the application, decide whether it belongs inside or outside that boundary and keep the decision unchanged.

Record resource saturation signals alongside time. A storage treatment that shortens I/O but exposes a CPU bottleneck may reduce read-phase latency without improving end-to-end duration. Conversely, a treatment that appears slower in the handler may still be preferable if it cuts high-performance-storage charges within an acceptable service objective. The benchmark should make those tradeoffs visible instead of compressing them into one “performance score.”

These measurements are easier to reason about when teams already share observability fundamentals: logs, metrics and traces should answer different questions, and no single latency number should stand in for a causal explanation.

Work through a proposed benchmark decision

The decision method is more important than a fabricated “winner.” Start by grouping observations into matched cells: same memory, same architecture, same fixture, same requested read size, same access-state definition and same concurrency. Compare direct-read enabled versus disabled only inside those cells. AUTO can be retained as a diagnostic control, but it should not replace the explicit A/B pair when the question is whether to force a path.

Summarize each matched cell with count, median, p95, error rate and correctness pass rate. For small samples, avoid over-reading a p99 that is effectively one observation. Plot distributions when possible; a faster median with a worse tail may fail the workload contract.

Compare like-for-like treatments

Suppose an illustrative result set contains 1024 MB enabled runs and 1024 MB disabled runs for the same 8 MiB fixture read in 2 MiB chunks. That is a valid comparison candidate. A 256 MB disabled run cannot be substituted merely because it happened to execute at the same time. AWS Lambda memory documentation shows that memory changes CPU allocation, so it changes more than the read path.

A reasonable local analysis rule is: reject any row pair whose configuration fingerprint differs outside the treatment field. That rule is proposed operating policy, not an AWS requirement.

When the matched data is available, compare both absolute and relative differences. A 5 ms improvement can be important in a 20 ms budget and irrelevant in a ten-minute batch. Likewise, a 15% percentage change can look impressive while sitting inside run-to-run noise. Report confidence intervals or another uncertainty measure appropriate to the sample design, and keep raw observations available for review.

Reject an apparently faster but invalid result

Imagine a deliberately hypothetical case where enabled runs show a 20% lower median read-phase time, but one fixture returns a different checksum, or only the disabled treatment can read the required object version. The correct decision is hold, not “enabled is faster.” Performance cannot compensate for content or authorization mismatch.

Likewise, if “enabled” succeeds only because AWS fell back after a direct-read failure, you have not demonstrated the intended path. The S3FilesConfig API reference explicitly says fallback can occur. Treat ambiguous path evidence as a failed interpretability gate and investigate before canarying.

Calculate workload cost without inventing prices

A Lambda read-path cost comparison belongs in the same experiment record as latency. Do not calculate savings from duration alone. The candidate path can alter Lambda duration, S3 GET request volume, S3 Files high-performance storage residency and S3 Files data-access usage. The September 11 AWS announcement says there is no additional feature charge beyond standard Lambda and S3 Files pricing.

The AWS S3 pricing page, accessed September 15, 2026, describes S3 Files charges for high-performance storage and data access, while reads served directly from S3 incur standard S3 GET request charges and no S3 Files data-access charge for those direct-read bytes. The AWS Lambda Pricing page, also accessed September 15, 2026, separately bases pricing on invocation and execution usage; use the current regional and account billing terms rather than copying a rate into a long-lived runbook.

Use a symbolic worksheet and fill rates only after a dated price verification:

The useful comparison is incremental workload cost:

ΔCost = Cost_enabled − Cost_disabled

Then pair it with the workload benefit, for example Δp95 or reduced job completion time. A FinOps partner can decide whether that trade is acceptable under the owner’s predeclared policy.

Do not assume direct reads are cheaper because they may avoid one S3 Files access charge, and do not assume file-system reads are cheaper because they may reduce Lambda duration. The workload’s request pattern, data residency and execution time determine the answer. Price verification should be performed on the decision date, in the deployment region, with any applicable account discounts or commitments documented separately.

Separate marginal experiment cost from steady-state production cost. The benchmark may intentionally issue more reads, retain extra telemetry, or create synthetic objects that would not exist in production. Charge those activities to the experiment, but do not project them into the steady-state model. For the production estimate, multiply representative per-invocation quantities by the owner-approved traffic forecast and show sensitivity for plausible low and high volumes.

Set owner-approved acceptance and stop gates

Acceptance gates should be written before the benchmark is run. Otherwise, teams tend to move the goalposts after seeing attractive latency numbers. The gates should cover correctness, permissions, path interpretability, latency and cost. Thresholds belong to the workload owner, not to AWS documentation.

A sample local policy might require 100% checksum equivalence in the controlled fixture set, no new authorization failures, no unexplained fallbacks, a p95 improvement of at least a workload-defined margin, and no cost increase above a workload-defined percentage. The specific percentages are intentionally absent here because they would be arbitrary without business context.

Stop immediately on correctness failures. Stop on authorization differences that would require broader permissions than the security owner accepts. Stop if memory changed between paired runs. Stop if concurrent load was uncontrolled enough to invalidate the comparison. And stop if cost crosses the workload owner’s declared ceiling even when latency improves.

A hold is not a failed experiment. It is the correct outcome when evidence is contradictory or incomplete. The direct read documentation discrepancy itself can be a hold reason if your intended deployment depends on behavior that the current authoritative pages describe inconsistently.

Assign each stop gate an owner who has authority to halt the rollout. Correctness typically belongs to the application owner, authorization to the security or platform owner, experimental validity to the performance engineer, and cost to the budget owner. Shared dashboards do not substitute for decision rights. A gate without a named approver tends to become advisory exactly when schedule pressure rises.

Canary the change and preserve a baseline

A laboratory result is not permission for an estate-wide serverless storage rollout. The next step is a narrow canary using the same configuration fingerprinting and acceptance gates. Choose a cohort that is representative enough to expose real traffic behavior but small enough to limit blast radius. Keep the existing configuration available as the baseline and do not remove the instrumentation used in the benchmark.

Before canary traffic begins, verify rather than assume that the previous direct-read state can be restored through the control surface your team actually uses. The S3FilesConfig API reference documents AUTO, ENABLED and DISABLED, but your rollback procedure still needs to be exercised with your deployment tooling and versioning model.

A practical rollout pattern is a baseline, then a small canary, an observation window, an expanded canary and a decision. Each transition should be gated by evidence rather than elapsed time alone. This aligns with the change-and-monitor discipline described in DevOps lifecycle management, while the AWS feature behavior remains grounded in AWS sources.

Do not call a rollback “safe” until it has been tested. A reversible application change is one whose prior state, dependent permissions and infrastructure are still available and whose restoration path has been executed successfully under controlled conditions.

Create a decision record that survives documentation changes

The most valuable artifact is not the benchmark chart; it is the decision record connecting source state, experiment state and ownership. AWS documentation can change after publication, and the feature described in the September 11 announcement was only days old at the research cutoff. Your record should make it obvious which claims were verified on which date and which were local assumptions.

Store the announcement date separately from the documentation access date. The AWS announcement is dated September 11, 2026. The live performance guide, Lambda configuration guide and memory guide do not expose a publication date in the material inspected here, so cite them as living documentation accessed September 15, 2026.

Attach blank-result templates before the run and filled results afterward. Preserve rejected runs with rejection reasons rather than deleting inconvenient data. That makes later review possible when a documentation update changes how you interpret earlier behavior.

Record assumptions in their own field. Examples include “traffic replay is representative of weekday peak,” “fixture keys are immutable for the test window,” or “the effective direct-read setting returned by the control plane reflects invocation behavior.” These statements are not documented product facts. Labeling them as assumptions makes it possible to revisit the conclusion if later evidence disproves one of them.

Trigger reevaluation when AWS reconciles the Lambda guide with the announcement, when the API semantics change, when your workload’s file/read-size distribution shifts, when memory changes materially, when concurrency changes, or when pricing changes enough to alter the cost gate. A benchmark is a dated decision, not a permanent truth.

Run a 30-day evaluation and hand over the result

Thirty days is a proposed operating window, not an AWS requirement. Use it to move from source reconciliation to a constrained canary without letting the experiment drift indefinitely. The schedule should be shortened or extended according to change risk and workload seasonality.

At handover, the platform engineer should own the configuration evidence and rollback mechanism; the performance engineer should own the protocol and statistical comparability; the application owner should own correctness and latency objectives; and FinOps should own the rate verification and budget interpretation. Shared ownership prevents a storage optimization from becoming someone else’s unexplained bill or reliability regression.

Include one short operational briefing with the people who will respond to alarms during the canary. They should know which metrics prove correctness, which signals merely suggest a path change, who can revert, and which anomalies require an immediate stop. The purpose is not ceremony; it is to prevent an on-call engineer from treating an experimental latency spike as an ordinary application incident or, worse, normalizing a correctness warning because the experiment is expected to look different.

For readers building the foundational skills behind this kind of work, the Refonte Learning Cloud Development Program lists a three-month schedule at 12–15 hours per week and covers cloud architecture, infrastructure as code, security, performance monitoring and optimization, DevOps, cost considerations, continuous integration and continuous delivery, and a cloud-application capstone. The page says prior experience is not required and basic programming knowledge is beneficial rather than mandatory. That is relevant as general cloud-development preparation, not as a promise of training on this newly announced Lambda control.

The handover package should contain the baseline snapshot, source discrepancy note, protocol, result tables, cost worksheet, canary evidence, recovery test and the final enable/disable/hold decision. Anything less makes the next engineer repeat the uncertainty you already paid to resolve.

Answer the tuning questions and decide whether to switch

Should I change Lambda memory to test direct reads? No, not inside a read-path A/B comparison. Memory changes CPU allocation, so changing it at the same time creates a confounder. Benchmark each direct-read treatment at fixed memory, then separately evaluate whether another memory setting is better for the whole workload. AWS Lambda memory documentation describes proportional CPU scaling with memory and approximately one vCPU at 1,769 MB.

Is 1 MB the same threshold as 1 MiB? No. The September 11 AWS announcement says files of 1 MB or larger, while the S3 Files performance guide says large reads of at least 1 MiB. The units differ, and so does the measured object: file size versus read size. Preserve both cases in the fixture matrix until AWS documentation is reconciled.

How should I interpret cold and warm results? Treat S3 Files cold and warm reads as experimentally defined states, not universal cache labels. Define observable states rather than claiming universal cache control. Use fresh immutable keys or another documented precondition for first access, repeated reads for warm access and explicit concurrency for load tests. The S3 Files performance guide documents higher first-access latency when it must import metadata or small-file data, but that does not prove every layer of the Lambda execution path is cold.

Is choosing no change a valid result? Yes. If explicit direct reads fail correctness, authorization, path-evidence, latency or cost gates, retaining the current behavior is the disciplined outcome. A hold is also valid when documentation conflict prevents you from proving the intended production state.

The objective of S3 Files read-path tuning is not to discover a universal crossover point. It is to produce a defensible, reversible decision for one workload under one documented configuration and price state. The September 2026 control makes that decision more explicit; it does not make controlled benchmarking optional.

That distinction matters most near the boundaries. A team may ultimately enable direct reads for a sequential analytics Lambda, disable them for a latency-sensitive small-file service, and hold a third workload because path evidence remains ambiguous. Those three decisions can all be technically correct at the same time. A benchmark earns trust by explaining why each result follows from its workload contract, not by forcing one tuning rule across unrelated functions.