News

Amazon S3 Files: NFS Mounts Without Code Changes

Amazon S3 Files is generally available since April 7, 2026. The feature allows mounting S3 buckets directly as an NFS-compatible file system in EC2, EKS, and Lambda – without code changes to …

By Benedikt Langer May 3, 2026 6 min read

Amazon S3 Files: NFS Mounts Without Code Changes

Amazon S3 Files is generally available since April 7, 2026. The feature allows mounting S3 buckets directly as an NFS-compatible file system in EC2, EKS, and Lambda – without code changes to existing applications. For DACH teams with legacy workloads, ML pipelines, and shared storage requirements, this fundamentally changes the architecture options.

Key Takeaways

NFS mount without application changes: S3 Files provides a POSIX-compatible mount point. Existing applications that work with open(), read(), and write() can access S3 without refactoring.
34 regions, significant price difference to EFS: S3 storage costs around 0.02 euros/GB/month in standard, EFS around 0.26 euros/GB/month in standard mode. For large ML datasets and model checkpoints, the cost factor is relevant.
Latency is the trade-off: Metadata operations with S3 Files are at 10-50ms, EFS under 1ms. Workloads with many small file operations (transactional databases, small config files at high frequency) are not the target scenario.
EKS integration via CSI driver: The AWS S3 CSI driver is updated and supports S3 Files as a PersistentVolume. Multi-pod access to the same bucket is possible, important for distributed training setups.

What S3 Files does technically – and what it doesn’t

What is Amazon S3 Files? S3 Files is a new feature from Amazon S3 that provides a POSIX-compatible file system mount endpoint for existing S3 buckets. Under the hood, a managed service translates POSIX calls into S3 API operations. The result: an application that reads /mnt/data/model.bin actually accesses s3://bucket/model.bin – without knowing it.

The technical foundation is the S3 Files Agent, a sidecar process running on the EC2 instance or in the Kubernetes pod. It handles the POSIX-to-S3 translation and maintains a local metadata cache. The agent is integrated into EKS via the AWS S3 CSI driver; for EC2, there is an RPM and DEB package. Lambda support is available via managed runtime layers.

What S3 Files is not: a full POSIX file system. File locking (flock/fcntl) is not supported. Symbolic links are read-only. Rename operations do not have atomic guarantees with concurrent access. For applications that rely on these primitives – particularly classic SQL databases or build systems with file locking – EFS remains the right choice.

Three Scenarios for DACH Teams

For which workloads is S3 Files a good fit?

ML Training and Model Serving: This is the primary scenario. Training data and model checkpoints are already stored in S3. With S3 Files, a PyTorch training job can read data via /mnt/training-data without the code needing to know about S3. Multi-pod access to the same bucket enables distributed training setups on SageMaker and EKS. The cost advantage over EFS is significant for datasets in the TiB range: with 10 TiB of training data, S3 Files saves around 2,414 euros/month compared to EFS Standard.

Legacy Applications with Filesystem Interface: Many older Java and C++ applications read configurations and temporary data from the local file system. If the actual storage is already in S3, S3 Files allows you to dispense with a separate EFS layer. This simplifies the deployment architecture, especially for lift-and-shift migrations that haven’t been refactored yet.

Lambda and Serverless Pipelines: Until now, Lambda functions have only had EFS as a persistent file system. S3 Files is more cost-effective. For Lambda workloads that already operate on S3 data (ETL, image processing, batch transformations), mounting is a more natural access method than S3 API calls in the code.

Storage Options Cost Comparison (us-east-1)

around 20 euros

S3 Files / GB / Month (Standard)

around 26 euros

EFS Standard / GB / Month

around 126 euros

FSx for Lustre Scratch / GB / Month

// Key point

The feature allows you to mount S3 buckets directly as an NFS-compatible file system in EC2, EKS, and Lambda – without changing code in existing applications.

What’s changing with EKS

For Kubernetes teams, the relevant entry point is the AWS S3 CSI driver in version 1.10, which brings S3 Files support. A PersistentVolume with S3 Files looks like this:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: s3-files-pv
spec:
  capacity:
    storage: 100Gi
  accessModes:
    – ReadWriteMany
  mountOptions:
    – allow-delete
    – allow-overwrite
  csi:
    driver: s3.csi.aws.com
    volumeHandle: s3-files-bucket-name

ReadWriteMany means that multiple pods can write to the same bucket simultaneously. For ML distributed training with parameter servers or shared model repositories, this is a clear advantage over a single EBS volume that can only be ReadWriteOnce.

A note for DACH teams under GDPR: the S3 bucket must be located in a European region. Frankfurt (eu-central-1) and Stockholm (eu-north-1) are fully supported. The S3 Files Agent communicates exclusively with the regional S3 endpoint – no data leaves the region.

When EFS and FSx are still a better choice

S3 Files is not a replacement for EFS. The latency differences are real: for applications with many small, sequential file system operations – classic web servers, PHP applications that frequently read config files, build systems – EFS is clearly ahead. Metadata operations like stat() or directory listings are significantly slower with S3 Files.

FSx for Lustre remains the tool of choice when maximizing bandwidth – Lustre is designed for parallel high-throughput, S3 Files is not. For very large ML workloads (models over 100 GB, intensive sequential reads), the FSx premium is still worth it.

S3 Files: right for

ML training on large datasets (>100 GB)
Model checkpoints and artifact storage
Lambda functions with file system interface
Legacy apps during lift-and-shift without refactoring
Cost optimization for storage-intensive workloads

Still EFS/FSx for

Applications with file locking requirements
Many small, sequential metadata operations
Web servers with frequent config reads
Classic SQL database files
Maximum throughput (>10 GB/s per pod)

The right decision question: Is the primary storage of the workload already in S3 – does the application not have file locking? Then S3 Files is the obvious choice. Is the storage in EBS or EFS – is the application highly latency-dependent? Then EFS remains the better option.

Sources: AWS documentation S3 Files GA (April 2026), AWS Pricing Calculator, AWS re:Invent S3 session materials.

Frequently Asked Questions

Is S3 Files compatible with all S3 storage classes?

S3 Files supports S3 Standard, S3 Intelligent-Tiering, and S3 Standard-IA for read and write operations. S3 Glacier and Glacier Deep Archive are not directly mountable – objects in Glacier must be restored first. For ML datasets, AWS recommends S3 Intelligent-Tiering as the standard storage class, as training data access patterns vary.

How does S3 Files behave in multi-region deployments?

S3 Files only mounts buckets in the same region as the mount point. Cross-region access is not directly supported. Those with workloads across multiple regions need either S3 Replication for read access or S3 Multi-Region Access Points as a separate layer. For DACH teams with eu-central-1 and eu-west-1 as primary regions, this is a planning point for global deployments.

Does S3 Files require additional IAM permissions compared to normal S3 access?

Yes. In addition to standard S3 permissions (GetObject, PutObject, DeleteObject), S3 Files requires s3:ListBucket, s3:GetBucketLocation, and the new s3files:* actions for metadata operations. The complete IAM policy is documented in the AWS documentation under “S3 Files IAM Permissions.” For least-privilege policies, these actions must be explicitly added.

Can S3 Files be used in AWS GovCloud and EU sovereign deployments?

S3 Files is available in AWS GovCloud (US-East and US-West). For EU sovereign requirements according to BSI C5 and GDPR: S3 Files runs in eu-central-1 (Frankfurt) and is thus usable under German data protection conditions. AWS has S3 Files in the scope of the C5 certification process, and the test update for 2026 was in progress at GA launch. Those who need this for KRITIS compliance should request the current C5 test directly from the AWS Compliance Team.