Armazenamento na AWS: Instance Store, EBS, EFS e S3

Este artigo assume que você já entende como HDD e SSD funcionam a nível de hardware: grãos magnéticos, células NAND, setores e blocos. Se ainda não leu sobre isso, recomendo começar por Como o Armazenamento Funciona em Nível de Hardware antes de continuar.

A abstração da AWS: do hardware para serviços

Os datacenters da AWS são cheios de HDDs e SSDs físicos, os mesmos componentes que você estudou. O que a AWS faz é pegar esse hardware e expor em camadas de abstração diferentes, cada uma com um trade-off claro entre performance, flexibilidade e custo.

A regra geral é simples: quanto mais próximo do hardware, mais rápido e mais barato, mas menos flexível. Quanto mais abstrato, mais lento e mais caro por GB, mas mais escala e menos gerenciamento.

Instance Store  →  hardware físico local, zero rede
EBS             →  SSD via rede interna NVMe
EFS             →  sistema de arquivos distribuído multi-AZ
S3              →  object storage global via HTTP

Vamos entender cada um em profundidade.

Instance Store

O que é fisicamente

O Instance Store é o SSD que está literalmente encaixado no servidor físico onde sua EC2 roda. Não existe rede entre a instância e o disco. É o mesmo hardware, na mesma placa.

Quando você sobe uma EC2, ela roda em algum servidor físico dentro do datacenter da AWS. O Instance Store é o disco desse servidor, exposto diretamente para a sua instância via protocolo NVMe local.

Servidor físico da AWS
├── CPU e RAM          → sua EC2 roda aqui
└── SSD NVMe local     → Instance Store (zero rede)

Quem pode acessar

Somente a instância que está rodando naquele servidor físico específico. Não é possível compartilhar com outras instâncias, nem anexar em outra instância depois.

Além disso, nem todo tipo de instância tem Instance Store. Tipos como i4i, r5d e c5d, onde o d no nome indica "disk", vêm com Instance Store incluso. Instâncias sem o d não têm, e você precisa de EBS se quiser disco.

Latência e performance

Por não ter rede no caminho, o Instance Store é o mais rápido de todos os serviços de storage da AWS. Latência abaixo de 0,1 ms e IOPS que podem chegar a milhões dependendo do tipo de instância.

O problema: efêmero

Se a instância for parada, terminada ou o hardware físico falhar, os dados somem. Sem recuperação possível. O disco vai junto com a máquina.

Quando usar

Exclusivamente para dados que você pode perder sem problema:

Cache temporário de processamento
Buffers e arquivos intermediários de pipelines de dados
Scratch space para computação de alto desempenho

Nunca para banco de dados, sessões de usuário ou qualquer dado que precisa persistir.

EBS — Elastic Block Store

O que é fisicamente

O EBS é block storage via rede interna. Os SSDs físicos ficam em servidores dedicados de storage dentro do mesmo datacenter, e sua instância acessa esses blocos via protocolo NVMe sobre a rede interna da AWS, usando o Nitro System com SR-IOV para eliminar overhead de virtualização.

Do ponto de vista do sistema operacional, o EBS aparece como um dispositivo NVMe local (/dev/nvme0n1, /dev/nvme1n1). O SO não sabe que há rede no meio: ele vê um bloco de storage como qualquer outro.

Servidor da sua EC2
└── Nitro System (SR-IOV)
      └── rede interna NVMe
            └── Servidor de storage
                  └── SSDs físicos replicados 3×

Por baixo, a AWS fragmenta e replica seus dados em múltiplos SSDs físicos automaticamente. Você pede um volume de 100 GB, e esses 100 GB podem estar distribuídos em dezenas de SSDs, com replicação transparente.

Como o EBS entrega blocos brutos sem sistema de arquivos, você precisa formatar o volume antes de usar. Na prática:

mkfs.ext4 /dev/nvme1n1   # cria o sistema de arquivos
mount /dev/nvme1n1 /data  # monta o volume

Quem pode acessar

Por padrão, um volume EBS é anexado a uma única instância EC2, dentro da mesma AZ. Um volume criado em us-east-1a só pode ser anexado em instâncias dentro de us-east-1a.

Existe o EBS Multi-Attach para volumes io2, que permite anexar o mesmo volume em até 16 instâncias simultaneamente, mas exige que a aplicação gerencie o acesso concorrente, o que é raro na prática.

Latência e performance

Tipo	Latência	IOPS máx.
gp3 (uso geral)	1–2 ms	16.000
io2 Block Express	< 0,5 ms	256.000

Custo

A partir de $0,08/GB/mês para gp3. Valores atualizados em aws.amazon.com/ebs/pricing.

Os preços podem mudar. Sempre consulte a página oficial de pricing da AWS antes de tomar decisões de arquitetura baseadas em custo.

Quando usar

