EFS pricing: storage is the cheap half (2026)

Amazon EFS storage costs $0.30 per GB-month on the Standard class in US East (N. Virginia), and that is usually the smaller half of the bill. The larger half is the throughput meter, which nobody budgets because it has no capacity to look at. Elastic Throughput charges $0.03 per GB read and $0.06 per GB written. Provisioned Throughput charges $6 per MB/s-month instead. AWS prices the same workload under both meters in its own FAQ and never says which one won.

What does Amazon EFS charge per GB-month by storage class?

The EFS pricing page renders its rate tables in JavaScript, so the rates below come from the prose worked examples on the EFS FAQ, all US East (N. Virginia). The pricing page summarises the model honestly: "You pay only for the primary and backup storage you use and for your read, write, and tiering activity to your EFS file system."

Moving a terabyte from Standard to IA saves $283.50 a month. Almost every EFS cost article stops at that row, and almost every EFS bill is decided by the ones underneath it.

What is the difference between EFS Elastic, Provisioned and Bursting throughput pricing?

Three modes, three unrelated meters. The EFS performance specifications describe what each delivers; the FAQ prices them.

Bursting is free and also the slowest. Its allowance is set by how much you store: "the base throughput is proportionate to the file system's size in the Standard storage class, at a rate of 50 KiBps per each GiB of storage". A 100 GB file system gets 5 MB/s, indefinitely. One more line changes every comparison below: "Amazon EFS meters read operations up to one-third the rate of write operations", so a provisioned 100 MB/s carries 300 MB/s of pure reads.

At what monthly volume does EFS Provisioned Throughput beat Elastic Throughput?

AWS answers this by accident. Its FAQ runs one workload through both meters: 100 GB of Standard storage, 75% reads, "a peak throughput of 100 MB/s for 3 hours a day and 3 days a week", idle otherwise. Elastic gives "Total Monthly Elastic Throughput Charge = $291.60 + $194.40 = $486.00". Provisioned at 100 MB/s gives "Total monthly Provisioned Throughput Charge = 95 MB/s-Month * $6/MB/s-month = $570.00". Same file system, same traffic: Provisioned costs 17.3% more, and AWS never puts the two totals in one sentence.

At the FAQ's own "blended Elastic Throughput cost of $0.0375/Gb transferred", $570 buys 15,200 GB, which is 3.5 days a week instead of 3. Expressed as a share of the provisioned peak, all hypothetical arithmetic on AWS's published rates:

AWS's own rule of thumb is a single number. The performance guide says to use Elastic "when your application drives throughput at an average-to-peak ratio of 5% or less", and Provisioned "at an average-to-peak ratio of 5% or more". That 5% is right for a workload that is about half writes. For a read-only workload the crossover is 7.5%, so following the rule at 5% moves you to Provisioned while Elastic is still 33% cheaper.

Getting it wrong is not instantly reversible. After switching to Provisioned or changing the amount, switching back and "Decreasing the Provisioned throughput amount" are both "restricted for a 24-hour period".

Is EFS Bursting throughput free, or does EFS Standard storage pay for it?

Standard storage pays for it, at exactly the Provisioned rate. In the FAQ's own units, baseline throughput is 50 KBps per GB of Standard storage, so 1 MB/s needs 20 GB, and 20 GB at $0.30 costs $6.00 a month. Provisioned Throughput costs $6.00 per MB/s-month. Identical to the cent.

AWS documents that equivalence nowhere, and it settles the mode question. On a large file system Bursting hands you throughput you have already bought. On a small one Bursting is not cheap, it is unavailable: nothing buys a 100 GB file system more than 5 MB/s of sustained write throughput, and the only ways up are Elastic or Provisioned.

How often can you read EFS Infrequent Access before it costs more than EFS Standard?

About 28 times a month, which in practice means never. IA saves $0.2835 per GB-month against Standard and charges $0.01 per GB read on top of the Elastic read charge, so you would have to read every byte of that gigabyte 28 times before the access fee caught the storage saving. The default lifecycle configuration moves files to IA after 30 days without access, and read frequency is almost never the reason that loses money.

File size is the reason. The pricing page footnote: "IA and Archive have a minimum billable file size of 128 KiB. Files smaller than 128 KiB can be tiered to these storage classes but will be charged for 128 KiB of storage at the appropriate storage class rate." The metering documentation adds that "Data access for IA and Archive storage is metered in 128 KiB increments" too. Set 128 KiB of IA against Standard and the crossover is a metered file size of 7.04 KiB. Regular file data is metered in 4 KiB increments, so files metered at 4 KiB cost more in IA than in Standard and files at 8 KiB or above cost less. Hypothetically:

A million 4 KiB files cost 1.76 times as much in IA as in Standard. Archive, cheaper per GB, clears the same floor at 3.41 KiB and never loses on size. S3 has the same trap with different constants, in the S3 storage class minimums that quietly raise your bill. Two charges sit underneath. Per-file metadata never leaves the expensive class: "IA and Archive file metadata (2 KiB per file) is always stored and metered in the Standard storage class". And on Elastic Throughput "Data operations are metered in 1 KiB increments after the first 32 KiB", so a 4 KiB random read is billed as 32 KiB.

Does EFS Archive save money if you read the data once a month?

