EBS, EFS e FSx: Quando Usar Cada Um
⏱ 12 min·⭐ 60 XP
Pré-requisitos (0/1)0%
- ⬜🪣 S3 Profundo: Classes, Lifecycle e Object Lock(AWS Solutions Architect Associate)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
S3 resolve object storage. Mas aplicações precisam muitas vezes de block (disco que uma instância formata) ou file (compartilhado entre várias máquinas com protocolo NFS/SMB). AWS tem um portfólio confuso aqui — EBS, EFS, quatro variantes de FSx, instance store, Storage Gateway — e o SAA adora testar a escolha certa em cenários específicos. Vamos alinhar os cinco vetores: protocolo, multi-attach, performance, custo e caso de uso.
📘 High-Performing· 24%
📘 Resilient· 26%
📘 Cost-Optimized· 20%
Mapa mental de storage para compute
🗺️ Taxonomia: qual storage para qual uso?
BLOCK
💽
EBS
gp3 · io2 · st1 · sc1 — volume persistente anexado a 1 EC2
⚡
Instance Store
SSD efêmero, perde ao stop/terminate — cache, buffers
FILE
📁
EFS
NFS para Linux, elástico, multi-AZ
🪟
FSx for Windows
SMB, AD-integrado, Windows workloads
🚀
FSx for Lustre
HPC/ML — sub-ms, integra com S3
🧬
FSx for NetApp ONTAP
NFS/SMB/iSCSI, snapshots, migração lift-and-shift
🧊
FSx for OpenZFS
NFS com snapshots/clones instantâneos
OBJECT
🪣
S3
API HTTP — qualquer cliente, qualquer região. Ilimitado.
Uma instância, um discoVPC
EC2 (AZ-a)
EBSgp3, io2 · UMA instância, UMA AZ
Instance StoreNVMe local · EFÊMERO
Muitas instâncias, um sistema de arquivosVPC
EC2 (AZ-b)
EFSNFS · multi-AZ · elástico
Protocolo específicoVPC
FSx for WindowsSMB + Active Directory
FSx for LustreHPC e ML, integra com S3
Snapshot e recuperação
Snapshot no S3incremental, cross-region
- → anexa · mesma AZ
- → disco do host
- → monta
- → monta o MESMO
- → SMB
- → lê e escreve no S3
- → snapshot
- Compute
- Armazenamento
Uma pergunta resolve: quantas máquinas precisam do mesmo conteúdo ao mesmo tempo? Uma → EBS. Várias, em Linux → EFS. Várias, com SMB ou HPC → FSx. E se o dado pode desaparecer, Instance Store é mais rápido e mais barato.
- EBS é um disco, e é de uma máquina. Vive numa AZ e anexa a uma instância por vez (multi-attach existe em io1/io2 com restrições, mas não é o caso padrão do exame). É onde fica o SO e o banco local.
- Instance Store desaparece ao parar. NVMe físico do host: latência mínima, e conteúdo perdido quando a instância para ou é terminada. Serve para cache, arquivo temporário e scratch de processamento. Dado que precisa sobreviver não vai aqui.
- EFS é o compartilhado de Linux. NFS gerenciado, elástico, montável por instâncias em AZs diferentes ao mesmo tempo. É a resposta de "vários servidores precisam ler e escrever os mesmos arquivos".
- FSx quando o protocolo manda. Windows precisa de SMB e integração com Active Directory: FSx for Windows. HPC e treino de ML precisam de throughput extremo e leitura direta do S3: FSx for Lustre. EFS não fala SMB.
- Snapshot é a ponte para o S3. Snapshot de EBS é incremental e vive no S3, podendo ser copiado para outra região — base de backup e de DR. FSx for Lustre vai além: lê e escreve direto no S3 como se fosse o filesystem.
EBS — block storage anexado à EC2
EBS é volume que você anexa a uma EC2 na mesma AZ. Formata, monta, usa como disco local. Persiste após stop, snapshot vai para S3, criptografia via KMS é transparente.
| Tipo | Família | IOPS máx | Throughput máx | Caso de uso |
|---|---|---|---|---|
| gp3 | SSD genérico | 16.000 | 1.000 MB/s | Padrão moderno — desacopla IOPS de tamanho, 20% mais barato que gp2 |
| gp2 | SSD genérico (legado) | 16.000 | 250 MB/s | Legado. 3 IOPS/GB até 16k máx. |
| io2 Block Express | SSD premium | 256.000 | 4.000 MB/s | SAP HANA, Oracle, SQL Server críticos |
| io2 | SSD premium | 64.000 | 1.000 MB/s | DBs críticos com SLA de durabilidade 99,999% |
| st1 | HDD throughput | 500 | 500 MB/s | Big Data, data warehouses, logs sequenciais |
| sc1 | HDD cold | 250 | 250 MB/s | Arquivamento acessado menos de 1x/dia |
Tipogp3
FamíliaSSD genérico
IOPS máx16.000
Throughput máx1.000 MB/s
Caso de usoPadrão moderno — desacopla IOPS de tamanho, 20% mais barato que gp2
Tipogp2
FamíliaSSD genérico (legado)
IOPS máx16.000
Throughput máx250 MB/s
Caso de usoLegado. 3 IOPS/GB até 16k máx.
Tipoio2 Block Express
FamíliaSSD premium
IOPS máx256.000
Throughput máx4.000 MB/s
Caso de usoSAP HANA, Oracle, SQL Server críticos
Tipoio2
FamíliaSSD premium
IOPS máx64.000
Throughput máx1.000 MB/s
Caso de usoDBs críticos com SLA de durabilidade 99,999%
Tipost1
FamíliaHDD throughput
IOPS máx500
Throughput máx500 MB/s
Caso de usoBig Data, data warehouses, logs sequenciais
Tiposc1
FamíliaHDD cold
IOPS máx250
Throughput máx250 MB/s
Caso de usoArquivamento acessado menos de 1x/dia
AZ-boundVolume existe em uma AZ. Para mover, faça snapshot → crie volume na outra AZ a partir do snapshot.
SnapshotsIncrementais em S3 (não acessível diretamente). Cross-region copy suportado. Fast Snapshot Restore elimina hydrate latency.
Multi-AttachApenas io1/io2 permitem anexar a até 16 instâncias na MESMA AZ. Precisa de cluster-aware FS (não ext4 padrão).
Elastic VolumesPode mudar tipo/tamanho/IOPS ao vivo sem stop. Limite: uma mudança a cada 6h no mesmo volume.
EncryptionKMS. Se habilitada por default na conta, todo volume novo é criptografado. Snapshot de volume encrypted herda encryption.
⚠️
Instance Store ≠ EBS. Instance store é SSD/NVMe local ao hypervisor, altíssima performance (milhões de IOPS) mas efêmero — stop ou failure apaga tudo. Usado para cache, shuffle de Spark, scratch de ML. Disponibilidade por família (i3, i4i, m5d, r5d, etc.).
EFS — NFS gerenciado para Linux
EFS é filesystem POSIX compatível com NFSv4, multi-AZ, elastic (cresce e encolhe automaticamente). Qualquer instância EC2 (ou ECS/EKS/Lambda) monta e compartilha.
| Dimensão | EFS Standard | EFS One Zone |
|---|---|---|
| Durabilidade | Multi-AZ na região | AZ única |
| Custo | $$$ | $ (~47% menor) |
| Caso | Produção | Dev/test, backups secundários |
DimensãoDurabilidade
EFS StandardMulti-AZ na região
EFS One ZoneAZ única
DimensãoCusto
EFS Standard$$$
EFS One Zone$ (~47% menor)
DimensãoCaso
EFS StandardProdução
EFS One ZoneDev/test, backups secundários
Performance modesGeneral Purpose (default, baixa latência) vs Max I/O (escala > 7k ops/s mas latência mais alta). Nova geração Elastic Throughput torna essa escolha menos crítica.
Throughput modesBursting (grátis, escala com tamanho) | Provisioned (pago fixo) | Elastic (auto-scale pay-per-use, recomendado).
IA + LifecycleMove arquivos não acessados para EFS-IA automaticamente após 7/14/30/60/90 dias. Reduz custo em até 92%.
Access PointsEndpoints com POSIX user enforcement + root directory — isola múltiplas apps no mesmo FS.
Cross-regionReplicação para outra região para DR, RPO < 1h.
💡
Lambda + EFS: Lambda pode montar EFS via Access Point na VPC. Útil para modelos ML grandes que não cabem no pacote de 250MB da Lambda. Cold start +1–2s ao montar.
FSx — 4 filesystems especializados
| Variante | Protocolo | Caso de uso |
|---|---|---|
| FSx for Windows File Server | SMB + NTFS ACL + AD | Apps Windows, share de departamento, home folders |
| FSx for Lustre | POSIX (Linux) + S3-backed | HPC, ML training, genômica, mídia (centenas de GB/s) |
| FSx for NetApp ONTAP | SMB + NFS + iSCSI | Lift-and-shift de NetApp, snapshots FlexClone, multi-protocolo |
| FSx for OpenZFS | NFS (v3/v4) | Apps Linux/Unix que querem snapshots baratos + clones instantâneos |
VarianteFSx for Windows File Server
ProtocoloSMB + NTFS ACL + AD
Caso de usoApps Windows, share de departamento, home folders
VarianteFSx for Lustre
ProtocoloPOSIX (Linux) + S3-backed
Caso de usoHPC, ML training, genômica, mídia (centenas de GB/s)
VarianteFSx for NetApp ONTAP
ProtocoloSMB + NFS + iSCSI
Caso de usoLift-and-shift de NetApp, snapshots FlexClone, multi-protocolo
VarianteFSx for OpenZFS
ProtocoloNFS (v3/v4)
Caso de usoApps Linux/Unix que querem snapshots baratos + clones instantâneos
📋 Cluster HPC de simulação física, 200 nós, lê 10TB de inputs por job
✓ FSx for Lustre linked ao bucket S3
Lustre é filesystem paralelo nativo para HPC. Linkar ao S3 permite hidratar dados sob demanda e devolver resultados sem copiar manualmente.
Alt: EFS Max I/O — escala mas não atinge centenas de GB/s sustentados.
📋 Migração de NetApp on-prem (iSCSI + NFS + SnapMirror) para AWS
✓ FSx for NetApp ONTAP
Mantém APIs, features (SnapMirror, FlexClone, Deduplication) e compatibilidade binária. Redução de risco na migração.
Alt: Refatorar para EFS + EBS — viável mas muito mais trabalho.
Quiz rápido
Um cluster de renderização Linux com 40 instâncias precisa ler os mesmos 8 TB de assets e gravar o resultado num local compartilhado. Qual storage?
Storage Gateway — ponte híbrida on-prem ↔ AWS
| Tipo | Protocolo local | Backend AWS | Caso de uso |
|---|---|---|---|
| File Gateway | NFS/SMB | S3 | On-prem vê um share, dados vão para S3 (com classes/lifecycle). |
| Volume Gateway | iSCSI | EBS Snapshots | Cached Mode (hot on-prem + cold AWS) ou Stored Mode (tudo on-prem + snapshot cloud). |
| Tape Gateway | VTL (iSCSI) | Glacier/Deep Archive | Substituir biblioteca física de fitas (backup software existente). |
| Amazon FSx File Gateway | SMB | FSx for Windows | Acesso local em branch offices a files em FSx central. |
TipoFile Gateway
Protocolo localNFS/SMB
Backend AWSS3
Caso de usoOn-prem vê um share, dados vão para S3 (com classes/lifecycle).
TipoVolume Gateway
Protocolo localiSCSI
Backend AWSEBS Snapshots
Caso de usoCached Mode (hot on-prem + cold AWS) ou Stored Mode (tudo on-prem + snapshot cloud).
TipoTape Gateway
Protocolo localVTL (iSCSI)
Backend AWSGlacier/Deep Archive
Caso de usoSubstituir biblioteca física de fitas (backup software existente).
TipoAmazon FSx File Gateway
Protocolo localSMB
Backend AWSFSx for Windows
Caso de usoAcesso local em branch offices a files em FSx central.
Comparação final — cheat sheet do exame
| Requisito | Escolha |
|---|---|
| Disco para EC2, single-host, alta IOPS | EBS io2 Block Express |
| Disco para EC2, padrão, custo-benefício | EBS gp3 |
| Filesystem compartilhado Linux | EFS |
| Filesystem compartilhado Windows + AD | FSx for Windows File Server |
| HPC / ML training com S3 dataset | FSx for Lustre |
| Migração de NetApp | FSx for NetApp ONTAP |
| Snapshots baratos + clones para teste | FSx for OpenZFS |
| Scratch disk ultra-rápido e descartável | Instance Store |
| On-prem quer usar S3 como se fosse NFS | File Gateway |
| Object storage global | S3 |
RequisitoDisco para EC2, single-host, alta IOPS
EscolhaEBS io2 Block Express
RequisitoDisco para EC2, padrão, custo-benefício
EscolhaEBS gp3
RequisitoFilesystem compartilhado Linux
EscolhaEFS
RequisitoFilesystem compartilhado Windows + AD
EscolhaFSx for Windows File Server
RequisitoHPC / ML training com S3 dataset
EscolhaFSx for Lustre
RequisitoMigração de NetApp
EscolhaFSx for NetApp ONTAP
RequisitoSnapshots baratos + clones para teste
EscolhaFSx for OpenZFS
RequisitoScratch disk ultra-rápido e descartável
EscolhaInstance Store
RequisitoOn-prem quer usar S3 como se fosse NFS
EscolhaFile Gateway
RequisitoObject storage global
EscolhaS3
Q&A estilo exame
❓ Volume EBS não anexa à instância — qual a primeira coisa a verificar?
Mesma AZ. EBS é AZ-scoped. Se instância está em us-east-1a e o volume foi criado em us-east-1b, attach falha. Snapshot → create volume na AZ correta → attach.
❓ Quero que snapshots EBS existam também em outra região para DR. Como?
Copie o snapshot com `CopySnapshot` para a região de destino, ou use Data Lifecycle Manager com policy cross-region. DLM automatiza as três etapas — snapshot, retenção e cópia — e é o caminho para DR recorrente; a cópia manual serve para o caso pontual.
❓ EFS em Lambda — quais limites devo saber?
A Lambda precisa estar em VPC com acesso ao mount target, e há limite de 25.000 conexões concorrentes por mount target. A política de IAM tem de permitir as ações de montagem e de escrita do EFS (ClientMount e ClientWrite) — sem elas a função sobe e falha só na primeira leitura.
❓ Preciso criptografar um volume EBS já existente que não estava criptografado.
Snapshot → copy snapshot com flag + KMS key → create volume do novo snapshot → detach antigo, attach novo. Não tem encryption in-place no EBS.
⚠️
Pegadinhas frequentes: (1) EBS é AZ-scoped, esqueceu e vai errar; (2) gp2 “parece” mais barato mas gp3 ganha em custo × performance quase sempre; (3) EFS é Linux/NFS — se viu Windows no enunciado, pense FSx for Windows; (4) Multi-Attach do io2 é limitado à mesma AZ e exige cluster-aware FS; (5) Instance Store some no stop, não no reboot.
# Criar EBS gp3 com IOPS e throughput customizados
aws ec2 create-volume \
--availability-zone us-east-1a \
--size 100 --volume-type gp3 \
--iops 6000 --throughput 250 \
--encrypted --kms-key-id alias/ebs-default
# Montar EFS em instância Linux
sudo mount -t efs -o tls fs-0abc123:/ /mnt/efs
# Criar FSx for Lustre linkado a bucket S3
aws fsx create-file-system --file-system-type LUSTRE \
--storage-capacity 1200 --subnet-ids subnet-xxx \
--lustre-configuration DataRepositoryAssociations=\
[{DataRepositoryPath=s3://meu-bucket,FileSystemPath=/data}]Perguntas frequentes
❓ Disco de bloco, sistema de arquivos compartilhado ou serviço gerenciado?
Bloco quando uma instância usa o volume. Arquivos compartilhados quando várias instâncias precisam escrever ao mesmo tempo, em Linux. Serviço gerenciado de arquivos quando o requisito é protocolo Windows ou desempenho de computação de alto porte. A pergunta que decide é quantas máquinas escrevem simultaneamente.
❓ Como escolher o tipo de volume de bloco?
Pelo perfil de acesso: propósito geral de estado sólido cobre quase tudo e permite ajustar desempenho sem crescer o disco; provisionado de alto desempenho quando há requisito de operações por segundo com latência garantida; magnético otimizado para varredura sequencial de dado grande e frio.
❓ Instantâneo de volume é incremental?
É: o primeiro copia tudo e os seguintes guardam apenas os blocos alterados, mas cada instantâneo é restaurável de forma independente — apagar um antigo não invalida os novos. É a pergunta de prova que confunde, porque incremental sugere dependência em cadeia, e aqui não há.
Fixando
Quiz rápido
Um workload de treino de machine learning precisa de throughput extremo lendo dados que vivem no S3. Qual filesystem?
Quiz rápido
Qual afirmação sobre snapshot de EBS é correta?
✅
Take-aways: escolha guiada por (1) quem acessa — 1 host = EBS, muitos = EFS/FSx; (2) protocolo — NFS vs SMB vs POSIX; (3) performance — gp3/io2 para latência, Lustre para throughput; (4) persistência — Instance Store nunca em produção crítica.
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…