Testing read and write performance with S3 Files from AWS Lambda
I compared read and write performance between the S3 SDK and S3 Files when accessing Amazon S3 from AWS Lambda.
Is S3 Files faster than the S3 SDK when reading files from AWS Lambda?
In April 2026, AWS Lambda added support for mounting Amazon S3 Files. With S3 Files, objects in an Amazon S3 bucket can be handled as files from a local mount path inside a Lambda function.
Until now, the common approach was to use an AWS SDK to get and put S3 objects. Another option was to mount Amazon EFS when a file system interface was required.
In this article, I compare how much performance difference appears when Lambda reads and writes files through two approaches:
- Non-VPC Lambda + S3 SDK
- Lambda + S3 Files
Note: This article summarizes one benchmark design and its results. Actual results can vary depending on the environment, Region, Lambda memory size, file size, concurrency, VPC configuration, and access patterns.
What is S3 Files?
Amazon S3 Files lets you access data in an S3 bucket as a file system. S3 is usually used as object storage, so the important point is that S3 Files gives you a file system interface while keeping S3 as the underlying storage.
According to the documentation, S3 Files "intelligently translates" file system operations into efficient S3 requests on behalf of the user.
For files smaller than a certain size, 128 KiB by default, S3 Files can import them into high-performance storage. This can improve read latency. On the other hand, when files are not stored in high-performance storage, or when a read is 1 MiB or larger, S3 Files reads directly from the S3 bucket.
What I tested
I compared two configurations.
| Configuration | Description | Purpose |
|---|---|---|
| A | Non-VPC Lambda + S3 SDK | Baseline for the simplest S3 access pattern |
| B | Lambda + S3 Files | Newer pattern where S3 is mounted as a file system |
I looked at three main questions:
- Small file reads: Does S3 Files low-latency access help?
- Large file reads: How does it compare with the S3 SDK for reads of 1 MiB or larger?
- Writes: How different are file writes and S3
PutObjectcalls?
The S3 Files configuration includes a VPC and mount targets. This means the comparison is not only "S3 API versus file I/O"; it also includes architectural differences between the two setups.
I used a 64 KiB file as the small file and a 16 MiB file as the large file. For each pattern, I measured single reads and single writes. I looked at
min, avg, p50, p90, p99, and max, instead of relying only on averages.Configurations
A. Non-VPC Lambda + S3 SDK
This is a normal Lambda function that is not connected to a VPC. It accesses S3 by using the AWS SDK.
If your function only needs to read and write S3 objects, this is the simplest baseline.
B. Lambda + S3 Files
This Lambda function mounts S3 Files and reads or writes files under a path such as
/mnt/s3files.When using S3 Files with Lambda, the Lambda function must be placed in the same VPC as the mount target. A mount target is also required for each subnet where the function runs.
The Lambda documentation says that direct reads from S3 for S3 Files are supported only for functions configured with 512 MB or more of memory:
Amazon S3 Files optimizes throughput by reading directly from Amazon S3. Direct reads from Amazon S3 are supported only for functions configured with 512 MB or more of memory.
Reference: Using Amazon S3 Files with AWS Lambda
For this benchmark, I configured both functions with 512 MB of memory.
Note: After running this test, I realized that a third pattern, VPC Lambda + S3 SDK, would also be useful to measure. This article compares only the two configurations above.
Benchmark environment
| Item | Value |
|---|---|
| Region | ap-northeast-1 |
| Lambda runtime | Python 3.14 |
| Lambda architecture | arm64 |
| Lambda memory | 512 MB |
| S3 storage class | S3 Standard |
| Small file size | 64 KiB |
| Large file size | 16 MiB |
| Metrics | min / avg / p50 / p90 / p99 / max |
Measurement method
Inside each Lambda function, I measured the elapsed time immediately before and after the file operation or S3 API call.
The total Lambda
Duration includes initialization, logging, and other overhead, so the main comparison in this article focuses on the read and write operation itself.Each pattern used the following settings:
| Test | Iterations |
|---|---|
| Single read | 100 measured samples |
| Single write | 100 measured samples |
The functions were invoked with
iterations=105 and warmup=5. The first five iterations were excluded from aggregation. These warmup iterations are not meant to remove Lambda cold start time. They are only used to remove the first few fluctuations inside the read or write loop.For p99, more samples would be ideal. I used 100 measured samples here to balance cost and effort while still seeing the overall trend.
Test patterns
Reads
| ID | Description | Size | Files | Measured samples |
|---|---|---|---|---|
| R1 | Single small-file read | 64 KiB | 1 | 100 |
| R2 | Single large-file read | 16 MiB | 1 | 100 |
S3 Files can behave differently on the first access and repeated accesses, so I also tested a "unique file per iteration" read pattern.
Writes
| ID | Description | Size | Files | Measured samples |
|---|---|---|---|---|
| W1 | Single small-file write | 64 KiB | 1 | 100 |
| W2 | Single large-file write | 16 MiB | 1 | 100 |
For writes, keep in mind that S3 Files separates the write to the mounted file system from the background export to the S3 bucket.
S3 Files setup
I followed the prerequisites in the S3 Files documentation for mounting S3 Files on Lambda:
Create a VPC
I created a VPC with one private subnet.
Create an S3 bucket
Before creating the file system, I created the S3 bucket that would be linked to S3 Files.
Create the S3 file system
Next, I created the S3 file system.
When I selected the bucket, the console indicated that bucket versioning was required, so I enabled versioning.
Then I selected the VPC and created the file system.
Mount target
When I tried to create a mount target, it had already been created automatically.
Access point
An access point was also created automatically. In my setup, the root directory path was
/lambda.
Security groups
I configured security groups for the mount target and the VPC Lambda function.
- The mount target security group allowed inbound NFS traffic on port 2049.
- The Lambda security group allowed outbound NFS traffic on port 2049.
Results
I aggregated 100 log records per pattern with CloudWatch Logs Insights.
R1. Single 64 KiB read
| Configuration | min | avg | p50 | p90 | p99 | max | Notes |
|---|---|---|---|---|---|---|---|
| Non-VPC Lambda + S3 SDK | 21.2 ms | 25.4 ms | 24.8 ms | 27.7 ms | 40.0 ms | 57.0 ms | S3 GetObject |
| Lambda + S3 Files | 1.8 ms | 2.0 ms | 2.0 ms | 2.2 ms | 2.4 ms | 2.5 ms | open().read() from /mnt/s3files |
For 64 KiB reads, S3 Files was much faster. At p50, it was about 12 times faster. At p99, it was about 16 times faster.
Because S3 Files can import small files into high-performance storage, that low-latency path seems to be very effective for this repeated-read condition.
R1 add-on. Reading a different 64 KiB file every iteration
Repeatedly reading the same file may benefit from caching. To separate that effect, I also tested reading a different file in every iteration.
| Configuration | min | avg | p50 | p90 | p99 | max | Notes |
|---|---|---|---|---|---|---|---|
| Non-VPC Lambda + S3 SDK | 34.9 ms | 55.4 ms | 53.8 ms | 68.2 ms | 104.6 ms | 112.3 ms | Different S3 object per iteration |
| Lambda + S3 Files | 2.2 ms | 2.4 ms | 2.4 ms | 2.5 ms | 2.7 ms | 2.7 ms | Different file per iteration |
Even when reading different 64 KiB files, S3 Files was still much faster. At p50, it was about 23 times faster. At p99, it was about 39 times faster.
This suggests that S3 Files is a good fit for workloads that read many small files.
R2. Single 16 MiB read
| Configuration | min | avg | p50 | p90 | p99 | max | Notes |
|---|---|---|---|---|---|---|---|
| Non-VPC Lambda + S3 SDK | 171.2 ms | 204.9 ms | 172.5 ms | 281.5 ms | 300.4 ms | 303.0 ms | S3 GetObject |
| Lambda + S3 Files | 4.3 ms | 10.5 ms | 14.8 ms | 15.8 ms | 19.9 ms | 19.9 ms | open().read() from /mnt/s3files |
For repeated reads of the same 16 MiB file, S3 Files was also much faster. At p50, it was about 12 times faster. At p99, it was about 15 times faster.
However, this condition repeatedly reads the same file inside the same Lambda invocation. It is very likely that caching in S3 Files or the execution environment strongly affected this result. So I also tested reading a different large file every iteration.
R2 add-on. Reading a different 16 MiB file every iteration
This additional test used the same
iterations=105 and warmup=5 settings.| Configuration | min | avg | p50 | p90 | p99 | max | Notes |
|---|---|---|---|---|---|---|---|
| Non-VPC Lambda + S3 SDK | 171.3 ms | 206.5 ms | 179.7 ms | 270.2 ms | 284.3 ms | 292.1 ms | Different S3 object per iteration |
| Lambda + S3 Files | 1,751.5 ms | 2,331.2 ms | 1,776.2 ms | 5,269.6 ms | 5,290.7 ms | 5,299.1 ms | Different file per iteration |
Under this condition, the S3 SDK was much faster.
This makes the earlier "S3 Files is very fast when repeatedly reading the same large file" result look like a cache-friendly case. When reading different large files each time, the S3 SDK may be more stable and easier to reason about.
W1. Single 64 KiB write
| Configuration | min | avg | p50 | p90 | p99 | max | Notes |
|---|---|---|---|---|---|---|---|
| Non-VPC Lambda + S3 SDK | 31.4 ms | 38.2 ms | 37.5 ms | 41.9 ms | 52.9 ms | 76.9 ms | S3 PutObject |
| Lambda + S3 Files | 12.4 ms | 13.4 ms | 13.4 ms | 14.1 ms | 15.3 ms | 17.1 ms | write() + flush() + fsync() |
For 64 KiB writes, S3 Files was faster and had less variance.
However, this does not mean that S3 Files always persists data to S3 faster than
PutObject.The S3 SDK measurement includes sending a
PutObject request to S3 and waiting for the response. The S3 Files measurement waits until the write is completed from the Lambda function's view of the mounted file system. S3 Files exports file changes to the S3 bucket after writes stop, with a delay before export. Therefore, these two completion points are not exactly the same.For small writes, fixed overhead such as API calls and HTTP communication can be a larger part of the total time, so S3 Files can appear much faster in this measurement.
W2. Single 16 MiB write
| Configuration | min | avg | p50 | p90 | p99 | max | Notes |
|---|---|---|---|---|---|---|---|
| Non-VPC Lambda + S3 SDK | 168.8 ms | 196.8 ms | 187.0 ms | 246.9 ms | 274.4 ms | 302.5 ms | S3 PutObject |
| Lambda + S3 Files | 147.5 ms | 198.1 ms | 190.1 ms | 240.6 ms | 286.3 ms | 298.4 ms | write() + flush() + fsync() |
For 16 MiB writes, the S3 SDK and S3 Files were very close. The advantage seen with small writes did not appear as clearly for large writes.
Summary of results
| Test | Condition | Faster configuration | More stable p99 | Comment |
|---|---|---|---|---|
| 64 KiB read | Same file repeatedly | Lambda + S3 Files | Lambda + S3 Files | S3 Files low-latency access was very effective |
| 64 KiB read | Different file each iteration | Lambda + S3 Files | Lambda + S3 Files | S3 Files was still fast for many small files |
| 16 MiB read | Same file repeatedly | Lambda + S3 Files | Lambda + S3 Files | Likely a cache-friendly condition |
| 16 MiB read | Different file each iteration | Non-VPC Lambda + S3 SDK | Non-VPC Lambda + S3 SDK | S3 SDK was faster and more stable |
| 64 KiB write | Single write | Lambda + S3 Files | Lambda + S3 Files | S3 Files looked faster for small writes, but completion semantics differ |
| 16 MiB write | Single write | Almost equal | Non-VPC Lambda + S3 SDK | p50 and avg were similar; S3 SDK had slightly better p99 |
From these results, S3 Files looks strong for small-file reads and repeated reads of the same file. On the other hand, for reading different large files, the S3 SDK was faster and more predictable in this test.
How I would choose
I would not choose only by raw speed. I would choose based on the workload.
| Use case | Candidate |
|---|---|
| Simply reading and writing S3 objects | S3 SDK |
| Using a library that expects file paths | S3 Files |
| Keeping S3 as the source of truth while using file system semantics | S3 Files |
| Sharing a workspace across multiple Lambda functions | S3 Files or Amazon EFS |
If the workload is just basic object reads and writes, the S3 SDK is still very strong. It is also simpler because it does not require a VPC or mount targets.
S3 Files is valuable because it lets you treat S3 data as files. That can be useful when moving existing file-based processing to Lambda, or when you want a shared working directory for workflows such as AI agents that create, update, and pass files between multiple steps.
Conclusion
This benchmark compared S3 SDK and S3 Files for single reads and writes of small and large files from Lambda.
S3 Files gives Lambda a new option: handling S3-backed data through a file system interface. But I would not think of it as a simple drop-in replacement for the S3 SDK.
Instead, S3 Files is best understood as an option for getting file system usability while keeping S3 as the backing store.
References
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article