EFS file systems with no reads, writes or clients
What does ZopNight detect here?
ZopNight flags an EFS file system when reads, writes and client connections are all flat for 30 days. EFS bills per GB stored regardless of access, so an unused file system keeps charging for data nobody has touched in a month.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-076 |
| Category | idle |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | efs_idle.go |
Where it applies
Storage bills whether or not anyone reads it
EFS charges for data stored, not for data accessed. A file system holding 500 GB costs the same whether it served a million reads last month or none. That is why an idle EFS is worth finding: the cost is entirely disconnected from the utilisation.
Three signals
DataReadIOBytesTotal, DataWriteIOBytesTotal and ClientConnections, three of the file-system
series EFS reports to CloudWatch, all flat across 30 days.
Connections matter alongside the byte counters because a mounted-but-unused file system behaves differently from an unmounted one. A file system with live mounts and no I/O is a workload that stopped rather than a file system nobody attached: same cost, different conversation with the owner.
Lifecycle policy before deletion
EFS has an Infrequent Access storage class at a fraction of the standard rate, and a lifecycle policy moves files there automatically after a configurable idle period. For data that must be retained but is genuinely cold, that is the answer rather than deletion, since it keeps the file system mountable while cutting the storage rate substantially.
Deletion is right when the data itself is obsolete. Lifecycle is right when the data matters and the access pattern does not justify standard storage.
Reading ClientConnections for the file system
aws cloudwatch get-metric-statistics \ --namespace AWS/EFS --metric-name ClientConnections \ --dimensions Name=FileSystemId,Value=fs-0123456789abcdef0 \ --start-time "$(date -u -v-30d +%Y-%m-%dT%H:%M:%SZ)" \ --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \ --period 86400 --statistics MaximumBefore deleting
Check the mount targets and the security groups that allow access to them. A file system with no I/O but live mount targets is still attached to running infrastructure, and deleting it produces hung mounts rather than a clean removal. Back the contents up to S3 first. EFS deletion is not recoverable.