Amazon EFS Pricing: Complete Guide + Calculator (2026)

Amazon EFS pricing has five distinct billing dimensions. Most guides cover two. That gap is exactly why engineers end up on AWS re:Post asking "why is my EFS bill so high?" after expecting charges based only on the storage rate they saw on the pricing page.

EFS Standard costs $0.30/GB-month. Enable lifecycle management and the effective rate drops to $0.0315/GB for mixed workloads. The path from $0.30 to $0.0315 runs through three storage tiers, three throughput modes, cross-AZ data transfer charges, metadata operation billing, and backup costs that live in a completely separate AWS console. This guide covers all of it.

By the end, you'll know exactly what drives your EFS bill, how to calculate your specific scenario, what to check when a bill is unexpectedly high, and how to provision a cost-optimized file system in CDK from day one. Use the EFS pricing calculator alongside this guide to model your actual storage volumes and access patterns.

All pricing reflects US East (N. Virginia) unless noted. Prices vary by Region.

EFS Pricing at a Glance

Amazon EFS is a fully managed, serverless NFS file system that scales automatically from gigabytes to petabytes. There's no capacity to provision, no minimum fee, and no setup charge - but there are five billing dimensions that appear on your monthly bill.

Understanding which dimensions apply to your workload is the first step to estimating an accurate monthly cost.

Regional (Multi-AZ) Storage Pricing

All three storage classes are available for Regional (Multi-AZ) file systems, which store data redundantly across multiple Availability Zones. According to the official EFS pricing page, these are the current rates in us-east-1:

One important detail: file metadata (names, ownership, directory structure) always stays in EFS Standard regardless of where the actual file data lives. So even if 95% of your data is tiered to IA or Archive, 100% of your metadata counts toward Standard storage.

With Elastic Throughput (the default mode), you also pay for data transferred on top of storage: $0.03/GB for reads, $0.06/GB for writes.

One Zone (Single-AZ) Storage Pricing

One Zone file systems store data within a single Availability Zone only. The tradeoff is lower durability - if that AZ has a problem, you lose access until it recovers. In exchange, you get roughly 47% lower costs across storage, throughput, and data access charges.

• One Zone Standard: ~$0.16/GB-month (vs $0.30 for Regional)
• One Zone Infrequent Access: ~$0.00858/GB-month (vs $0.0165 for Regional)

Verify exact One Zone pricing for your region on the AWS EFS pricing page - the 47% discount is consistent, but precise rates vary slightly.

Best fits for One Zone: dev/test environments, build caches, staging, analytics pipelines, and media transcoding where durability requirements are lower.

Free Tier: What's Actually Included

New AWS accounts get 5 GB/month of EFS Standard storage on a Regional file system for the first 12 months. A few specifics worth noting:

• Applies to EFS Standard storage on Regional file systems only - not One Zone, IA, or Archive
• Available across all AWS Regions except GovCloud
• Unused monthly free tier does not roll over to the next month
• The 5 GB applies to storage only - Elastic Throughput charges and data transfer fees still apply

Now that you have the rate card, the question becomes which storage class fits your workload. The difference between $0.30 and $0.008/GB is real, but it depends entirely on how often you access that data.

EFS Storage Classes: Which One Do You Actually Need?

EFS offers three storage classes targeting different access frequency profiles. Lifecycle management moves files between them automatically based on access patterns - no application changes required. That automation is what makes the $0.0315/GB effective rate achievable without rewriting anything.

EFS Standard: For Your Hot Data

EFS Standard is SSD-backed, multi-AZ redundant (for Regional file systems), and has a designed durability of 99.999999999% (eleven nines). Performance specs:

• First-byte read latency: as low as 250 microseconds
• First-byte write latency: as low as 2.7 milliseconds
• Supports up to 60 GiBps read throughput / 5 GiBps write throughput per file system (major regions)

Use EFS Standard when applications require sub-millisecond read latency, write data frequently, or when data access patterns are unpredictable. And remember: file metadata always stays in Standard even when data transitions to IA or Archive. That's a source of confusion when you look at StorageBytes in CloudWatch and see Standard storage that's larger than you expected.

