EBS vs EFS para Múltiplas Instâncias EC2: Como Compartilhar Arquivos Entre Servidores

Você acabou de receber a tarefa de compartilhar um diretório entre cinco instâncias EC2 — parece simples, mas a escolha errada entre EBS e EFS pode resultar em dados corrompidos, arquitetura não suportada, ou horas de retrabalho. A dúvida entre EBS vs EFS para múltiplas instâncias é uma das mais comuns em ambientes AWS, e a resposta não é óbvia para quem vem de infraestrutura on-premises.

TL;DR — EBS vs EFS para Múltiplas Instâncias

Critério EBS EFS
Compartilhamento entre instâncias Limitado (Multi-Attach apenas em volumes io1/io2, mesma AZ) Nativo — múltiplas instâncias, múltiplas AZs
Tipo de acesso Block storage File storage (NFS v4.1/v4.2)
Sistema de arquivos compartilhado Não (sem coordenação de cluster) Sim, gerenciado pela AWS
Caso de uso típico Volume dedicado por instância, banco de dados Conteúdo web, home directories, dados compartilhados
Compatibilidade de SO Linux e Windows Linux (NFS)
Escalabilidade Provisionado manualmente Elástico e automático

Como EBS e EFS Funcionam — Antes de Decidir

EBS (Elastic Block Store) é um dispositivo de bloco — funciona como um HD externo conectado à instância via rede. O sistema operacional enxerga o volume como um disco local e formata com o sistema de arquivos que quiser (ext4, xfs, NTFS). O ponto crítico: por padrão, um volume EBS é anexado a uma única instância por vez. Existe o recurso Multi-Attach, mas com restrições sérias que a maioria dos tutoriais ignora.

EFS (Elastic File System) é um serviço de sistema de arquivos gerenciado baseado em NFS. Você monta o mesmo endpoint em quantas instâncias quiser, em múltiplas zonas de disponibilidade, e todas enxergam o mesmo namespace de arquivos simultaneamente. A AWS gerencia capacidade, replicação e disponibilidade.

graph TD subgraph EBS_Padrao["EBS Padrão — Uma Instância"] V1["Volume EBS"] I1["Instância EC2 A"] V1 -- "Anexado" --> I1 I2["Instância EC2 B"] I3["Instância EC2 C"] V1 -. "NÃO suportado
simultaneamente" .-> I2 V1 -. "NÃO suportado
simultaneamente" .-> I3 end subgraph EFS_Compartilhado["EFS — Múltiplas Instâncias"] FS["Sistema de Arquivos EFS"] MT1["Mount Target AZ-1"] MT2["Mount Target AZ-2"] FS --> MT1 FS --> MT2 EC1["Instância EC2 1"] EC2["Instância EC2 2"] EC3["Instância EC2 3"] EC4["Instância EC2 4"] EC5["Instância EC2 5"] MT1 -- "NFS" --> EC1 MT1 -- "NFS" --> EC2 MT1 -- "NFS" --> EC3 MT2 -- "NFS" --> EC4 MT2 -- "NFS" --> EC5 end
  1. EBS padrão: cada volume é conectado a uma única instância. Instâncias diferentes não compartilham o mesmo volume simultaneamente no modo padrão.
  2. EBS Multi-Attach: permite múltiplas instâncias no mesmo volume, mas apenas volumes io1/io2, apenas dentro da mesma Availability Zone, e requer que a aplicação gerencie acesso concorrente — a AWS não fornece semântica de sistema de arquivos compartilhado.
  3. EFS: um único sistema de arquivos montado por todas as instâncias via NFS. Acesso simultâneo é o comportamento padrão e esperado.

EBS Multi-Attach: O Que Ninguém Conta na Documentação

O Multi-Attach existe e é documentado — mas ele não resolve o problema de compartilhar uma pasta entre cinco instâncias da forma que a maioria das pessoas espera. Aqui está o que acontece na prática:

Quando você ativa Multi-Attach em um volume io1 ou io2 e monta em duas instâncias Linux com ext4, você vai ter corrupção de dados. O ext4 não foi projetado para acesso concorrente de múltiplos hosts. Para usar Multi-Attach de forma segura, você precisa de um sistema de arquivos cluster-aware como GFS2 ou OCFS2, que requer configuração adicional de cluster fencing, quorum e lock manager — infraestrutura que a maioria dos times não quer operar.

Pensar no Multi-Attach como 'compartilhamento de pasta' é como conectar o mesmo HD externo em dois computadores ao mesmo tempo sem nenhum software de coordenação — os dois vão escrever no mesmo bloco sem saber um do outro.

Além disso, Multi-Attach tem restrições adicionais: as instâncias precisam estar na mesma Availability Zone que o volume, o volume não pode ser o volume raiz, e há um limite no número de instâncias que podem ser anexadas simultaneamente. Verifique os limites atuais na documentação oficial da AWS, pois podem variar.

EFS para Múltiplas Instâncias EC2: A Solução Correta

Para o cenário de cinco instâncias compartilhando um diretório, EFS é a resposta certa. O processo é direto: você cria um sistema de arquivos EFS, configura mount targets nas subnets desejadas, ajusta o Security Group para permitir NFS (porta 2049), e monta em cada instância.

Passo 1 — Criar o Sistema de Arquivos EFS

Crie o sistema de arquivos e anote o ID retornado. Ele será usado nos próximos passos.

aws efs create-file-system \
  --performance-mode generalPurpose \
  --throughput-mode bursting \
  --encrypted \
  --region us-east-1 \
  --tags Key=Name,Value=shared-fs

O comando retorna um objeto JSON com o FileSystemId (formato fs-XXXXXXXX). Guarde esse valor.

Passo 2 — Criar Mount Targets nas Subnets

Cada Availability Zone onde suas instâncias residem precisa de um mount target. Repita o comando para cada subnet, substituindo os IDs correspondentes. O Security Group informado deve permitir tráfego NFS (TCP 2049) a partir das instâncias EC2.

aws efs create-mount-target \
  --file-system-id fs-0abc12345def67890 \
  --subnet-id subnet-0123456789abcdef0 \
  --security-groups sg-0123456789abcdef0 \
  --region us-east-1

Passo 3 — Configurar o Security Group

O Security Group do mount target precisa aceitar NFS a partir das instâncias EC2. A forma mais controlada é referenciar o Security Group das instâncias como source, em vez de abrir por CIDR.

aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --protocol tcp \
  --port 2049 \
  --source-group sg-0fedcba9876543210 \
  --region us-east-1

Passo 4 — Instalar o Helper de Montagem e Montar nas Instâncias

A AWS disponibiliza o pacote amazon-efs-utils que simplifica a montagem com suporte a TLS e IAM authorization. Execute em cada uma das cinco instâncias:

# Amazon Linux 2 / Amazon Linux 2023
sudo yum install -y amazon-efs-utils

# Ubuntu
sudo apt-get install -y amazon-efs-utils

# Criar ponto de montagem e montar
sudo mkdir -p /mnt/shared
sudo mount -t efs fs-0abc12345def67890:/ /mnt/shared

Para montagem persistente após reboot, adicione ao /etc/fstab de cada instância:

fs-0abc12345def67890:/ /mnt/shared efs defaults,_netdev 0 0

Passo 5 — Verificar Conectividade e Acesso

Após montar, confirme que todas as instâncias enxergam o mesmo sistema de arquivos. Crie um arquivo em uma instância e verifique nas demais — esse teste simples confirma que o compartilhamento está funcionando corretamente.

# Na instância 1
echo 'teste de compartilhamento' | sudo tee /mnt/shared/teste.txt