Against Standard, yes, overwhelmingly. Against IA, no. Archive saves only $0.0085 per GB-month over IA while charging $0.03 per GB read instead of IA's $0.01. Read more than 42.5% of your Archive data in a month and IA would have been cheaper. Over a year that is 5.1 full reads, about what the EFS features page means by "accessed a few times each year or less". The guidance is right; the margin behind it is thinner than it sounds.

Tiering makes the window tighter. Moving a GB from IA to Archive costs $0.03, which takes 3.5 months of the $0.0085 saving to repay, while Archive's minimum storage duration is 90 days. The minimum expires before the transfer has paid for itself. A round trip costs $0.06 and needs 7.1 months. Straight from Standard to Archive is different: the saving is $0.292 per GB-month and the $0.03 repays in about three days.

Nothing moves back by default. The lifecycle management guide says "By default, files are not moved back to the Standard storage class, and they remain in the IA or Archive storage class when they are accessed." Setting Transition into Standard to On first access buys latency and starts paying tiering in both directions. Writes cross back regardless: "All write operations to files in the file system's IA or Archive storage classes are first written to Standard storage classes".

Why can't an EFS file system use Archive storage and Provisioned Throughput together?

Because AWS forbids it, in one sentence on the features page: "The EFS Archive storage class is supported on EFS file systems with Elastic throughput. If your file system has a lifecycle policy that transitions data to Archive, you cannot change the throughput mode to Bursting or Provisioned."

That coupling is the most expensive line in EFS pricing and it appears on no pricing page: the cheapest storage class is available only on the throughput mode that bills per GB. A cold archive with an occasional bulk scan is exactly the workload where Bursting would be free, and exactly the one barred from it.

Backups escape the read fee: "You don't incur data access charges when using AWS Backup to back up lifecycle management-enabled EFS file systems". What they do cost is in what AWS Backup actually costs per GB.

Is Amazon EFS more expensive than Amazon EBS gp3 for the same gigabyte?

Yes: 3.75x on storage and 100x on provisioned throughput. The EBS pricing page works its gp3 example at "$0.08 per GB-month" and "$0.06 per provisioned MB/s-month", against EFS Standard at $0.30 and EFS Provisioned Throughput at $6.00.

gp3 includes "a free baseline performance of 3,000 provisioned IOPS (input/output operations per second) and 125 provisioned MB/s throughput" on any volume size. Matching that 125 MB/s through EFS Bursting takes 2,500 GB of Standard storage, $750 a month. That is the price of shared-filesystem semantics and a multi-AZ write path: a fair trade when you need them, a bad one when a single instance mounts the file system. EBS has its own idle meters, in a stopped EC2 instance's bill and what EBS snapshots really cost.

Two adjacent charges belong in the estimate. One Zone file systems are priced separately, on their own tab of the pricing page, and the EFS overview is explicit about what the single zone costs you: "data that is stored in these types of file systems might be lost". And reading across a zone boundary is billed twice. The pricing page says "you will be charged the EC2 cross-AZ data transfer rate ($0.01/GB) for data transfer" both in and out, turning a $0.03 Elastic read into $0.05. That is the subject of cross-AZ data transfer charges.

Which numbers in AWS's own EFS pricing examples are wrong?

The IA rate changes mid-page. The FAQ's storage example charges "392,400 GB-Hours x (1 month / 744 hours) x $0.0165/GB-month = $8.70". Its replication example, same page, same Region, charges "576,000 * (1 month / 744 hours) * $0.025/GB-month = $19.36". Both totals check out against their own rate, so one rate is stale. The FAQ's TCO table reproduces $0.0165, so that is the figure used here.

The IA usage line does not add up. The FAQ prints "Total EFS IA usage (GB-Hours): 168,000 GB-Hours + 40,800 GB-Hours + 326,400 GB-Hours = 392,400 GB-Hours". Those addends sum to 535,200. The correct third term, 450 GB for 17 days, is 183,600, and that does total 392,400. The total is right; the sum printed above it is not.

The hours-in-a-month convention changes between examples. The storage examples divide by 744 hours. The scratch-data TCO example bills 1,024 GB for 60 hours as $25.60, which is 720 hours. At 744 the same line is $24.77. Neither convention is wrong, but using both makes two totals incomparable.

Terabytes appear where gigabytes are meant. The first TCO example describes a 2.7 TB file system, then splits it into "145 TB" of SSD, "527 TB" of IA and "2,027 TB" of Archive. Those add to 2,699, and the table beside the prose labels the same three numbers GB-mo.

One more inconsistency is not arithmetic. The features page gives Regional and One Zone the same "99.999999999% (11 9s)" durability and the same 99.99% availability in one table, then lists the Availability SLA in the next as "99.99% (Regional)" and "99.9% (One Zone)". The durability figures match because the engineering does. The availability figures do not match each other.

None of this makes EFS a bad service. It makes the FAQ a document to recompute rather than quote, and that habit is worth carrying to the bill. EFS throughput and tiering arrive as separate usage types from storage, which is what the difference between Cost Explorer and the CUR is for. Metadata counts as throughput: the FAQ confirms "EFS data transfer charges for metadata operations such as list (ls), remove (rm), and create directory (mkdir)", which is why a nightly find across millions of files lands on an Elastic Throughput bill and nowhere in a storage graph. The per-Region ceilings are in the EFS quotas page.