EFS Infrequent Access: The 95% Cost Reduction (With a Catch)

EFS Infrequent Access (IA) costs $0.0165/GB-month - 94.5% less than Standard. For data that sits untouched for weeks at a time, that's a meaningful reduction. But there are trade-offs to understand before you enable it.

The catch: every time you read data from IA, you pay $0.01/GB on top of the Elastic Throughput read charge of $0.03/GB. That stacks to $0.04/GB per read operation. If you're reading the same 100 GB of "infrequent" data every day, you're paying $4/day in access charges - which quickly exceeds what Standard storage would have cost.

Other billing rules for IA:

• 128 KiB minimum billing per file - a 1 KiB file in IA is billed as 128 KiB
• No minimum storage duration - unlike Archive, you can delete files without penalty
• Latency: low double-digit milliseconds (not sub-millisecond - latency-sensitive apps will notice)

When IA saves you money: when average monthly reads are less than roughly 30% of stored volume. When it doesn't: high-churn workloads that read data frequently after it moves to IA, or repositories full of tiny files.

EFS Archive: The Deepest Tier (And Its Hidden Traps)

EFS Archive sits at $0.008/GB-month - 50% cheaper than IA, and 97% cheaper than Standard. For genuinely cold data accessed a few times per year, the storage savings are hard to beat. But Archive has two constraints that catch engineers off guard.

First: the 90-day minimum storage duration. If a file moves to Archive and you delete or truncate it within 90 days, AWS charges you for the remaining duration at the Archive rate. For frequently churning data, this can make Archive more expensive than keeping everything in Standard.

Second: writes land in Standard first. When you write to a file in Archive, it lands in EFS Standard and waits 24 hours before transitioning back to Archive. During that window, you're paying Standard rates for that data. This is the expected behavior, but it surprises teams who assumed writes would go directly to Archive.

Access charges for Archive are also higher than IA: $0.03/GB for reads (vs $0.01/GB for IA), plus $0.03/GB for tiering from IA to Archive.

The 128 KiB minimum billing per file applies here too. A workload with millions of small files in Archive is a common bill-shock scenario - more on that in the hidden costs section.

Knowing storage costs is only half the picture. EFS also charges for throughput - how much data you move to and from the file system. That's the next billing dimension.

EFS Throughput Pricing: Elastic vs Provisioned vs Bursting

Throughput billing is where EFS pricing gets genuinely confusing. There are three modes with completely different billing models, and picking the wrong one for your workload can mean paying for capacity you don't use - or facing throttling when you need performance. Here's how each mode works and when to use it.

Elastic Throughput: Pay for What You Use

Elastic is the default and recommended mode for most workloads. You pay per gigabyte transferred, not for reserved capacity:

• Reads: $0.03/GB transferred
• Writes: $0.06/GB transferred
• Metadata operations (ls, rm, mkdir): metered at 4 KiB minimum per operation

There are no burst credits to track. Throughput scales automatically to up to 60 GiBps read / 5 GiBps write per file system in major regions (us-east-1, us-east-2, us-west-2, ap-, eu-). Per-client maximum is 1,500 MiBps with EFS client v2.0+ or the EFS CSI Driver.

One thing to be aware of: if you're accessing files in IA or Archive storage, the IA/Archive per-access charges stack on top of the Elastic Throughput read charge. A read from IA costs $0.03/GB (Elastic) + $0.01/GB (IA access) = $0.04/GB total.

Elastic Throughput works well for spiky or unpredictable workloads - CI/CD pipelines, web application shared storage, ECS task volumes that see burst activity and then go quiet. The billing follows actual usage rather than reserving capacity you might not need.

Provisioned Throughput: Fixed Capacity, Fixed Cost

Provisioned Throughput lets you specify a fixed MB/s level independent of storage size. The pricing model is:

• $6.00 per MB/s-month for throughput provisioned above the included baseline
• Included baseline: 50 KiBps per GiB of EFS Standard storage (5 MB/s per 100 GB of Standard storage)

You only pay for throughput above the included baseline. That means large Standard-class file systems automatically get meaningful included throughput before any provisioning charge kicks in.

Worked example (100 GB Standard storage, provisioning 100 MB/s total):

