What Is Amazon S3 Files? How It Works, Setup on EC2, Lambda, ECS and EKS, a Pricing Example, Sync Rules, and S3 Files vs EFS and Mountpoint

Amazon S3 Files is a shared file system linked to an S3 bucket: you mount it over NFS (versions 4.1 and 4.2) and your applications see the bucket's objects as ordinary files and folders, with real file behavior (edits, renames, file locking, POSIX permissions, read-after-write consistency), while every change syncs back to the bucket as normal S3 objects. It went generally available on April 7, 2026, it is built on Amazon EFS technology, and it mounts from Linux EC2 instances, Lambda functions, ECS tasks on Fargate or ECS Managed Instances, and EKS with sudo mount -t s3files fs-ID:/ /mnt/s3files. You need a general purpose bucket with versioning on, a mount target in your VPC, NFS port 2049 open, and two IAM roles. You pay only for the small, busy part of your data that sits on its fast storage (an example rate of $0.30 per GB-month) plus per-GB read and write charges; large reads stream straight from S3 at normal GET prices. Below: how it works, how it compares with Mountpoint, EFS and File Gateway, console and CLI setup, Lambda, ECS and EKS, sync and conflicts, pricing with a worked example, limits, and the errors you will meet.

Jake's team had built the usual workaround. Their document app wrote to an EFS share, a nightly job copied everything into S3 for the analytics team, and a second job copied the analysts' results back. Two copies of every file, two bills, and a day of lag. When S3 Files launched, Ethan asked the obvious question: what if the app just worked on the bucket?

New to S3 or to file systems on AWS? The cards below cover S3, EFS, the three storage types, and the instance roles that every mount needs.

What Amazon S3 Files is, in plain English

S3 stores objects: whole files under a key, with no real folders, no renames and no editing in place. Most applications expect a file system instead. Until 2026 you had two choices: copy data between S3 and a file system such as EFS, or use a client like Mountpoint that turns file calls into S3 requests and gives up the features S3 cannot do.

S3 Files is the third option. You create an S3 file system linked to a bucket (or one prefix of it), and S3 manages a layer of high-performance storage in front of the bucket. Here is what happens as you use it:

• Browsing: the first time you open a folder, S3 Files imports the metadata (names, sizes, permissions) for every file in it, plus the data of small files (under 128 KiB by default). The first listing of a big folder can take seconds; after that, ls and stat are fast.
• Reading: small, busy files are served from the fast storage at sub-millisecond to single-digit millisecond latency. Large reads (1 MiB or more per read) and files not on the fast storage stream directly from S3, at S3's huge aggregate throughput.
• Writing: writes land on the fast storage first (as durable as S3, across several Availability Zones). After 60 seconds without further writes to a file, S3 Files exports it to the bucket as a new object version.
• Outside changes: when another application uploads, changes or deletes objects through the S3 API, S3 Files picks it up through S3 event notifications and updates the file system view.
• Expiry: file data nobody has read for 30 days (you can choose 1 to 365) drops off the fast storage; the file still shows in listings and is fetched again from S3 on the next read.

The result: file tools get file behavior, S3 tools get S3 objects, and only the active slice of your data pays file system prices. Everything stays in the bucket, which remains the source of truth.

Jake: "So the app sees a folder, and the analysts still see a bucket?"

Ethan: "The same data, both ways at once. No nightly copy."

S3 Files vs Mountpoint vs EFS vs File Gateway

AWS now has several ways to put a file interface on storage. The differences that decide which one you want:

The quick rule: if your data already lives in S3 and file-based tools need to change it, S3 Files. If you mostly read big files on Linux and want zero extra cost, Mountpoint. If the data is a working folder with no S3 role at all, plain EFS. If people on Windows desktops need a share, a File Gateway or FSx. Our object vs block vs file storage guide explains the underlying difference.

What you need before you start

