Amazon S3 Files na prática: integrando ECS Fargate e S3 usando Terraform

No dia 7 de abril de 2026, a AWS lançou um novo recurso que aproxima o armazenamento de objetos e o armazenamento de arquivos: o Amazon S3 Files.

Até antes do seu lançamento, as aplicações que precisavam acessar arquivos armazenados no Amazon S3 frequentemente dependiam de outras soluções, aumentando custos e complexidade. Agora, o Amazon S3 Files muda esse cenário ao permitir que buckets sejam acessados como sistemas de arquivos via NFS.

Neste artigo, vamos entender o que é o S3 Files, por que ele é tão importante e ainda como utilizá-lo em uma demonstração com ECS Fargate e Terraform.

Bora lá?

A vida antes do S3 Files

Por anos, arquitetos e outros profissionais da nuvem precisavam escolher entre armazenamento de objetos e armazenamento de arquivos. Na AWS, isso se resumia, na maioria dos casos, aos serviços:

• Amazon S3: é um dos serviços mais antigos da AWS, lançado em 2006. É escalável, durável, barato, mas sem semântica de sistema de arquivos;
• Amazon EFS: sistema de arquivos compatível com POSIX/NFS, porém mais caro e com outro modelo de uso;
• Amazon EBS: armazenamento em bloco de alto desempenho e baixa latência;
• Amazon FsX: família de sistemas de arquivos gerenciados, com opções para Windows File Server, Lustre, NetApp ONTAP, entre outras.

Para fazer com que os dados trafegassem pelos sistemas, eles eram copiados de um lado para o outro: do S3 para o EFS, do S3 para o EBS, do S3 para FsX, depois copiar tudo de volta e por aí vai. Todo esse processo gerava custos adicionais de armazenamento; complexidade de configuração e sincronização dos dados; duplicação do armazenamento; entre outros.

Mas agora, com o S3 Files, muitos desses problemas podem ser eliminados ou significativamente reduzidos...

O que é o Amazon S3 Files

O Amazon S3 Files é um recurso que permite acessar dados armazenados no Amazon S3 como se fossem um sistema de arquivos tradicional. Na prática, ele conecta os recursos de computação da AWS (tais como EC2, ECS/EKS, Fargate e funções Lambda) aos dados do S3, por meio do protocolo padrão NFS, apresentando-os como diretórios e arquivos navegáveis. Dessa forma, aplicações podem ler e gravar arquivos sem a necessidade de copiá-los para outro serviço de armazenamento, enquanto os dados continuam sendo armazenados nativamente como objetos no Amazon S3.

Um ponto importante é que internamente o S3 Files compartilha a camada NFS com o EFS. Para isso, ele mantém apenas os dados usados ativamente armazenados em uma camada de cache de alto desempenho. Os arquivos que permanecem sem acesso por um período configurável (1 a 365 dias, sendo 30 dias o padrão) são removidos automaticamente do cache, permanecendo disponíveis no bucket. Ou seja, os dados continuam armazenados no S3, o que pode reduzir consideravelmente os custos se comparado à duplicação dos dados entre sistemas de arquivos e armazenamento de objetos.

E veja bem um detalhe aqui: não se trata exatamente de um novo serviço de armazenamento, mas uma nova forma de acessar os dados existentes no S3.

Principais casos de uso

• Substituição de servidores SFTP gerenciados: Empresas que recebem arquivos de parceiros podem disponibilizar acesso direto aos dados armazenados no S3;
• Machine Learning (ML): Elimina a necessidade de criar cópias temporárias dos dados do S3 em discos locais antes do treinamento, pois datasets podem ser acessados diretamente durante treinamento e inferência;
• Agentes de Inteligência artificial: Múltiplos agentes podem compartilhar arquivos, logs e estados persistentes;
• Aplicações legadas: aplicações que esperam um sistema de arquivos tradicional podem operar diretamente sobre dados armazenados no S3;
• Espaços de trabalho colaborativos: Equipes podem compartilhar conjuntos de arquivos sem necessidade de múltiplas cópias.

S3 Files x Amazon EFS

Uma dúvida comum é se o S3 Files substitui completamente o Amazon EFS. A resposta é: depende da carga de trabalho.

No quadro abaixo, temos uma breve comparação que ajude a entender sobre quando usar um ou outro:

Amazon S3 Files	Amazon EFS
Os dados permanecem armazenados no Amazon S3	Os dados são armazenados no próprio EFS
Melhor custo para grandes volumes de dados	Melhor latência e desempenho consistente
Utiliza cache inteligente para os arquivos mais acessados	Não utiliza cache; todos os dados estão disponíveis diretamente
Ideal para IA, Analytics, mídia, processamento em lote e aplicações que já armazenam dados no S3	Ideal para aplicações POSIX tradicionais que exigem acesso compartilhado de baixa latência
Sincronização entre NFS e S3 é assíncrona	Sistema de arquivos nativo com consistência imediata entre clientes
Compatibilidade POSIX (via NFS/cache)	Compatibilidade POSIX completa

