Archil vs Amazon EFS for AI agents

Archil vs Amazon EFS for AI agents compares workload fit as well as shared storage. Archil is the stronger fit for agents that handle many small files and need persistent, forkable workspaces. EFS remains a sound choice for AWS-integrated systems, shared NFS locking, and write-heavy workloads where its benchmark results lead.

What EFS is and what agents actually do to a file system

Amazon EFS is a mature, fully managed, serverless NFS service. It is built to let clients share large files with high throughput at cloud scale. As average I/O size grows, each network round trip carries more data, so the per-operation cost is spread over more bytes.

Agents often generate the opposite pattern through repo clones, package installs, SQLite databases, and sandbox environments. These use many small files and metadata operations, so each round trip has little data to carry. Agents also write reports, datasets, and build outputs that need to survive beyond a sandbox’s default end-of-run wipe. Meanwhile, models have had so much training on bash and command-line tools that the file system has become a universal interface for agent context. Agents can explore files as they need them instead of getting everything in a prompt, while Archil brings persistent, forkable disks and isolated Firecracker sandboxes together so the working environment and its storage are one unit.

Where the performance gap comes from and what the benchmark shows

NFS clients must round-trip every mutating metadata operation to the server. Archil clients instead take exclusive write delegations through archil checkout, so creates and writes can be acknowledged locally. For a repo clone or package install, that saves a network round trip for each small create or write. Archil’s own benchmark, run on 2026-10-15 from one c7gn.2xlarge in us-east-1 against EFS in General Purpose mode with Elastic throughput, shows the gap on those workloads and where EFS still wins:

Archil’s benchmark reports a single bulk SQLite insert of 1 M rows taking 1.7 s on EFS versus 11.0 s on Archil. It reports sequential write performance for 4 GiB + fsync of 590 MB/s on EFS versus 194 MB/s on Archil. For 4 KiB random writes, it reports 2,976 IOPS on EFS versus 953 IOPS on Archil. These results matter for agents that spend most of their time on large sequential writes or high-IOPS random writes. They also show why “uses SQLite” is not enough to choose a file system, since a bulk insert and many small transactions present different workloads.

Why small-file billing makes EFS expensive specifically for agent workloads

Small files change the billing picture as well as the latency picture. EFS Infrequent Access and Archive tiers bill a minimum of 128 KiB per file, regardless of its actual size, and each file’s metadata stays in the Standard tier. As a result, a workspace full of Python cache files, git objects, node_modules entries, and SQLite WAL files may gain little from tiering.

Archil bills on active data rather than provisioned capacity or per-file minimums. That model fits workspaces whose size changes unpredictably, from 1 MB to 1 GB. Which service costs less still depends on the EFS tiers and throughput modes chosen, as well as cross-AZ transfer. The structural distinction is that actual file size and billable file size can diverge sharply on EFS’s colder tiers.

What Archil adds that EFS was never designed to provide

Performance is only part of the comparison because EFS supplies shared storage. On its own, it has no sandboxed execution, native disk branching and checkpointing, S3-compatible API access to disk data, or native mounting of existing object storage buckets. With EFS, those pieces must come from the rest of the system.

Archil pairs each disk with a Firecracker microVM sandbox that has its own kernel, isolated network, and persistent packages and files. Serverless execution has been available since April 2026, and persistent sandboxes are generally available. Stops and restarts therefore need not mean rebuilding the working environment from scratch. Disk checkpoints and branches also let separate attempts start from the same state. S3-compatible API access and native bucket mounts connect that workspace to the rest of the data stack. Together, these capabilities change the unit being managed from a shared mount to an agent’s working environment.

Sandboxes and code isolation: why EFS needs a separate layer and what that costs

A shared file system is not a boundary around agent-generated code. An EFS-backed agent therefore needs a separate isolation primitive, such as a microVM, gVisor, or at minimum a hardened container. Without a suitable boundary, storage alone cannot stop destructive file operations or keep credentials from being exposed. EFS network access is controlled through VPC security groups and NACLs, but those controls require their own configuration and expertise. The cost includes running both layers as well as paying for disk space.

Archil’s Firecracker microVM gives the sandbox its own kernel. Its Developer plan also restricts outbound traffic to a managed allowlist of package registries, git hosts, and model APIs. Fully custom firewall rules for this constrained egress require the Team plan. Team plan and above also broker credentials at the network boundary to keep secrets out of agent code, while ports stay private until they are explicitly exposed. These specific controls still leave scope for an agent to do harm.

Persistent, shared workspaces across sessions and machines

Persistence and sharing solve different problems. An agent needs files to survive a restart, but a parallel agent also needs a way to see and update that state. Archil disks can mount on many machines simultaneously, and writes are durable once fsync returns, with copies sent to the backing bucket in the background. EFS also handles persistence and sharing directly, with native ReadWriteMany access across EKS pods through the EFS CSI driver that survives pod restarts, node replacements, and cluster upgrades.

Archil’s flock and fcntl locks work only within each client, and writes are lost when clients use concurrent O_APPEND. Writers on different machines should thus use explicit ownership in place of advisory locks. An already-running reader may also take some seconds to see another client’s file unless it runs archil invalidate-cache. EFS’s shared NFS locking semantics are a genuine advantage for applications that depend on them.

Branching agent workspaces for parallel attempts and safe rollbacks

Once an agent can resume a workspace, the next useful step is to branch it. Separate attempts can start from the same state, take different paths, and be checked without having to run every experiment through the original workspace. EFS has no native branching or checkpointing. Teams must build checkpoint logic around it, using approaches such as application-level checkpoints to S3 or a separate EBS snapshot arrangement. That adds work and latency to the branch-and-rollback process.

Archil reports disk checkpoint and branch operations of ~90 ms regardless of size. That is the disk operation alone; forking a whole running sandbox also snapshots its CPU and memory. The distinction matters because a saved workspace and a frozen process are not the same thing. For an agent whose structured state lives in SQLite files, a branch preserves the database state at the fork point without a separate application-level database copy process. On bring-your-own-bucket disks, however, checkpoints and branching are Enterprise-only.

Giving agents access to large datasets in S3, GCS, and R2 without copying them

Agents that work with lots of data often start with source material already in an object bucket. Copying it into a separate workspace consumes time, storage, and egress budget while creating another version to keep synchronized. Archil instead mounts existing S3, GCS, R2, Azure Blob, and S3-compatible buckets as a POSIX file system without migration, ETL, or copies. It syncs with the bucket in both directions, and the bucket remains the source of truth. Revoking access leaves the data in the customer’s account, exactly where it was.

The same disk is accessible through an S3-compatible API, so pipelines, dashboards, and other services can read agent outputs without an export step. AWS offers S3 Files as an AWS-native way to mount an S3 bucket directly into an agent environment and keep the data in S3, so there is less need for an EFS staging layer. Its scope is AWS-only, so it does not serve data in GCS or R2. With Archil, cache nodes run alongside agent compute, and data moves across regions only when that is explicitly configured, which helps set a boundary for where data must stay.

Per-tenant storage isolation at thousands of tenants

A multi-tenant agent product needs more than a directory named after each customer. It needs storage boundaries, controlled access, and an egress policy for each tenant, all of which must stay manageable as the number of tenants grows. Archil’s guidance is to make the disk the unit of isolation: give each tenant its own disk and a disk-scoped token, because credentials cover a whole disk and POSIX permissions are not a boundary between untrusted users. Subdirectory mounts (disk:/path) let different clients work in different directories of one disk without delegation conflicts, but they are a convenience, not a tenant boundary.

Disk tokens, read-only or conditional mounts and archil checkout delegations control who writes where within a disk. These storage controls are separate from the sandbox network policies, which need Team plan for custom rules. EFS has a well-established option in Access Points, which enforce a specific POSIX user identity and root directory for each tenant. That lets one file system serve many tenants under IAM policy, which is simpler than a disk per tenant, but it does not supply S3-format data or native branching. At thousands of tenants, the key comparison is how much provisioning and coordination each tenant adds. The way small files are billed adds to that burden, but the number of tenants alone cannot show how much it will cost.

When EFS is the right answer and when to choose Archil

EFS is the better call for an AWS-only team that wants deep IAM, VPC, AWS Backup, and EKS CSI integration without adding another vendor. It also leads in Archil’s benchmark for bulk SQLite inserts, sequential writes, and random writes. Applications that depend on NFS file locks shared across clients have a concrete reason to choose it, because Archil’s advisory locks are per client. Existing EFS infrastructure and compliance requirements anchored to AWS services are equally valid reasons to stay. Switching friction belongs in the engineering decision.

Archil is the better fit when repo clones, package installs, small files, and transaction-heavy SQLite work dominate, especially when persistent environments and branching are core requirements. Its bucket mounts also fit teams that need agent access to data across S3, GCS, R2, or Azure Blob without migration, while its mount boundaries suit multi-tenant workspaces. Archil’s Firecracker infrastructure has carried production load for over a year, and persistent sandboxes have been generally available since September 2026. Teams checking how mature the product is should ask about that production track record as well as look at the date on the product page. Choose EFS for the shared AWS file-system semantics the application needs, and Archil when the agent needs a persistent workspace it can branch, execute in, and connect to existing data.