• A general purpose bucket with versioning turned on. S3 Files uses object versions to sync safely; every saved change becomes a new version. Turn it on with aws s3api put-bucket-versioning --bucket shop-docs --versioning-configuration Status=Enabled.
• SSE-S3 or SSE-KMS encryption on the bucket (the default SSE-S3 is fine).
• A VPC where your compute runs, with a subnet in each Availability Zone you will mount from. One file system belongs to one VPC (other VPCs can reach it through peering or a transit gateway).
• Security groups: inbound TCP 2049 on the mount target from your clients' security group, and outbound TCP 2049 from the clients to the mount target.
• Two IAM roles: one that S3 Files assumes to read and write the bucket, and one on your compute (instance profile, Lambda execution role, task role or pod role) to mount the file system.
• The client on EC2: amazon-efs-utils version 3.0.0 or newer, which adds the s3files mount type.
• A supported Linux: Amazon Linux 2 or 2023, RHEL 8 or 9, Ubuntu 20.04, 22.04 or 24.04, SLES 15 or openSUSE Leap.

If the File systems tab is missing on your bucket's page in the S3 console, check that you are in a Region where S3 Files is available, and that the bucket is a general purpose bucket rather than a directory or table bucket.

Set up S3 Files in the console (fastest way)

The console creates most of the plumbing for you, including the bucket access role, a mount target in every Availability Zone of your default VPC, and one access point:

1. Turn on versioning for the bucket (Properties, Bucket Versioning, Enable).
2. Open the bucket in the S3 console (General purpose buckets), choose the File systems tab, then Create file system.
3. Confirm the VPC (the default VPC for a first try) and choose Create. Creating the mount targets takes a few minutes.
4. Prepare the instance role: on your EC2 instance's role, attach the managed policy AmazonS3FilesClientFullAccess (or AmazonS3FilesClientReadOnlyAccess), plus read access to the bucket (shown in the CLI section). Our instance profile guide covers attaching roles.
5. Check security groups on the instance and the mount targets for port 2049, as listed above.
6. On the file system's Overview page, choose Attach under Attach to an EC2 instance, pick the instance and a path such as /mnt/s3files/, and follow the commands shown (they open CloudShell and mount for you).
7. Test: ls /mnt/s3files shows your objects as files; create a file and look for it in the bucket about a minute later.

The EC2 launch wizard can also attach a file system to a new instance: under Storage, choose File systems, then S3 Files, and it generates the mount and fstab commands, which you can place in user data so the instance mounts at launch.

Set up S3 Files with the AWS CLI

From the CLI you create the bucket access role yourself. Its trust policy lets the S3 Files service assume it:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowS3FilesAssumeRole",
    "Effect": "Allow",
    "Principal": { "Service": "elasticfilesystem.amazonaws.com" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": { "aws:SourceAccount": "111122223333" },
      "ArnLike": { "aws:SourceArn": "arn:aws:s3files:eu-west-2:111122223333:file-system/*" }
    }
  }]
}

Its permissions policy allows s3:ListBucket and s3:ListBucketVersions on the bucket; s3:GetObject*, s3:PutObject*, s3:DeleteObject*, s3:List* and s3:AbortMultipartUpload on its objects; the KMS actions for the bucket's key if it uses SSE-KMS; and permission to manage EventBridge rules whose names start with DO-NOT-DELETE-S3-Files (that is how it hears about bucket changes). Then the steps:

1. Create the role:

   aws iam create-role --role-name S3FilesBucketRole --assume-role-policy-document file://trust.json
   aws iam put-role-policy --role-name S3FilesBucketRole --policy-name S3FilesBucketAccess --policy-document file://bucket-access.json

2. Create the file system and note the fs- ID in the response:

   aws s3files create-file-system --region eu-west-2 \
     --bucket arn:aws:s3:::shop-docs \
     --role-arn arn:aws:iam::111122223333:role/S3FilesBucketRole

3. Create a mount target in the subnet (and so the Availability Zone) of your instance, one per zone you use; each takes up to about five minutes:

   aws s3files create-mount-target --region eu-west-2 \
     --file-system-id fs-0123456789abcdef0 --subnet-id subnet-0aaa1111bbbb2222c