For comparison, the same workload using Elastic Throughput at 100 MB/s peak, 3 hours/day, 3 days/week:

• Read charges: 9,720 GB x $0.03 = $291.60
• Write charges: 3,240 GB x $0.06 = $194.40
• Total: $486/month

Elastic is cheaper at that usage pattern. But if that same 100 MB/s workload runs consistently 8+ hours a day, Provisioned Throughput starts to win. The decision rule: start with Elastic and run CloudWatch MeteredIOBytes metrics for 2-4 weeks. If average throughput is consistently 5% or more of your peak, do the math on Provisioned.

One operational note: there's a 24-hour wait before you can reduce Provisioned Throughput or switch modes after an increase. Monitor actual usage before provisioning to avoid being locked into higher costs than you need.

Bursting Throughput: The Legacy Option

Bursting Throughput has no separate billing - it's included in storage charges. Throughput scales with how much data you store in EFS Standard:

• Baseline: 50 KiBps per GiB of Standard storage (50 MiBps per TiB)
• Burst rate: 100 MiBps per TiB, for up to 12 hours/day on a 1 TiB file system
• Burst credits accrue when usage is below baseline; consumed when bursting above baseline

AWS doesn't recommend Bursting for new deployments. Elastic Throughput handles spiky workloads more predictably without the burst credit accounting. Bursting still makes sense in one scenario: when your throughput requirements grow proportionally with your stored data volume and you want no separate throughput billing.

The Hidden EFS Costs Most Guides Ignore

This section addresses the questions that show up in AWS re:Post forums precisely because none of the standard pricing guides answer them. These are the charges that look fine on the rate card but cause real bill surprises in production.

Cross-AZ Data Transfer Charges

EFS mount targets are AZ-specific. When compute in one AZ accesses an EFS mount target in a different AZ, you pay cross-AZ data transfer charges - $0.01/GB in each direction.

Round-trip access (in + out) costs $0.02/GB. For a workload processing 500 GB/day from the wrong AZ, that's $10/day or $300/month in transfer charges that don't appear on the EFS pricing page.

The fix is simple: create an EFS mount target in every AZ where your compute runs. For Regional file systems, each AZ needs its own mount target. EC2 instances, ECS tasks, and EKS pods should always mount from the AZ-local endpoint. Same-AZ access has no data transfer charge.

Metadata Operation Charges

Under Elastic Throughput, every file system metadata operation is metered at a minimum of 4 KiB. This includes ls, rm, mkdir, stat, and similar operations.

A single ls on a directory with 10,000 files charges 10,000 x 4 KiB = 40 MB of read throughput at $0.03/GB = $0.0012. That's negligible for a one-time operation. But a monitoring agent running ls -la on a large directory tree every 30 seconds will accumulate meaningful charges.

The practical implication: metadata operations are not free. Polling-based file watchers, backup agents that enumerate every file on every run, and health checks that scan the mount point all appear as throughput charges on your bill.

Backup Storage: Why It's Larger Than Your Data

AWS Backup handles EFS backups using an incremental-forever model. The first backup copies everything. Subsequent backups copy only changed files - but "changed" includes any modification to file metadata: permissions, ownership, timestamps, extended attributes.

This means a file that hasn't changed in content but had its permissions updated at 2am (from a cron job, an OS update, or a configuration management tool) gets backed up again. Over time, backup storage can grow significantly larger than your primary EFS storage.

Backup storage is billed separately from primary EFS storage and does not appear in the EFS StorageBytes CloudWatch metric. When diagnosing an unexpectedly high bill, check the AWS Backup pricing and the AWS Backup console - not just the EFS console.

The Small File Problem: 128 KiB Minimum Billing

Both EFS Infrequent Access and Archive bill a minimum of 128 KiB per file, regardless of actual file size.

Here's where this becomes a significant cost trap. If you have a repository with 1 million files averaging 1 KiB each, that's 1 GB of actual data. Move those files to IA, and you're billed for 1 million x 128 KiB = 128 GB of IA storage, not 1 GB. At $0.0165/GB-month, that's $2.11/month for what looks like 1 GB of IA data - compared to $0.30 if you left it all in Standard.

