Amazon S3 Files launch

Amazon just tried to erase one of cloud computing’s oldest dividing lines. On April 7, 2026, Amazon Web Services launched Amazon Simple Storage Service Files, a new layer that lets software open data in Amazon Simple Storage Service as if it were sitting in a normal shared file system instead of an object bucket. (aws.amazon.com) That split has shaped cloud architecture for nearly two decades. Amazon Simple Storage Service, usually called Amazon S3, stores data as objects, which works well for backups, logs, media, and giant data lakes, but object storage does not behave like the file system on a laptop or a shared network drive. (docs.aws.amazon.com) A file system and an object store solve different problems. A file system lets programs update part of a file, lock it while another process waits, and walk through folders in place, while an object store usually treats each object more like a sealed package that gets replaced as a whole. (aws.amazon.com) That difference sounds abstract until an application expects file behavior and gets object behavior instead. Amazon’s own Mountpoint for Amazon S3 has long helped Linux workloads read and write S3 buckets more naturally, but Amazon says workloads that need full POSIX support should use Amazon FSx for Lustre instead, which shows how incomplete the old bridge was for file-native software. (docs.aws.amazon.com) Amazon S3 Files is the new bridge. Amazon Web Services says the service makes any general-purpose Amazon S3 bucket accessible as a high-performance file system from Amazon Elastic Compute Cloud instances, containers on Amazon Elastic Container Service and Amazon Elastic Kubernetes Service, and Amazon Lambda functions. (aws.amazon.com) The pitch is simple: keep the data in S3, but let applications touch it like files. Amazon says S3 Files provides full file-system semantics, low-latency access, and synchronization between file operations and the underlying S3 bucket, so a change made through the file interface is reflected back in object storage. (aws.amazon.com) The performance claim is what made engineers stop scrolling. In the launch materials, Amazon Web Services said S3 Files can deliver about 1 millisecond latency, and the company described the product as a way to give S3 “high-performance” file access without moving data out of S3 into a separate storage silo. (aws.amazon.com) The way it gets there is not by turning every byte in a bucket into a hot file all at once. Amazon’s documentation says S3 Files stores actively used data on a file system’s high-performance storage, imports metadata when directories are touched, and by default pulls in file data under 128 kilobytes when a directory is first accessed. (docs.aws.amazon.com) Large reads take a different path. Amazon says files that are better served by large sequential reads can be streamed directly from Amazon S3, while byte-range reads move only the requested bytes, which means the service is constantly deciding whether to use the fast file-system layer or the bucket underneath it. (aws.amazon.com) That hybrid design is why the launch immediately turned into a pricing argument. Amazon’s metering page says S3 Files charges on two dimensions: the amount of data stored on the file system’s high-performance storage, measured in gigabyte-months, and the file-system operations performed by applications and synchronization. (docs.aws.amazon.com) That is where comparisons with Amazon Elastic File System started. Amazon Elastic File System, usually called Amazon EFS, is Amazon’s managed shared Network File System service, and S3 Files documentation explicitly says the new service is built using Amazon EFS, which helps explain why many engineers read the launch as part S3 feature and part EFS-style cache in front of S3. (aws.amazon.com) (docs.aws.amazon.com) The most repeated number in the backlash was $0.30 per gigabyte-month. That figure showed up in discussion threads because Amazon has historically priced Amazon EFS Standard storage at $0.30 per gigabyte-month in some examples, and outside analysts quickly argued that if S3 Files keeps a meaningful hot working set on a premium layer, the cheap-S3 story can get expensive fast. (aws.amazon.com) (lastweekinaws.com) Amazon’s own docs support the idea that cost depends on how much you keep hot. The customization guide says importing more data up front lowers read latency but raises storage and write charges, while importing less keeps storage costs down but leaves more reads to come from S3 with higher latency. (docs.aws.amazon.com) So the real comparison is not “S3 versus EFS.” The real comparison is whether a workload’s active slice is small enough that you can pay file-system prices for the hot portion and object-storage prices for the cold portion, instead of paying file-system prices for every byte all month. (docs.aws.amazon.com) (aws.amazon.com) That makes the launch feel aimed at a specific class of software. Amazon’s materials repeatedly point to production applications, machine learning training, and agentic artificial intelligence systems, which are all cases where teams want shared files, low latency, and one central copy of data without duplicating buckets into a separate file store. (aws.amazon.com) The lock-in debate followed right behind the pricing debate. Because S3 Files is presented as a native Amazon Web Services way to give Amazon S3 buckets POSIX-style behavior, teams that build around its synchronization rules, mount targets, and high-performance storage layer may get a simpler stack inside Amazon Web Services while becoming more dependent on Amazon-specific storage semantics. That lock-in concern is an inference from the product design and the fact that the feature is tightly integrated with Amazon S3, Amazon EFS components, and Amazon’s compute services. (docs.aws.amazon.com 1) (docs.aws.amazon.com 2) (aws.amazon.com) Amazon S3 Files is real, and the argument around it is real too. If a team has petabytes of cold data in Amazon S3 and only a thin hot layer that needs file locking, low latency, and shared access, this launch could remove a lot of copying and glue code; if that hot layer grows large or stays hot all month, the economics could start to look a lot more like Amazon Elastic File System with extra steps. ([aws.amazon.com](https://aws.amazon.com/s3/features/files/