Publicado em abril de 2026 | por Rafaela Vidotti
Em 7 de abril de 2026, a AWS lançou o Amazon S3 Files: uma funcionalidade que permite montar buckets S3 diretamente como sistemas de arquivos em instâncias EC2, containers ECS/EKS e funções Lambda, usando o protocolo NFS v4.1 e v4.2. Sem modificar a aplicação. Sem duplicar dados. Sem appliance intermediário.
Quando li o anúncio, a primeira coisa que pensei foi: finalmente. Não porque a ideia seja nova. S3 com acesso tipo arquivo é um problema que a comunidade de cloud tenta resolver há anos de formas diferentes. Mas porque agora é nativo, sem gateway, com semântica POSIX completa e com um modelo de preço que, se você entender direito, muda completamente a conta para workloads de dados e IA. Quero destrinchar o que esse lançamento representa de concreto, o que ele entrega na prática, e onde os gaps ainda existem. Porque eles existem, e ser honesta sobre isso faz parte da análise.
O problema que o S3 Files resolve e por que ele durou tanto tempo
O Amazon S3 é um armazenamento de objetos. Isso significa que, para acessar um dado no S3, você precisa de chamadas de API: GetObject, PutObject, ListObjects. Funciona muito bem para aplicações construídas do zero com o SDK. Mas cria uma fricção real em dois cenários que eu vejo o tempo todo no dia a dia de arquitetura.
O primeiro é o das aplicações legadas: sistemas que só entendem caminhos de arquivo, que assumem que os dados estão em /data/arquivo.csv e não foram escritos para fazer chamadas de API para um storage. Modernizar essas aplicações para consumir S3 diretamente exige reescrita. Com S3 Files, você monta o bucket como um diretório e a aplicação não precisa saber que está falando com o S3.
O segundo, e onde eu vejo o impacto mais imediato, são os pipelines de dados e de IA. Ferramentas como PyTorch, TensorFlow, scripts de pré-processamento e agentes de dados assumem caminhos de arquivo. O fluxo padrão hoje é: dispara o job, copia o dataset do S3 para um volume local, espera às vezes minutos, às vezes horas, e aí começa o trabalho de verdade. No final, copia os artefatos de volta pro S3. É um ciclo ineficiente que custa tempo, custa dinheiro em volume parado e impede paralelismo real.
Antes do S3 Files, a alternativa nativa da AWS para isso era o S3 File Gateway, que faz parte do AWS Storage Gateway. Funciona, mas é um appliance, virtual ou físico, que você precisa gerenciar, com limitações de throughput e uma camada operacional que muitos times não querem absorver. O S3 Files elimina o gateway da equação. É nativo, gerenciado pela AWS, sem infraestrutura adicional para operar.
O que o S3 Files entrega realmente
Acesso NFS nativo sem gateway. Você monta o bucket com o comando de mount padrão, como faria com qualquer volume NFS. Do ponto de vista do sistema operacional, é um diretório comum. Qualquer aplicação, script ou ferramenta que use NFS v4.1 ou v4.2 funciona sem modificação de código.
Cache inteligente com threshold configurável. Na minha análise, essa é a mudança de design mais importante. Existe um limite de tamanho de arquivo configurável, o padrão é 128 KB. Arquivos menores que esse limite são carregados no storage de alta performance quando acessados pela primeira vez, com latência de aproximadamente 1 ms nas leituras seguintes. Arquivos maiores são servidos diretamente do S3 com máximo throughput, sem passar pelo cache. Essa separação é o que torna o modelo de preço inteligente, e chego nisso na próxima seção.
Semântica POSIX completa. Read-after-write consistency, file locking, permissões de arquivo. Não é uma emulação aproximada: é a semântica que aplicações POSIX esperam. Mudanças feitas pelo sistema de arquivos refletem automaticamente no bucket S3. Mudanças feitas no bucket via API são visíveis pelo sistema de arquivos. Bidirecional, com controle fino de sincronização.
Throughput que o EFS não entrega nativamente. A AWS anuncia múltiplos terabytes por segundo de throughput agregado. Para workloads com leitura de datasets grandes em paralelo, exatamente o que acontece em treinamento de modelos, isso é relevante. O EFS provisioned throughput entrega muito menos e a um custo fixo mais alto.
O cenário de IA que muda o cálculo
Vou ser específica, porque “pipeline de IA” é um termo que todo mundo usa e ninguém detalha. Imagine o seguinte: um time de ML mantém um dataset de fine-tuning de 500 GB no S3, a escolha natural para armazenar dados não estruturados em escala. Cada job de treinamento começa copiando esse dataset para um volume EBS local. O bootstrap leva 40 minutos. Durante esse tempo, a instância está ligada e sendo cobrada. O volume EBS está provisionado para o dataset inteiro, mesmo que o job acesse só uma fração dele.
Com S3 Files montado, o script de treinamento aponta para o diretório de mount. Não há etapa de cópia. O framework de treino acessa os arquivos conforme os lê, e o S3 Files serve sob demanda, carregando para cache apenas o que foi acessado. Checkpoints e modelos salvos no diretório já aparecem no S3 automaticamente. O tempo de bootstrap vai a zero, o storage é cobrado só sobre o que o job tocou, e múltiplos pods EKS ou instâncias EC2 podem montar o mesmo bucket ao mesmo tempo, algo que é impossível com EBS.
Esse último ponto, o acesso simultâneo de múltiplos workers, é onde o S3 Files abre uma possibilidade arquitetural que o EBS simplesmente não oferece. Para treinamento distribuído com dados compartilhados, é uma mudança de paradigma.
O modelo de preço que mais importa entender
Esse é o ponto que mais me chamou a atenção no lançamento, e é onde está tanto a maior oportunidade quanto o maior risco de surpresa.
Você paga a tarifa premium apenas sobre o slice de dados que realmente passou pelo cache de alta performance. O storage de cache custa $0,30/GB-mês, o mesmo do EFS Standard, não por acaso, já que o S3 Files é construído sobre o EFS por baixo dos panos. Leituras via cache custam $0,03/GB. Escritas custam $0,06/GB. Leituras de arquivos grandes servidos diretamente do S3 não têm custo adicional de leitura. O restante do bucket permanece no S3 padrão a $0,023/GB-mês.
Na prática: um bucket com 1 PB onde você acessa ativamente apenas 1 TB paga a tarifa de $0,30/GB-mês somente nesse 1 TB. Os 999 TB restantes ficam no S3 padrão. Com EFS, esses 1 PB custariam $307.200/mês independentemente de quantos bytes você realmente tocou esse mês.
A ressalva que preciso fazer com clareza: esse modelo só é vantajoso quando o acesso é seletivo. Se uma aplicação varrer um volume amplo e distribuído de arquivos pequenos, e isso é mais comum do que parece em pipelines de dados, o cache cresce e o custo pode escalar de forma imprevisível. Antes de migrar qualquer workload crítico, implemente tags específicas para S3 Files no AWS Cost Explorer e monitore o custo do cache desde o primeiro dia. Não é opcional.
O que ainda não foi resolvido
Seria desonesto da minha parte apresentar esse lançamento apenas como notícia positiva. Existem gaps reais que a AWS ainda não endereçou com essa versão inicial.
A documentação de limites de concorrência ainda é incompleta. File locking via NFS em ambientes com muitos nós simultâneos escrevendo no mesmo arquivo é historicamente problemático. A AWS não documentou com clareza o comportamento em cenários de alta contenção de escrita. Para workloads com múltiplos workers escrevendo em arquivos compartilhados, logs centralizados, por exemplo, esse comportamento precisa ser testado e validado antes de ir para produção.
A camada de cache é construída sobre EFS, e isso significa que os limites de disponibilidade do EFS se aplicam a ela. O EFS não é Multi-AZ por padrão sem configuração adicional. Se a camada de cache falhar, o comportamento de fallback para o S3 direto precisa ser documentado e testado pela equipe. A AWS ainda não deixou claro o SLA específico para o S3 Files em cenários de falha parcial.
A integração com serviços como AWS Backup e Amazon Macie ainda não está documentada com clareza. Se você tem requisitos de conformidade que envolvem backup gerenciado ou classificação de dados sensíveis, verifique a documentação oficial antes de adotar.
A latência dos dados de monitoramento também não está especificada. Para times que querem visibilidade em tempo quase-real do que está sendo carregado no cache e do custo associado, ainda não há uma resposta clara de com que frequência esses dados são atualizados.
O lançamento foi em abril de 2026. A maturidade da documentação ainda é inicial. Esse é um momento de teste controlado, não de migração em massa.
O que vale fazer agora
Se você trabalha com arquitetura de soluções na AWS, especialmente em contextos de dados e IA, o movimento mais direto é identificar um pipeline que sofra com a etapa de cópia do S3 e usá-lo como piloto. Um ambiente de desenvolvimento ou staging é suficiente para validar latência, custo e comportamento antes de promover para produção. Instrumentalize com Cost Explorer e CloudWatch desde o início — não é possível otimizar o que não se mede.
Se você ainda usa o S3 File Gateway do Storage Gateway, vale avaliar a migração. São produtos diferentes, mas o S3 Files entrega a mesma proposta de acesso NFS ao S3 sem o overhead operacional do gateway. A migração não é automática, mas o caso de negócio de simplificação operacional é forte.
E antes de escalar qualquer workload com S3 Files, entenda o padrão de acesso real da aplicação. Mapear quais arquivos são acessados com que frequência é o que vai definir se o modelo de preço funciona a seu favor ou contra. Workloads com acesso seletivo e concentrado ganham. Workloads que varrem datasets inteiros de forma ampla precisam de um cálculo mais cuidadoso.
Por que esse lançamento é um sinal, não só uma funcionalidade
O gap entre object storage e file system é um dos mais antigos da computação em nuvem. Cada um foi otimizado para um modelo de acesso diferente, e essa divisão criou fricção em toda uma geração de arquiteturas, especialmente em IA e dados, onde os dados vivem no S3 mas as ferramentas assumem filesystem.
O S3 Files não é a primeira tentativa de resolver isso, mas é a primeira tentativa nativa, sem gateway, com semântica POSIX completa e com um modelo de preço que cobra só o que você usa de forma intensiva. Isso importa porque sinaliza que a AWS está levando a sério a convergência entre as duas abstrações, e que a próxima geração de arquiteturas de dados não vai precisar mais escolher entre a escala do S3 e a usabilidade de um filesystem.
A ferramenta tem limitações reais, que detalhei acima. Mas o movimento de tornar um bucket S3 montável como diretório, com throughput agregado de múltiplos TB/s e sem infraestrutura adicional para operar, é o tipo de lançamento que muda o que é possível fazer em arquitetura de dados. Cabe a nós, arquitetos de soluções, testar, medir e usar isso com critério.
Links: