An Amazon EFS lifecycle policy is supposed to move cold files into the Infrequent Access storage class to cut cost. How does EFS decide which files to move, and what commonly defeats the saving or makes the bill worse?

seniorshould knowfreq 32%

answer

classes are per file, not per file system
the clock is days since last read
listing a directory is not reading it
cheap to store, charged to retrieve
the nightly scan touches everything

basics

~20 s

EFS lifecycle management moves a file to Infrequent Access or Archive after a configured number of days without access to its contents. Infrequent Access charges per GB retrieved and adds latency, so jobs that read every file destroy the saving.

solid answer

~50 s

You attach a lifecycle configuration that says, for example, transition to Infrequent Access after 30 days and to Archive after 90, based on last access time of the file's contents. Metadata operations such as listing a directory do not count as access, but reading a file does. The colder classes are much cheaper per GB stored, but they add per-GB retrieval charges and higher first-byte latency, so the saving depends entirely on the files genuinely staying cold. The classic defeat is a nightly backup, antivirus scan or search indexer that reads the whole tree: every file is accessed, you pay retrieval on all of it, and if the policy also transitions files back to the primary class on first access, everything returns to Standard and the cycle repeats. Verify the workload's access pattern before enabling it.

You attach a lifecycle configuration that says, for example, transition to Infrequent Access after 30 days and to Archive after 90, based on **last access time of the file's contents**. Metadata operations such as listing a directory do not count as access, but reading a file does. The colder classes are much cheaper per GB stored, but they add per-GB retrieval charges and higher first-byte latency, so the saving depends entirely on the files genuinely staying cold. The classic defeat is a nightly backup, antivirus scan or search indexer that reads the whole tree: every file is accessed, you pay retrieval on all of it, and if the policy also transitions files back to the primary class on first access, everything returns to Standard and the cycle repeats. Verify the workload's access pattern before enabling it.

code

bash · 5 lines

bash

aws efs put-lifecycle-configuration \
  --file-system-id fs-0123456789abcdef0 \
  --lifecycle-policies '[{"TransitionToIA":"AFTER_30_DAYS"},
                         {"TransitionToArchive":"AFTER_90_DAYS"},
                         {"TransitionToPrimaryStorageClass":"AFTER_1_ACCESS"}]'

go deeper

for a junior

Know that EFS has cheaper storage classes for cold data and that a lifecycle policy moves files there automatically after a period without access.

for a middle

Explain the mechanics: rules are expressed in days since the file's contents were last accessed, metadata operations do not count, and the colder classes trade a lower storage price for retrieval charges and higher first-byte latency.

for a senior

Show that you audit the access pattern before enabling it — naming backups, antivirus scans and indexers as the things that read every byte — and reason about whether transition-back should be on for a bursty dataset.

for a principal

Question the premise. Decide which data belongs on a shared filesystem at all, set the standard for where cold data lives across teams, and treat storage-class tuning as the smaller lever compared with moving archival data out of EFS entirely.

The storage classes

An EFS file system stores data in tiers rather than one flat pool:

Standard — the primary class: lowest latency, highest price per GB-month.
Infrequent Access (IA) — substantially cheaper per GB, with a per-GB retrieval charge every time data is read and higher first-byte latency.
Archive — colder and cheaper still, with a higher retrieval charge and higher latency again, intended for data touched a few times a year at most.

A parallel set of One Zone classes trades multi-AZ resilience for a lower price by keeping data in a single Availability Zone.

The important property is that classes are per file, not per file system. One file system can hold hot files in Standard and cold ones in IA simultaneously, and lifecycle management is what moves them.

How lifecycle management decides

You attach a lifecycle configuration with rules expressed in days since last access:

bash

aws efs put-lifecycle-configuration \
  --file-system-id fs-0123456789abcdef0 \
  --lifecycle-policies '[{"TransitionToIA":"AFTER_30_DAYS"},
                         {"TransitionToArchive":"AFTER_90_DAYS"},
                         {"TransitionToPrimaryStorageClass":"AFTER_1_ACCESS"}]'

Three things about this deserve care:

"Access" means reading or writing the file's contents. Metadata operations — listing a directory, stating a file, reading permissions — do not reset the clock. That is a deliberate and useful design: a backup tool that only walks the tree does not warm everything up.
TransitionToPrimaryStorageClass: AFTER_1_ACCESS is optional and consequential. With it, any read pulls a file back to Standard, which is right for data that becomes hot again in bursts. Without it, files stay in the cold class and every read pays retrieval — cheaper for genuinely archival data, more expensive for anything with a long tail of repeat reads.
Archive has a minimum transition period measured in months, and is only meaningful for data that is realistically untouched for that long.

Why the saving evaporates

The economics assume cold files stay cold. Three patterns break that:

Whole-tree readers. A nightly backup that copies file contents, an antivirus scanner, a search indexer or a compliance crawler reads every byte. You pay a retrieval charge across the entire dataset on every pass, and with transition-back enabled the whole file system is dragged into Standard and then re-transitioned — paying twice for nothing. The fix is to back up with a tool that works from EFS's own backup integration rather than a client-side full read, or to accept a cold class without transition-back and schedule reads deliberately.
Reads that are not as rare as assumed. A 30-day threshold on data actually touched every six weeks means most files bounce between classes, incurring retrieval each time.
Latency-sensitive paths. IA and Archive add first-byte latency. A user-facing request that happens to hit a cold file gets a visibly slower response, so cold-tiering a directory that serves live traffic trades a small storage saving for a latency regression.

There is also a throughput interaction: with Elastic throughput, reads and writes are metered per GB regardless of class, so a whole-tree scan costs throughput charges on top of retrieval charges.

How to approach it properly

Measure first. CloudWatch publishes per-storage-class size metrics for an EFS file system, so you can see how much data actually sits in each class and whether it stays there. Then:

Establish what reads the whole file system and on what schedule, before enabling anything.
Prefer a threshold comfortably longer than the longest legitimate access interval, rather than the shortest one that looks like a saving.
Decide TransitionToPrimaryStorageClass deliberately: on for data with bursty re-use, off for true archives.
Consider whether the data belongs on EFS at all. Genuinely cold, write-once data is usually far cheaper in S3 with its own lifecycle rules — cold-tiering within EFS is optimising the wrong axis if the data never needed POSIX access in the first place.

That last point is the senior answer. Lifecycle management makes an EFS file system cheaper; moving cold data out of EFS entirely often makes it an order of magnitude cheaper.

