AWS Builder Center

Builder Center

Getting started with Amazon S3 Files using ECS Fargate and Terraform

Learn how to use Amazon S3 Files to mount Amazon S3 buckets as a file system in Amazon ECS Fargate using Terraform.

Lud Silva

Cloud Enginner
On April 7, 2026, AWS introduced a new feature that brings object storage and file storage closer together: Amazon S3 Files.
In this article, we'll explore what Amazon S3 Files is, why it matters, and how to use it with an Amazon ECS Fargate application provisioned with Terraform.
Let's dive in!

Life Before Amazon S3 Files

For years, cloud architects and engineers had to choose between object storage and file storage. In AWS, that usually meant choosing among services such as:
  • Amazon S3: one of AWS's oldest services, launched in 2006. It's highly scalable, durable, and cost-effective, but it doesn't provide traditional file system semantics.
  • Amazon EFS: a fully managed NFS file system with POSIX compatibility, designed for shared file storage, but generally more expensive.
  • Amazon EBS: high-performance block storage with low latency, primarily intended for EC2 instances.
  • Amazon FSx: managed file systems for workloads that require Windows File Server, Lustre, NetApp ONTAP, or OpenZFS.
When applications needed to work with both object and file storage, data often had to be copied between services, for example: from S3 to EFS, from S3 to EBS, or from S3 to FSx and then synchronized back again.
This approach introduced several challenges like: aditional storage costs; more complex architectures; data synchronization overhead; duplicate copies of the same data and increased operational effort.
With Amazon S3 Files, many of these challenges can now be significantly reduced.

What exactly is Amazon S3 Files?

Amazon S3 Files is a feature that allows applications to access data stored in Amazon S3 as if it were a traditional file system. In practice, it connects AWS compute services such as Amazon EC2, Amazon ECS, Amazon EKS, AWS Fargate, and AWS Lambda to data stored in S3, exposing objects as directories and files through a standard NFS interface.
As a result, applications that expect a traditional file system can work directly with data stored in S3 without copying it to another storage service. From the application's perspective, everything looks like regular files and directories, while the data continues to live as S3 objects behind the scenes.
Another important point is that Amazon S3 Files is not a new storage service. Instead, it provides a new way to access data that already exists in Amazon S3. The service uses an intelligent caching layer to keep recently accessed data readily available, while inactive files are automatically evicted from the cache after a configurable period (from 1 to 365 days, with 30 days as the default). The original data always remains stored in Amazon S3. This architecture can significantly reduce storage costs compared to solutions that require maintaining duplicate copies of data in both object storage and file systems.
Simply put, Amazon S3 Files lets applications access S3 objects through a familiar file system interface while keeping Amazon S3 as the single source of truth.

Common use cases

Some common use cases include:
  • Replacing managed SFTP servers: Organizations that receive files from partners can provide direct access to data stored in Amazon S3.
  • Machine Learning (ML): Eliminates the need to create temporary copies of datasets on local disks before training, since data can be accessed directly from Amazon S3 during training and inference.
  • AI Agents: Multiple AI agents can share files, logs, and persistent state.
  • Legacy applications: Applications that expect a traditional file system can work directly with data stored in Amazon S3.
  • Collaborative workspaces: Teams can share datasets without maintaining multiple synchronized copies.

Amazon S3 Files vs. Amazon EFS

One of the first questions that comes to mind is: Does Amazon S3 Files replace Amazon EFS?
The answer is: it depends on your workload**.** The following table provides a quick comparison to help you understand when to choose one over the other.
Amazon S3 Files
Amazon EFS
Data remains stored in Amazon S3
Data is stored directly in Amazon EFS
Lower storage cost for large datasets
Lower latency and consistent performance
Uses intelligent caching for frequently accessed files
No cache layer; all data is immediately available
Ideal for AI, analytics, media processing, batch workloads, and applications that already store data in Amazon S3
Ideal for POSIX workloads requiring shared storage with consistently low latency
Synchronization between NFS and S3 is asynchronous
Native file system with immediate consistency between clients
As you can see, there isn't a single winner; Amazon S3 Files and Amazon EFS solve different problems. While Amazon S3 Files enables applications to access data already stored in Amazon S3 through a file system interface, Amazon EFS remains the better choice for workloads that require low latency, immediate consistency, and continuous shared access across multiple compute instances.
In short, Amazon S3 Files doesn't replace Amazon EFS, it addresses a different use case.

