AWS S3 Files: object storage just became a file system
AWS S3 Files lets you mount S3 buckets as local file systems on compute resources. We explore what this means for architecture, cost, and ML workflows.
What happened
AWS has launched S3 Files, a new capability that makes S3 buckets accessible as high-performance file systems on AWS compute resources. In practical terms, EC2 instances, containers, and Lambda functions can now mount an S3 bucket as a local file system, with approximately 1ms latencies.
This eliminates a long-standing tradeoff. Until now, organisations had to choose between the durability, scale, and cost profile of S3 object storage and the interactive, POSIX-compatible access patterns of a traditional file system. S3 Files bridges that gap.
Why this matters
Many workloads still depend on file-based access. Machine learning training pipelines, analytics platforms, content management systems, and legacy applications all expect to read and write files in a directory structure. Previously, serving these workloads from S3 meant bolting on additional services like Amazon FSx or running custom sync processes to keep object and file layers aligned.
S3 Files simplifies this. One storage layer. One set of data. Accessible as both objects and files.
The implications are worth considering:
- Reduced architectural complexity. No more maintaining separate file and object storage tiers for the same data. Fewer moving parts means fewer failure modes.
- Cost consolidation. S3's tiered pricing model, including Intelligent-Tiering and lifecycle policies, now applies directly to data that would previously have lived on more expensive file storage.
- AI and ML workflows. Training jobs that need fast file-level access to large datasets can now read directly from S3 buckets. This removes a common bottleneck in data pipeline design.
- Data sharing. Multiple compute resources can access the same S3 bucket as a shared file system, simplifying collaboration across services and teams.
What organisations should consider
This is a meaningful step forward, but it does not automatically replace every file storage deployment.
First, evaluate your existing file system workloads. Some will benefit immediately from migration to S3 Files, particularly those already tightly coupled with S3 for storage. Others, especially those with strict POSIX compliance requirements or sub-millisecond latency needs, will need careful testing.
Second, review your access controls. S3 bucket policies, IAM permissions, and encryption configurations all apply. Mounting a bucket as a file system does not change the security model, but it does change the access surface. Ensure your policies account for file-level operations, not just API calls.
Third, consider the operational impact. If you are currently running Amazon EFS or FSx alongside S3, there may be an opportunity to consolidate. That means lower costs and simpler management, but only if the performance characteristics meet your workload requirements.
Metaphor's perspective
We have seen many organisations maintain parallel storage architectures simply because their applications needed both file and object access. That duplication creates cost, complexity, and data consistency challenges.
S3 Files is the kind of infrastructure improvement that quietly reshapes how cloud architectures are designed. It does not demand immediate action, but it should prompt a conversation about whether your current storage topology is still the right one.
If you are planning a cloud migration, building ML pipelines, or looking to simplify your AWS environment, this is worth factoring into your design decisions. We help organisations make these assessments pragmatically, matching capability to actual workload requirements rather than chasing features for their own sake.
Sources: AWS Blog: Launching S3 Files, making S3 buckets accessible as file systems