## The storage classes An EFS file system stores data in tiers rather than one flat pool: - **Standard** — the primary class: lowest latency, highest price per GB-month. - **Infrequent Access (IA)** — substantially cheaper per GB, with a per-GB **retrieval charge** every time data is read and higher first-byte latency. - **Archive** — colder and cheaper still, with a higher retrieval charge and higher latency again, intended for data touched a few times a year at most. A parallel set of **One Zone** classes trades multi-AZ resilience for a lower price by keeping data in a single Availability Zone. The important property is that classes are per *file*, not per file system. One file system can hold hot files in Standard and cold ones in IA simultaneously, and lifecycle management is what moves them. ## How lifecycle management decides You attach a lifecycle configuration with rules expressed in days since last access: ```bash aws efs put-lifecycle-configuration \ --file-system-id fs-0123456789abcdef0 \ --lifecycle-policies '[{"TransitionToIA":"AFTER_30_DAYS"}, {"TransitionToArchive":"AFTER_90_DAYS"}, {"TransitionToPrimaryStorageClass":"AFTER_1_ACCESS"}]' ``` Three things about this deserve care: 1. **"Access" means reading or writing the file's contents.** Metadata operations — listing a directory, stating a file, reading permissions — do **not** reset the clock. That is a deliberate and useful design: a backup tool that only walks the tree does not warm everything up. 2. **`TransitionToPrimaryStorageClass: AFTER_1_ACCESS` is optional and consequential.** With it, any read pulls a file back to Standard, which is right for data that becomes hot again in bursts. Without it, files stay in the cold class and every read pays retrieval — cheaper for genuinely archival data, more expensive for anything with a long tail of repeat reads. 3. **Archive has a minimum transition period** measured in months, and is only meaningful for data that is realistically untouched for that long. ## Why the saving evaporates The economics assume cold files stay cold. Three patterns break that: - **Whole-tree readers.** A nightly backup that copies file contents, an antivirus scanner, a search indexer or a compliance crawler reads every byte. You pay a retrieval charge across the entire dataset on every pass, and with transition-back enabled the whole file system is dragged into Standard and then re-transitioned — paying twice for nothing. The fix is to back up with a tool that works from EFS's own backup integration rather than a client-side full read, or to accept a cold class without transition-back and schedule reads deliberately. - **Reads that are not as rare as assumed.** A 30-day threshold on data actually touched every six weeks means most files bounce between classes, incurring retrieval each time. - **Latency-sensitive paths.** IA and Archive add first-byte latency. A user-facing request that happens to hit a cold file gets a visibly slower response, so cold-tiering a directory that serves live traffic trades a small storage saving for a latency regression. There is also a throughput interaction: with Elastic throughput, reads and writes are metered per GB regardless of class, so a whole-tree scan costs throughput charges on top of retrieval charges. ## How to approach it properly Measure first. CloudWatch publishes per-storage-class size metrics for an EFS file system, so you can see how much data actually sits in each class and whether it stays there. Then: - Establish what reads the whole file system and on what schedule, before enabling anything. - Prefer a threshold comfortably longer than the longest legitimate access interval, rather than the shortest one that looks like a saving. - Decide `TransitionToPrimaryStorageClass` deliberately: on for data with bursty re-use, off for true archives. - Consider whether the data belongs on EFS at all. Genuinely cold, write-once data is usually far cheaper in S3 with its own lifecycle rules — cold-tiering within EFS is optimising the wrong axis if the data never needed POSIX access in the first place. That last point is the senior answer. Lifecycle management makes an EFS file system cheaper; moving cold data out of EFS entirely often makes it an order of magnitude cheaper.

Does listing a directory reset a file's transition clock?
No. EFS lifecycle management counts access to a file's contents, not metadata operations, so `ls`, stat calls and permission reads leave a cold file cold. That is what makes it safe for tools that merely walk the tree — the danger is tools that read the bytes, such as backups, antivirus scanners and indexers.
When would you leave `TransitionToPrimaryStorageClass` off?
For genuinely archival data with no expectation of repeat reads: an occasional retrieval charge is cheaper than paying Standard rates again for months. Turn it on when access is bursty — a dataset ignored for a quarter and then hammered for a week — because otherwise every read in that week pays retrieval on cold storage.
When is EFS lifecycle management the wrong tool entirely?
When the data never needed POSIX semantics. Cold, write-once data — logs, exports, media archives — is far cheaper in S3 with its own storage classes, and lifecycle-tiering it inside EFS optimises the wrong axis. Use EFS tiering for cold corners of a file system whose hot parts genuinely require a shared filesystem.

saying these in an interview costs you the question

Believing directory listings keep files warm
Assuming Infrequent Access is cheaper unconditionally, with no retrieval cost
Enabling lifecycle rules without auditing what reads the whole tree
Ignoring the added first-byte latency on user-facing reads
Treating storage class as a property of the file system rather than each file

An Amazon EFS lifecycle policy is supposed to move cold files into the Infrequent Access storage class to cut cost. How does EFS decide which files to move, and what commonly defeats the saving or makes the bill worse?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~3 min

The storage classes

How lifecycle management decides

Why the saving evaporates

How to approach it properly

▾common follow-ups3 questions

▾red flags5 flags

§ context

▾related questions4 questions

▾related topics3 topics

The storage classes

How lifecycle management decides

Why the saving evaporates

How to approach it properly

answer

go deeper

context