AWS launched S3 Files on Tuesday, clocking sub-millisecond latency for read/writes on any S3 bucket. Inside AWS, anyway.
Your Mac? Forget it. EC2 only. That’s the rub — and why I burned 48 hours (and five kernel panics) bridging the gap.
S3 Files isn’t some half-baked overlay. Andy Warfield’s crew at AWS built it on EFS guts, with S3 as the unkillable backend. Bidirectional sync. POSIX compliance. Auto-warming metadata so ls flies instantly, no minutes-long scans like clunky FUSE hacks.
As Corey Quinn put it, “S3 has never been a filesystem — but now there’s a real one sitting in front of it.”
Spot on. Small files under 128KB slurp into a hot tier on cd. Big ones stream straight from S3’s throughput monster. Changes heartbeat back every minute via EventBridge. Expires after 30 days, rehydrates on demand. Agentic AI workloads? AWS screams that’s the killer app — agents swapping state, docs, outputs without S3’s object hell.
But local dev? VS Code on your MacBook, editing S3-backed code like it’s a folder? Nope. macOS NFSv4.0 kernel client. No TLS. No IAM handshake via efs-proxy. Three brick walls.
Why Does Mounting S3 Files on macOS Even Matter?
Dev velocity craters without it. Picture this: your team’s EKS cluster chews S3 Files for ML training data. You? Stuck aws s3 cp dancing or third-party FUSE (Mountpoint for S3, anyone? ls timeouts galore). Market’s shifting — AI agents demand shared mutable state. S3 Files nails it in-cloud. Local proxy? Gold for iteration speed.
Here’s my sharp take: AWS shipped Day 1 CloudFormation (AWS::S3Files::FileSystem, MountTarget). CDK L1 works. Entire VPC+NLB+bucket stack in one cdk deploy. Impressive. But ignoring local mounts? Classic cloud-vendor blind spot. Reminds me of 2010’s s3fs-fuse era — devs jury-rigged POSIX over S3 till AWS noticed and built better. Prediction: proxies like this hack go viral; AWS spins up official Mac support by Q2 ‘25, or acquires a startup doing it.
Is macOS NFS Ready for S3 Files? Spoiler: Hard No
First try: NLB in front of the mount target (TCP 2049). Point macOS NFS at it.
sudo mount -t nfs -o vers=4 nlb-dns:/ /mnt
Black screen. Kernel panic. Reboot. Tried vers=4.0 explicit. Panic. Five times total. macOS NFSv4.0 barfs on v4.2 handshakes — no graceful fallback, just driver implosion. Documented bug since Big Sur. Dangerous.
Lesson one: Don’t point Apple NFS at modern servers. Ever.
Docker time. Spin Amazon Linux container (proper NFSv4.2). Raw mount inside:
mount -t nfs4 -o nfsvers=4.2 nlb-dns:/ /mnt
“Access denied.” IAM bind flop — efs-proxy missing. That’s the auth glue, part of amazon-efs-utils. Linux-only binary. Handles TLS + SigV4 over NFS RPC.
The Docker + efs-proxy Rabbit Hole (And That Crash Bug)
Port efs-proxy to container. Easy, right? amazon-efs-utils Dockerfile exists. But S3 Files tweaks it — efs-proxy now proxies S3-specific ops. Pulled latest. Mounted via Docker volume-share to macOS /mnt.
Crash. Segfault in efs-proxy on large-file ReadBypass. Bug — non-EC2 env mangles throughput paths. Reported it (AWS ticket open). Workaround: patch proxy to force fast-tier fetch, cap bypass.
NLB twist: S3 Files mount targets are private IPs. Internet-facing NLB passthrough. But macOS-to-Docker networking? Socat tunnel. Or Tailscale for VPC punch-out (cleaner, but VPC peering pain).
Here’s the thing. IAM roles. Container needs sts:AssumeRole for S3 Files access. OIDC provider on EKS? Nah, local Docker. Baked temp creds via aws sts assume-role piped to container env.
Final stack: CDK spits VPC, S3 bucket/prefix, S3 Files FS + target, IAM role/policy (s3files:MountFilesystem), NLB. Then local:
-
docker run -it --privileged -v /mnt:/mnt -e AWS_ACCESS_KEY_ID=... amazonlinux:2023 -
Inside:
yum install amazon-efs-utils, patch efs-proxy if needed,efs-proxy-dnsbackground,mount -t efs fs-xxx.efs.us-east-1.amazonaws.com:/ /mnt(S3 Files uses EFS-style DNS).
Wait, no. S3 Files mount targets mimic EFS. DNS: fs-abc123.efs.region.amazonaws.com:/
But TLS mandates proxy. Full mount: mount -t nfs4 -o nfsvers=4.2,port=2049 tls://nlb-dns:2049:/ /mnt
It sticks. ls /mnt instant. echo 'test' > /mnt/foo.txt. Syncs to S3 in ~60s. VS Code opens /mnt smoothly. Bidirectional. Hot tier warms on access.
Cracks in the Armor — And Why This Hack’s No Silver Bullet
Latency? 10-20ms roundtrip via NLB + Docker overhead. Vs sub-ms in-EC2. Fine for dev, not prod proxy.
Security: NLB public. Mitigate with client IP whitelisting, AWS WAF. IAM session tokens expire — script refresh.
Scale: Single-node. Multi? Kubernetes local cluster (k3s) with DaemonSet efs-proxy pods, NFS server export. But that’s devops overkill.
Corporate spin check: AWS hypes “agentic AI”. Legit — but local mount unlocks solo prototyping. Their omission? Sloppy. Devs live outside EC2.
Why Does This Matter for Local Dev Workflows?
Teams split cloud/local. S3 Files unifies. No more “works on my EC2”. Edit configs, notebooks, datasets natively. Git over S3? Risky, but symlinks hack it.
Market angle: S3 $20B+ run rate. Files tier grabs hot-data slice from EFS/FSx. Pricing? $0.30/GB-mo fast tier + S3 underlay. Cheaper than EFS for mutable hot data.
Bold call: This sparks proxy ecosystem. Like Teleport for SSH, expect S3 Files tunnels (ngrok-style) by month-end.
Tool drop: GitHub repo coming — s3files-mac-mount. Two commands: npm i -g @you/s3files-mac, s3files-mac mount --stack my-s3files-stack --dir ~/s3dev. Handles CDK deploy, Docker spin, creds. Zero-config post-bootstrap.
Risks? Kernel panics if you skip Docker. efs-proxy bugs linger. Test small.
Worth it? For AI/ML devs, yes. Rest? Mountpoint-S3 suffices till official support.
🧬 Related Insights
- Read more: FSF Draws Line: Relicensing Ain’t Compatibility
- Read more: How Pyroscope and Alloy Exposed TON Blockchain’s Hidden Speed Killers
Frequently Asked Questions
Can you mount AWS S3 Files on macOS?
Yes, via Docker + NLB + efs-proxy workaround. Avoid direct NFS — kernel crashes. Full guide above.
What are the risks of mounting S3 Files on Mac?
Kernel panics (NFSv4 mismatch), auth flakes, 10-50ms latency hit. Secure NLB properly.
Does S3 Files replace EFS for dev?
No — complements. S3 durable, EFS faster in-VPC. Use Files for S3-native mutable access.