Desempenho de armazenamento
Escolher serviços e configurações de armazenamento que atendam ao desempenho exigido e acompanhem o crescimento. É a tarefa 3.1 de Design High-Performing Architectures, o domínio que vale 24% do conteúdo pontuado.
A primeira decisão é o tipo de armazenamento. Ele define como o dado é endereçado, quem pode compartilhá-lo e até onde ele escala.
Pontos-chave
- Bloco (Amazon EBS, instance store): blocos de tamanho fixo ligados a uma instância, com baixa latência e muitos IOPS. Serve para volumes de boot, bancos de dados e cargas transacionais.
- Arquivo (Amazon EFS, Amazon FSx): sistema de arquivos hierárquico compartilhado por vários clientes ao mesmo tempo via NFS ou SMB.
- Objeto (Amazon S3): objetos com metadados em um namespace plano, acessados por APIs HTTPS, com escala praticamente ilimitada.
- Híbrido (AWS Storage Gateway): aplicações locais acessam o armazenamento na nuvem por interfaces de arquivo, volume ou fita.
Na prova
"Sistema de arquivos compartilhado por muitas instâncias Linux" -> EFS, não EBS. "Disco de menor latência para uma instância de banco" -> EBS (ou instance store se o dado for temporário). "Milhões de imagens ou um data lake" -> S3.
Desempenho do S3
Amazon S3 performance
O Amazon S3 escala sozinho, mas a taxa de requisições é contada por prefixo e objetos grandes trafegam mais rápido divididos em requisições paralelas.
Pontos-chave
- Prefixos: no mínimo 3.500
PUT/COPY/POST/DELETEe 5.500GET/HEADpor segundo por prefixo particionado, sem limite de prefixos. 10 prefixos chegam a 55.000 leituras por segundo. Enquanto o S3 escala, ele pode responder503 Slow Down. - Multipart upload: recomendado a partir de 100 MB e obrigatório acima de 5 GB, o limite de um único
PUT. Partes de 5 MiB a 5 GiB, até 10.000 partes, enviadas em paralelo e reenviadas uma a uma. Objetos chegam a 48,8 TiB. - Transfer Acceleration: o upload entra pelo edge location do CloudFront mais próximo e segue até o bucket por um caminho de rede otimizado. Usa o endpoint
bucket.s3-accelerate.amazonaws.com, exige nome de bucket compatível com DNS e sem pontos, e pode gerar cobrança de transferência. - Byte-range fetches: requisições
GETcom o cabeçalhoRangeleem partes de um mesmo objeto em conexões simultâneas, o que aumenta o throughput agregado e barateia as novas tentativas. - Proximidade e cache: leia o bucket a partir do EC2 na mesma Região e coloque CloudFront ou ElastiCache na frente do S3 para leituras repetidas que precisam de menos latência.
Na prova
"Uploads grandes de escritórios em outros continentes estão lentos" -> Transfer Acceleration mais multipart upload. "Erros 503 em um prefixo muito acessado" -> espalhe as chaves em mais prefixos. "Ler só um pedaço de um arquivo enorme" -> byte-range fetch.
Classes do S3
Amazon S3 storage classes
Toda classe recomendada é projetada para 99,999999999% (11 noves) de durabilidade. Elas mudam em disponibilidade, número de AZs, duração mínima e tempo de recuperação.
Pontos-chave
- Duração mínima: 30 dias em Standard-IA e One Zone-IA, 90 dias em Glacier Instant Retrieval e Glacier Flexible Retrieval, 180 dias em Glacier Deep Archive. Apagar antes ainda cobra os dias restantes.
- Tamanho mínimo cobrado: 128 KB em Standard-IA, One Zone-IA e Glacier Instant Retrieval. O Intelligent-Tiering não monitora objetos com menos de 128 KB.
- Uma única AZ: One Zone-IA e Express One Zone não resistem à perda da zona de disponibilidade. Guarde ali só o que dá para recriar.
- Recuperação de arquivo: o Glacier Flexible Retrieval restaura em 1 a 5 minutos (Expedited), 3 a 5 horas (Standard) ou 5 a 12 horas (Bulk, gratuito). O Deep Archive restaura em até 12 horas (Standard) ou 48 horas (Bulk).
- Regras de lifecycle: movem objetos para classes mais baratas conforme envelhecem, expiram objetos e abortam multipart uploads incompletos.
Na prova
"Padrão de acesso desconhecido ou variável" -> Intelligent-Tiering. "Lido uma vez por trimestre, mas precisa de milissegundos" -> Glacier Instant Retrieval. "Arquivo de compliance, 48 horas para recuperar é aceitável, menor custo" -> Glacier Deep Archive.
Classes de armazenamento do S3
| Classe | Perfil |
|---|---|
| Standard | Acesso frequente em milissegundos. 99,99% de disponibilidade, 3 ou mais AZs, sem duração mínima. |
| Intelligent-Tiering | Padrão desconhecido ou variável. Move objetos para Infrequent Access após 30 dias e Archive Instant Access após 90 dias sem acesso. Taxa de monitoramento, sem taxa de recuperação. |
| Express One Zone | Acesso em milissegundos de um dígito em uma AZ escolhida, em directory buckets. Até 10x mais rápido que o Standard, com requisições 50% mais baratas. |
| Standard-IA | Acesso cerca de uma vez por mês, em milissegundos. 99,9% de disponibilidade, taxa de recuperação por GB. |
| One Zone-IA | Dado pouco acessado e recriável em 1 AZ. 99,5% de disponibilidade. |
| Glacier Instant Retrieval | Arquivo lido cerca de uma vez por trimestre, ainda em milissegundos. |
| Glacier Flexible Retrieval | Arquivo lido uma ou duas vezes por ano, restaurado de minutos a 12 horas. Bom para backup e DR. |
| Glacier Deep Archive | Menor custo da AWS, lido menos de uma vez por ano, restaurado em 12 a 48 horas. |
Tipos de volume EBS
Amazon EBS
Volumes SSD são ajustados para IOPS em I/O pequeno e aleatório. Volumes HDD são ajustados para throughput em I/O grande e sequencial.
Pontos-chave
- gp3: 3.000 IOPS e 125 MiB/s incluídos em qualquer tamanho. IOPS (até 500 por GiB) e throughput são provisionados sem depender do tamanho, até 80.000 IOPS e 2.000 MiB/s, com preço por GiB 20% menor que o gp2.
- gp2: 3 IOPS por GiB, de 100 a 16.000. Volumes abaixo de 1 TiB fazem burst até 3.000 IOPS com créditos de I/O. O desempenho só cresce com o tamanho.
- io2 Block Express: até 256.000 IOPS, 4.000 MiB/s e 64 TiB, com 99,999% de durabilidade e latência média abaixo de 500 microssegundos. Para bancos críticos que precisam de IOPS sustentado.
- HDD (st1, sc1): de 125 GiB a 16 TiB e nunca volume de boot. st1 para big data, data warehouses e logs, sc1 para o armazenamento mais barato de dados raramente lidos.
- Elastic Volumes: muda tipo, IOPS e throughput de um volume em uso sem interromper a instância, por exemplo de gp2 para gp3.
- Lado da instância: use instâncias EBS-optimized para alcançar os IOPS provisionados. Volumes acima de 64.000 IOPS exigem instâncias baseadas em Nitro.
Na prova
"Mais IOPS sem pagar por mais GiB" -> gp3 (no gp2 o IOPS depende do tamanho). "Mais de 80.000 IOPS ou latência abaixo de 1 milissegundo" -> io2 Block Express. "EBS mais barato para logs sequenciais" -> st1, ou sc1 se quase não for lido.
Tipos de volume EBS
| Tipo | Limites e uso |
|---|---|
| gp3 | 1 GiB a 64 TiB, 3.000 a 80.000 IOPS, 125 a 2.000 MiB/s. Padrão para boot e a maioria das cargas. |
| gp2 | 1 GiB a 16 TiB, até 16.000 IOPS (3 por GiB), até 250 MiB/s. Créditos de burst. |
| io2 Block Express | 4 GiB a 64 TiB, até 256.000 IOPS e 4.000 MiB/s, 99,999% de durabilidade. Multi-Attach. |
| io1 | 4 GiB a 16 TiB, até 64.000 IOPS e 1.000 MiB/s. Multi-Attach. |
| st1 | 125 GiB a 16 TiB, até 500 MiB/s. Big data, warehouses, logs. Não serve de boot. |
| sc1 | 125 GiB a 16 TiB, até 250 MiB/s. Dado frio de menor custo. Não serve de boot. |
Duas opções de bloco fora da regra de um volume durável por instância: um volume Provisioned IOPS compartilhado e discos locais rápidos que vivem e morrem com a instância.
Pontos-chave
- Multi-Attach: um volume io1 ou io2 ligado a até 16 instâncias baseadas em Nitro na mesma zona de disponibilidade, todas com leitura e escrita. Sem custo adicional.
- Escrita coordenada: XFS e ext4 não foram feitos para vários escritores simultâneos. Use um sistema de arquivos em cluster ou uma aplicação que ordene as escritas. Volumes Multi-Attach não podem ser volume de boot.
- Instance store: discos fisicamente ligados ao host, incluídos no preço da instância. Ideal para buffers, caches, dados de rascunho e dados replicados entre várias instâncias.
- Dado efêmero: sobrevive a um reboot, mas se perde em stop, hibernação, término ou falha do disco. Só pode ser adicionado no launch e nunca desanexado.
Na prova
"Aplicação em cluster em uma AZ precisa de um dispositivo de bloco compartilhado" -> EBS Multi-Attach com io2. "Maior I/O de disco para dado temporário, perda aceitável" -> instance store. Dado que precisa sobreviver a um stop fica no EBS.
EFS
Amazon Elastic File System
Sistema de arquivos NFS serverless que cresce sozinho até petabytes e é compartilhado por EC2, ECS, EKS, Fargate e Lambda. Instâncias Windows não são suportadas.
Pontos-chave
- Protocolo: NFSv4.0 e NFSv4.1 com permissões POSIX. Para compartilhamentos SMB no Windows, use o FSx for Windows File Server.
- Tipo de sistema de arquivos: Regional guarda os dados em 3 ou mais AZs (recomendado). One Zone guarda em 1 AZ, mais barato mas exposto à perda dessa AZ.
- Modo de desempenho: General Purpose (padrão, menor latência, recomendado). Max I/O é de geração anterior, com mais latência, e não existe com throughput Elastic nem em One Zone.
- Modo de throughput: Elastic (padrão) escala sozinho para cargas com picos ou imprevisíveis. Provisioned fixa o throughput para necessidades conhecidas. Bursting acompanha o volume de dados na classe Standard.
- Classes de armazenamento: Standard (SSD, leitura abaixo de 1 milissegundo), Infrequent Access e Archive (dezenas de milissegundos, mínimo de 90 dias no Archive). O lifecycle management move os arquivos entre elas.
- Replicação: mantém uma cópia em outra Região com RPO e RTO medidos em minutos.
Na prova
"Centenas de instâncias Linux em várias AZs compartilham os mesmos arquivos" -> EFS Regional. "Sistema de arquivos limitado no modo Bursting" -> mude para throughput Elastic ou Provisioned. "Compartilhamento de arquivos Windows" nunca é EFS.
FSx
Amazon FSx
Sistemas de arquivos totalmente gerenciados, baseados em tecnologias comerciais e open source conhecidas. Escolha o que combina com o protocolo ou o sistema de arquivos já em uso.
Pontos-chave
- FSx for Windows File Server: sistema de arquivos Windows nativo via SMB, com autenticação no Microsoft Active Directory e ACLs do Windows. Single-AZ ou Multi-AZ com servidor standby, armazenamento SSD ou HDD.
- FSx for Lustre: sistema de arquivos paralelo POSIX para HPC, machine learning, processamento de vídeo e modelagem financeira. Liga-se a um bucket S3, apresenta os objetos como arquivos e grava os resultados de volta. Implantação scratch (sem replicação) ou persistent, clientes Linux.
- FSx for NetApp ONTAP: acesso multiprotocolo NFS, SMB, iSCSI e NVMe a partir de Linux, Windows e macOS. Snapshots, clones, replicação SnapMirror, compressão, deduplicação e tiering automático de dados frios.
- FSx for OpenZFS: acesso NFS para migrar servidores ZFS ou Linux, com latência de centenas de microssegundos, snapshots, clones e compressão. Implantações Multi-AZ ou Single-AZ.
Na prova
"Compartilhamentos Windows integrados ao Active Directory" -> FSx for Windows File Server. "Job de HPC sobre um dataset guardado no S3" -> FSx for Lustre. "Migrar um NAS NetApp sem trocar ferramentas" -> FSx for NetApp ONTAP. "Levar um servidor ZFS" -> FSx for OpenZFS.
Storage Gateway
AWS Storage Gateway
Um appliance de software ou hardware no ambiente local que oferece às aplicações interfaces de armazenamento padrão apoiadas na AWS, com cache local para baixa latência.
Pontos-chave
- S3 File Gateway: compartilhamentos NFS (v3, v4.1) e SMB cujos arquivos viram objetos no S3, com cache local. Os dados ficam disponíveis para lifecycle, replicação e análise no S3.
- Volume Gateway: volumes de bloco iSCSI. Volumes cached guardam os dados no S3 e só o que é frequente no local. Volumes stored guardam o dataset inteiro no local e fazem backup por snapshots assíncronos.
- Tape Gateway: biblioteca de fitas virtual para o software de backup existente, arquivando as fitas no S3 Glacier Flexible Retrieval ou no S3 Glacier Deep Archive.
- FSx File Gateway: não está mais disponível para novos clientes. Projetos novos acessam o FSx for Windows File Server direto por Direct Connect ou Site-to-Site VPN.
- Implantação: VM em VMware ESXi, Microsoft Hyper-V ou Linux KVM, appliance de hardware ou instância EC2.
Na prova
"Substituir fitas físicas sem trocar o software de backup" -> Tape Gateway. "Aplicação local grava arquivos via NFS ou SMB que precisam ir para o S3" -> S3 File Gateway. "Dataset inteiro no local com baixa latência e backup na AWS" -> Volume Gateway stored volumes.