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:

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) — de forma transparente para a aplicação, sem exigir mudança de caminho ou lógica de acesso.

💡 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.

---

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?".

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.

---

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 "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

1. 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.
2. Planeje como distribuir mount targets em múltiplas AZs para garantir alta disponibilidade de acesso ao EFS.
3. 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.
4. 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.
5. 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).
6. 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

Questão 2

Questão 3

Questão 4

Questão 5

Questão 6

Questão 7

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:

1. Crie um sistema de arquivos EFS no modo de performance General Purpose e throughput Bursting (ou Elastic).
2. 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.
3. 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).
4. Na primeira instância, crie um arquivo de teste dentro do diretório montado.
5. 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.
6. 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