Amazon EFS (Elastic File System) é um sistema de arquivos NFS totalmente gerenciado, que pode ser montado simultaneamente por milhares de instâncias EC2 (e também por containers e funções Lambda), crescendo e encolhendo automaticamente conforme os dados são adicionados ou removidos.

🎯 Para a certificação

Questões sobre EFS testam se você sabe quando compartilhamento de arquivos entre múltiplas instâncias exige EFS (e não EBS), entende a diferença entre modos de performance e de throughput, sabe como mount targets garantem disponibilidade por AZ, e consegue posicionar EFS corretamente entre EBS (bloco) e S3 (objetos) num cenário de arquitetura.

Resumo

Pense no EFS como uma pasta de rede compartilhada — do tipo que várias pessoas num escritório acessam ao mesmo tempo pelo mesmo caminho de rede, cada uma lendo e escrevendo arquivos sem que isso exija coordenação manual entre elas. Diferente de um HD externo (EBS), que só pode estar plugado numa máquina de cada vez, essa pasta de rede pode ser acessada por dezenas, centenas ou milhares de "computadores" (instâncias EC2) simultaneamente — e ela cresce sozinha conforme você guarda mais arquivos, sem você precisar "comprar mais espaço" antecipadamente.

O que é: sistema de arquivos gerenciado, acessado via protocolo NFS, com semântica POSIX (permissões, hierarquia de pastas, links — como um sistema de arquivos Linux tradicional).
Elástico: cresce e encolhe automaticamente com o uso — você não provisiona um tamanho fixo como faz no EBS.
Multi-AZ por natureza: um único sistema de arquivos EFS é acessível a partir de múltiplas Availability Zones dentro da região, via mount targets.
Não substitui EBS (para latência baixíssima e IOPS de bloco) nem S3 (para armazenamento de objetos em larga escala e baixo custo).

1. Como o compartilhamento funciona, por dentro

A diferença mais importante entre EFS e EBS não é "performance" — é arquitetura de acesso. Um volume EBS é um disco de bloco, fisicamente ligado (via rede interna da AWS) a uma única instância por vez, e o sistema operacional dessa instância é o único "dono" responsável por gerenciar o sistema de arquivos sobre ele. Já o EFS é o sistema de arquivos — ele vive fora de qualquer instância individual, como um serviço de rede, e cada instância que o monta está simplesmente acessando esse mesmo sistema de arquivos remotamente via protocolo NFSv4, exatamente como você montaria uma pasta compartilhada de um servidor de arquivos corporativo.

Essa arquitetura é o que permite múltiplas instâncias lerem e escreverem no mesmo conjunto de arquivos ao mesmo tempo, com coordenação de concorrência (locks, permissões POSIX) já resolvida pelo próprio serviço — algo que o EBS não oferece nativamente, porque não foi desenhado para isso.

1.1 Mount targets — o ponto de entrada por AZ

Para que instâncias numa determinada AZ acessem o EFS com baixa latência, é necessário criar um mount target nessa AZ — essencialmente um endpoint de rede (com seu próprio IP dentro de uma subnet) através do qual o tráfego NFS daquela AZ entra no sistema de arquivos.

💡 Para a prova: uma arquitetura de alta disponibilidade com EFS precisa de um mount target em cada AZ onde existem instâncias que vão montá-lo. Esquecer de criar o mount target numa AZ é o erro mais comum cobrado em cenários "instância não consegue montar o EFS".

2. Modos de performance

Definido na criação do sistema de arquivos e não pode ser alterado depois — essa é uma pegadinha clássica de prova.

General Purpose: modo padrão, latência mais baixa por operação. Adequado para a grande maioria dos casos de uso (web serving, home directories, CMS, ferramentas de desenvolvimento).
Max I/O: escala para um número maior de operações paralelas simultâneas (milhares de clientes/instâncias acessando ao mesmo tempo), mas com latência por operação individual maior que o General Purpose.