Veja que entre o S3 Files e o EFS não existe um vencedor absoluto, pois eles atendem necessidades diferentes. Enquanto o S3 Files permite que aplicações acessem dados já armazenados no Amazon S3 através de uma interface de sistema de arquivos, o EFS continua sendo a melhor escolha para workloads que exigem baixa latência, consistência imediata e acesso compartilhado contínuo entre múltiplas instâncias.

Em resumo, podemos dizer que o S3 Files não substitui o Amazon EFS; ele resolve um problema diferente: permitir que aplicações que esperam um sistema de arquivos trabalhem diretamente sobre dados armazenados no Amazon S3.

Demonstração: implementando ECS Fargate com S3 Files via Terraform

Para este laboratório, vamos subir uma task no ECS Fargate, que é o serviço serveless da AWS voltado para execução e orquestração de containers Docker. Com ele, podemos executar os containers sem a necessidade de provisionar, configurar ou gerenciar clusters de máquinas EC2. Dessa forma, a escolha pelo Fargate se deu a fim de abstrairmos o gerenciamento da infraestrutura para o exemplo deste artigo, e também aproveitarmos o modelo de cobrança baseado nos recursos alocados para cada task (CPU e memória).

Além disso, para fins de praticidade, a estrutura será provisionada com Terraform, utilizando os módulos da AWS mantidos pela comunidade para acelerar o desenvolvimento.

Outro ponto importante é que, neste laboratório, usaremos como ponto de montagem apenas um prefixo do bucket S3, e não o bucket inteiro. Essa é uma prática recomendada, pois reduz a quantidade de metadados importados durante a criação do sistema de arquivos, acelera a montagem inicial e minimiza o impacto de operações como movimentação e renomeação de diretórios, que no Amazon S3 são implementadas por meio de operações de cópia e exclusão de objetos.

Arquitetura

O lab provisiona, via Terraform, tudo que é necessário para conectar um container no ECS Fargate a um bucket S3 via S3 Files: uma VPC com subnets privadas em duas zonas de disponibilidade, um bucket S3 com versionamento habilitado (pré-requisito do serviço), o file system do S3 Files com um mount target por AZ, as roles IAM para o serviço e para a task, e o próprio cluster ECS com o serviço Fargate configurado para montar o prefixo lab/ do bucket em /mnt.

Na demonstração proposta, o nosso container roda no ECS Fargate e enxerga o prefixo lab/ do bucket como se fosse uma pasta local, montada em /mnt. Conforme mencionado anteriormente, essa é uma prática recomendada, ao invés de montarmos o bucket inteiro. Por baixo dos panos, o Fargate configura um proxy NFS na própria interface de rede da task. Quando o container escreve um arquivo, o S3 Files sincroniza esse dado com o bucket S3 em segundo plano, geralmente em menos de um minuto. Para a aplicação, é só uma escrita em disco como qualquer outra.

Para verificar o funcionamento, usamos uma imagem Docker customizada, baseada no Alpine, com um script de entrada que confirma o mount NFS, exibe o espaço disponível e escreve um arquivo no prefixo montado. Mas vale deixar claro: qualquer imagem funcionaria com o S3 Files. O mount acontece na plataforma Fargate, antes de o container iniciar, independente do que está dentro da imagem. A imagem customizada existe apenas para tornar a validação mais visível com os logs, pois sem ela, precisaríamos conectar manualmente ao container para confirmar que o nosso volume realmente está lá.

Pré-requisitos

• Conta AWS
• Terraform >= 1.8
• AWS CLI configurado
• Docker instalado
• Permissões para criar:
  • VPC
  • ECS
  • IAM
  • S3
  • S3 Files

Passo 1 - Clonar o repositório

Para iniciar o laboratório, clone o repositório do GitHub que contém os arquivos Terraform:

git clone https://github.com/ludsilva/aws-s3files-ecs.git
cd aws-s3files-ecs

Dentro do diretório, você encontrará os arquivos Terraform necessários para provisionar a infraestrutura.

Passo 2 - Provisionar a infraestrutura

Execute os comandos:

terraform init
terraform apply

O Terraform sobe VPC, S3, S3 Files, IAM e o ECS Service. O polling dos mount targets já acontece aqui, o apply só irá terminar quando os volumes estiverem disponíveis.

Passo 3 - Acompanhar os logs

Após os recursos serem provisionados, o ECS Fargate sobe a task e executa o script de entrada. Para acompanhar os logs, você pode acessar a console AWS ou usar o comando:

aws logs tail /ecs/app-s3-files --follow

Saída esperada: [OK] Lab completed.

Passo 4 - Checar a sincronização com o S3 Files Caso queira verificar se o arquivo foi realmente gravado no bucket S3, você pode ir até o console do S3 ou usar o comando:

aws s3 ls s3://my-blog-s3-files-demo/lab/test/

O arquivo result.txt deve aparecer no bucket após ~60s da escrita.

Passo 5 - Teste de persistência dos arquivos

Por fim, vamos validar a persistência dos arquivos gravados no S3 Files. Para isso, vamos parar a task manualmente (ou com o comando aws ecs stop-task) e aguardar o ECS subir uma nova automaticamente.

