This finding is distinct from the other EFS findings Parsivex surfaces:
- Idle EFS file system — the file system has no or near-zero read/write throughput over the lookback window, suggesting no active workloads are using it.
- Missing lifecycle policy (this page) — the file system has no TransitionToIA lifecycle policy, so all data stays in Standard storage even when infrequently accessed. Savings estimates assume a conservative share of data could move to Standard-IA once lifecycle management is enabled.
What triggers this finding
An EFS file system with no lifecycle management policy to transition infrequently accessed files to Infrequent Access.
Typical fix
Enable EFS lifecycle management to transition files to IA after a set number of days without access.
Example savings
Up to ~92% savings on cold data — e.g. $5–$50+/month on file systems with large infrequently accessed datasets.
See also: Severity and savings estimates for how Parsivex calculates figures on your report.
What lifecycle management moves, and when
EFS prices each storage class separately and bills you for whatever sits in each: $0.30 per GB-month for Standard in us-east-1, $0.025 for Infrequent Access, and less again for Archive. Lifecycle management is the mechanism that moves files between them. You choose a window — 1, 7, 14, 30, 60, or 90 days — and any file not accessed within it transitions to Infrequent Access automatically. Archive uses the same mechanism with a longer window for data measured in months.
Without a policy, nothing moves. A file written once during a migration three years ago is billed at the Standard rate today, at twelve times the IA rate, purely because no one enabled the setting.
The companion setting is TransitionToPrimaryStorageClass. Set to AFTER_1_ACCESS, a cold file returns to Standard the first time anything reads it, which keeps repeat access at Standard price and speed. That is what makes IA safe for data whose access pattern you cannot predict.
Parsivex flags a file system when it is available, at least 30 days old, holds at least 1 GB in the Standard class, and reports no lifecycle configuration. When the scan cannot determine whether a policy exists, the file system is skipped rather than guessed at. The savings figure assumes 30% of Standard data is cold and prices the difference between the two rates — deliberately conservative, because nothing outside your own access pattern can tell Parsivex how much of your data is actually dormant.
Checking the storage class split
Whether a policy exists is one call, and an empty LifecyclePolicies array is the finding's trigger:
aws efs describe-lifecycle-configuration --file-system-id fs-0123456789abcdef0
The split across classes comes from the file system description:
aws efs describe-file-systems --file-system-id fs-0123456789abcdef0 \
--query 'FileSystems[].{Mode:ThroughputMode,Standard:SizeInBytes.ValueInStandard,IA:SizeInBytes.ValueInIA,Archive:SizeInBytes.ValueInArchive}'
These sizes are metered rather than live and can lag by several hours. For the trend over time — which is what tells you whether a policy you enabled is actually working — use the CloudWatch StorageBytes metric with the StorageClass dimension set to Standard, IA, or Total. Watching Standard fall and IA rise over the days after you enable a policy is the clearest confirmation available.
Note the throughput mode in that output. It determines what reading cold data costs you, and it is the first thing to check before enabling anything.
Data that will not transition
The 30% assumption is a stand-in for knowledge Parsivex does not have, and it is wrong in both directions depending on the workload:
- Files under 128 KB are not moved to Infrequent Access. A file system holding millions of small configuration files, source files, or per-user documents will see almost nothing transition regardless of how cold it is, and the estimated saving will not materialise.
- Hot working sets. If your workload touches essentially everything within the transition window, files either never leave Standard or bounce straight back on first access. You get the churn without the saving.
- Retrieval charges on the wrong throughput mode. File systems using Bursting or Provisioned throughput are billed per GB retrieved from Infrequent Access, and those reads consume throughput as well. On a file system with Elastic throughput there is no IA retrieval fee. Read-heavy workloads on Bursting throughput can genuinely end up worse off — check the mode before enabling a policy.
- Deeply cold archives. Here the estimate understates: if 90% of the data has not been touched in a year, the real saving is triple what the report shows, and Archive rather than IA is the right target.
Risk of enabling lifecycle management
This is one of the least risky fixes on your report. Enabling lifecycle management is a configuration change, it deletes nothing, and it can be turned off at any time:
aws efs put-lifecycle-configuration --file-system-id fs-0123456789abcdef0 \
--lifecycle-policies '[{"TransitionToIA":"AFTER_30_DAYS"},{"TransitionToPrimaryStorageClass":"AFTER_1_ACCESS"}]'
Files stay at the same paths, with the same permissions, readable by the same clients throughout. Transitions run in the background over hours to days, and the bill follows them rather than the setting.
The cost is latency, not availability. First-byte latency on an Infrequent Access file runs into the tens of milliseconds against single-digit milliseconds for Standard, which is invisible for batch work and noticeable for a workload opening many small cold files in sequence. Pairing the policy with AFTER_1_ACCESS bounds that exposure: the first read of a cold file is slow, and everything after it is back at Standard speed and Standard price.
If you are unsure, start with the longest window — 90 days — and watch the class split move for a month before tightening it. Reversing a policy stops future transitions but does not pull data back to Standard on its own; files return as they are read, so the safest sequence is to widen the window rather than to expect an instant rollback.