💡 Para a prova: a troca é throughput agregado e paralelismo massivo (Max I/O) contra latência mínima por operação (General Purpose). Se o cenário descreve "milhares de instâncias EC2 acessando simultaneamente, com foco em processamento distribuído em larga escala" pense Max I/O; se descreve "aplicação web comum, latência importa mais que paralelismo extremo", General Purpose é a resposta padrão — e é o que a maioria dos cenários da prova espera, salvo indicação explícita de escala massiva.

3. Modos de throughput

Diferente do modo de performance, o modo de throughput pode ser alterado depois de criado o sistema de arquivos.

Bursting Throughput: o throughput disponível escala proporcionalmente ao tamanho armazenado no sistema de arquivos (quanto mais dados guardados, mais throughput baseline disponível), com capacidade de estourar (burst) acima do baseline por períodos, usando um sistema de créditos acumulados — parecido em espírito com o burst de instâncias t3 ou volumes gp2.
Provisioned Throughput: você define um throughput fixo, independente do tamanho de dados armazenado — essencial quando o sistema de arquivos tem pouco dado armazenado, mas precisa de throughput alto (o cenário clássico onde Bursting seria insuficiente, porque o throughput baseline dele depende do volume de dados).
Elastic Throughput: o modo mais recente — a AWS ajusta o throughput automaticamente conforme a demanda real da carga de trabalho, sem necessidade de provisionar nem monitorar créditos de burst manualmente; geralmente a opção mais simples para cargas de trabalho com padrões de tráfego imprevisíveis ou variáveis.

💡 Para a prova: se o cenário descreve "sistema de arquivos pequeno em tamanho, mas que precisa de throughput consistentemente alto", a resposta é Provisioned Throughput — porque no modo Bursting, pouco dado armazenado significa pouco throughput baseline disponível, mesmo que a demanda real seja alta.

4. Classes de armazenamento e Lifecycle Management

Assim como o S3, o EFS tem classes de armazenamento com custo decrescente para dados menos acessados:

Classe	Uso
Standard	Acesso frequente, menor latência
Standard-Infrequent Access (Standard-IA)	Dados acessados algumas vezes por trimestre, custo menor de armazenamento
Archive	Dados acessados algumas vezes por ano ou menos — a classe mais barata, até 50% mais econômica que a IA
One Zone	Igual ao Standard, mas numa única AZ (menor custo, menor resiliência)
One Zone-IA	Combinação de single-AZ com acesso infrequente

O recurso EFS Lifecycle Management move automaticamente arquivos entre classes com base em um período configurável de não-acesso (ex: mover para IA após 30 dias sem acesso, e para Archive após 90 dias sem acesso) — de forma transparente para a aplicação, sem exigir mudança de caminho ou lógica de acesso. O EFS Intelligent-Tiering completa esse ciclo: ele monitora o padrão de acesso e move automaticamente arquivos de volta para Standard (ou One Zone) caso um arquivo em IA ou Archive volte a ser acessado — sem exigir que você defina manualmente quando isso deve acontecer.

💡 Para a prova: as classes One Zone trocam resiliência (ficam restritas a uma única AZ, perdendo a redundância multi-AZ padrão do EFS) por um custo menor — adequadas para dados recriáveis ou não-críticos, como ambientes de desenvolvimento/teste.

💡 Para a prova: Archive só é suportada em sistemas de arquivos Regionais usando o modo de throughput Elastic — não está disponível em sistemas One Zone, nem em sistemas configurados com Bursting ou Provisioned Throughput. Se um cenário descreve um sistema de arquivos com Provisioned Throughput e pede a classe mais barata possível, a resposta correta para de ser Archive e passa a ser Standard-IA — a única forma de usar Archive é migrar (ou já configurar) o sistema de arquivos com throughput Elastic.

5. Segurança e controle de acesso

EFS tem duas camadas independentes de controle de acesso, um ponto que a prova gosta de testar:

