Stop Downloading S3 Files into /tmp: How Lambda’s New S3 Files Read Path Changes File Processing

Lambda file processing often means downloading S3 objects into /tmp before doing any real work. Amazon S3 Files changes that model by exposing S3 through a filesystem interface, while Lambda can now control whether reads use S3 Files storage or stream directly from S3. This practical guide explains the architecture, setup, read-path behavior, troubleshooting, security, cost, and when the traditional S3 API is still the better choice.

Uchit Agrawal

Aspiring Data Engineer | AWS Cloud | SQL, Python & Data Analytics | B.Tech CSE Student

Published Oct 4, 2026

Last modified Oct 4, 2026

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# Stop Downloading S3 Files into /tmp: How Lambda’s New S3 Files Read Path Changes File Processing

There is a familiar pattern in Lambda-based file processing:

```text
Amazon S3
    ↓
download object
    ↓
/tmp
    ↓
process file
    ↓
upload result
    ↓
Amazon S3

It works. But sometimes the actual problem is not processing the file — it is moving the file around first.

That is where Amazon S3 Files becomes interesting.

AWS launched Amazon S3 Files in April 2026, allowing compute workloads to access S3 data through a filesystem interface. Lambda support followed shortly after. Then, on September 11, 2026, AWS added configurable direct S3 reads for Lambda functions using S3 Files.

That last change is particularly interesting because the question is no longer simply:

“Can Lambda access an S3 object as a file?”

It can.

The better question is:

Where should Lambda read that file from, and which access pattern makes the most sense for the workload?

This article focuses on that decision.

The Problem with the Traditional `/tmp` Pattern

A common Lambda workflow looks like this:

1
2
3
4
5
6
7
8
9
10
11
S3 object
   ↓
download
   ↓
/tmp/file.csv
   ↓
Python / application
   ↓
result
   ↓
upload to S3

For a small object, this can be completely reasonable.

For file-heavy workloads, however, the application now has to manage another layer:

downloading the input
using ephemeral storage
checking available /tmp space
processing the local copy
uploading the result
cleaning up temporary data
handling failures during transfers

Lambda provides configurable ephemeral storage in /tmp, but increasing local storage does not eliminate the data-transfer step.

There is also a programming-model problem.

Many tools naturally expect a file path:

1
with open("/some/path/data.csv", "rb") as file:    ...

while S3 naturally exposes objects through APIs.

That often creates this bridge:

1
2
3
4
5
Object storage
      ↓
local copy
      ↓
filesystem-based application

Amazon S3 Files changes that bridge.

What Amazon S3 Files Changes

Amazon S3 Files provides a filesystem interface over data stored in Amazon S3.

Conceptually:

1
2
3
4
5
6
7
                  Amazon S3
                     ↕
                 S3 Files
                     ↕
              /mnt/data in Lambda
                     ↕
                 Application

The application can use normal file operations instead of explicitly downloading every object first.

For example:

1
from pathlib import Pathpath = Path("/mnt/data/incoming/sales.csv")with path.open("rb") as file:    data = file.read()

The important part is not the open() call itself.

The important part is that the application can continue to use filesystem semantics while the underlying data remains in S3.

S3 Files maintains a filesystem view of the linked S3 bucket and synchronizes changes between the filesystem and S3.

That means S3 Files is not simply:

1
S3 → copy the entire bucket to a filesystem

Instead, data remains associated with S3 while applications can interact with it through standard filesystem operations.

The Part That Makes S3 Files More Interesting: Read Routing

The newest Lambda capability is configurable direct S3 reads.

Lambda supports:

1
2
3
AUTO
ENABLED
DISABLED

`AUTO`

This is the default.

Direct reads are active for Lambda functions configured with 512 MB or more of memory.

`ENABLED`

Direct reads are enabled regardless of the function's memory configuration.

`DISABLED`

Reads are routed through the S3 Files high-performance storage layer.

When direct reads are enabled, files 1 MB or larger are read directly from Amazon S3 for maximum throughput, while smaller files are served through the high-performance storage layer.

If a direct read fails, Lambda can fall back to reading through the S3 Files filesystem.

So the mental model becomes:

1
2
3
4
5
6
7
8
9
                    Lambda
                       │
                   /mnt/data
                       │
                ┌──────┴──────┐
                │             │
                ▼             ▼
       S3 Files storage     Amazon S3
       low-latency path    direct reads

That is a much more useful way to think about S3 Files.

The application sees a file.

The underlying read path can be different.

Why This Matters for Data Engineering

Consider two workloads.

Workload 1: Small, frequently accessed files

Imagine a Lambda function repeatedly reads:

1
2
3
4
5
config.json
schema.json
rules.json
lookup.csv
metadata.json

The filesystem layer is useful because the application wants normal file semantics and frequently accesses relatively small files.

Workload 2: Large sequential data

Now imagine:

1
sales_2026_09.csv

containing a large dataset that is processed sequentially.

For this kind of workload, direct reads from S3 can be useful because AWS can serve eligible large reads directly from S3 for higher throughput.

This is why direct S3 reads are important.

The application does not necessarily have to choose between:

1
filesystem

and:

1
S3

at the application-code level.

S3 Files can expose the filesystem interface while the underlying read path is optimized for the workload.

A Practical Architecture

A simple event-driven processing architecture can look like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
                    Amazon S3
              ┌──────────────────┐
              │   incoming/      │
              │    *.csv         │
              └────────┬─────────┘
                       │
                 ObjectCreated
                       │
                       ▼
               ┌───────────────┐
               │    Lambda     │
               │    in VPC     │
               └───────┬───────┘
                       │
                 S3 Files mount
                       │
                       ▼
                  /mnt/data
                       │
                       ▼
                 Process file
                       │
                       ▼
                processed/*.csv
                       │
                       ▼
                    Amazon S3

A simple and important design choice is to separate the input and output locations:

1
2
incoming/
processed/

That makes the event flow easier to reason about.

For example:

1
2
3
4
5
incoming/orders.csv
        ↓
      Lambda
        ↓
processed/orders.csv

This is preferable to triggering Lambda from every object creation and then writing more objects into the same unfiltered event source.

Lambda also has recursive invocation detection, but event filtering should still be your primary design safeguard.

Setting Up Lambda

Before configuring the Lambda function, create an Amazon S3 file system and the required access point and mount-target resources.

For Lambda, the function must be configured to use the appropriate VPC and be able to reach the S3 Files mount target.

S3 Files uses NFS connectivity, with TCP port 2049 used for the NFS path.

The basic network relationship is:

1
2
3
4
5
Lambda
  │
  │ TCP 2049
  ▼
S3 Files mount target

A blocked NFS path can make an otherwise correct filesystem configuration fail.

AWS also states that a Lambda function can use either Amazon EFS or Amazon S3 Files, but not both at the same time.

Preparing the S3 Bucket

S3 Files requires S3 Versioning to be enabled on the linked bucket.

You can enable it with:

1
2
3
aws s3api put-bucket-versioning \
  --bucket YOUR_BUCKET_NAME \
  --versioning-configuration Status=Enabled

YOUR_BUCKET_NAME is a placeholder.

The bucket must also use server-side encryption with either SSE-S3 or SSE-KMS.

IAM Permissions

For a Lambda function that needs read-write access through S3 Files, AWS documents permissions including:

1
2
s3files:ClientMount
s3files:ClientWrite

For direct reads from the S3 bucket, the execution role also needs:

1
2
s3:GetObject
s3:GetObjectVersion

A simplified example is:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "S3FilesAccess",
      "Effect": "Allow",
      "Action": [
        "s3files:ClientMount",
        "s3files:ClientWrite"
      ],
      "Resource": "*"
    },
    {
      "Sid": "S3DirectRead",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:GetObjectVersion"
      ],
      "Resource": "arn:aws:s3:::YOUR_BUCKET_NAME/incoming/*"
    }
  ]
}

YOUR_BUCKET_NAME is a placeholder.

In production, narrow permissions to the resources and prefixes the function actually needs.

The important lesson is that mounting the filesystem and reading directly from S3 are related but distinct permission requirements.

Mounting S3 Files in Lambda

From the Lambda console:

1
2
3
4
5
6
Lambda
→ Function
→ Configuration
→ File systems
→ Add file system
→ S3 Files

Configure:

1
2
3
4
S3 file system
Access point
Local mount path
Direct S3 Reads

A valid local mount path starts with:

1
/mnt/

For example:

1
/mnt/data

Once configured, Lambda can access the mounted filesystem from the function.

A Simple File-Based Lambda Example

The following example intentionally uses Python's standard library.

The important part is that the function reads the file identified by the S3 event instead of hardcoding a filename.

1
import csvfrom pathlib import Pathfrom urllib.parse import unquote_plusMOUNT_PATH = Path("/mnt/data")INPUT_PREFIX = "incoming/"OUTPUT_PREFIX = "processed/"def clean_csv(source: Path, destination: Path) -> int:    destination.parent.mkdir(parents=True, exist_ok=True)    rows_written = 0    with source.open(        "r",        newline="",        encoding="utf-8"    ) as input_file, destination.open(        "w",        newline="",        encoding="utf-8"    ) as output_file:        reader = csv.reader(input_file)        writer = csv.writer(output_file)        for row_number, row in enumerate(reader):            cleaned_row = [                value.strip()                for value in row            ]            if row_number == 0:

The important thing here is what the code does not contain.

For this filesystem-based processing path, there is no:

1
s3.download_file(...)

before processing.

There is also no:

1
s3.upload_file(...)

after processing.

The application works with file paths exposed by the S3 Files mount.

That is the programming-model improvement S3 Files is designed to provide.

An Important Synchronization Detail

This is probably the easiest behavior to misunderstand.

Suppose the Lambda function writes:

1
/mnt/data/processed/result.csv

That does not necessarily mean another system using the S3 API will observe the corresponding object at exactly the same moment.

S3 Files synchronizes filesystem changes back to the S3 bucket asynchronously.

AWS documents a 60-second period of write inactivity before changes are exported back to S3.

For example:

1
2
3
4
5
6
7
8
9
Lambda writes file
       ↓
S3 Files filesystem
       ↓
60 seconds of write inactivity
       ↓
S3 synchronization
       ↓
S3 object

This has an important architectural consequence.

If your downstream workflow requires another service to consume the resulting S3 object immediately after the filesystem write, the traditional S3 API may still be the simpler choice.

S3 Files solves a filesystem-access problem.

It does not remove the need to understand synchronization semantics.

Changes Made Directly in S3

The synchronization works in the other direction as well.

When another application adds, modifies, or deletes objects through S3, S3 Files reflects those changes in its filesystem view.

AWS documents that S3-side changes can take time to appear through the filesystem view.

Also, if a file has been removed from the active high-performance storage layer, S3 Files can retrieve the latest version from S3 when the file is accessed again.

That means an application should not assume:

1
2
3
S3 PUT
=
filesystem immediately updated

For workloads that depend on filesystem visibility, bounded retries and explicit error handling are safer than assuming instant synchronization.

One More Performance Detail: First Access Is Different

There is another behavior worth knowing before benchmarking S3 Files.

S3 Files can import metadata for files when a directory is first accessed, and small files can be brought into the high-performance storage layer according to the configured import behavior.

That means the first access to a directory can behave differently from later accesses.

For performance testing, separate:

1
cold / first access

from:

1
warm / repeated access

Otherwise, a benchmark may mix filesystem initialization work with steady-state application performance.

Common Problems and Troubleshooting

Problem 1: The filesystem does not mount

Start with:

1
2
3
4
5
6
IAM permissions
VPC configuration
Mount targets
Security groups
Access point
Filesystem state

For Lambda, the function must be able to reach the S3 Files access point over the required network path.

AWS exposes specific Lambda errors such as:

1
2
3
S3FilesMountFailureException
S3FilesMountConnectivityException
S3FilesMountTimeoutException

These can help distinguish permissions, connectivity, and timeout-related failures.

Problem 2: NFS connectivity fails

Check TCP port:

1
2049

The relevant security groups need to allow traffic between Lambda and the S3 Files mount target.

A filesystem can exist correctly while the network path prevents Lambda from mounting it.

Problem 3: Direct reads are not working

Check:

1
DirectS3Read

and verify:

1
2
s3:GetObject
s3:GetObjectVersion

are available to the Lambda execution role.

Remember the three modes:

1
2
3
AUTO
ENABLED
DISABLED

Also remember that direct reads require the Lambda function to have network access to S3.

Problem 4: The application sees permission errors

There can be multiple authorization layers:

1
2
3
4
5
6
7
IAM and resource policies
        +
S3 Files client permissions
        +
Access point configuration
        +
POSIX permissions

A successful mount does not automatically mean every file operation is permitted.

Keep the access boundary as narrow as possible.

Problem 5: The file exists in S3 but is not immediately visible through the mount

Check synchronization timing.

S3 Files reflects S3-side changes into the filesystem asynchronously.

A bounded retry strategy is often better than assuming immediate visibility.

For example:

1
import timefrom pathlib import Pathdef wait_for_file(path: Path, timeout_seconds: int = 30):    deadline = time.monotonic() + timeout_seconds    while not path.exists():        if time.monotonic() >= deadline:            raise FileNotFoundError(                f"File did not appear: {path}"            )        time.sleep(1)

The important part is the timeout.

A retry loop should eventually fail rather than waiting forever.

Problem 6: You wrote the output file, but the S3 object is not there yet

Check the synchronization behavior.

Filesystem writes are exported back to S3 after the write-inactivity period.

AWS also provides CloudWatch metrics for monitoring S3 Files activity and synchronization health.

A growing PendingExports value can indicate that filesystem changes are being generated faster than they are being synchronized.

A non-zero ExportFailures value indicates exports that need attention.

Security Considerations

S3 Files introduces a filesystem interface, but that should not be treated as unrestricted access to the entire bucket.

A better model is:

1
2
3
4
5
6
7
Lambda
  ↓
specific access point
  ↓
specific filesystem scope
  ↓
required S3 data

Use least-privilege IAM.

Restrict NFS network access.

Use access points and filesystem policies where appropriate.

Also remember that POSIX permissions affect filesystem access.

A production workload should deliberately define:

1
2
3
4
Who can mount?
What can they read?
What can they write?
Which prefix can they access?

Another important consideration is concurrent modification.

If the same data is being modified through both the filesystem and directly through S3 at the same time, S3 Files has defined conflict behavior and treats the S3 bucket as the source of truth for conflicts.

The simplest design is to designate one path as the primary writer for a given dataset.

Cost Considerations

One of the biggest mistakes would be to assume:

“S3 Files must always be cheaper than the S3 API.”

That is not a safe assumption.

The cost profile depends on the workload.

S3 Files provides a high-performance storage layer for actively used data, while eligible large reads can be served directly from S3.

That means different workloads can exercise different parts of the architecture:

1
2
3
small / latency-sensitive access
        ↓
high-performance storage

versus:

1
2
3
large sequential reads
        ↓
direct S3 reads

S3 Files also meters file-system operations, so many small reads and writes can have a different cost profile from larger I/O operations.

Before estimating production cost, check the current AWS pricing documentation rather than copying a price from an older article.

A good practice is to measure your actual access pattern first and then model the cost.

S3 Files vs the Traditional S3 API

This is where the architecture decision becomes clearer.

Approach	Good fit	Main trade-off
S3 API / SDK	Straightforward object reads and writes	Application explicitly manages object I/O
S3 Files	File-oriented applications and workloads that benefit from filesystem semantics	Adds VPC, NFS, access-control, and synchronization considerations
Amazon EFS	Traditional shared filesystem requirements	Separate filesystem/storage architecture
AWS Glue	Larger-scale distributed ETL workloads	More infrastructure and orchestration

The wrong question is:

“Is S3 Files better than S3?”

The better question is:

“Does my application benefit enough from filesystem semantics to justify the additional architecture?”

That is a much more useful decision.

When S3 Files Is a Strong Fit

S3 Files is particularly interesting when the application already expects files.

Examples include:

1
2
3
4
5
6
Document processing
File-oriented Python applications
Machine learning preprocessing
Shared working data
Tools that expect filesystem paths
Multi-step workloads working on common files

It can also simplify workloads where multiple compute functions need access to shared data through the same filesystem interface.

Instead of implementing custom download-and-upload logic in every function, the functions can work against a common filesystem abstraction.

When the S3 API Is Still Better

The normal S3 API is not obsolete.

Suppose your Lambda does exactly this:

1
2
3
4
5
6
7
Receive one object
     ↓
Read it
     ↓
Transform it
     ↓
Write one result object

In that case, using the S3 SDK may still be the cleanest architecture.

There is no reason to add filesystem infrastructure when the application already fits the object model naturally.

A newer feature is not automatically the correct feature.

When Lambda Is Not the Right Processing Engine

There is another question worth asking before optimizing the file-access layer:

Should this processing happen in Lambda at all?

For lightweight event-driven processing, Lambda is a natural option.

For larger distributed data transformations, a service designed for data processing may be more appropriate.

For example:

1
2
3
Lightweight event-driven processing
            ↓
          Lambda

while:

1
2
3
Large distributed ETL
            ↓
      AWS Glue / EMR

The storage interface and the compute engine are separate architecture decisions.

S3 Files can make file access easier.

It does not turn Lambda into a distributed ETL platform.

The Architectural Shift

The traditional model is:

1
2
3
4
5
6
7
8
9
10
11
S3
 ↓
download
 ↓
/tmp
 ↓
process
 ↓
upload
 ↓
S3

The S3 Files model is:

And reads can use different paths:

1
2
3
4
5
6
7
                File read
                    │
             ┌──────┴──────┐
             │             │
             ▼             ▼
       S3 Files layer   Direct S3 read
        low latency     high throughput

That is the real reason this feature is interesting.

The application can remain file-oriented without requiring the developer to manually copy every object into ephemeral local storage.

Key Takeaways

The main lesson is not:

“Never use /tmp again.”

/tmp is still useful.

The better lesson is:

Do not move data simply because the application wants a file interface.

S3 Files provides a filesystem interface while keeping the durable data in S3.

The newer direct-read capability adds another important layer:

1
2
3
4
5
Filesystem interface
        +
Multiple read paths
        +
S3 as durable storage

But that flexibility comes with real engineering considerations:

VPC and NFS connectivity
IAM permissions
Access points
POSIX permissions
Direct S3 read configuration
Filesystem-to-S3 synchronization
Cost
Choosing the right compute service

The most important thing is to understand the workload before choosing the abstraction.

Conclusion

Lambda file processing has traditionally involved a lot of data movement:

1
S3 → /tmp → process → S3

Amazon S3 Files changes the programming model by letting Lambda work with S3 data through a filesystem interface.

The September 2026 direct-read capability makes the design even more interesting because Lambda can use S3 Files storage or directly read eligible large files from S3 depending on configuration and workload.

But the best architecture is not automatically the newest one.

For a simple object-processing function, the S3 API may remain the cleanest choice.

For a file-oriented workload, S3 Files can remove an entire class of download, upload, and local-staging logic.

The real engineering question is not:

“Can I use S3 Files?”

It is:

“Does my workload benefit from a filesystem interface enough to make S3 Files the right abstraction?”

That is the decision worth testing.

Discussion

Have you encountered a Lambda workload where downloading S3 objects into /tmp became more complicated than the actual processing?

For a production data pipeline, would you choose the S3 API, S3 Files, or AWS Glue — and what would drive your decision?

1
2

The key claims in this version are supported by current AWS material: S3 Files and Lambda integration, `DirectS3Read` behavior, 1 MB threshold, VPC/NFS requirements, IAM permissions, Versioning/encryption prerequisites, synchronization behavior, and conflict handling. :chatgpt-content-reference{index="1"}

# aws-lambda # amazon-s3 # serverless # data-engineering # data-processing

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.

Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article

Builder Center

Stop Downloading S3 Files into /tmp: How Lambda’s New S3 Files Read Path Changes File Processing

Uchit Agrawal

The Problem with the Traditional /tmp Pattern

What Amazon S3 Files Changes

The Part That Makes S3 Files More Interesting: Read Routing

AUTO

ENABLED

DISABLED

Why This Matters for Data Engineering

Workload 1: Small, frequently accessed files

Workload 2: Large sequential data

A Practical Architecture

Setting Up Lambda

Preparing the S3 Bucket

IAM Permissions

Mounting S3 Files in Lambda

A Simple File-Based Lambda Example

An Important Synchronization Detail

Changes Made Directly in S3

One More Performance Detail: First Access Is Different

Common Problems and Troubleshooting

Problem 1: The filesystem does not mount

Problem 2: NFS connectivity fails

Problem 3: Direct reads are not working

Problem 4: The application sees permission errors

Problem 5: The file exists in S3 but is not immediately visible through the mount

Problem 6: You wrote the output file, but the S3 object is not there yet

Security Considerations

Cost Considerations

S3 Files vs the Traditional S3 API

When S3 Files Is a Strong Fit

When the S3 API Is Still Better

When Lambda Is Not the Right Processing Engine

The Architectural Shift

Key Takeaways

Conclusion

Discussion

The Problem with the Traditional `/tmp` Pattern

`AUTO`

`ENABLED`

`DISABLED`