Before enabling lifecycle management for workloads with small files, check the CloudWatch StorageBytes metric broken down by storage class after a test run. If average file size is below 128 KiB, lifecycle tiering may cost more than staying in Standard.

Now that you know what drives EFS costs, here's what those costs look like in dollar terms for three realistic scenarios.

Real-World EFS Cost Examples

All examples use us-east-1 pricing. Use the EFS pricing calculator to input your actual volumes and access patterns.

Scenario 1: Shared Dev Environment (One Zone, Lifecycle Enabled)

Setup: 100 GB total, moderate daily access to 30% of files, 70% cold after 14 days. One Zone file system with lifecycle enabled at 14 days. Elastic Throughput. Light read activity (~5 GB/day reads, ~1 GB/day writes).

Without lifecycle (all data in One Zone Standard):

With lifecycle (30 GB Standard, 70 GB IA after 14 days):

Savings with lifecycle enabled: approximately 45% reduction ($10.10/month saved). For a team running 10 dev environments, that's $1,200/year from one configuration change.

Scenario 2: ECS Production Workload (Regional, Elastic Throughput)

Setup: 500 GB total storage, 80% actively accessed (400 GB Standard, 100 GB IA), Regional Multi-AZ, Elastic Throughput. Traffic pattern: 200 GB/day reads, 50 GB/day writes.

For this workload, check whether Provisioned Throughput would be cheaper. If average throughput is consistently above 5% of peak (say, 10+ MB/s average for a 200 MB/s peak), run the provisioned calculation: (provisioned MB/s - included baseline) x $6.00/MB/s-month. With 400 GB of Standard storage, your included baseline is 400 GB x 50 KiBps/GiB / 1,024 = ~19.5 MB/s before you'd pay anything for Provisioned Throughput.

Scenario 3: Long-Term Data Archive (Full Lifecycle Tiering)

This is the official AWS FAQ example. Starting point: 2.7 TB total data (before lifecycle runs). After lifecycle reaches steady state with 200 GB Standard + 500 GB IA + 2 TB Archive:

Effective rate: $0.0315/GB versus $0.30/GB without tiering - an 89.5% reduction on storage costs. Source: Amazon EFS FAQ

Important caveat: the first 90 days after enabling Archive have higher costs. Files that moved to Archive haven't yet exhausted the minimum 90-day duration, and any deletions during that window incur pro-rated charges. Factor in a 3-month ramp period before the full steady-state savings are realized.

How to Reduce Your EFS Bill

The good news: most EFS cost optimization requires configuration changes, not architectural rewrites. Here are the highest-impact levers in order of ROI.

Enable Lifecycle Management (The Single Biggest Lever)

Lifecycle management is free to enable and can reduce storage costs by up to 97% on cold data. The AWS lifecycle management documentation covers all configuration options.

The three policies you can set per file system:

• Transition into IA: after 14, 30, 60, or 90 days without access (Standard to IA)
• Transition into Archive: after 90, 180, 270, or 365 days without Standard-class access
• Transition into Standard (Intelligent-Tiering): promotes files back to Standard on first access from IA or Archive

A few things lifecycle management does not do:

• It applies to the entire file system, not per-directory
• Metadata always stays in Standard regardless of policy
• Metadata operations (ls, stat) do not reset lifecycle timers or count as file access
• Writes to IA/Archive files temporarily land in Standard first

Before enabling for small-file workloads: calculate average file size using du from a mounted instance. If average file size is below 128 KiB, lifecycle tiering to IA/Archive will likely cost more than Standard due to the minimum billing per file.

Switch Non-Critical Workloads to One Zone

One Zone file systems cost approximately 47% less than Regional across storage, throughput, and access charges. The switch takes one configuration change in CDK, Terraform, or the console.

Good candidates: dev/test environments, build caches, CI/CD pipeline artifacts, staging environments, analytics pipelines operating on secondary copies, media transcoding temp storage.

Not appropriate for: production file shares that need Multi-AZ durability, workloads accessed from instances in multiple AZs (cross-AZ access charges would eat the savings).

Pick the Right Throughput Mode

