Adding a POSIX Layer to an S3 Bucket You Already Own Without Moving a Single Object

An existing S3 bucket can now be mounted as a POSIX-style filesystem without migrating its objects. Amazon S3 Files provides that surface for AWS workloads, while Archil offers existing-bucket mounts across several object stores. The choice turns on what happens behind the folder view, especially write-back delays, cache charges, and the boundary between persistent storage and isolated execution.

Why S3 and POSIX have been structurally incompatible until recently

S3 stores objects, but POSIX applications expect files. The mismatch is visible in atomic rename, in-place modification, and directory traversal. A copy followed by a delete is not an atomic rename, so a checkpoint commit using Python’s os.rename(tmp, final) cannot rely on the same behavior through an object API. Client-side FUSE tools such as s3fs and Goofys emulated missing primitives, but LIST-operation costs and write amplification made that approach troublesome under production load.

S3 added strong consistency in December 2020 and native directory semantics in 2023, and it gained single-digit-millisecond latency through S3 Express One Zone in 2023–2024. These changes let filesystem access build on what the server could do instead of leaving each client to fill in what was missing. Systems such as Archil took a complementary route, layering a full POSIX cloud filesystem over object storage instead of trying to make the object API itself behave like POSIX.

What Amazon S3 Files actually does and how it is structured

Amazon S3 Files exposes an existing bucket through a file layer without requiring a data migration. Its two-tier architecture uses Amazon EFS as an SSD-backed working layer, typically serving files under 128 KB at roughly 1 ms latency. Large sequential reads and byte-range requests pass directly through to S3. On first access to a namespace, the service materializes object metadata so directory traversal does not require a full data copy.

Writes take a different route from those direct reads. They land in the file layer and synchronize to S3 asynchronously, with a default window of approximately 60 seconds and an explicit flush API for immediate propagation. With translation on the server, the service adds the EFS cache and write batching in place of the earlier Mountpoint for S3 FUSE approach. The service supports EC2, ECS, EKS, Fargate, Lambda, and Batch, with compute in a VPC and support for cross-VPC and cross-account access. Access points map entry points to directory paths, combining IAM and POSIX permissions to support independent workspaces.

What S3 Files preserves and what it deliberately gives up

Most POSIX behavior does not mean every POSIX guarantee. S3 Files makes deliberate tradeoffs around hard links, mandatory byte-range locking, and real-time fsync durability to the bucket. An application that depends on one of them needs more than a successful mount to establish that it will work correctly. The object namespace also retains its 1,024-byte key-length limit, which deeply nested paths with long names can reach.

Non-POSIX-valid keys can silently disappear from the mounted view.

That omission is different from an inaccessible storage class. AWS’s S3 FAQ says objects stay visible in any storage class, but opening files backed by S3 Glacier Flexible Retrieval or Deep Archive returns an I/O error. Before teams commit, they need to check which namespace entries are missing and which objects are visible but cannot be opened through the filesystem.

How the 60-second write-back window shapes workload fit

The synchronization delay buys fewer S3 writes. Bursty checkpoint workloads can accumulate small updates during a write phase, then let the service coalesce them into fewer, larger PUTs during a computation gap. ML training pipelines fit that pattern naturally. A workload that calls fsync and immediately reads the same object through the S3 REST API has the opposite requirement. It can see stale data because the file-layer write has not yet crossed the aggregation boundary, while S3 retains strong consistency.

The two interfaces are not equal write authorities. S3 wins a conflict, because the bucket is the system of record and the file layer is a working surface derived from it. Applications that write the same keys through NFS and REST therefore cannot treat the mount as a peer interface with independent ownership. An explicit flush forces propagation when needed, but sacrifices write coalescing. Archil also synchronizes external-bucket writes in the background after fsync returns, so bucket visibility needs separate consideration there rather than being inferred from the presence of a POSIX interface.

Pricing structure and the workloads where the economics actually work

The favorable profile is a small hot working set above a large cold bucket. Cache storage charges apply only to the active slice of the bucket. That can make filesystem access economical without moving all data onto higher-priced storage. Access patterns still decide the bill. A low storage rate says little about a workload that spends its day opening tiny files and inspecting their attributes.

File data access through the high-performance layer has a 32 KB minimum, while metadata operations have a 4 KB minimum. Metadata reads, including directory listings and attribute checks, are metered as 4 KiB reads. Metadata writes, including creation, deletion, rename, and fsync, are metered as 4 KiB writes, and a commit through fsync or close-after-write is metered as a 4 KB write. Those charges can make a workload with many small files cost more than EFS, even when storage costs less.

Bulk reads follow a more favorable path. Reads of 1 MiB or more stream from the bucket without an S3 Files file-read charge, although each operation still incurs a 4 KiB metadata read and standard S3 GET costs. AWS Pricing Calculator has S3 Files, so teams can model the costs of these access patterns. The comparison should account for actual access behavior as well as bucket size. EFS remains relevant when the filesystem is the system of record, while FSx for Lustre serves high-throughput parallel training where throughput and parallelism dominate.

Security: running two permission models simultaneously

IAM and POSIX permissions operate at the same time. POSIX ownership and access controls persist beyond a session as object metadata, including UID and GID. AWS’s POSIX permissions documentation states that objects created outside the filesystem receive default root:root ownership and 0644 permissions when no POSIX metadata exists. When applications use a mount to access a bucket filled through REST, those defaults can cause permission conflicts.

One permission model does not fill in the other. Configuring IAM and assuming filesystem ownership is covered leaves a gap, as does configuring POSIX permissions without auditing object access. That gap can become a privilege-escalation surface, particularly when both interfaces remain active. Both layers need auditing against the paths applications actually use.

Where S3 Files fits agent workloads specifically

Persistent files let an agent pick up where it left off after a restart, and shared subdirectories let pipeline steps pass notes, summaries, and intermediate artifacts to each other through ordinary file I/O. S3 Files makes the bucket a live working directory without a staging copy. AWS says thousands of compute resources can connect to a single S3 filesystem simultaneously. That shared surface removes the need for each step to invent its own object-to-file handoff.

File compatibility also helps existing ML tooling. PyTorch DataLoader and NVIDIA DALI can use mounted data without code changes, subject to the service’s supported semantics. Checkpoints that use tempfile.NamedTemporaryFile followed by os.rename get the filesystem behavior that raw object access lacked. S3 Files is a VPC-bound NFS service that leaves egress policy enforcement, credential brokering, and separate kernels to an execution environment.

For agent-generated code, teams need to check persistence and isolation separately. Archil’s persistent sandbox approach combines Firecracker microVM isolation with a persistent disk, addressing execution boundaries as well as working state. That complements the filesystem behavior S3 Files provides, with the two serving distinct roles. Purpose-built sandbox storage can also offer branching and rapid checkpoints for parallel attempts and rollback. Those capabilities must be checked for the chosen disk type, since externally synchronized Archil disks do not support branching or checkpointing.

Multi-tenant agent platforms and per-prefix isolation

A tenant_id supplied in a prompt is not an isolation boundary. Tenant scope must come from authenticated infrastructure, such as an IAM role or access point ARN, that the agent cannot modify. S3 Files access points map entry points to specific directory paths. With correct IAM and POSIX configuration, a shared bucket can give each tenant read/write isolation over its own prefix.

A dedicated bucket per tenant maximizes isolation at higher per-tenant cost, while a shared bucket with access-point segmentation reduces overhead but demands rigorous permission configuration. Locks do not repair a permission gap. Direct S3 REST writes bypass NFS advisory locks, so credentials that allow object writes still have that power outside the mounted interface. Namespace isolation must therefore account for both routes into the bucket.

Connecting your existing bucket to a POSIX layer without S3 Files: the alternative options

Archil mounts existing S3, GCS, R2, Azure Blob, and S3-compatible buckets as POSIX filesystems through an Archil disk, without migration or an ETL pipeline. The bucket remains the source of truth, data stays in the customer’s account, and revoking access leaves it there. This addresses a specific gap in staging workflows. Migration and ETL remain useful when relocation or transformation is the goal, but they add a separate data-handling step when an application only needs file access to existing objects.

Archil disks synchronized to external buckets cannot branch or checkpoint, even though other Archil disks support rapid branching and checkpointing regardless of size. Its sandbox controls address a separate requirement from mounting. The Developer plan uses default-deny outbound access with a managed allowlist, while Team plans can set firewall rules. Credentials are brokered at the network boundary and never enter the sandbox.

Mountpoint for S3 serves a narrower, read-heavy use case. The FUSE-based client has no write-back or EFS cache and suits pipelines that do not need edit-in-place behavior and want to avoid S3 Files cache costs. EFS fits applications that use the filesystem as the system of record and need hard links and strict POSIX behavior. FSx for Lustre remains a choice for high-throughput parallel training.

Deciding whether to mount your existing bucket

S3 Files fits an AWS-native, VPC-bound workload with read-heavy or bursty-write behavior and a small hot working set. The application must work with its POSIX exceptions and use just one write path, NFS or REST, for each key. Immediate fsync durability to the bucket changes that answer. So do same-key writes through both interfaces, Windows client requirements, and workloads that must traverse non-POSIX-valid names or inaccessible Glacier-tiered objects. Those are selection criteria to apply before deployment.

Run the actual bucket namespace against the mount before a production cutover, including REST-created objects and the names a clean-room test would omit. For agents, assess microVM isolation, default-deny egress, and credential brokering independently of storage persistence. For data spread across clouds, compare existing-bucket mounts that work with those stores instead of trying to use an AWS-only service for the job. Finally, document the 60-second synchronization window and the S3-wins conflict rule explicitly, so future application changes do not mistake a file-shaped interface for a different durability contract.