Segurança de rede: controlada por security groups associados aos mount targets — define quais instâncias/subnets podem sequer alcançar o EFS na camada de rede (tráfego NFS na porta 2049).
Segurança de dados: controlada por permissões POSIX tradicionais (usuário/grupo/dono, como num Linux comum) e, opcionalmente, por políticas baseadas em IAM para controle mais granular de quem pode montar o sistema de arquivos e realizar operações específicas via EFS Access Points.

EFS Access Points são pontos de entrada com uma identidade POSIX (usuário/grupo) e um diretório-raiz específicos já predefinidos — úteis para dar a diferentes aplicações (ou containers) acesso apenas a uma "fatia" isolada do sistema de arquivos, sem precisar gerenciar permissões manualmente em cada uma.

Criptografia: EFS suporta criptografia em repouso (via KMS) e em trânsito (TLS na conexão NFS), ambas configuráveis de forma transparente para a aplicação.

6. EFS vs EBS vs S3 — comparação e critério de decisão

Uma forma simples de decidir: pergunte "quantas instâncias precisam ler/escrever ao mesmo tempo?" e "eu preciso de estrutura de pastas/arquivos (POSIX) ou só preciso guardar e buscar objetos por chave?".

Critério	EFS	EBS	S3
Tipo	Arquivos (NFS)	Bloco	Objetos
Acesso simultâneo multi-instância	Sim, nativo	Não (padrão) / até 16 com Multi-Attach (io1/io2)	Sim, via API, não é "montagem" de sistema de arquivos
Semântica POSIX (pastas, permissões Unix)	Sim	Sim (via SO)	Não
Escopo	Multi-AZ (regional)	Uma única AZ	Regional
Latência típica	Maior que EBS	Menor	Não comparável (é acesso via API HTTP, não filesystem)
Provisionamento de tamanho	Elástico, automático	Fixo, você define e redimensiona manualmente	Ilimitado, sem provisionamento
Caso de uso típico	Compartilhamento entre instâncias, home directories, CMS	Boot volumes, bancos de dados locais	Backup, data lake, hospedagem estática, distribuição via CDN

Exemplo prático: um cluster de 10 servidores web que precisa compartilhar a mesma pasta de uploads de usuários não pode usar EBS (só uma instância por vez o monta com leitura/escrita, salvo Multi-Attach em io1/io2 — que ainda exige um sistema de arquivos cluster-aware). EFS resolve porque todas as 10 instâncias montam o mesmo sistema de arquivos simultaneamente, como uma pasta de rede compartilhada — sem exigir nenhuma coordenação extra da aplicação.

💡 Para a prova: se o enunciado menciona "conteúdo estático distribuído globalmente via CDN", a resposta raramente é EFS — é S3 + CloudFront. EFS resolve compartilhamento entre instâncias dentro da AWS, não distribuição de conteúdo para usuários finais na internet.

💡 Para a prova: EFS fala NFS, é voltado para workloads Linux/POSIX. Se o enunciado menciona compartilhamento de arquivos via SMB, Windows Server ou integração com Active Directory, a resposta não é EFS — é Amazon FSx for Windows File Server, um serviço de arquivos gerenciado separado, desenhado especificamente para esse protocolo e esse ecossistema. É uma pegadinha clássica: "sistema de arquivos compartilhado" sozinho não define a resposta — o protocolo/SO do cenário é o que decide entre EFS e FSx.

7. Casos de uso típicos

Compartilhamento de diretórios entre múltiplas instâncias EC2 (ex: pasta de uploads de usuários, assets compartilhados entre servidores web).
Home directories de usuários em ambientes corporativos migrados para a AWS.
Diretórios de build compartilhados entre instâncias/containers num pipeline de CI/CD.
Workloads de containers (ECS/EKS) que precisam de armazenamento persistente e compartilhado entre tasks/pods em diferentes AZs.
Repositórios de conteúdo para CMS (sistemas de gerenciamento de conteúdo) rodando em múltiplas instâncias atrás de um load balancer.