# Em qualquer outra instância
cat /mnt/shared/teste.txt
graph LR EFS["Sistema de Arquivos EFS
fs-0abc12345def67890"] subgraph AZ1["Availability Zone us-east-1a"] MT1["Mount Target
porta 2049"] EC1["EC2 Instância 1"] EC2["EC2 Instância 2"] EC3["EC2 Instância 3"] end subgraph AZ2["Availability Zone us-east-1b"] MT2["Mount Target
porta 2049"] EC4["EC2 Instância 4"] EC5["EC2 Instância 5"] end EFS --> MT1 EFS --> MT2 MT1 -- "NFS v4.1" --> EC1 MT1 -- "NFS v4.1" --> EC2 MT1 -- "NFS v4.1" --> EC3 MT2 -- "NFS v4.1" --> EC4 MT2 -- "NFS v4.1" --> EC5 SG["Security Group
TCP 2049 permitido"] SG -. "controla acesso" .-> MT1 SG -. "controla acesso" .-> MT2
  1. Todas as cinco instâncias EC2 montam o mesmo sistema de arquivos EFS via NFS.
  2. Cada Availability Zone tem seu próprio mount target — o tráfego NFS permanece dentro da AZ para menor latência.
  3. O EFS gerencia a consistência e disponibilidade dos dados de forma transparente.
  4. O Security Group controla quais instâncias podem se conectar ao mount target na porta 2049.

IAM para Acesso ao EFS — Permissões Mínimas

Se você usar EFS com IAM authorization (recomendado para ambientes com requisitos de controle de acesso mais granulares), a role das instâncias EC2 precisa das permissões abaixo. Para operações básicas de montagem sem IAM authorization, as permissões de rede (Security Group) são suficientes.

🔽 Clique para expandir — Política IAM para EFS 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "elasticfilesystem:ClientMount",
        "elasticfilesystem:ClientWrite",
        "elasticfilesystem:ClientRootAccess"
      ],
      "Resource": "arn:aws:elasticfilesystem:us-east-1:123456789012:file-system/fs-0abc12345def67890"
    }
  ]
}

Diagnóstico: Quando a Montagem EFS Falha

O erro mais comum ao configurar EFS pela primeira vez não é de configuração do sistema de arquivos — é de Security Group. A instância tenta conectar na porta 2049 do mount target e a conexão simplesmente trava, sem mensagem de erro clara no mount.

O sintoma clássico: o comando mount fica pendurado por 1-2 minutos e então retorna Connection timed out. A maioria dos engenheiros vai primeiro verificar se o EFS foi criado corretamente, se o mount target existe, se o ID do sistema de arquivos está correto — tudo certo. O problema está no Security Group do mount target não permitindo tráfego da instância, ou no Security Group da instância não permitindo saída na porta 2049.

Verifique a conectividade antes de gastar tempo em outros diagnósticos:

# Testar conectividade NFS ao mount target (substitua pelo DNS do mount target)
nc -zv fs-0abc12345def67890.efs.us-east-1.amazonaws.com 2049

Se o nc retornar Connection refused ou timeout, o problema é de rede/Security Group — não de configuração EFS. Verifique as regras de inbound do Security Group do mount target e as regras de outbound do Security Group da instância.

# Verificar mount targets e seus estados
aws efs describe-mount-targets \
  --file-system-id fs-0abc12345def67890 \
  --region us-east-1

# Verificar Security Groups associados ao mount target
aws efs describe-mount-target-security-groups \
  --mount-target-id fsmt-0123456789abcdef0 \
  --region us-east-1

Quando EBS Ainda Faz Sentido — Não Descarte sem Avaliar

EFS resolve o compartilhamento de arquivos, mas não é sempre a escolha certa para todos os workloads. EBS oferece latência mais baixa e previsível para operações de I/O intensivo — bancos de dados relacionais, por exemplo, não devem rodar sobre NFS em produção.

Use EBS quando cada instância precisa de seu próprio volume de alta performance e não há necessidade de compartilhamento. Use EFS quando o caso de uso é genuinamente de sistema de arquivos compartilhado: conteúdo web servido por múltiplos servidores, home directories de usuários, artefatos de build acessados por múltiplos workers, ou configurações compartilhadas entre instâncias de um Auto Scaling Group.

EBS vs EFS — Próximos Passos e Recursos

Para o cenário de compartilhar um diretório entre cinco instâncias EC2, EFS é a solução correta e suportada. EBS Multi-Attach não é um substituto para sistema de arquivos compartilhado sem infraestrutura adicional de cluster. Configure o EFS com mount targets em cada AZ relevante, controle o acesso via Security Groups, e use amazon-efs-utils para montagem simplificada com suporte a TLS.