Volume de boot de qualquer instância EC2 (já vem anexado por padrão)
Banco de dados relacional (PostgreSQL, MySQL, Oracle)
Redis com persistência habilitada
Elasticsearch e outros índices em disco
Qualquer workload que precisa de baixa latência e persistência em uma única instância

EFS — Elastic File System

O que é fisicamente

O EFS é um sistema de arquivos NFS distribuído e gerenciado pela AWS. Ao contrário do EBS, que entrega blocos brutos, o EFS já entrega um sistema de arquivos completo, com diretórios, permissões, file locking e consistência forte.

Internamente, a AWS mantém os dados replicados em pelo menos três zonas de disponibilidade simultaneamente. Para garantir essa replicação e a semântica de sistema de arquivos distribuído, cada escrita precisa ser confirmada em múltiplas AZs antes de retornar sucesso, o que explica a latência um pouco maior em comparação com EBS.

O acesso acontece via protocolo NFS, através de um mount target, uma interface de rede criada dentro da sua VPC em cada AZ que você quiser usar.

EC2 (us-east-1a)  ──┐
EC2 (us-east-1b)  ──┼──  Mount targets  ──  EFS (multi-AZ)
EC2 (us-east-1c)  ──┘

Quem pode acessar

Qualquer instância EC2 dentro da mesma VPC, em qualquer AZ da região, simultaneamente. Milhares de instâncias podem montar o mesmo EFS ao mesmo tempo, todas enxergando os mesmos arquivos em tempo real.

Essa é a diferença fundamental em relação ao EBS: o EFS existe no nível da região, não da AZ.

Latência e performance

Operação	Latência
Leitura (dados frequentes)	~0,25–1 ms
Escrita (EFS One Zone)	~1,6 ms
Escrita (EFS Standard, multi-AZ)	~2,7 ms

A diferença entre One Zone e Standard na escrita existe porque o Standard precisa confirmar a escrita em múltiplas AZs antes de responder.

Custo

A partir de $0,30/GB/mês para EFS Standard. Valores atualizados em aws.amazon.com/efs/pricing.

Os preços podem mudar. Sempre consulte a página oficial de pricing da AWS antes de tomar decisões de arquitetura baseadas em custo.

O EFS é o mais caro dos quatro porque resolve um problema genuinamente complexo: semântica de sistema de arquivos com compartilhamento em tempo real entre múltiplas instâncias em múltiplas AZs.

Quando usar

WordPress ou qualquer CMS rodando em múltiplos servidores (uploads precisam estar disponíveis em todos)
Aplicações web horizontalmente escaladas que leem e escrevem arquivos em disco
Kubernetes ou ECS com pods em múltiplos nodes que precisam de um volume compartilhado
Pipelines de CI/CD com múltiplos agentes compartilhando artefatos
Treino de modelos de ML com múltiplos workers lendo o mesmo dataset

S3 — Simple Storage Service

O que é fisicamente

O S3 é object storage distribuído globalmente. Internamente, a AWS separa completamente metadados de dados: o metadata store guarda o nome do objeto, bucket e um UUID que aponta para a localização dos bytes reais. O data store guarda os bytes brutos, identificados apenas pelo UUID.

Para tolerância a falhas, os objetos são divididos em shards usando erasure coding, similar ao RAID 5 para sistemas distribuídos. Para reconstruir um objeto, qualquer N dos (N+K) shards são suficientes, o que permite perder alguns nodes sem perda de dados.

Por baixo, a AWS usa HDDs densos e baratos para a maioria dos dados no S3 Standard, o que explica o custo muito menor comparado ao EBS e EFS, que usam SSDs.

sua aplicação
      ↓ HTTP PUT/GET
   S3 API
      ├── metadata store (key → UUID → localização)
      └── data store (HDDs distribuídos com erasure coding)

Quem pode acessar

Qualquer coisa com uma URL e as permissões certas: outras instâncias EC2, Lambda, usuários finais, CDNs, outros serviços AWS, outras contas AWS, o mundo inteiro se você quiser. O acesso é via HTTP, não via montagem de disco.

Isso significa que o S3 não é um sistema de arquivos. Você não abre um arquivo, edita uma linha e salva. Você faz PUT do objeto inteiro para escrever e GET para ler. Objetos são imutáveis, e para modificar, você substitui o objeto completo.

Latência e performance

Classe	Latência	Caso de uso
S3 Express One Zone	5–10 ms	Cache de datasets, acesso frequente
S3 Standard	50–150 ms	Uso geral
S3 Standard-IA	50–150 ms	Acesso infrequente
S3 Glacier	minutos a horas	Arquivo de longo prazo

Custo

A partir de $0,023/GB/mês para S3 Standard. Valores atualizados em aws.amazon.com/s3/pricing.