Start with Elastic Throughput - it's the default and handles most workloads well. Then monitor CloudWatch for 2-4 weeks before deciding whether Provisioned Throughput would be cheaper:

• MeteredIOBytes: actual throughput consumed. This is the basis for Elastic Throughput billing.
• PermittedThroughput: maximum allowed in the current mode. If MeteredIOBytes frequently approaches PermittedThroughput, you may need to evaluate your mode.
• PercentIOLimit: IOPS utilization in General Purpose mode. High values suggest evaluating Provisioned mode.

If average throughput is consistently 5% or more of peak, calculate Provisioned Throughput cost. Compare against your actual Elastic Throughput charges over the same period. Switch only when the math is clearly better - and remember the 24-hour wait before you can reduce throughput again.

Monitor What You're Actually Using

Four CloudWatch metrics tell you most of what you need for cost governance:

Set up a CloudWatch dashboard with StorageBytes broken down by storage class. Watching that metric over 30-60 days after enabling lifecycle management shows you exactly how much data is moving to IA and Archive, and whether the tiering savings are materializing as expected.

EFS vs EBS vs S3: Which Storage Service Fits?

EFS is not the cheapest storage option per GB. It earns its cost when two things are true: applications need a POSIX-compatible file system, and that storage needs to be concurrently accessible from multiple compute instances.

EFS vs Amazon S3: When POSIX Semantics Matter

EFS Standard at $0.30/GB-month is approximately 13x more expensive than S3 Standard at ~$0.023/GB-month for equivalent storage volume.

S3 is object storage accessed via HTTP API. It cannot be mounted directly as a file system without FUSE-based workarounds like s3fs or Amazon's own Mountpoint for S3, which add operational complexity and performance constraints.

Choose EFS over S3 when your applications use standard file I/O (open(), read(), write(), close()), depend on POSIX semantics like file locking and directory structure, or require concurrent multi-writer access from multiple instances. ECS containers using shared configuration files, ML training pipelines that need random file access across a dataset, and Lambda functions that need to share state across invocations are all use cases where EFS's file semantics justify the cost premium.

If your application accesses data through an API and doesn't need a mounted file system, S3 is the right choice and significantly cheaper.

EFS vs Amazon EBS: Shared Access vs Single-Instance

EBS gp3 volumes cost $0.08/GB-month (provisioned) - about 3.75x cheaper than EFS Standard for equivalent capacity. For single-instance workloads, EBS wins on both price and latency.

But EBS volumes attach to a single EC2 instance. Multi-Attach for gp3 exists but is restricted to specific scenarios (same AZ, up to 16 instances, requires cluster-aware filesystem management). It's not a general-purpose solution for shared storage.

EFS scales to 25,000 concurrent connections from EC2, ECS, EKS, Lambda, and SageMaker instances across multiple AZs, without any special configuration. For shared persistent storage across a distributed application, EFS vs EBS isn't really a comparison - they solve different problems.

Use EBS when: single-instance block storage with low latency is needed (databases, boot volumes, high-IOPS applications). Use EFS when: storage must be shared concurrently across multiple compute resources. If you're calculating ECS compute costs alongside EFS, the shared storage model is usually the right choice for container workloads that need to share files.

Check the EBS pricing calculator if you're comparing EBS volume options for single-instance use cases.

Provisioning Cost-Optimized EFS with AWS CDK

The CDK section is where pricing decisions get encoded into code. Every choice covered in this guide maps to a specific CDK property. Getting them right at provision time costs nothing. Getting them wrong means paying unnecessary charges in production until someone notices and fixes it.

If you're new to structuring CDK stacks, the CDK best practices guide and CDK project structure guide are worth reading before building out your EFS stack. Taking an Infrastructure as Code approach to EFS configuration is what prevents costly defaults from reaching production unnoticed.

Here's a CDK TypeScript stack that provisions both a cost-optimized Regional file system and a One Zone file system for non-critical workloads:

import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as efs from 'aws-cdk-lib/aws-efs';
import { Stack, StackProps } from 'aws-cdk-lib';
import { Construct } from 'constructs';