8. Boas práticas

Crie um mount target em cada AZ onde há instâncias que precisam montar o EFS, garantindo baixa latência e resiliência.
Use General Purpose como modo de performance padrão, e só migre para Max I/O quando o cenário realmente exigir paralelismo massivo (milhares de conexões simultâneas) — lembrando que essa escolha não pode ser alterada depois de criado o sistema de arquivos.
Use Provisioned Throughput quando o volume de dados armazenado for pequeno mas a demanda de throughput for consistentemente alta; caso contrário, Elastic Throughput costuma ser a opção mais simples e com menos necessidade de ajuste manual.
Configure Lifecycle Management para mover automaticamente arquivos pouco acessados para classes IA, reduzindo custo sem intervenção manual.
Separe permissões de rede (security groups) de permissões de dados (POSIX/IAM) — ambas precisam estar corretas para o acesso funcionar.
Use EFS Access Points para isolar o acesso de diferentes aplicações/containers a subconjuntos específicos do sistema de arquivos.
Evite EFS para cargas sensíveis a latência mínima de bloco (ex: banco de dados transacional local) — nesse caso, EBS continua sendo a escolha correta.

9. Como cai na certificação

Cenário "várias instâncias em diferentes AZs precisam ler/escrever o mesmo conjunto de arquivos" → EFS, com mount target em cada AZ envolvida.
Cenário "instância não consegue montar o sistema de arquivos numa AZ específica" → verificar se existe mount target criado nessa AZ (e se o security group permite a porta NFS 2049).
Cenário "milhares de clientes acessando em paralelo, priorizando throughput agregado sobre latência individual" → modo de performance Max I/O.
Cenário "aplicação web comum, sem escala massiva de paralelismo" → modo de performance General Purpose (padrão recomendado).
Cenário "sistema de arquivos pequeno em tamanho, mas throughput alto necessário" → Provisioned Throughput (Bursting seria insuficiente, pois depende do tamanho armazenado).
Cenário "reduzir custo de arquivos raramente acessados sem mudar a aplicação" → Lifecycle Management movendo para classes IA.
Cenário "dados acessados poucas vezes por ano, minimizar custo ao máximo, sem processo de recuperação manual" → EFS Archive (não confundir com S3 Glacier, que exige recuperação assíncrona).
Cenário "sistema de arquivos com Provisioned ou Bursting Throughput precisa da classe mais barata possível" → lembrar que Archive exige o modo de throughput Elastic; sem essa migração, o piso de custo é o Standard-IA.
Cenário "compartilhamento de arquivos via SMB ou integração com Active Directory" → FSx for Windows File Server, não EFS (EFS é NFS/Linux).
Cenário "conteúdo estático distribuído globalmente para usuários finais via CDN" → S3 + CloudFront, não EFS.
Cenário "banco de dados local, baixa latência de bloco, uma única instância" → EBS, não EFS.

10. Exercícios práticos

Compare e justifique o uso de EFS vs EBS para um cluster de aplicações web que compartilha a mesma pasta de uploads de usuários.
Planeje como distribuir mount targets em múltiplas AZs para garantir alta disponibilidade de acesso ao EFS.
Explique o impacto de escolher Max I/O vs General Purpose, e por que essa escolha precisa ser feita na criação do sistema de arquivos.
Um sistema de arquivos armazena poucos dados, mas precisa de throughput alto e constante. Explique por que o modo Bursting Throughput seria insuficiente e qual configuração resolve.
Discuta quando preferir S3 em vez de EFS para arquivos compartilhados, considerando o público-alvo do acesso (instâncias internas vs usuários finais na internet).
Explique as duas camadas independentes de segurança do EFS (rede e dados) e o que aconteceria se apenas uma delas estivesse configurada corretamente.

11. Questões de Revisão

Questão 1

Um site é servido por várias instâncias EC2 distribuídas em diferentes Availability Zones, todas precisando ler e escrever no mesmo diretório de arquivos compartilhados. Qual solução é mais direta?

Questão 2

Uma aplicação precisa suportar milhares de conexões simultâneas realizando operações de I/O em paralelo, priorizando throughput agregado sobre a latência de cada operação individual. Qual modo de performance é indicado?

Questão 3

Qual afirmação descreve corretamente uma limitação ou característica do EFS em comparação ao EBS?

Questão 4

Uma aplicação precisa distribuir arquivos estáticos (imagens, vídeos) para usuários finais espalhados globalmente pela internet, com baixa latência de entrega. Qual combinação de serviços é mais adequada?

Questão 5

Ao projetar alta disponibilidade de acesso a um sistema de arquivos EFS a partir de instâncias em três Availability Zones diferentes, o que precisa ser configurado?

Questão 6

Um sistema de arquivos EFS armazena atualmente poucos dados (poucos GB), mas a aplicação precisa de throughput alto e constante desde o primeiro dia. Qual configuração resolve esse cenário?

Questão 7

Qual afirmação descreve corretamente as camadas de segurança do Amazon EFS?

Questão 8

Uma equipe cria um sistema de arquivos EFS no modo de performance General Purpose. Alguns meses depois, o volume de tráfego cresce muito e a equipe passa a considerar migrar para Max I/O. O que é preciso saber sobre essa mudança?

Questão 9

Diferente do modo de performance, qual característica do EFS pode ser alterada a qualquer momento após a criação do sistema de arquivos, sem necessidade de recriar nada?

Questão 10

Uma empresa tem dados no EFS que são acessados apenas algumas vezes por ano — muito além do padrão de "acesso infrequente" comum. O objetivo é minimizar ao máximo o custo de armazenamento, mantendo os dados sempre acessíveis quando necessário (sem processo manual de recuperação). Qual classe de armazenamento do EFS é mais adequada?

Questão 11

Um sistema de arquivos EFS está configurado com Provisioned Throughput, pois a aplicação precisa de throughput garantido mesmo com pouco dado armazenado. A equipe quer configurar Lifecycle Management para mover os arquivos mais antigos para a classe Archive. O que é importante verificar antes disso?

Questão 12

Uma equipe configura o EFS Lifecycle Management com a política padrão recomendada pela AWS, combinada com EFS Intelligent-Tiering. Um arquivo que havia sido movido para a classe IA por falta de acesso volta a ser acessado com frequência pela aplicação. O que acontece com esse arquivo?

Questão 13

Uma aplicação Lambda precisa acessar um conjunto compartilhado de modelos de machine learning grandes demais para caber no limite do pacote de deployment da função. Qual arquitetura resolve esse requisito?

Questão 14

Uma empresa migra uma aplicação Windows que depende de compartilhamento de arquivos via protocolo SMB e integração com Active Directory para a AWS. Qual serviço de armazenamento de arquivos gerenciado é o mais adequado para esse cenário?

Questão 15

Um cluster de containers rodando em Amazon ECS, com tasks distribuídas em múltiplas Availability Zones, precisa de um armazenamento persistente e compartilhado entre as tasks, sobrevivendo a reinícios e realocações de containers entre AZs. Qual solução atende esse requisito?

Questão 16

Uma equipe de segurança configurou permissões POSIX corretamente num diretório do EFS, garantindo que apenas um grupo específico de usuários possa escrever nele. No entanto, as instâncias que precisam desse acesso não conseguem sequer montar o sistema de arquivos. Qual é a causa mais provável?

Questão 17

Um arquiteto está decidindo entre EFS e um volume EBS com Multi-Attach (io1/io2) para permitir que várias instâncias EC2 leiam e escrevam no mesmo conjunto de dados simultaneamente. Qual afirmação compara corretamente as duas opções?

Questão 18

Uma aplicação armazena dados sensíveis num sistema de arquivos EFS e precisa garantir que os dados estejam protegidos tanto quando armazenados quanto durante a transmissão entre a instância e o serviço. Qual combinação de recursos do EFS atende esse requisito?

