S3 Files — 13x Cheaper Than EFS
EFS Standard storage costs $0.30/GB-month.
S3 costs $0.023/GB-month.
AWS recently released S3 Files: a POSIX file system with an S3 bucket as the backing store.
Same NFS mount, same fs.readFile calls, Lambda reads files like a normal file system.
The data just lives in S3 instead of EFS.
One terabyte on EFS Standard: $307/month.
The same terabyte on S3 Files: around $25/month.
How it works
Three resources to understand:
- File system — maps NFS paths to S3 object keys.
- Mount target — the NFS endpoint inside your VPC. Lambda connects over port 2049, same as EFS.
- Access point — scoped entry with an assigned POSIX user. Lambda uses the access point ARN to mount.
One thing that surprises people: the IAM service role uses the elasticfilesystem.amazonaws.com principal — not a separate one.
S3 Files shares the NFS layer with EFS. Only the storage backend is different.
⚠️ The 60-second write-back delay
This is the part that bites teams.
When Lambda writes a file, the data lands in the kernel's NFS cache first.
The NFS client flushes that cache to the mount target after a write-back interval. Then the mount target pushes to S3.
Two hops, each with their own delay. Total: typically around 60 seconds.
Patterns that break silently:
- Coordination via file existence (if file exists, skip)
- Handoff between concurrent Lambda invocations using file writes as signals
- Any write-then-immediately-read pattern across different Lambda instances
For coordination: use SQS, DynamoDB, or S3 directly. S3 has had strong read-after-write consistency since 2020.
POSIX limits
If your code only uses fs.readFile, fs.writeFile, fs.readdir — you're fine.
But these break:
- Hard links — not supported. Tools like
rsync --hard-links will error or fall back to copies silently.
- Advisory locks (
flock, fcntl) — succeed locally but have no effect across Lambda instances. Concurrent invocations writing to the same cache directory will corrupt data.
- SQLite, LevelDB, RocksDB — all use file locking for write serialization. Corrupt data under concurrent access on S3 Files.
- Atomic rename on directories — the rename window is visible to other readers. The write-to-temp-then-rename pattern isn't atomic here.
When to use which
Use S3 Files when: you need POSIX access to data already in S3, your workload is read-heavy or write-once, cost matters more than consistency speed.
Use EFS when: you need strict read-after-write consistency across concurrent processes, your code uses file locking or hard links, or you're running a file-based database.
The full post walks through the SAM setup, service role permissions, CloudFormation custom resource for async provisioning, and the complete cost model for small-file workloads (where the math flips and S3 Files ends up more expensive than EFS).
