EFS Cost Optimization
Price exercises use hypothetical us-east-1 (US East, N. Virginia) rates for study on 2026-10-12, not current tariffs, unless explicitly identified as a dated published fee.
Amazon EFS cost includes stored data, throughput/access charges and related backup/transfer services. Choose availability and recovery requirements before selecting a cheaper storage configuration.
Storage and lifecycle
Regional file systems support Standard, Infrequent Access and Archive classes under documented configuration requirements. One Zone configurations have distinct availability and lifecycle options; do not treat a one-AZ filesystem as equivalent to Regional storage.
Lifecycle management moves eligible files based on access behavior. IA/Archive access charges, minimum billing sizes and minimum durations can outweigh lower storage rates for small or frequently read files. Archive requires supported Regional configuration/throughput settings. A lifecycle policy is therefore workload-specific, not mandatory for every filesystem.
Transition-on-access can help files that become hot again, but increases transitions/storage costs. Benchmark representative file sizes and read patterns before enabling a policy broadly. Access points provide identity/path controls; they do not independently lower storage rates.
Throughput selection
Compare Elastic, Provisioned and Bursting modes using actual throughput, storage volume and burst behavior. Elastic throughput charges for metered reads/writes; Provisioned throughput has configured-capacity charges under its pricing rules. There is no universal 50% utilization break-even point: rates and the included/baseline behavior matter.
Scenario and drill
A shared build cache contains reproducible artifacts and millions of small files. Measure object sizes and reuse intervals. Compare Regional Standard with eligible lifecycle tiers, and One Zone only if rebuild time and AZ-loss risk satisfy the team’s SLO. Calculate storage, retrieval and throughput separately; do not multiply all bytes by the cheapest rate.
Use an existing authorized filesystem’s metrics or a supplied dataset for the exercise. Produce a proposed lifecycle policy and rollback plan without deleting files or changing production configuration.
Storage and throughput worksheet
| Choice | Useful when | Model before enabling |
|---|---|---|
| Regional Standard | Active shared production data | Regional availability, stored bytes and throughput |
| Regional IA | Eligible colder files | Access charges, size/duration rules and rewarming |
| Regional Archive | Eligible very cold files | Required configuration, access/retention and recall behavior |
| One Zone / One Zone-IA | Acceptable AZ-loss/rebuild risk | Backups, restore time and cross-AZ clients |
| Elastic throughput | Variable demand | Metered read/write work and file operation pattern |
| Provisioned throughput | Predictable sustained need | Configured rate versus included throughput rules |
| Bursting | Suitable storage-linked burst pattern | Credits and sustained throughput limits |
This separates file-system availability from storage class; not all classes exist in every filesystem/mode. “Always enable lifecycle” can be wrong when files are tiny or repeatedly accessed.
Complete illustrative calculation
For a hypothetical us-east-1 exercise dated 2026-10-12, assume 1,000 GB average stored, with 200 GB active at $0.30/GB-month and 800 GB IA at $0.025/GB-month:
all active storage = 1,000 × $0.30 = $300/month
tiered storage = 200 × $0.30 + 800 × $0.025 = $80/month
storage difference = $220/monthAt an assumed $0.01/GB access charge and 5,000 GB of IA reads, add $50, reducing that simplified difference to $170 before throughput, minimum billing and transitions. These rates are arbitrary exercise inputs, not an EFS quotation.
For throughput, estimate metered_read_GB × read_rate + metered_write_GB × write_rate under Elastic, then compare the configured Provisioned option under the actual pricing rules. Do not derive cost from application bytes alone if metering differs. There is no universal 50% break-even.
Lifecycle lab
EFS lifecycle configuration applies to all files in a filesystem, not to an S3-style prefix, access point or application filter. To isolate an application population, use a disposable filesystem containing representative synthetic files; otherwise inventory every population on the existing shared filesystem and keep this a proposal-only exercise. A directory boundary does not isolate policy effects.
Define acceptable retrieval/access performance, test repeated reads and confirm storage-class/throughput eligibility. Compare a no-lifecycle baseline with one candidate filesystem policy, including backups and cross-AZ mounting paths. Record average stored bytes per class, metered access/throughput, small-file overhead and p95 read latency. Apply the calculation above to those observations rather than assuming every cold byte is eligible immediately.
Before any authorized sandbox policy change, inspect and save the prior configuration:
aws efs describe-lifecycle-configuration \
--file-system-id DISPOSABLE_FILE_SYSTEM_ID --region us-east-1Write the proposed transition list separately, with one transition per lifecycle-policy object. The PutLifecycleConfiguration contract replaces the filesystem’s existing configuration; an empty list disables lifecycle management. Restoring the prior configuration stops/changes future transitions but does not instantly return already-tiered files to Standard. Include a rewarming/access-cost plan and protected recovery points. This note changes no production filesystem, and a short sandbox run cannot prove a multi-day cold-file transition.