Os preços podem mudar. Sempre consulte a página oficial de pricing da AWS antes de tomar decisões de arquitetura baseadas em custo.

Quando usar

Imagens, vídeos e arquivos de mídia servidos via CDN para usuários finais
Data lake para análise com Athena, Glue ou Redshift
Backups e snapshots de longo prazo
Sites estáticos e Single Page Applications
Artefatos de deploy e pacotes de software
Logs para análise

Como eles funcionam juntos

Na prática, os quatro serviços coexistem em uma arquitetura típica, cada um no papel que foi feito para resolver.

Imagine uma plataforma de e-commerce com processamento de pedidos:

Usuário final
      │
      ▼
CloudFront + S3          ← imagens de produtos, assets estáticos
      │
      ▼
Load Balancer
      │
   ┌──┴──┐
   │     │
  EC2   EC2             ← instâncias da aplicação
   │     │
   └──┬──┘
      │
      ├── EFS /uploads   ← comprovantes, arquivos enviados pelos usuários
      │
      ├── EBS (RDS)      ← banco de dados PostgreSQL
      │
      ├── EBS (Redis)    ← cache de sessões e carrinho
      │
      └── S3 backups     ← snapshots noturnos do banco

O Instance Store apareceria se houvesse processamento pesado de imagens. Os frames intermediários ficam no disco local do worker enquanto o processamento acontece, e o resultado final vai para o S3.
O EBS sustenta banco de dados e Redis, onde performance e persistência são inegociáveis.
O EFS resolve o problema dos arquivos enviados pelos usuários que precisam estar acessíveis em qualquer instância da aplicação.
O S3 serve os assets estáticos para o mundo via CDN e guarda os backups com custo mínimo.

Comparativo rápido

	Instance Store	EBS	EFS	S3
Tipo	Block (local)	Block (rede)	File (NFS)	Object (HTTP)
Latência	< 0,1 ms	0,5–2 ms	0,25–2,7 ms	5–150 ms
Persistência	Não	Sim	Sim	Sim
Instâncias	1 (local)	1 por AZ	N (multi-AZ)	Ilimitado
Custo/GB	Incluso na EC2	~$0,08	~$0,30	~$0,023
Sistema de arquivos	Você formata	Você formata	Pronto (NFS)	Não tem

Bônus: dúvidas comuns

Instance Store e EBS não são a mesma coisa?

Parecem, mas a diferença é física. O Instance Store é o SSD encaixado no mesmo servidor físico da sua EC2, sem rede no caminho. O EBS é um SSD em outro servidor, acessado via rede interna NVMe. A consequência prática: Instance Store é mais rápido, mas os dados somem se a instância parar. EBS é persistente e pode ser anexado em outra instância se necessário.

Quando o EBS faz sentido versus o EFS?

O EBS faz sentido quando apenas uma instância precisa acessar o storage e você quer máxima performance. O EFS faz sentido quando múltiplas instâncias precisam ler e escrever nos mesmos arquivos em disco ao mesmo tempo. Se só uma instância precisa, use EBS: é mais rápido e mais barato.

Quando sair do EFS e ir para o S3?

Quando seus dados não precisam de semântica de sistema de arquivos. Se a aplicação não precisa abrir um arquivo, editar e salvar, se ela apenas gera o objeto inteiro e lê o objeto inteiro, o S3 é mais adequado e muito mais barato ($0,023/GB versus $0,30/GB). O EFS faz sentido quando a aplicação já espera um sistema de arquivos normal e você precisa que ele seja compartilhado.

Por que banco de dados e Redis ficam no EBS e não no EFS?

Banco de dados e Redis não são acessados via disco compartilhado: eles são acessados via protocolo de rede (TCP, porta 5432 para PostgreSQL, porta 6379 para Redis). Suas outras instâncias se conectam ao banco via endereço de rede, não montando um disco. O EBS fica na instância do próprio banco, fornecendo o disco local de alta performance que ele precisa. O compartilhamento acontece na camada de aplicação, não na camada de storage.

Consigo reduzir custo usando EFS para compartilhar storage entre instâncias?

O EFS em si não reduz custo de storage: ele é o mais caro dos quatro ($0,30/GB). O que você evita é o custo de engenharia e infraestrutura de sincronização de arquivos entre instâncias. Se o objetivo for reduzir custo de storage, a pergunta certa é: esses arquivos precisam de disco local ou podem ir para o S3? Migrar do EFS para o S3 reduz o custo em mais de 10×.

O EFS consegue conectar instâncias em AZs diferentes?

Sim, esse é um dos principais diferenciais do EFS em relação ao EBS. O EFS existe no nível da região: uma EC2 em us-east-1a e outra em us-east-1b podem montar o mesmo EFS e enxergar os mesmos arquivos em tempo real. O EBS é travado na AZ onde foi criado e só pode ser anexado em instâncias dentro da mesma AZ.