Amazon EFS Pricing: The Throughput Mode and Storage Class Decisions That Decide the Bill

Amazon EFS occupies an awkward billing position. It is more expensive per GB than any block-storage or object-storage alternative on AWS, by a wide margin — $0.30/GB-month for Standard storage is more than 13× S3 Standard, 4× gp3 EBS storage, and even ahead of the io2 Block Express premium tier. The premium pays for shared POSIX semantics that no other AWS storage primitive offers natively. When that premium is justified, EFS is the right answer. When it isn’t, the bill becomes one of the largest unjustified line items in a typical AWS account.

This post is the bill story. For the architecture decision of whether to use EFS, Lambda S3 Files, or stay on S3 entirely, our Lambda S3 Files vs EFS guide covers the trade-offs. For S3-side pricing math, the S3 pricing calculator is a good reference point.

The Seven EFS Billing Dimensions

The 13× Premium: Why EFS Storage Costs So Much

EFS Standard costs more per GB than any other AWS storage primitive. The premium is not arbitrary — it pays for:

• Multi-AZ durability with automatic replication across availability zones in a region, with no application-side configuration.
• POSIX semantics including file locking (flock, fcntl), atomic renames, hard links, and standard Unix permissions.
• Concurrent access from any compute primitive that mounts NFSv4.1 — Lambda, EC2, ECS, EKS, Fargate, on-premises via Direct Connect.
• Elastic capacity that scales without provisioning; no resize operation, no provisioned-IOPS decision, no “filling up” condition.

The premium is genuinely worth it for workloads that need these properties: content-management systems with concurrent author writes, ML training pipelines with shared dataset access from many GPU workers, legacy applications that expect a mounted filesystem, scientific computing with HPC-style shared scratch.

It is not worth it for workloads that don’t use these properties. Read-mostly training data, model artifacts, reference datasets, cache layers, and stateless batch processing all routinely sit on EFS for historical reasons rather than because they need POSIX semantics.

Standard-IA and Archive: The 92–99% Storage Saving Hiding in Plain Sight

EFS Intelligent-Tiering, enabled at the file-system level, automatically moves files between Standard and Standard-IA (and Archive) based on access patterns. Without it, every file sits on Standard at $0.30/GB-month forever, even files no one has touched in three years.

The numbers on a 5 TB file system with a typical hot/cold distribution:

The single-click enabling of Intelligent-Tiering is one of the highest-leverage cost optimizations available on AWS. Most file systems have not enabled it.

Elastic Throughput: The 2024 Default That Changed the Pricing Math

Until 2024, EFS throughput was either Bursting (credit-based; throttled under sustained load) or Provisioned ($6/MBps-month; fixed cost regardless of actual usage). Elastic Throughput, introduced in 2023 and the default for new file systems since 2024, replaces both with a per-GB-transferred model: $0.03 per GB read, $0.06 per GB write, scaling instantly to workload demand.

For most workloads, Elastic is cheaper than Provisioned. A workload averaging 50 GB/day read and 20 GB/day write costs about $1.5/day in read fees ($45/mo) plus $1.2/day in write fees ($36/mo) — $81/month total — versus provisioning 100 MBps at $600/month even when the actual peak is much lower than the provisioned rate.

Where Provisioned still wins: workloads with sustained high throughput (above ~25 MBps continuously) where the per-GB Elastic charges accumulate faster than the fixed Provisioned monthly fee.

One Zone Storage: Half the Price for Half the Durability

One Zone storage classes (One Zone Standard at $0.16/GB-month, One Zone-IA at $0.0133/GB-month) store data in a single availability zone rather than replicated across multiple AZs. The price reflects the reduced durability: an AZ failure means data unavailability until the AZ recovers, and a true regional AZ destruction means data loss.

For regenerable data — model training datasets that can be re-downloaded from a primary source, scratch space, cache layers, ML model artifacts that re-publish from a CI/CD pipeline — One Zone is correct and saves 47–95% on storage. For primary production data, multi-AZ is the right insurance and the premium is worth it.

The waste pattern: defaulting to multi-AZ for all EFS file systems out of habit, including ones whose data is trivially regenerable.

Lambda S3 Files: The 13× Cheaper Alternative for the Right Workload

We covered the architectural decision in our Lambda S3 Files vs EFS cost and limits post. The pricing summary: S3 Standard is $0.023/GB-month against EFS Standard’s $0.30/GB-month — a 13× difference. For workloads where Lambda S3 Files’ six documented limitations (no flock(), eventual consistency on writes, throughput caps, etc.) are acceptable, the storage saving alone justifies the migration on any file system over a few hundred GB.

The decision tree from that post:

1. Does the workload need POSIX file locking? → Stay on EFS.
2. Does the workload need strict write consistency? → Stay on EFS.
3. Does the workload need sustained high write throughput? → Stay on EFS (or evaluate FSx for Lustre for HPC patterns).
4. Otherwise → Lambda S3 Files (for Lambda-mounted access) or direct S3 SDK (for API-driven access).

For the GPU training dataset case specifically, S3 with a Mountpoint for S3 client often outperforms EFS at a fraction of the cost.

Common EFS Bill Surprises

When EFS Is and Is Not the Right Storage

A 30-Day EFS Bill Cleanup Plan

Week 1 — Enable Intelligent-Tiering everywhere. Audit file systems via aws efs describe-file-systems --query "FileSystems[].LifecyclePolicies". Enable Intelligent-Tiering with a 30-day transition threshold on every file system over 100 GB. This typically recovers 60–80% of the storage line within 30 days as cold files transition.

Week 2 — Audit Provisioned Throughput. Identify file systems still on Provisioned Throughput via aws efs describe-file-systems --query "FileSystems[].ThroughputMode". For each, compare actual usage (CloudWatch BurstCreditBalance history and DataReadIOBytes / DataWriteIOBytes) against provisioned rate. Switch to Elastic Throughput where utilization is consistently below 80% of provisioned.

Week 3 — Identify migration candidates. For each remaining file system over 500 GB, classify the workload by access pattern. Single-writer database storage → migrate to EBS gp3. Read-mostly training data → migrate to S3 with Mountpoint or Lambda S3 Files. Sustained high-throughput HPC → consider FSx for Lustre. Document the decision per file system.

Week 4 — Backup retention. Audit AWS Backup plans backing EFS sources. Apply explicit retention policies. Move long-term retention to S3-based AWS Backup vaults rather than retaining EFS-side recovery points.

Cross-check the S3 alternative pricing in our S3 pricing calculator when scoping migration candidates.

What This Post Doesn’t Cover

• EFS Replication (cross-region) — billed as a combination of source/destination storage and inter-region transfer; treat as a separate budget line.
• EFS-on-FSx-for-Windows — different product entirely; pricing model is different (per-GB throughput-capacity).
• Cross-account EFS access — uses AWS RAM and standard EFS pricing; no additional EFS-side charge.
• In-depth FSx for Lustre comparison — covered in a separate HPC-focused post; relevant when sustained throughput requirements exceed what EFS provisioned mode can serve cost-effectively.

If You Only Do One Thing This Week

Enable Intelligent-Tiering on every EFS file system over 100 GB with the default 30-day transition threshold. The change is non-destructive, happens in the background, and typically recovers 60–80% of the storage line within 30 days. Pair with a quarterly review of FilesAccessedFromIA and MeteredIOBytes CloudWatch metrics to confirm the tiering ratio is working as expected. For file systems with stale data older than a year, also enable Archive-tier transition for a deeper saving on truly-cold files.

For the architectural decision of whether to stay on EFS at all, the Lambda S3 Files vs EFS guide lays out the decision tree.