export class EfsStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);

    const vpc = new ec2.Vpc(this, 'VPC');

    // Regional (Multi-AZ) EFS with full lifecycle tiering - lowest TCO
    const regionalFileSystem = new efs.FileSystem(this, 'RegionalEfsFileSystem', {
      vpc,
      lifecyclePolicy: efs.LifecyclePolicy.AFTER_30_DAYS,           // Standard to IA after 30 days
      transitionToArchivePolicy: efs.LifecyclePolicy.AFTER_90_DAYS, // IA to Archive after 90 days
      outOfInfrequentAccessPolicy: efs.OutOfInfrequentAccessPolicy.AFTER_1_ACCESS, // Intelligent-Tiering
      performanceMode: efs.PerformanceMode.GENERAL_PURPOSE,          // Default, recommended
      // throughputMode defaults to ThroughputMode.ELASTIC - pay per GB transferred
      encrypted: true,
    });

    // One Zone (Single-AZ) EFS - ~47% cheaper for non-critical workloads
    const oneZoneFileSystem = new efs.FileSystem(this, 'OneZoneEfsFileSystem', {
      vpc,
      oneZone: true,
      vpcSubnets: { availabilityZones: ['us-east-1a'] }, // Pin to a single AZ
      lifecyclePolicy: efs.LifecyclePolicy.AFTER_14_DAYS,
      outOfInfrequentAccessPolicy: efs.OutOfInfrequentAccessPolicy.AFTER_1_ACCESS,
      performanceMode: efs.PerformanceMode.GENERAL_PURPOSE,
      encrypted: true,
    });

    // Access Point - share one file system across multiple apps without redundant storage
    regionalFileSystem.addAccessPoint('AppAccessPoint', {
      path: '/app-data',
      createAcl: { ownerUid: '1001', ownerGid: '1001', permissions: '755' },
      posixUser: { uid: '1001', gid: '1001' },
    });
  }
}

A few CDK-specific notes on cost implications:

• PerformanceMode.MAX_IO is incompatible with Elastic Throughput and One Zone file systems. Avoid it for new deployments - it's a legacy mode. Performance mode cannot be changed after file system creation, so get this right at provision time.
• throughputMode defaults to ThroughputMode.ELASTIC if not specified. Being explicit makes the intent clear in code review.
• outOfInfrequentAccessPolicy: AFTER_1_ACCESS enables Intelligent-Tiering. Omit this if re-accessed data doesn't need sub-millisecond Standard latency - it adds a Standard access charge every time a tiered file is read.
• The oneZone: true flag combined with vpcSubnets: { availabilityZones: [...] } pins the file system to a specific AZ. Make sure your compute in that AZ mounts this file system to avoid cross-AZ charges.

CloudBurn can show EFS cost estimates directly in pull requests when you're making infrastructure changes - catching a missing lifecycle policy or a One Zone vs Regional choice during code review rather than on the next monthly bill. That's the shift-left cost visibility approach in practice.

Key Takeaways

EFS pricing has five dimensions: storage class, throughput mode, data transfer, metadata operations, and backup. Most unexpected bills trace back to throughput charges or cross-AZ transfer - neither appears prominently on the storage rate card.

The practical summary:

1. Lifecycle management is the highest-ROI change you can make. Enable Standard to IA after 30 days and IA to Archive after 90 days. Zero application changes required. Effective rate drops from $0.30/GB to as low as $0.0315/GB for cold data.
2. One Zone saves 47% for non-critical workloads. Dev, staging, build pipelines, analytics - switch them to One Zone and capture that savings immediately.
3. Start with Elastic Throughput. Run 2-4 weeks of CloudWatch data before evaluating Provisioned. The 24-hour wait makes it expensive to experiment with Provisioned mode without data to back the decision.
4. Cross-AZ mount targets are silent cost generators. Create a mount target in every AZ where compute runs - same-AZ access is free.
5. Small files in IA/Archive cost more than they save. Check average file size before enabling lifecycle on file systems with large numbers of small files.
6. In CDK, set lifecyclePolicy, transitionToArchivePolicy, and oneZone at provision time. It costs nothing to configure them correctly upfront.

Use the EFS pricing calculator to plug in your actual storage volumes, access patterns, and throughput metrics for a precise monthly estimate.

Frequently Asked Questions