4. Open port 2049 from the instances to the mount target's security group:

   aws ec2 authorize-security-group-ingress --group-id sg-0mount0target0001 \
     --protocol tcp --port 2049 --source-group sg-0app0servers00002

5. Give the instance role the client policy (AmazonS3FilesClientFullAccess, or individual actions such as s3files:ClientMount and s3files:ClientWrite) and this inline read policy, which lets large reads go straight to S3:

   {
     "Version": "2012-10-17",
     "Statement": [
       { "Effect": "Allow", "Action": ["s3:GetObject", "s3:GetObjectVersion"], "Resource": "arn:aws:s3:::shop-docs/*" },
       { "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::shop-docs" }
     ]
   }

6. Install the client and mount on the instance:

   sudo yum -y install amazon-efs-utils
   sudo mkdir /mnt/s3files
   sudo mount -t s3files fs-0123456789abcdef0:/ /mnt/s3files
   df -h /mnt/s3files

   On Ubuntu, RHEL and SUSE, install the client with AWS's installer script: curl https://amazon-efs-utils.aws.com/efs-utils-installer.sh | sudo sh -s -- --install.

The mount always uses TLS and IAM authentication; you cannot turn either off. df shows a size of 8.0E, because the file system has no fixed size.

Jake: "Two roles feels like one too many."

Ethan: "One is the service touching your bucket, one is your server touching the file system. Different jobs, so different roles."

Mount at boot, access points and subfolders

Add the file system to /etc/fstab so it comes back after a reboot. The _netdev option is essential (without it the instance can hang at boot waiting for a network file system), and nofail lets it boot even if the mount fails:

# whole file system
fs-0123456789abcdef0:/ /mnt/s3files s3files _netdev,nofail 0 0

# through an access point
fs-0123456789abcdef0:/ /mnt/reports s3files _netdev,nofail,accesspoint=fsap-0abc1234def567890 0 0

# one subfolder only
fs-0123456789abcdef0:/projects/alpha /mnt/alpha s3files _netdev,nofail 0 0

Run sudo mount -a and findmnt -T /mnt/s3files to check the entry before you reboot. Access points are entry points for one application: each can force a user and group ID and a root folder, so a Lambda function or a team only sees its own part. You can have up to 25,000 per file system. To unmount, use plain sudo umount /mnt/s3files. If you mount the same file system on many instances, put the fstab line in the launch template's user data so every new instance in an Auto Scaling group mounts it the same way.

Use S3 Files from Lambda, ECS and EKS

AWS Lambda. The function must be in the same VPC, in subnets whose Availability Zones have mount targets, and it connects through an access point (the console creates one with user and group ID 1000 and a /lambda scope). In the S3 console, open the file system, choose Attach under Attach to a Lambda function, pick the function and a local mount path under /mnt/. The function then reads and writes there like a local folder, sharing data across invocations. If the mount fails, the causes are the same subnet, zone and security group problems as with EFS; our Lambda EFS mount guide walks through them.

Amazon ECS. S3 Files volumes work for tasks on Fargate and ECS Managed Instances, and not on the EC2 launch type (a task with an S3 Files volume fails to start there). Choose Attach under Attach to an ECS task, pick the task definition and a container path, optionally an access point and root folder, and give the task role the client permissions above. This is the big change for Fargate users, who could not mount S3 with FUSE tools at all.

Amazon EKS. S3 Files uses the Amazon EFS CSI driver (the same driver serves EFS and S3 Files), with dynamic and static provisioning. Create a role with the AmazonS3FilesCSIDriverPolicy managed policy, preferably with EKS Pod Identity, install the EFS CSI driver add-on with that role, and use persistent volume claims as you would for EFS. AWS Batch jobs on EKS can use those claims too. For general EKS background, see our EKS explainer.

How sync works: versions, renames and conflicts

Knowing four sync rules saves you from surprises:

• Every saved change is a new object version. New files become new objects, changed files become new versions, deleted files become delete markers. chmod and chown are stored as user metadata on the object, which also writes a new version. Old versions add up, so add a lifecycle rule that expires noncurrent versions after a few days or weeks (see our lifecycle guide). The upside: our restore guide works for anything deleted through the mount.
• Exports wait for 60 seconds of quiet. A file being written continuously is exported only after writes stop for a minute, so a log written every 30 seconds for 5 minutes reaches S3 at about minute 6. Other S3 readers see the new data after that.
• Renames are copies. Renaming a file is instant on the file system, but in the bucket S3 Files copies each object to the new key and deletes the old one. Renaming a folder with millions of files takes a long time and costs a PUT per file; while it runs, the bucket shows both prefixes. Creating a file system over a prefix so large that a rename could take more than about 4 hours (roughly 12 million objects) returns a warning you must accept explicitly.
• The bucket wins conflicts. If a file is changed through the mount and the same object is changed in the bucket before the export, S3 Files keeps the bucket's version and moves your file into .s3files-lost+found-fs-ID in the root of the file system. To keep your copy, copy it back to its original path (stored in the file's extended attributes). Files in lost and found stay there and are billed until you delete them.

You can tune the import size threshold (raise it for workloads that reread the same files, lower it for streaming jobs) and the expiry window in the file system's synchronization settings.

Jake: "Our app saves drafts every ten seconds."

Ethan: "Then S3 gets one version when the editing stops, not hundreds. Still, set the noncurrent-version lifecycle rule on day one."

Amazon S3 Files pricing, with a worked example

Your bucket is billed as normal (storage, requests, versions). On top, S3 Files charges for two things: storage of whatever sits on the high-performance layer, and data access per GB read from or written to that layer, including the background imports and exports. Example list rates (check your Region on the S3 pricing page):

How operations are metered matters for small files: each data read or write counts at least 32 KiB, and each metadata operation (listing, stat, create, delete, rename, chmod, fsync) at least 4 KiB, rounded up to the next KiB.

Worked example: a 100 GB bucket linked to a file system. In a month, your app reads 10 GB; 94% of that (9.4 GB) is large-file reads that stream from S3, and 6% (0.6 GB) is small files under 128 KiB served from fast storage. It writes 1 GB, of which 0.25 GB is the final output synced to the bucket.

1. Fast storage: 0.6 GB small data + 0.25 GB writes = 0.85 GB × $0.30 = $0.255
2. Writes: 1 GB × $0.06 = $0.06
3. Export of the output: 0.25 GB × $0.03 = $0.0075
4. Small-file reads: 0.6 GB × $0.03 = $0.018
5. Import of those small files: 0.6 GB × $0.06 = $0.036
6. Large reads from S3: 9.4 GB, no S3 Files charge (S3 GET requests only)

Total S3 Files charge: about $0.38 for the month, on top of normal S3 costs for the 100 GB and its requests. Keeping the same 100 GB on EFS as a second copy would cost far more, because you would pay file system storage for all of it. The things that raise an S3 Files bill: huge numbers of tiny files (the 32 KiB and 4 KiB minimums), first listings of very large folders (one metadata import per file), big folder renames (a PUT per object), and forgotten noncurrent versions. Our S3 request pricing guide covers the request side.

S3 Files vs EFS: cost and performance, honestly compared

"S3 Files vs EFS cost" is the question most teams ask first, and the answer depends on whether your data needs to be S3 objects as well as files. Take a 10 TB dataset where about 200 GB of small files are busy at any time, at typical US East list prices:

• S3 Files: S3 Standard for all 10 TB (about $0.023 per GB-month, so roughly $235), plus fast storage for the busy 200 GB at $0.30 per GB-month ($60), plus per-GB access charges on the busy slice. Large reads stream from S3 at GET prices. Roughly $300 a month before access charges.
• EFS, everything in Standard: 10 TB at about $0.30 per GB-month is roughly $3,070 a month. Nobody should run it that way.
• EFS with lifecycle tiering: the busy 200 GB in Standard ($60) and the rest moved to Infrequent Access at about $0.016 per GB-month (roughly $160), or to Archive at $0.008. Roughly $220 to $240 a month, plus access fees when cold data is read and throughput charges of about $0.03 per GB read and $0.06 per GB written.