Lab: deploying Amazon ECS Fargate with Amazon S3 Files Using Terraform

Now let's build a practical example. For this lab, we'll deploy a task on Amazon ECS Fargate, AWS's serverless service for running and orchestrating Docker containers. With Fargate, we can run containers without provisioning, configuring, or managing EC2 clusters.
We chose Fargate to abstract away the underlying infrastructure, keeping the focus of this article on Amazon S3 Files itself. It also takes advantage of Fargate's pay-for-what-you-use pricing model, where you're charged based on the CPU and memory allocated to each task.
For simplicity, the entire infrastructure will be provisioned with Terraform using the official AWS community-maintained modules.
Another important detail is that, in this lab, we'll mount only a prefix of the S3 bucket, rather than the entire bucket. This is a recommended practice because it reduces the amount of metadata imported when the file system is created, speeds up the initial mount process, and minimizes the impact of operations such as moving or renaming directories, which in Amazon S3 are implemented as object copy and delete operations.

Architecture

This lab provisions, using Terraform, everything required to connect an Amazon ECS Fargate container to an Amazon S3 bucket through Amazon S3 Files:
  • A VPC with private subnets across two Availability Zones;
  • An Amazon S3 bucket with versioning enabled (a prerequisite for the service);
  • An Amazon S3 Files file system with one mount target per Availability Zone;
  • IAM roles for both the ECS service and the task;
  • An ECS cluster with a Fargate service configured to mount the  lab/  prefix of the bucket at  /mnt .
                +----------------------+
                | Amazon ECS Fargate   |
                |      Container       |
                +----------+-----------+
                           |
                           | NFS v4.1
                           |
                +----------v-----------+
                |   Amazon S3 Files    |
                +----------+-----------+
                           |
                           | Async sync
                           |
                +----------v-----------+
                |    Amazon S3 Bucket  |
                +----------------------+
In this demonstration, our container runs on Amazon ECS Fargate and sees the  lab/  prefix of the bucket as if it were a local directory mounted at  /mnt . As mentioned earlier, mounting a specific prefix instead of the entire bucket is a recommended practice.
Behind the scenes, Fargate configures an NFS proxy on the task's network interface. Whenever the container writes a file, Amazon S3 Files synchronizes the data with the S3 bucket in the background, typically within a minute. From the application's perspective, it's simply writing to a local disk.
To validate the setup, we'll use a custom Docker image based on Alpine. Its entrypoint script verifies the NFS mount, displays the available disk space, and writes a test file to the mounted prefix.
One important note: any container image would work with Amazon S3 Files. The mount is performed by the Fargate platform before the container starts, regardless of what's inside the image. The custom image exists only to make the validation easier through the application logs. Otherwise, we'd need to connect to the running container manually to verify that the volume was mounted successfully.

Prerequisites

Before getting started, make sure you have:
  • An AWS account
  • Terraform >= 1.8
  • AWS CLI configured
  • Docker installed
  • Permissions to create:
  • VPC
  • ECS
  • IAM
  • Amazon S3
  • Amazon S3 Files

Step 1 - Clone the repository

To get started, clone the GitHub repository containing the Terraform files:
git clone https://github.com/ludsilva/aws-s3files-ecs.git
cd aws-s3files-ecs
Inside the repository, you'll find all the Terraform files required to provision the infrastructure used in this demonstration.

Step 2 - Provision the infrastructure

Run the following commands:
terraform init
terraform apply
Terraform provisions the VPC, Amazon S3 bucket, Amazon S3 Files, IAM resources, and the Amazon ECS service. During the deployment, Terraform also waits for the Amazon S3 Files mount targets to become available. As a result, the  terraform apply  command will only complete once the file system is ready to be mounted by the ECS task.

Step 3 - Monitor the logs

Once the infrastructure has been provisioned, Amazon ECS Fargate starts the task and executes the container entrypoint script.
To follow the application logs, you can either access the AWS Management Console or run:
aws logs tail /ecs/app-s3-files --follow
Logs with Lab completed message

Expected output:
[OK] Lab completed

Step 4 - Verify synchronization with Amazon S3 Files

