POSIX Filesystem Access Over S3 Without Touching Your Data Pipeline

An existing S3 bucket can now serve as a filesystem without a separate data migration or copy-process-copy-back pipeline. Amazon S3 Files provides NFS access over an existing S3 bucket for AWS compute, and other POSIX layers cover other clouds and agent sandboxes. The choice turns on filesystem semantics, write visibility, and isolation.

Why teams still copy data before processing it, and what that costs

Manual copies and ETL workflows help when the work needs a different storage layer or structured records. But many pipelines move data for a less useful reason: the data lives in S3 while the tools expect files. Teams copy it onto EFS or local NVMe, process it, and copy the results back. That is a storage mismatch wearing a workflow badge.

The mismatch creates two storage bills, synchronization logic, and more copies of sensitive data to govern. Rsync scripts, cron jobs, and lifecycle policies become dependencies that can break when directory structures change. AWS says S3 Files delivers up to 90% lower costs compared with cycling data between S3 and separate file systems. Teams accepted the overhead because the underlying storage lacked the guarantees their tools needed.

Why POSIX-on-S3 kept failing through the 2010s

The earlier FUSE-based tools could translate filesystem calls, but they could not manufacture guarantees S3 did not provide. Before December 2020, reads after writes could return stale data, putting checkpoint recovery and rename-as-swap workflows at risk. Metadata operations including stat, rename, and chmod had no cheap object-store equivalent. Listing a large prefix meant enumerating objects through LIST calls. Small random writes were worse, because changing part of an immutable object required rewriting the whole object.

S3FS-FUSE worked for single-user browsing, but production workloads exposed the cost of all that metadata traffic. LIST operations could consume a substantial share of data-loading time and generate unexpected request charges. Goofys improved sequential reads, but concurrent-write races and write amplification made multi-client workloads unreliable. These were architectural limits. POSIX-on-S3 could not be fixed at the client layer alone.

The server-side changes that made POSIX-on-S3 viable

S3 strong consistency arrived in December 2020, making completed writes immediately visible to readers and providing a prerequisite for correct checkpoint recovery. S3 Express One Zone followed in November 2023 with single-digit millisecond latency and high request throughput. Directory buckets, announced in November 2023, supplied a hierarchical namespace with efficient listing that eliminated prefix-sorting overhead. These changes moved essential work from client-side emulation into the storage service. They enabled stronger filesystem layers, though they did not make every S3 API operation a POSIX operation.

How can an existing S3 bucket become a filesystem without migrating objects?

Amazon S3 Files, generally available since April 7, 2026, is a managed filesystem layered over an existing S3 bucket. It serves NFS and S3 API access to the same dataset without requiring a separately maintained copy. Clients reach it through a mount target in the customer's VPC, one per Availability Zone. An EFS-based caching layer holds the active working set while S3 remains the source of truth.

The service turns filesystem operations into S3 API calls without the need for custom drivers or FUSE libraries on the compute side. NFS v4.1 and v4.2 support lets EC2, EKS, ECS, and Lambda use existing application code. The first time a directory is listed or a file in it is opened, S3 Files imports metadata for every file in that directory, plus the data of files under an import threshold (128 KiB by default). Larger files are read from S3 when accessed, and reads of 1 MiB or more stream directly from the bucket even when the data is also cached.

Writes take a different route. They land on the file system, and S3 Files exports a changed file to S3 only after 60 seconds of write inactivity, so rapid successive writes become a single PUT. During that window, NFS readers see the changes but S3 API readers do not. If an NFS write conflicts with an update to the same object through the S3 API, S3 wins. The filesystem moves the conflicting NFS version to lost+found and imports the bucket version.

The filesystem interface also has boundaries. Hard links are unsupported because each file maps to one S3 object key, and all locks are advisory. The S3 objects behind the files are still immutable, so renames in the bucket need copy-and-delete operations. Bucket versioning must be turned on, and at launch the service is available in a set of AWS regions. Costs combine standard S3 storage and requests with cached storage billed per GB-month and small-file cache reads billed per GB, while large reads incur standard S3 GET request rates without an S3 Files data access charge.

When S3 Files fits and when EFS, FSx for Lustre, or Mountpoint is the better call

S3 Files fits a large cold dataset with a small active working set, especially when the applications already in use expect filesystem paths. Legacy applications can mount the data without code changes, and PyTorch, Horovod, and Ray can read training data over NFS. Shared mounts also serve multiple compute services that previously needed both an EFS volume and an S3 bucket.