Recursos oficiais para aprofundamento:

Glossário

Termo Definição
EBS (Elastic Block Store) Serviço de armazenamento em bloco da AWS, análogo a um disco rígido virtual conectado a uma instância EC2.
EFS (Elastic File System) Serviço de sistema de arquivos gerenciado baseado em NFS, permitindo acesso simultâneo de múltiplas instâncias.
Mount Target Endpoint de rede criado em uma subnet para permitir que instâncias EC2 montem um sistema de arquivos EFS via NFS.
Multi-Attach Recurso EBS que permite anexar um volume io1/io2 a múltiplas instâncias na mesma AZ, com restrições de sistema de arquivos.
NFS (Network File System) Protocolo de sistema de arquivos distribuído usado pelo EFS para expor o armazenamento às instâncias EC2.

Related Posts

Comentários

Postar um comentário

Postagens mais visitadas deste blog

Variáveis de Ambiente no Lambda: Configuração, Acesso e Criptografia com KMS

Você tem um endpoint de banco de dados que precisa chegar até a função Lambda — hardcodar isso no código é o caminho mais rápido para um vazamento de credencial em um repositório público. Variáveis de ambiente no Lambda resolvem esse problema, e quando combinadas com KMS, você adiciona uma camada de criptografia que vai além do padrão gerenciado pela AWS. TL;DR — Variáveis de Ambiente no Lambda Ponto Detalhe Onde configurar Console, CLI ( --environment ), IaC (CloudFormation/SAM/Terraform) Criptografia padrão AWS gerencia com chave própria (aws/lambda) — transparente, sem custo adicional de KMS Criptografia customizada Você fornece uma CMK do KMS; Lambda criptografa em repouso e você descriptografa em runtime Acesso no código process.env.NOME (Node.js), os.environ['NOME'] (Python) Limite de tamanho 4 KB total para todas as variáveis — verifique a documentação oficial para limites atuais ...
Leia mais

Monitoramento de Memória RAM no EC2: Por que o CloudWatch Agent é Obrigatório

Você abre o console do CloudWatch, navega até as métricas da sua instância EC2 e percebe que CPU, rede e disco de I/O estão lá — mas RAM não aparece em lugar nenhum. Não é um bug, não é permissão faltando: o CloudWatch simplesmente não coleta métricas de memória por padrão, e entender por que isso acontece evita horas de busca no lugar errado. TL;DR — Monitoramento de Memória no EC2 Ponto Detalhe Métricas padrão do EC2 Coletadas pelo hipervisor AWS — CPU, rede, disco de I/O de bloco. Sem acesso ao SO convidado. Memória RAM e disco usado Visíveis apenas de dentro do SO. Exigem o CloudWatch Agent instalado na instância. CloudWatch Agent Processo rodando dentro do SO que publica métricas customizadas no namespace CWAgent . IAM necessário A instância precisa de uma IAM Role com a policy CloudWatchAgentServerPolicy . Custo Métricas customizadas têm custo separado das métricas padrão — verifique a tabela ...
Leia mais

S3 Access Denied: Por que 'Bloquear Acesso Público' impede seu objeto mesmo após torná-lo público

Você fez upload de uma imagem no S3, marcou o objeto como público, copiou a URL e abriu no navegador — e recebeu um 403 Access Denied . A configuração de ACL do objeto está correta, mas o acesso público continua bloqueado. O culpado quase sempre é o Block Public Access no nível do bucket, uma camada de controle que opera acima das ACLs e políticas de objeto e que muita gente ignora até levar o primeiro 403 em produção. TL;DR — S3 Access Denied com objeto público Camada O que controla O que verificar Block Public Access (bucket) Bloqueia ACLs e políticas públicas no bucket inteiro aws s3api get-public-access-block --bucket NOME ACL do objeto Permissão pública no objeto individual aws s3api get-object-acl --bucket NOME --key CHAVE Bucket Policy Permissões baseadas em política no bucket aws s3api get-bucket-policy --bucket NOME Object Ownership Controla se ACLs são respeitadas ou ignoradas aws s3api get-buc...
Leia mais