To confirm that the file was actually written to the S3 bucket, you can either use the Amazon S3 console or run the following command:
aws s3 ls s3://my-blog-s3-files-demo/lab/test/
After approximately 60 seconds, the  result.txt  file should appear in the bucket.
Txt file in S3 Bucket


Step 5 - Testing file persistence

Finally, let's validate the persistence of the files written through Amazon S3 Files.
To do this, stop the running ECS task manually (or by using the  aws ecs stop-task  command) and wait for Amazon ECS to automatically launch a new one.
Once the new task is running, follow the application logs again. You'll notice that the entrypoint script runs once more, generating a new  result.txt  file with a different timestamp.
Logs with Lab completed message

In the S3 bucket, you can confirm that the previous  result.txt  file is still there, while a new file with a different timestamp has also been created. This demonstrates that the persistence of files written through Amazon S3 Files is independent of the container lifecycle.
3 .txt files with different timestamps, resulting from the execution of new tasks

Note: Since our custom Docker image generates a timestamped file, the contents of  result.txt  will be different each time the container starts. However, the file itself remains stored in the bucket. If you'd like, you can repeat this test using a different Docker image and write files to the mounted directory.

Step 6 - Cleaning up

To avoid unexpected charges on your AWS bill, remember to remove all the resources created during this lab. Run:
terraform destroy

Estimated Lab costs

For reference, this architecture would cost approximately $41.30 USD per month if it were running continuously. Since this lab is intended to run for only a few hours, the actual cost is typically just a few cents.
Below is an estimated monthly cost breakdown:
Resource
Estimated Cost (USD/month)
Amazon ECS Fargate
~$8.90
Amazon S3
< $0.01
NAT Gateway
~$32.40
Total
~$41.30
Note: These values are only estimates for this lab and may vary depending on the AWS Region, application runtime, the amount of data stored, and the number of requests made to Amazon S3 Files and the S3 bucket.

Important considerations

Although Amazon S3 Files simplifies access to data stored in Amazon S3 through a file system interface, it's important to understand some of its characteristics before adopting it:
  • Amazon S3 Files doesn't replace every storage option: as mentioned earlier, even though it uses NFS as its access interface, the underlying storage is still Amazon S3. This means it inherits Amazon S3's latency characteristics. As a result, workloads that are highly latency-sensitive or require consistently high IOPS, such as databases, are still better served by Amazon EBS or Amazon EFS.
  • Synchronization between NFS and Amazon S3 is asynchronous: changes made through the file system and through the Amazon S3 API are not reflected immediately across both interfaces. If your application requires immediate consistency between multiple consumers or simultaneously accesses the same files through both the file system and the S3 API, this behavior should be taken into account.
  • Avoid concurrent writes: is a best practice to designate a single interface for writing data. If the same file is modified simultaneously through both the file system and the Amazon S3 API, conflicts may occur. In these situations, the version stored in Amazon S3 is preserved, while the conflicting version is automatically moved to the  S3.lost+found  directory.
  • Rename operations can be expensive: unlike traditional file systems, Amazon S3 doesn't provide a native  rename  operation. Renaming or moving directories requires copying all affected objects and then deleting the originals. For large datasets, this can significantly increase both execution time and costs.
  • Mount only the required prefix: whenever possible, mount only the bucket prefix your application needs instead of the entire bucket. This reduces the amount of metadata loaded during the mount process, speeds up application startup, and minimizes the impact of directory-related operations.

Conclusion

Amazon S3 Files represents an important shift in how applications can consume data stored in Amazon S3. By providing access through a file system interface, it reduces the need for multiple storage layers and simplifies architectures that previously relied on services such as Amazon EFS solely to share files.
Although it doesn't completely replace Amazon EFS in every scenario, it opens up new possibilities for workloads running on Amazon ECS, Amazon EKS, Amazon EC2, Machine Learning, and AI, especially when the goal is to reduce costs while simplifying both data management and application architecture.
More than just a new feature, Amazon S3 Files is an opportunity to rethink how applications are designed on AWS. Like any new technology, however, its adoption should be guided by your application's latency, consistency, and access pattern requirements. In other words, Amazon S3 Files doesn't eliminate the need for sound architectural decisions, it the architectural options for building simpler, more cost-effective solutions that better align with real-world application behavior.

References

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article