EFS is still a better fit when all data stays hot with reads and writes all the time, or when the toolchain needs hard links. A workflow that cannot wait for S3 Files' approximately 60-second commit delay needs a different storage design, because it cannot count on NFS and S3 API readers seeing writes at the same time. Large directory renames are expensive too: every object under the prefix is copied and deleted in S3, and AWS warns when a file system is scoped to a prefix large enough (roughly 12 million objects) that a rename could take hours. Windows workloads requiring SMB fall outside its NFS-only interface.

Mountpoint for S3 fits high-throughput, read-heavy workloads by streaming large checkpoint files without a local copy, with limited write semantics: no hard links, no symlinks, and no renames on general purpose buckets. FSx for Lustre instead serves parallel workloads such as compute-intensive training and large-scale genomics, prioritizing throughput across millions of files over cost. It can link to S3, but remains a separate managed filesystem. S3 Files' advantage is clearest when most data stays cold, because only the active working set carries filesystem storage charges.

What POSIX-on-S3 means specifically for AI agents working on large datasets

The storage mismatch is especially clear with agents because they often work through bash, standard file tools, and Python file I/O. Without a filesystem mount, they need either a local copy or a custom tool that speaks the S3 API. A mounted bucket removes that detour without adding an SDK or an MCP tool to the agent's context.

Lazy loading makes this useful for a multi-terabyte dataset when a task touches only a small subset. S3 Files supports thousands of concurrent NFS connections, allowing multiple agents or sessions to share access without separate dataset copies. Shared access does not remove the documented conflict behavior when writers overlap. Its write batching also fits checkpoint-style work better than sub-second transactions, as long as the tools that use the results can wait through the S3 commit lag.

How sandbox environments connect agent compute to S3-backed filesystems

A mount supplies the data interface, but a sandbox supplies the agent's working environment. Persistence saves the work of rebuilding packages, files, and intermediate work between sessions. When the sandbox can mount the bucket directly, the bucket stays the source of truth and nobody maintains a separate copy of the dataset. Archil, a cloud file system that runs AI agents inside Firecracker microVMs on durable, forkable disks, takes this approach by letting an existing S3, GCS, R2, or Azure Blob bucket appear as a POSIX filesystem inside the sandbox without migrating the underlying objects.

The questions to ask of any POSIX layer over object storage are the ones this article applies to S3 Files. Which operations are supported: renames, hard links, locks across clients? When is a write durable: on fsync, or only after a background upload? How long before other clients, and readers using the S3 API, see it? What happens when the bucket changes underneath the file system? Durable storage and compute isolation are separate decisions, so the sandbox boundary needs to be checked on its own.

Why the isolation model of the sandbox matters when agents access sensitive bucket data

A filesystem mount gives agent-generated code a direct route to data, so the compute boundary is part of the storage design. Standard Docker/runc containers provision quickly but share the host kernel. An escape can expose the host and perhaps the bucket access its IAM role grants, so this boundary is a poor fit for untrusted agent-generated code with S3 access. GVisor reduces the exposed kernel surface by interposing a user-space kernel, as in Cloud Run’s first-generation execution environment. It does not provide hardware-level memory isolation.

Firecracker microVMs give each sandbox its own kernel and a hardware isolation boundary. The restricted surrounding environment limits host filesystem access, networking beyond the configured tap device, and privileged syscalls. That makes the boundary a good fit for agent-generated code that works with production data, but which data the agent may access still needs to be decided.

Credentials and egress therefore need separate controls. Environment variables remain readable inside a sandbox, and runtime vault retrieval still places secrets in its memory. Proxy-based credential injection adds tenant-scoped credentials at the network layer so they stay outside the agent process. Deny-by-default outbound rules with required endpoints allowlisted constrain exfiltration, while blocking IMDS at the network-policy layer prevents agent code from retrieving node credentials. The practical boundary is therefore not just where code runs, but which credentials and outbound routes it can use.

Where POSIX-on-S3 fits in a data architecture and where a copy step is still the right call

With those boundaries in place, mounting a bucket fits legacy file-based applications, large read-heavy training datasets, and agents that explore subsets of data and save checkpoints. It also works for multi-tenant products that already have bucket isolation and where each sandbox needs scoped access to its tenant's files. The data already resides in the bucket. If the task is to work on it with file tools, a mount can replace the transfer job.

That does not make every dataset a filesystem problem. Databases are still the better interface for clean schemas, structured records, and joins. Hard-link-dependent tools need a filesystem that supports them, which rules out S3 Files but not every POSIX-on-S3 implementation. With a write-back cache, writes may take time to become visible through both NFS and the S3 API, and very large prefixes make directory renames slow and costly.

Filesystems and databases are complements, and data movement is useful when it changes what a workload can do. It is wasteful when it exists only to turn an object into a path. The copy step is now optional for a substantial class of workloads. In practice, membership in that class depends on the workload's semantics, visibility requirements, and security boundary.