A lot of Lambda code that works with S3 is not complicated because the business logic is complicated. It is complicated because the function has to download an object, manage /tmp, process the file, upload the result, and clean up after itself.
The AWS Compute Blog post on modernizing Lambda and S3 workloads with Amazon S3 Files shows a different model: mount an S3-backed file system and let the function use normal file paths.
That sounds small. For many workloads, it changes the shape of the code.
What changed
S3 Files lets a Lambda function mount an S3 bucket as a file system at a path such as /mnt/data. Code can open, read, write, list, and organize files using filesystem operations while S3 remains the durable backing store.
The source article uses examples such as image processing, ETL pipelines, and multi-agent shared workspaces. In each case, the function moves away from explicit S3 transfer code and toward direct file I/O.
That removes a surprising amount of glue:
- no manual download before processing,
- no upload step after writing output,
- less
/tmpcapacity management, - fewer cleanup paths for failed invocations,
- simpler handoffs between functions that share a workspace.
Why builders should care
The strongest use case is modernization of existing file-oriented libraries. Many image, document, ML, and data-processing libraries expect file paths. Without S3 Files, Lambda code often has to adapt object storage into temporary local files before real work can start.
S3 Files lets builders keep file-based code and still use S3 as the storage layer. That can make Lambda more attractive for workloads that previously moved to containers only because file handling became awkward.
The shared workspace pattern is also interesting for AI agents. If multiple Lambda functions collaborate on a session, a directory tree can be easier to reason about than a collection of object keys and serialized state blobs.
The trade-offs
I would not replace every S3 API call with file I/O.
Object APIs are still excellent when you want explicit object boundaries, event-driven processing, presigned URLs, lifecycle policies, replication, and direct control over metadata. File systems are easier for some code, but they can also hide transfer and consistency behavior behind familiar syntax.
Builders should validate:
- throughput for large files,
- behavior under high concurrency,
- consistency expectations between producers and consumers,
- VPC and mount target requirements,
- IAM permissions for mount and write operations,
- failure behavior when a function exits while writing.
Also remember that simpler code is not the same as simpler operations. If many functions share a writable workspace, you need naming conventions, cleanup policies, and safeguards against accidental overwrite.
What to do next
Look for Lambda functions where more code is spent on S3 transfers than on the actual business logic. Image resizing, report generation, data conversion, document processing, and agent workspaces are good candidates.
For each candidate, compare two versions:
- current S3 API flow with
/tmp, - S3 Files flow with mounted paths.
Measure duration, memory, error handling complexity, and cost. The winning design may be different per workload.
The useful takeaway is not that file systems are better than object APIs. It is that Lambda now has a cleaner option when the workload is naturally file-shaped.