Idle EFS file systems have no or near-zero read/write throughput over the last 30 days but still incur storage charges. This is different from missing lifecycle policy, where the file system may still be actively used but all data stays in Standard storage.
Before you delete
- Confirm no EC2 instances, ECS tasks, Lambda functions, or other workloads still mount this file system.
- Check mount targets in each VPC — active mount targets mean something may still depend on this EFS.
- Create an AWS Backup recovery point first if the data might be needed later.
Deleting an idle file system
All mount targets must be removed before the file system itself can be deleted. Paid plans include remediation scripts that list mount targets, delete them, and then delete the file system.
Savings equal 100% of ongoing storage charges for the file system — Parsivex estimates this at the Standard storage rate ($0.30/GB-month) multiplied by total stored size.
AWS EFS delete-file-system does not support --dry-run — review commands carefully before running them.
What triggers this finding
An EFS file system with no or near-zero read/write throughput over the lookback window.
Typical fix
Delete the file system if no workloads mount it. Confirm EC2 instances and Lambda functions no longer depend on it.
Example savings
100% of storage charges — scales with stored data (e.g. $0.30/GB-month for Standard storage).
See also: Severity and savings estimates for how Parsivex calculates figures on your report.
How EFS storage is billed
EFS has no instance to stop. There is no equivalent of shutting down an idle EC2 instance and paying only for the disk — with EFS the storage is the bill, and it accrues per GB-month for every byte the file system holds, whether or not a single client has it mounted. Standard storage runs $0.30 per GB-month in us-east-1, which is around thirteen times the S3 Standard rate and nearly four times gp3 EBS. That multiplier is why a forgotten 400 GB file system is a $120-a-month line item rather than a rounding error.
Parsivex flags a file system when combined DataReadIOBytes and DataWriteIOBytes over 30 days come to less than 10 MB, the file system holds at least 0.1 GB, it is more than 30 days old, and its state is available. The estimate is the full stored size at the Standard rate, because deleting the file system removes all of it.
One cost sits outside that figure. If the file system uses Provisioned Throughput, you are billed per MB/s per month for the provisioned level regardless of whether any I/O occurs — an idle file system on provisioned throughput therefore costs more than the storage estimate suggests. Parsivex records the throughput mode on the finding, so check it there before deciding how urgent the cleanup is.
Checking file system I/O yourself
The two metrics behind the finding, summed exactly as the detector sums them:
aws cloudwatch get-metric-statistics --namespace AWS/EFS \
--metric-name DataReadIOBytes \
--dimensions Name=FileSystemId,Value=fs-0123456789abcdef0 \
--start-time 2026-07-12T00:00:00Z --end-time 2026-08-11T00:00:00Z \
--period 86400 --statistics Sum
Repeat with --metric-name DataWriteIOBytes and add the daily sums together. Under 10 MB across a month is effectively nothing — a single directory sync would exceed it.
Then find out whether anything can still reach the file system, which is a stronger signal than the metrics:
aws efs describe-mount-targets --file-system-id fs-0123456789abcdef0 \
--query 'MountTargets[].[MountTargetId,SubnetId,LifeCycleState]' --output table
A file system with no mount targets cannot be reached by anything and is safe to reason about. One with live mount targets in a production subnet deserves a look at which instances hold them before you go further.
Quiet file systems that are still in use
DataReadIOBytes and DataWriteIOBytes count data movement, not metadata operations. A file system that is mounted and constantly listed, stat-ed, or lock-checked — but whose file contents are never read — reports near-zero data I/O and lands on this report while being actively depended on. Configuration directories, lock files, and shared state used only for coordination all behave this way.
Other correct-but-misleading cases:
- Restore targets. A file system that exists to receive a disaster-recovery restore is meant to sit empty and quiet. Its value is availability on the day it is needed.
- Compliance archives. For retained data, "no reads for 30 days" is the expected steady state, not a symptom. Here the finding is right about the cost and wrong about the remedy — the answer is lifecycle management moving that data to Infrequent Access or Archive, not deletion.
- Seasonal pipelines. Batch systems that run quarterly leave a file system dormant for months by design.
The size and age floors keep the noise down at the other end: a file system under 0.1 GB or younger than 30 days is never flagged, however quiet it is.
Deletion order, downtime, and recovery
EFS has no recycle bin. Once delete-file-system returns, the data is gone, and the only route back is an AWS Backup recovery point or a copy you made yourself. Restores create a new file system with a new ID, so anything referencing the old one — mount commands, task definitions, access points — needs updating even in the recovery path. Take the backup first; it is cheap next to the alternative.
The order of operations carries its own risk. Mount targets must be deleted before the file system, and removing a mount target cuts NFS access immediately for every client in that subnet. NFS hard mounts do not fail cleanly when the server disappears — they block. Processes hang in uninterruptible I/O rather than returning an error, which can wedge an instance badly enough to need a reboot. Confirm nothing has the file system mounted before removing mount targets, rather than assuming a hang will announce itself.
If you are not yet confident, there is a reversible middle step that captures much of the saving: leave the file system in place and enable a lifecycle policy so untouched data drops to Infrequent Access or Archive. Storage cost falls substantially, nothing is lost, and you can re-check the I/O metrics next month with the decision still open.