Após subir a nova task, você pode acompanhar os logs novamente e verá que o script de entrada será executado novamente, gerando um novo arquivo result.txt com timestamp diferente.

No bucket, confirmamos que o arquivo result.txt anterior ainda está lá, e um novo arquivo com timestamp diferente foi criado. Isso demonstra que a persistência dos arquivos gravados no S3 Files independe do ciclo de vida do container.

OBS: Como a nossa imagem customizada gera um arquivo com timestamp, você verá que o conteúdo do arquivo será diferente a cada execução, mas o arquivo em si permanecerá no bucket. Caso queira, você pode testar a persistência com outra imagem Docker e escrever no diretório montado.

Passo 6 - Apagar o ambiente Para não ter surpresas desnecessárias na sua fatura no fim do mês, lembre-se de apagar o ambiente criado. Para isso, execute:

terraform destroy

Custos estimados do laboratório

Apenas a título de curiosidade, a implementação desta arquitetura custou aproximadamente $41.30 dólares por mês, mas como aplicamos somente em poucas horas, o custo real do laboratório foi de apenas alguns centavos.

Abaixo, segue uma estimativa dos custos mensais:

Recurso	Custo aproximado (USD/mês)
Amazon ECS Fargate	~$8.90
Amazon S3	< $0.01
NAT Gateway	~$32.40
Total	~$41.30

Observação: Os valores apresentados são apenas uma estimativa para este laboratório e podem variar conforme a região da AWS, o tempo de execução da aplicação, a quantidade de dados armazenados e o volume de requisições realizadas ao Amazon S3 Files e ao bucket S3.

Observações importantes

Embora o Amazon S3 Files simplifique o acesso aos dados armazenados no Amazon S3 por meio de uma interface de sistema de arquivos, é importante compreender algumas características antes de utilizá-lo:

• O S3 Files não substitui todos os tipos de armazenamento: conforme dito antes, embora ele utilize NFS como interface de acesso, o armazenamento continua sendo o Amazon S3 (por isso ele herda as características de latência do S3). Isso significa que workloads extremamente sensíveis à latência ou que exigem alto volume de IOPS, como bancos de dados, o Amazon EBS ou Amazon EFS ainda continuam sendo opções mais adequadas;
• A sincronização entre NFS e S3 é assíncrona: Isto significa que as alterações realizadas pelo sistema de arquivos e pela API do Amazon S3 não são refletidas instantaneamente entre as duas interfaces. Se uma aplicação exige consistência imediata entre múltiplos consumidores ou acessa simultaneamente os mesmos arquivos pelo sistema de arquivos e pela API do S3, esse comportamento deve ser considerado;
• Evite escrita concorrente: Uma boa prática é definir uma única interface responsável pela escrita dos dados. Quando um mesmo arquivo é modificado simultaneamente pelo sistema de arquivos e pela API do Amazon S3, podem ocorrer conflitos. Nesses casos, a versão armazenada no S3 é preservada e a versão conflitante é movida automaticamente para o diretório S3.lost+found;
• Operações de renomeação podem ser custosas: Ao contrário de sistemas de arquivos tradicionais, o Amazon S3 não possui uma operação nativa de rename. Com isso, renomear ou mover diretórios exige que o serviço copie todos os objetos envolvidos e remova os originais posteriormente. Em grandes volumes de dados, esse comportamento pode aumentar significativamente o tempo de execução e o custo da operação.
• Monte apenas o prefixo necessário: Sempre que possível, monte apenas o prefixo do bucket utilizado pela aplicação, em vez do bucket inteiro. Essa prática reduz a quantidade de metadados carregados durante a montagem, acelera a inicialização da aplicação e diminui o impacto de operações envolvendo diretórios.

Conclusão

O Amazon S3 Files representa uma mudança importante na forma como aplicações podem consumir dados armazenados no Amazon S3. Ao permitir acesso através de uma interface de sistema de arquivos, ele reduz a necessidade de múltiplas camadas de armazenamento e simplifica arquiteturas que anteriormente dependiam de serviços como Amazon EFS apenas para compartilhar arquivos.

Embora não substitua completamente o EFS em todos os cenários, o recurso abre novas possibilidades para workloads em ECS, EKS, EC2, Machine Learning e Inteligência Artificial, especialmente quando o objetivo é reduzir custos e simplificar a gestão de dados e a arquitetura.

Mais do que um novo recurso, o Amazon S3 Files é uma oportunidade para repensar aplicações na AWS. Como toda novidade, porém, sua adoção deve considerar cuidadosamente os requisitos de latência, consistência e padrão de acesso da aplicação. Em outras palavras, o Amazon S3 Files não elimina a necessidade de boas decisões arquiteturais; ele amplia as possibilidades para projetar soluções mais simples, econômicas e aderentes ao comportamento real das aplicações.

Referências

• Documentação: Amazon S3 Files
• Documentação: Working with Amazon S3 Files
• Documentação: Configuring S3 Files for Amazon ECS
• Artigo: Getting Started with Amazon S3 Files: Mounting S3 Buckets as File Systems
• Artigo: AWS S3 Files — 13x Cheaper Than EFS (But Read This First)