Mounting a POSIX filesystem directly over an existing S3 bucket without migrating data is possible, but a mount point is not a promise of full file-system behavior. s3fs-fuse, Mountpoint for Amazon S3, and Amazon S3 Files bridge the gap differently. The right choice depends on which file operations the workload needs, how clients share changes, and whether the code using those files also needs isolation.
Why object storage and file systems have never agreed on what a file is
S3 is a flat key-value object store that is accessed over HTTP. It has no native directories, file descriptors, inode metadata, or open file handles. POSIX applications expect a different contract. They can seek within files, append, rename atomically, and coordinate through advisory locks such as flock and fcntl. Other expectations include mmap, hard links, and sparse files, none of which an object API natively provides.
Neither design is a mistake to fix. The difficulty comes when an application expects one contract while its data lives behind the other. Duplicating objects into EFS or FSx adds redundant storage, running a sync pipeline adds operational work, and rewriting around the S3 SDK adds development work. AI agents sharpen that tension because models trained on bash and file tools tend to reach for a file system, even when the data already lives in S3.
The three distinct approaches to mounting S3 as a POSIX file system today
s3fs-fuse is a community FUSE client that runs in userspace and turns file operations into S3 API calls to S3-compatible endpoints. Mountpoint for Amazon S3 is AWS’s open-source FUSE client, built for sequential read throughput with writes limited to sequential new-file creation. Amazon S3 Files, launched April 7, 2026, has a managed NFS v4.1 interface with an EFS-powered cache behind it. That cache supports more ways to write files and has a managed consistency model.
What s3fs-fuse actually does to bridge object storage and file operations
s3fs-fuse shows an existing bucket or prefix as a directory tree and leaves the existing objects unchanged. Underneath, operations such as open, read, stat, and ls turn into HTTP requests, while writes can involve multipart upload assembly. The interface changes, but the underlying object operations remain. Local disk caching through use_cache, stat cache TTL, parallel request count, and multipart chunk size can reduce redundant requests. On EC2, -o iam_role=auto uses an IAM role without a credential file, while elsewhere ~/.passwd-s3fs can hold the access key and secret.
Rename is the trap worth marking in red. s3fs-fuse documentation states that renaming copies the entire object to the new key and deletes the old one. That is not atomic, so applications that depend on atomic rename, including many databases, editors, and build tools, can fail silently or visibly. Overwriting also rewrites the full object, and frequent metadata operations can generate substantial request charges.
Concurrency imposes another limit because flock and fcntl do not coordinate clients across machines. Local metadata caches can also diverge from S3 state, leaving stale reads and uncoordinated writers. These limits favor read-mostly applications that mainly need ls and cat and make shared mutable workspaces a poor fit. Portability is its clear advantage. Supported endpoints include GCS, Cloudflare R2, MinIO, DigitalOcean Spaces, Wasabi, and Backblaze B2, while Azure Blob requires S3Proxy as an intermediary.
What Mountpoint for Amazon S3 trades away in exchange for read throughput
Mountpoint chooses throughput over broad POSIX compatibility. It is an AWS-maintained open-source FUSE client that runs on EC2, ECS, and EKS without a managed service behind it. Large sequential reads are its intended work, including ML training datasets, log analysis, and model checkpoint loading. For those workloads, omitting general file-system behavior is a deliberate design choice.
Sequential writes can create new files, but overwrites, random writes, and append to existing files return I/O errors. Rename and file locking are not supported. In exchange, Mountpoint adds no charge for managed cache-storage or data-access above S3 API pricing, so it fits workloads that can work within those limits.
How Amazon S3 Files delivers full POSIX write semantics without leaving S3
S3 Files adds the managed layer that the two FUSE clients lack. An S3 Files Agent runs as a sidecar on EC2 or in a Kubernetes pod, handling translation and maintaining local metadata. Data in use sits in an EFS-backed high-performance SSD cache, while large sequential reads of cold data can stream straight from S3. Writes land in that cache first. The backing bucket reflects them as new objects or versions within minutes, so avoiding migration does not mean avoiding another storage layer.
That layer supports overwrite, random write, append, truncate, directory listing, and permission management through UID/GID values stored as object metadata. It also provides NFS-layer advisory locks and fast rename from the client’s perspective, with copy-and-delete still occurring at the S3 layer. The qualification is important for concurrent access. Rename does not have atomic guarantees under concurrent access, and mandatory locks are not supported. “Full POSIX write semantics” therefore does not make every database or build tool compatible.
The consistency model is close-to-open. Closing a file flushes its data to the server, and another client sees it on its next open. Readers using the S3 API can lag behind because bucket synchronization takes minutes. To mount a bucket, it must be an existing general-purpose bucket with versioning enabled, but its existing objects can stay as they are. Compute options include EC2, ECS, EKS, and Lambda within the same VPC, with a Multi-AZ cache beneath the service.
Where the three approaches diverge on rename, locking, consistency, and cost
The tools differ most in rename and locking: s3fs-fuse copies and deletes an object, has no atomic rename, and does not enforce advisory locks across clients. Mountpoint supports neither rename nor file locking. S3 Files makes rename a fast metadata operation at the file interface and supports NFS advisory locks, but it does not guarantee atomic rename under concurrent access or provide mandatory locking. A workload requiring those stronger guarantees has not found its answer simply because all three tools expose paths.
Consistency also needs a more precise question than whether files are “shared.” s3fs-fuse can serve stale cached metadata without cross-client coordination, while Mountpoint relies on the S3 object API rather than adding a shared file-system consistency layer. With S3 Files, NFS clients have close-to-open visibility, while changes become visible through the bucket API later. The access path changes the answer. A pipeline reading through the mount and a dashboard reading directly from S3 need not see a change at the same time.
s3fs-fuse and Mountpoint add no service charge above S3 API pricing, though frequent listings and other metadata requests can drive up request charges. S3 Files charges for active cache storage and per-GB data access, so a small hot working set limits the cache premium. Metadata latency remains a separate constraint. S3 Files metadata operations run at 10–50ms, compared with around 1ms for EFS, while FSx for Lustre remains the option for maximum parallel bandwidth on very large ML workloads.
How AI agent workloads expose the limits of per-session scratch storage
An agent’s local scratch directory can disappear when its session ends or its container is replaced. Intermediate results and working files can disappear with it, even when the user expects them to last. The AWS S3 Files product page describes an agent product whose sessions write files tens of thousands of times a day, with users expecting to open them right away. A manual download or sync pipeline is a poor substitute for that expectation.
Persistence must also work between stages and machines. One Lambda can write a file that the next Lambda needs without an explicit copy or publish step. For agents working on genomics datasets, financial records, or government document corpora, a mount also avoids downloading terabytes for every session because the agent reads only what it touches. Archil addresses this combination with isolated, persistent sandboxes whose disks mount existing buckets as POSIX file systems while keeping data in the source bucket.
Isolation requirements when agent-generated code runs inside the mounted workspace
A mount gives code access to files. In a container-based sandbox without enough isolation, code that can reach the instance metadata service may be able to get host IAM credentials. An agent that obtains an IMDSv2 token may then gain access beyond its intended workspace, including cluster S3 data or KMS operations. Storage permissions alone do not solve that exposure. Sandbox design must establish what separates code running as root inside the sandbox from the host and other tenants.
Firecracker provides a hypervisor-based boundary with a separate Linux kernel for each microVM. That isolates execution, while egress controls and credential brokering address different risks. Restricting outbound traffic limits where code can connect, and injecting keys at the network boundary keeps secrets out of the sandbox itself. In Archil’s implementation, each sandbox is a Firecracker microVM. Free-plan sandboxes use a managed egress allowlist, and on Developer and above each sandbox can have its own firewall policy, including deny-by-default rules. Its egress proxy can also broker credentials for the agent code without giving them to it.
Persistent, forkable disks as the storage layer underneath an agent sandbox
Isolation without persistence still leaves agents rebuilding their workspace after restarts. Installed packages, downloaded data, and intermediate files need a lifetime independent of the process that created them. Bundled storage-and-compute systems address that requirement differently from standalone FUSE clients or managed NFS. With Archil, persistent disks accompany the microVMs and can mount existing S3, GCS, R2, or Azure Blob buckets without migration. This trades standalone-client portability for tighter coupling between execution and storage.
Durability has a specific acknowledgment boundary in this design. Writes are durable once fsync returns and copy to the backing bucket in the background. For multi-AZ durability, the guarantee comes from fsync or [archil sync](https://docs.archil.com/mounting/linux), but plain sync gives no such guarantee. Those names are not interchangeable housekeeping commands. The bucket stays the source of truth, and revoking access leaves the data in the customer’s account.
On Archil-managed disks, checkpoints and branches take milliseconds no matter how large the disk is (disks synced to your own bucket support them on Enterprise), so attempts can run in parallel or a fork can be made before a risky operation. Many machines can mount a disk, but flock and fcntl work per-client and do not coordinate access across machines. Writers instead use read-only or conditional mounts and explicit checkout. Each disk is also accessible through an S3-compatible API, while serverless execution can run a command in a fresh microVM against a named disk whose state survives the invocation.
How to match workload requirements to the right approach
The decision starts with operations, then moves to isolation and persistence. Choose s3fs-fuse for read-mostly access, especially across non-AWS endpoints, when stale metadata is tolerable and neither atomic rename nor cross-client locking is required. Choose Mountpoint for large sequential reads and, at most, sequential creation of new files. Both avoid a managed service premium. Neither is a substitute for coordinated multi-writer storage.
Choose S3 Files when overwrite, append, rename, and NFS advisory locks are needed across compute nodes, provided close-to-open consistency and delayed bucket visibility fit. Its economics are especially useful when active data is a small fraction of the bucket. Keep latency-sensitive metadata workloads on EFS or FSx to avoid forcing them through a slower interface. Applications requiring mandatory locks also need a different fit, and FSx for Lustre remains appropriate for maximum parallel throughput on very large ML workloads. Compatibility begins with the calls the application actually makes.
When agents run generated code, check execution isolation on its own, apart from the mount. Each sandbox vendor should identify its named hypervisor, default egress policy, and the location of credentials relative to agent code. For multi-tenant agent products or branch-and-rollback workspaces, Archil is an option beside AWS-native storage approaches because it pairs microVM isolation with persistent, forkable disks. The pairing is the requirement to preserve. An agent needs both a boundary around what it can do and a workspace that survives when it stops doing it.