Questão 19

Uma aplicação de CMS (sistema de gerenciamento de conteúdo) roda em múltiplas instâncias EC2 atrás de um load balancer, todas precisando acessar o mesmo repositório de mídia enviado pelos usuários. Diferentes áreas da aplicação (upload de imagens, geração de thumbnails, área administrativa) devem ter acesso restrito apenas à própria "fatia" do sistema de arquivos, sem gerenciar permissões POSIX manualmente em cada aplicação. Qual recurso do EFS resolve esse isolamento de acesso por aplicação?

Questão 20

Uma equipe de arquitetura está decidindo o armazenamento para um novo workload e considera três opções: um banco de dados transacional local de alta performance, um data lake para análise em larga escala, e um diretório de configuração compartilhado entre 20 instâncias EC2 em 3 AZs. Qual combinação de serviços atende cada necessidade corretamente?

Questão 21

Um sistema de arquivos EFS foi criado sem nenhuma configuração explícita de Lifecycle Management. Passados vários meses, arquivos antigos, raramente acessados, continuam na classe Standard. Por que isso aconteceu, e como corrigir?

Questão 22

Uma aplicação crítica armazena dados no EFS usando a classe One Zone-IA para reduzir custo. Durante um incidente que afeta inteiramente a Availability Zone onde os dados estão armazenados, a aplicação perde acesso aos dados. Qual afirmação explica corretamente esse risco?

Laboratório Prático

Objetivo: criar um sistema de arquivos EFS, montá-lo em instâncias de duas AZs diferentes, e observar o compartilhamento de arquivos em tempo real entre elas.

Pré-requisitos: conta AWS com permissão para EFS e EC2; duas instâncias EC2 já em execução, em AZs diferentes da mesma região.

Tempo estimado: 30 minutos

Possíveis custos: baixo, dentro do free tier para pouco armazenamento e curto período de uso.

Passos:

Crie um sistema de arquivos EFS no modo de performance General Purpose e throughput Bursting (ou Elastic).
Crie mount targets em cada uma das AZs onde as duas instâncias de teste estão localizadas, associando um security group que permita tráfego NFS (porta 2049) a partir dessas instâncias.
Em cada instância, instale o cliente NFS (ex: amazon-efs-utils no Amazon Linux) e monte o EFS no mesmo caminho local (ex: /mnt/efs).
Na primeira instância, crie um arquivo de teste dentro do diretório montado.
Na segunda instância (em outra AZ), liste o mesmo diretório e confirme que o arquivo criado na primeira instância aparece imediatamente — comprovando o compartilhamento em tempo real entre AZs.
Configure uma política de Lifecycle Management para mover arquivos sem acesso após um período curto (ex: 7 dias) para a classe Standard-IA, e observe a mudança de classe de armazenamento reportada para o arquivo de teste após o período (ou revise a configuração no console, já que aguardar o período completo pode não ser prático no laboratório).

Resultado esperado: você confirma na prática que múltiplas instâncias em AZs diferentes acessam o mesmo conteúdo simultaneamente através do EFS, algo que não seria possível com um volume EBS padrão.

Limpeza dos recursos: desmonte o EFS nas instâncias, delete os mount targets, e delete o sistema de arquivos EFS criado no laboratório.

Referências:

Amazon EFS User Guide: https://docs.aws.amazon.com/efs/latest/ug/what-is-efs.html
Modos de performance do EFS: https://docs.aws.amazon.com/efs/latest/ug/performance.html
Modos de throughput do EFS: https://docs.aws.amazon.com/efs/latest/ug/performance.html#throughput-modes
Classes de armazenamento e Lifecycle Management: https://docs.aws.amazon.com/efs/latest/ug/storage-classes.html
Segurança no Amazon EFS: https://docs.aws.amazon.com/efs/latest/ug/security-considerations.html
EFS Access Points: https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html