The Amazon EFS file storage tax: why shared NFS costs 4x more than EBS

Published September 25, 2026

EFS is often the first tool engineers reach for when multiple containers or EC2 instances need to share files. It mounts over NFSv4, gives full POSIX semantics, scales capacity without provisioning, and replicates synchronously across Availability Zones.

That convenience comes with a high price tag. In us-east-1, Amazon EFS Standard storage costs $0.30 per GB-month ($300 per TB-month). For comparison, EBS gp3 costs $0.08 per GB-month, and S3 Standard costs $0.023 per GB-month.

Storage is only the baseline charge. EFS couples capacity with a throughput billing model that routinely surprises teams with secondary bills for reading and writing their own data.

The storage price ladder

In our file storage dataset, EFS divides storage into five classes across regional and single-zone deployments:

EFS Standard is 3.75 times more expensive than EBS gp3 storage and 13 times more expensive than S3 Standard.

Lifecycle Management moves files unread for a configurable window (1 to 90 days) into IA or Archive automatically.

A file system with 20% active data in Standard and 80% cold data in IA yields an effective blended rate of $0.08 per GB-month, matching gp3’s storage rate.

That discount holds only while files stay dormant. Reading a file in IA costs $0.01 per GB in access fees, and $0.03 per GB in Archive. Reading a full 1 TB dataset costs $10.00 from IA and $30.00 from Archive.

The throughput trap: bursting, provisioned, and elastic

Storage pricing is predictable because volume size changes gradually. Throughput pricing on EFS is where budgets routinely break.

EFS offers three throughput modes.

1. Bursting throughput: the small volume penalty

Under bursting mode, baseline throughput scales linearly with the amount of data stored in EFS Standard: exactly 50 KiB/s per GB stored (equivalent to 50 MB/s per TB).

Volumes can burst above that, but bursting consumes accumulated credits. For a 50 GB application directory or container mount:

• Your guaranteed baseline throughput is 2.44 MiB/s (2,500 KiB/s).
• Sustaining more than that drains the burst credit bucket.
• Once depleted, the file system throttles to 2.44 MiB/s, which shows up as kernel I/O wait and application timeouts.

To hold a steady 100 MiB/s baseline without bursting credits you need roughly 2,100 GB in Standard, costing $630 a month in storage alone.

2. Provisioned throughput: $6 per MB/s

If your storage footprint is small but your application needs high bandwidth, you can buy throughput independently of storage:

• EFS Provisioned Throughput: $6.00 per MiB/s-month

gp3, by contrast:

• Includes 125 MB/s of throughput on every volume at no extra cost.
• Additional throughput runs $0.040 per MB/s-month ($40.96 per GiBps-month).

At 100 MiB/s of sustained throughput the gap is stark:

• On gp3, 125 MB/s is included free.
• On EFS, 100 MiB/s costs $600.00 a month, before any storage charge.

3. Elastic throughput: paying per transferred gigabyte

Elastic Throughput removes credit monitoring and provisioned planning. EFS scales dynamically to 3 GiB/s for reads and 1 GiB/s for writes, and charges for every byte transferred:

• Elastic Read Throughput: $0.03 per GB transferred
• Elastic Write Throughput: $0.06 per GB transferred

On read-heavy or write-heavy workloads these processing fees dwarf the storage bill.

A realistic scenario: CI/CD build cache

Consider a team running a Kubernetes CI/CD cluster that shares a 500 GB build cache across multiple runner pods using EFS Standard with Elastic Throughput.

Each weekday, the runners read 1.5 TB of cached dependencies and write 500 GB of newly built artifacts. Over a 22-working-day month, total monthly throughput equals 33 TB of reads and 11 TB of writes.

Here is the monthly cost breakdown:

Storage is $150 of that bill, 8.3%. Throughput is $1,650, or 91.7%. The effective cost of storing a gigabyte rose from $0.30 to $3.60.

Running that same 500 GB cache on an EC2 instance with an EBS gp3 volume serving NFS via Linux kernel-server would cost:

• 500 GB gp3 storage: $40.00
• 125 MB/s baseline throughput: $0.00
• t4g.medium instance at $0.0336/hr: $24.53
• Total: $64.53 per month (a 96% cost reduction).

The small-file metadata penalty

EFS stores file metadata (inodes, directory listings, permissions) on distributed servers to maintain multi-AZ consistency. When a file system contains hundreds of thousands of small files (such as node_modules trees, Git repositories, or PHP application source code), POSIX operations like stat(), ls, and directory traversals incur high network round trips.

In addition to latency overhead, small files trigger a financial penalty in IA:

• Any file smaller than 128 KB stored in Infrequent Access is billed for a minimum of 128 KB.
• IA adds a small-file overhead of $0.025 per GB-month for those files. Our data does not carry a separate small-file rate for Archive, so treat Archive’s equivalent as unverified here.

A repository containing 200,000 files averaging 10 KB each holds 1.9 GB of actual code. In EFS Infrequent Access those files bill as 24.4 GB, a 12.8x multiplier.

Architectural alternatives to EFS

EFS remains a valid solution when multiple EC2 instances or containers require concurrent read-write access to a shared POSIX file hierarchy. When those exact requirements are absent, alternative AWS storage patterns provide substantial cost savings:

1. Mountpoint for Amazon S3

If your application needs file-system-style read access to large datasets without needing full POSIX locking, random writes, or directory renaming, AWS Mountpoint for S3 mounts an S3 bucket as a local file system directory. Storage bills at S3 Standard rates ($0.023/GB-mo), cutting base storage costs by 92% compared to EFS Standard.

2. S3 API with presigned URLs

Web applications often use EFS as a shared target for user uploads (such as avatar images or document attachments) across a fleet of web servers. Replacing shared disk paths with direct S3 uploads via presigned URLs removes file server contention and drops storage spend to S3 rates with zero throughput tax.

3. EBS Multi-Attach with clustered file systems

For high-performance database clustering, EBS Provisioned IOPS (io2) supports Multi-Attach, allowing up to 16 Nitro-based instances in the same Availability Zone to attach to the same volume. This requires a cluster-aware file system (such as GFS2) but avoids EFS’s $6/MB/s provisioned throughput fees.

4. Dedicated NFS or Samba on EBS gp3

For non-critical shared caches or developer environments where single-AZ availability is acceptable, running an open-source NFS server on a modest EC2 instance backed by gp3 storage delivers 3,000 IOPS and 125 MB/s throughput at a fraction of EFS’s operational price.

Sizing rules for Amazon EFS

If your architecture requires EFS, apply these rules to keep expenses in check:

1. Enable Lifecycle Management immediately: Configure a 14-day or 30-day transition policy to Infrequent Access to bring cold data down from $0.30 to $0.025 per GB-month.
2. Never place node_modules or package managers on EFS: Package trees generate millions of small file metadata lookups and run into the 128 KB minimum billable object floor in IA. Keep runtime code on container images or EBS root disks.
3. Calculate your read/write volume before enabling Elastic Throughput: If your monthly data transfer exceeds 10 times your stored volume size, throughput fees will dominate your bill. Monitor the CloudWatch MeteredIOBytes metric to verify transfer rates.
4. Choose One Zone for non-production environments: Staging and ephemeral testing workloads can use EFS One Zone ($0.16/GB-month Standard, $0.0133/GB-month IA), saving 47% to 53% on base storage fees.