Mounting an Amazon S3 bucket makes a bucket appear as a folder on your Linux box or EC2 instance, so existing tools (ls, cp, log writers, legacy apps) can read and write objects as if they were ordinary files. It is a genuinely useful trick — but the way you should do it changed a lot since the old s3fs era.
In 2026 there are four mature options, and the right one depends on your workload:
- Mountpoint for Amazon S3 (
mount-s3) — AWS's own high-performance FUSE client, GA since 2023. The best default for read-heavy and big-data workloads. - s3fs-fuse — the classic, most POSIX-complete option. Slower, but supports random writes and broad app compatibility.
- goofys and rclone mount — lightweight alternatives, each with trade-offs.
TL;DR: Use Mountpoint for S3 if you mostly read large files or append. Use s3fs-fuse if an app must overwrite or randomly write files. And for many jobs you should not mount at all — the
boto3SDK oraws s3 syncis faster and safer (more on that below).
First, the honest part: S3 is object storage, not a filesystem
Every mount tool fakes a POSIX filesystem on top of an HTTP object API. That illusion leaks, and knowing where it leaks saves you days of debugging:
- Latency. Every
open,stat, or directory listing is a network call to S3. Afindover thousands of keys that is instant on a local disk can take minutes on a mount. - No true random writes. S3 objects are immutable — you replace a whole object, you don't patch bytes in place. Tools emulate in-place edits by re-uploading the entire object, which is slow and can silently break apps that
seek()and write. - No real file locking.
flock/fcntllocking is not reliable across a mount, so two writers can clobber each other. - Per-request cost adds up. Thousands of tiny reads and writes mean thousands of API calls; lots of small-file operations cost more (and run slower) than a few large ones.
- Eventual surprises. Renames are copy-then-delete (not atomic), and "directories" are just a key-naming convention, not a real thing.
If your workload is lots of small files, heavy random writes, databases, or anything latency-sensitive, a mount is the wrong tool — reach for the boto3 SDK or aws s3 sync instead. Mounts shine when you have a legacy app that only speaks "files," or you stream a few large objects sequentially.
The options at a glance
| Tool | Performance | POSIX completeness | Writes | Best for |
|---|---|---|---|---|
Mountpoint for S3 (mount-s3) |
Very high (multi-GB/s) | Low — by design | Sequential writes & appends only; no overwrite / random write | Read-heavy analytics, ML training data, log & output staging on EC2 |
| s3fs-fuse | Moderate | High-ish | Full read/write incl. random writes (via re-upload) | Legacy apps that must overwrite files; broadest compatibility |
| goofys | High | Low | Limited writes | Fast read-mostly access when you don't need POSIX |
| rclone mount | Moderate–high (with VFS cache) | Medium | Read/write with cache | Multi-cloud setups, ad-hoc mounts, bandwidth & encryption control |
Pick by workload, not by habit. The rest of this guide shows install and mount steps for each, then how to run them securely on EC2.
Option 1: Mountpoint for Amazon S3 (recommended for read-heavy workloads)
Mountpoint for Amazon S3 is AWS's officially supported FUSE client, generally available since 2023 and actively maintained. It is built for throughput: it can saturate the network on an EC2 instance and is the right default for analytics, ML training, and rendering pipelines that read large objects sequentially.
Know its semantics before you rely on it:
- Optimized for sequential reads and sequential writes to new objects (plus appends to objects it created).
- It does not support random writes, in-place modification, or renaming existing objects.
- Directory listings and reads are fast; it deliberately skips POSIX features it can't do efficiently.
In short: a fantastic read cache and write-once staging area, not a general-purpose disk.
# Ubuntu / Debian (x86_64)
wget https://s3.amazonaws.com/mountpoint-s3-release/latest/x86_64/mount-s3.deb
sudo apt-get install -y ./mount-s3.deb
# Amazon Linux 2023 / RHEL / Fedora (x86_64)
wget https://s3.amazonaws.com/mountpoint-s3-release/latest/x86_64/mount-s3.rpm
sudo dnf install -y ./mount-s3.rpm
# On Graviton/arm64, swap "x86_64" for "arm64" in the URL.
mount-s3 --version# Create a mount point and mount the bucket
mkdir -p /mnt/s3
mount-s3 my-app-bucket /mnt/s3
# Read-only is safer when you only consume data
mount-s3 --read-only my-app-bucket /mnt/s3
# Scope to a prefix and add a local cache for repeated reads
mount-s3 --prefix data/ --cache /tmp/s3cache --max-cache-size 10000 my-app-bucket /mnt/s3
# Use it like a folder
ls /mnt/s3
cp /mnt/s3/model.bin .
# Unmount when done
umount /mnt/s3Option 2: s3fs-fuse (general-purpose, POSIX-ish mount)
s3fs-fuse is the long-standing community FUSE driver. It is slower than Mountpoint, but it is the most compatible: it supports random writes (by transparently re-uploading the object), chmod/chown metadata, and the directory semantics most legacy apps expect. Choose it when an application must overwrite or edit files in place and you can't change the app.
Don't install the ancient v1.77 from old tutorials — use your distro package or build the current release.
# Ubuntu / Debian
sudo apt-get update && sudo apt-get install -y s3fs
# Amazon Linux 2023 / Fedora / RHEL
sudo dnf install -y s3fs-fuse
# Verify
s3fs --versionOn a laptop or a non-AWS server you can authenticate with a credentials file. On EC2, skip this entirely and use an IAM role (see the security section) — never place long-lived keys on an instance. If you do use a file, s3fs will refuse to read it unless it is locked down to chmod 600.
# Credentials file format is ACCESS_KEY:SECRET_KEY on a single line
echo "AKIAEXAMPLE:wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" > ~/.passwd-s3fs
# Lock it down — s3fs REFUSES a world-readable credentials file
chmod 600 ~/.passwd-s3fsmkdir -p /mnt/s3
# Mount using the credentials file (laptop / non-AWS host)
s3fs my-app-bucket /mnt/s3 -o passwd_file=${HOME}/.passwd-s3fs
# On EC2 with an attached IAM role — no keys at all
s3fs my-app-bucket /mnt/s3 -o iam_role=auto
# Persist across reboots via /etc/fstab (IAM-role example)
echo 's3fs#my-app-bucket /mnt/s3 fuse _netdev,iam_role=auto 0 0' | sudo tee -a /etc/fstabOptions 3 and 4: goofys and rclone mount
goofys is a Go FUSE driver focused on speed for read-mostly workloads. It skips most POSIX metadata, so it's fast but limited — handy when you just need quick sequential access and don't care about permissions.
rclone mount turns rclone's S3 remote into a mounted filesystem. With its VFS cache it handles reads and writes reasonably, works across 70+ storage providers (so it's great for multi-cloud), and gives you fine control over bandwidth, encryption, and caching.
# goofys — mount a read-mostly bucket (uses the AWS credential chain / IAM role)
goofys my-app-bucket /mnt/s3
# rclone — configure an S3 remote once (interactive), then mount it
rclone config # create a remote named e.g. "s3"
rclone mount s3:my-app-bucket /mnt/s3 \
--vfs-cache-mode writes \
--dir-cache-time 12h \
--daemonRun it securely on EC2 (IAM roles, least privilege)
The single most important rule: do not hardcode AWS keys. On EC2, attach an IAM role (instance profile) and let the AWS credential chain supply temporary, auto-rotating credentials. Mountpoint, goofys, and rclone use this automatically; s3fs needs -o iam_role=auto.
Security checklist:
- Use an instance profile, not access keys. No
~/.passwd-s3fs, no keys in env files or/etc/fstab. - Grant least privilege. Scope the policy to the one bucket (and prefix) the app needs — and to read-only when you only read. See our guide to IAM roles and policies.
chmod 600any credentials file you do use off-EC2; s3fs refuses world-readable creds anyway.- Prefer a VPC gateway endpoint for S3 so traffic stays on AWS's network, not the public internet.
- Avoid
allow_otherunless you genuinely need other system users to see the mount.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ListTheBucket",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::my-app-bucket"
},
{
"Sid": "ReadWriteObjects",
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
"Resource": "arn:aws:s3:::my-app-bucket/*"
}
]
}When a mount is the wrong tool
For a read-only mount, attach a policy with just s3:ListBucket and s3:GetObject. But before you wire any of this into production, ask whether you should mount at all.
A mount is the wrong tool when you have:
- Many small files or high request volume — per-request latency and cost dominate. Use the SDK and batch your calls.
- A database or anything needing real locking and random writes — never run a database off an S3 mount.
- Application code you control — talking to S3 directly with
boto3and pagination is faster, cheaper, and more predictable than faking a filesystem. - One-off bulk transfers —
aws s3 sync ./local s3://my-app-bucket/moves data far faster than copying through a mount.
Mounts are a compatibility shim, not a storage architecture. Over 12+ years and 50+ delivered projects we've helped teams choose between mounts, the SDK, and proper data pipelines — and migrate the storage layer when a quick mount has quietly become a bottleneck. If you're weighing the options, our AWS consulting and cloud migration teams do exactly this.
Frequently Asked Questions
Should I use Mountpoint for S3 or s3fs?
Use Mountpoint for S3 (mount-s3) when your workload is read-heavy or writes new objects sequentially — analytics, ML training data, log and output staging. It's AWS-official, far faster, and the right default in 2026. Use s3fs-fuse when an application must overwrite files or do random writes in place and you can't change that app; s3fs is slower but much more POSIX-complete.
Can I do random writes on a mounted S3 bucket?
Not really. S3 objects are immutable, so there is no true in-place write. Mountpoint for S3 only supports sequential writes to new objects. s3fs can fake random writes by re-uploading the whole object on every change, which is slow and can break apps that expect cheap seek()-and-write behavior. If you need real random writes, use a block/file store (EBS or EFS) and sync to S3.
Is mounting S3 a good idea for production?
Sometimes — for read-heavy access with Mountpoint, or to bridge a legacy app that only speaks files. It's a poor idea for databases, high-volume small-file workloads, or anything needing locking. For production code you control, the boto3 SDK or aws s3 sync is more reliable and cheaper than a mount.
How do I mount S3 on EC2 securely?
Attach an IAM role (instance profile) to the instance and let the tool use the AWS credential chain — Mountpoint, goofys, and rclone do this automatically, and s3fs uses -o iam_role=auto. Don't store long-lived access keys on the instance. Scope the role's policy to the single bucket (and prefix) with least privilege, and use a VPC gateway endpoint for S3.
Why is my mounted S3 bucket so slow?
Because every file operation is an HTTP request to S3. Listing directories with many keys, stat-ing files, and small random reads are all network round-trips. Speed it up by enabling a local cache (--cache on Mountpoint, use_cache on s3fs, VFS cache on rclone), reading large objects sequentially, scoping to a prefix, and avoiding tools that recursively stat everything.
Should I use a mount or the boto3 SDK?
If you're writing application code, prefer the SDK. boto3 gives you explicit, batched, retry-aware control over S3, avoids the leaky filesystem illusion, and is faster and cheaper for most access patterns — see our guide to paginating S3 objects with boto3. Reach for a mount only when an existing tool or legacy app can't be changed to call the API directly.