So for a pure file workload with good lifecycle rules, EFS and S3 Files land in the same range. S3 Files pulls ahead when the same data is also used as S3 objects (Athena queries, data lake jobs, sharing with other accounts, S3 replication), because you keep one copy instead of two and skip the copy jobs. EFS stays the simpler choice for home directories, CMS uploads and application state that never needs to be an S3 object.

On performance, both give low latency for small active files. S3 Files streams large reads straight from S3 at very high aggregate throughput, which suits analytics and media; EFS gives consistent file system throughput for everything without the sync model, conflicts or the 60-second export delay. Our object vs block vs file guide covers the S3, EBS and EFS basics behind this choice.

Jake: "So S3 Files isn't automatically cheaper than EFS?"

Ethan: "Not for files alone. It's cheaper when you'd otherwise keep the same data in both places."

S3 Files performance: the numbers

Read throughput grows with the number of clients and the parallelism inside each one, so many instances reading many files beat one instance reading one big file. If one file system is not enough, you can attach several file systems to the same bucket, each scoped to a different prefix, which removes the per-file-system ceilings. Bucket changes usually appear in the file system within seconds, and a directory rename of 100,000 files is instant on the file system but takes a few minutes to finish in the bucket.

Limits and unsupported features

• Storage classes: objects in Glacier Flexible Retrieval, Glacier Deep Archive, or the Intelligent-Tiering Archive and Deep Archive tiers cannot be read through the file system until restored.
• ACLs: object ACLs are not kept when a file changes through the file system; use bucket policies with ACLs disabled.
• Names and keys: each folder or file name can be up to 255 bytes, full keys up to 1,024 bytes, and folders up to 1,000 levels deep. Keys that are not valid paths (a//b, a/./b, a/../b, null bytes) cannot be accessed through the file system.
• Files: up to 48 TiB each; no hard links; symlinks are supported with targets up to 4,080 bytes.
• Locks: advisory only, up to 512 per file across all clients and 8,192 per mount.
• Scale: 1,000 file systems per account (can be raised), 25,000 connections and 25,000 access points per file system, one mount target per Availability Zone, one VPC per file system, up to 65,536 open files per client.
• NFS features not supported: pNFS, delegations, mandatory locks, NFS ACLs, Kerberos, block and character devices, the NFS 4.2 extras such as server-side copy and sparse files, and the nconnect mount option.

Encryption is always on: TLS in transit, and KMS at rest with an AWS owned key by default or your own customer managed key.

S3 Files on Windows and Mac

S3 Files clients are Linux only; Windows and macOS are not supported, even though the protocol is NFS. The built-in Windows NFS client only speaks NFS version 3, and the S3 Files mount helper (which handles TLS and IAM) runs only on Linux. For Windows users who need S3 data as a drive, the practical choices are an S3 File Gateway (an SMB share whose files are S3 objects) or a tool like rclone with WinFsp on each PC. If the files have no reason to be in S3 at all, FSx for Windows File Server is the managed SMB option. On a Mac, rclone is the usual route.

People also compare S3 Files with Azure Files. Azure Files is a managed SMB and NFS file share with its own storage, closer to EFS or FSx. S3 Files is different in kind: the files are your S3 objects, with a file system layered on top.

S3 Files vs FSx (and does S3 Files support SMB?)

S3 Files speaks NFS only (versions 4.1 and 4.2), so it does not support SMB, the protocol Windows file shares use. The FSx family covers the cases S3 Files does not:

• FSx for Lustre: a high-performance file system for HPC and machine learning, which can also link to an S3 bucket and load objects on first access. It is provisioned (you choose capacity and throughput), aimed at heavy parallel compute rather than general applications.
• FSx for Windows File Server: managed SMB shares with Active Directory, for Windows applications and users; our FSx for Windows guide covers it.
• FSx for NetApp ONTAP and OpenZFS: for teams that want those storage systems' features, such as both NFS and SMB on the same data or snapshots and clones.

A rule of thumb: S3 Files for Linux applications working on data that lives in S3, FSx for Lustre for compute clusters that need the highest throughput, FSx for Windows for SMB users, and an S3 File Gateway when people in an office need a share backed by S3.

Moving from EFS to S3 Files

If your data sits on EFS today and you want it in S3 with file access kept, the move has a natural order:

1. Create the destination bucket with versioning on and SSE-S3 or SSE-KMS encryption.
2. Copy the data with AWS DataSync from the EFS file system to the bucket. DataSync handles large file counts, retries and verification, and can run incrementally so the final cutover is short.
3. Create the S3 file system on the bucket (or on the prefix you copied into) and the mount targets in each Availability Zone.
4. Test with a copy of the application mounted on S3 Files, watching the first-access latency on big folders and the 60-second export delay.
5. Cut over: stop writes, run a last incremental DataSync task, switch the mounts or fstab entries from efs to s3files, and start the application.
6. Keep the EFS file system (read-only) for a week as a fallback before deleting it.

Check permissions on the way: POSIX owners and modes are stored as object metadata by S3 Files, so confirm that files show the expected users after the move, and use access points to enforce a user and group for applications that expect them.

S3 Files with CloudFormation and Terraform

S3 Files has infrastructure-as-code support. In CloudFormation, the file system is AWS::S3Files::FileSystem, which takes the bucket, the IAM role S3 Files assumes, and optionally a prefix, a KMS key and the synchronization settings:

Resources:
  DocsFileSystem:
    Type: AWS::S3Files::FileSystem
    Properties:
      Bucket: arn:aws:s3:::shop-docs
      RoleArn: arn:aws:iam::111122223333:role/S3FilesBucketRole
      Prefix: documents/

Mount targets, access points, the synchronization configuration and file system policies have their own resource types. The Terraform AWS provider added matching resources in April 2026: aws_s3files_file_system, aws_s3files_mount_target, aws_s3files_access_point, aws_s3files_synchronization_configuration and aws_s3files_file_system_policy, plus a data source for looking up existing file systems. Check the provider documentation for the exact argument names in your provider version before writing modules. Whichever tool you use, create the bucket (with versioning) and the bucket access role in the same stack, so their names and permissions stay in step with the file system.

Monitoring S3 Files with CloudWatch

S3 Files publishes metrics in the AWS/S3/Files namespace, per FileSystemId. The ones to alarm on first:

• ExportFailures and ImportFailures: files that could not sync after retries, usually permissions, KMS keys or path length limits. Any value above zero needs attention.
• PendingExports and ExportAge: a growing backlog means you write faster than S3 Files exports; ImportAge does the same for bucket changes coming in.
• LostAndFoundFiles: conflicts where the bucket version won; investigate which writer changed the bucket directly.
• StorageBytes, Inodes and ClientConnections: size, file count and how many clients are mounted.

aws cloudwatch put-metric-alarm --alarm-name s3files-export-failures \
  --namespace AWS/S3/Files --metric-name ExportFailures \
  --dimensions Name=FileSystemId,Value=fs-0123456789abcdef0 \
  --statistic Sum --period 300 --evaluation-periods 1 \
  --threshold 0 --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:sns:eu-west-2:111122223333:ops-alerts

The client also publishes connectivity metrics in the efs-utils/S3Files namespace: NFSConnectionAccessible, S3BucketAccessible and S3BucketReachable. When large reads are slow, a 0 in S3BucketAccessible usually means the compute role lacks the direct S3 read permission, so every read is going through the file system instead of streaming from S3.

Security: who can read what

Three layers decide access, and it helps to know which one answers which question. IAM decides which roles may mount the file system at all and whether they may write (the client policies or s3files:ClientMount and s3files:ClientWrite). A file system policy, a resource policy of up to 20,000 characters attached to the file system, can add conditions such as requiring a specific access point or blocking root access. POSIX permissions then decide which Linux users can open which files once mounted, and access points can force every request to a fixed user and group with a fixed root folder, which is the simplest way to keep one application inside its own directory.

Remember the side door: the compute role's direct S3 read permission (needed for fast large reads) is governed by IAM and bucket policies, not by POSIX permissions. If some users must not read certain files, enforce that in the bucket policy or by scoping the file system to a prefix, not only with chmod. Data is encrypted in transit with TLS on every mount and at rest with KMS, using an AWS owned key by default or your own customer managed key.

S3 Files best practices

• Scope to the smallest prefix your workload needs: fewer objects to import, cheaper renames, and tighter access.
• Use several file systems for scale: one per prefix spreads load and lifts the per-file-system limits.
• Read and write in large chunks: operations are metered at 32 KiB minimum, so 1 MiB I/O is cheaper per byte; the mount helper already sets 1 MiB NFS buffers.
• Tune the import threshold (default 128 KiB) to your file sizes, and use prefix rules to keep cold prefixes metadata-only.
• Match the expiry window to the job: 1 to 7 days for batch jobs and training runs, 30 to 90 days for data revisited over weeks.
• Put a mount target in every Availability Zone you use, to avoid cross-zone transfer charges and keep a local path.
• Pick one primary writer per path, file system or S3 API, to avoid conflicts.
• Leave the S3 Files role and its EventBridge rule alone (the rule's name starts with DO-NOT-DELETE-S3-Files); changing them breaks sync.
• Restrict client logs: /var/log/amazon/efs records object key names, so lock it down with chmod 700 if your keys contain sensitive names.

Jake: "Someone deleted a rule called DO-NOT-DELETE and the folder stopped updating."

Ethan: "The name was the instruction. Recreate the file system's sync rule, then add an SCP so nobody can delete it again."

Common S3 Files errors and fixes

• unknown filesystem type 's3files': amazon-efs-utils is missing or older than 3.0.0; install or update it.
• Mount hangs, then times out: port 2049 is blocked between the client and the mount target, there is no mount target in the client's Availability Zone, or the client is in another VPC without peering or a transit gateway. For cross-VPC mounts, pass -o mounttargetip=10.0.1.25.
• Access denied when mounting: the compute role lacks the client permissions (s3files:ClientMount, plus s3files:ClientWrite for read-write), or a bucket policy denies the role. Our bucket access guide explains policy layers.
• Read-only file system errors: the role has only the read-only client policy (no s3files:ClientWrite), or the POSIX owner and mode on the folder, often forced by an access point's user ID, block that user.
• Create file system fails: versioning is off, the bucket uses an encryption type other than SSE-S3 or SSE-KMS, the bucket access role's trust policy is wrong, or the prefix is so large it needs the explicit rename warning accepted.
• Changes not in the bucket yet: exports wait for 60 seconds without writes; check the sync metrics in CloudWatch if it takes much longer.
• A file reverted and a copy appeared in .s3files-lost+found-…: a conflict; the bucket's version won. Copy yours back if it should win.
• Some files cannot be opened: archived storage classes; restore them first. KMS-encrypted objects also need the KMS permissions on the bucket access role (our S3 KMS access denied guide shows the key policy side).
• ECS task stops with a volume error: it is running on the EC2 launch type; use Fargate or ECS Managed Instances.

CloudWatch metrics for the file system show storage, throughput, client connections and synchronization errors, which is the first place to look when something is slow or stuck.

Frequently asked questions

Two weeks after the switch, the EFS share and both nightly jobs were gone. The document app mounts the bucket through S3 Files on its instances and in a Lambda function that generates previews, the analysts query the same objects with Athena minutes after they are saved, and a lifecycle rule clears noncurrent versions after 14 days. The file system part of the bill came to a few dollars, because only the small, busy files ever sit on the fast storage.

Revision note. Written October 20, 2026. Prices shown are example list rates; check your Region before you plan a budget.