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:

1. File system — maps NFS paths to S3 object keys.
2. Mount target — the NFS endpoint inside your VPC. Lambda connects over port 2049, same as EFS.
3. 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).

🚀 Read the Full Tutorial →