Amazon SAA-C03: Armazenamento e Ciclo de Vida de Dados — Guia de estudos

By Laurynas Brazys · 18 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Faz parte do AWS SAA-C03 — Guia de estudos completo. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Classes de armazenamento do S3 e o espectro de custo/latência

As classes de armazenamento do S3 existem em um espectro que equilibra latência de recuperação, duração mínima de armazenamento e taxas de recuperação por GB em contrapartida ao custo de armazenamento por GB. A escolha correta é a maior alavanca para a otimização de custos no armazenamento de objetos.

S3 Standard é o padrão: durabilidade de onze noves em três ou mais AZs, latência de milissegundos, sem taxa de recuperação e o preço por GB mais alto. Standard-IA e One Zone-IA reduzem o custo de armazenamento em aproximadamente 40–50%, mas adicionam uma taxa de recuperação por GB, uma duração mínima faturável de 30 dias e um tamanho mínimo de objeto de 128 KB (objetos menores são faturados como se tivessem 128 KB, o que corrói a economia). O One Zone-IA reduz ainda mais o custo ao armazenar em uma única AZ — apropriado apenas para cópias secundárias reproduzíveis onde a perda de uma única AZ é tolerável.

S3 Intelligent-Tiering é a escolha correta sempre que os padrões de acesso são desconhecidos, imprevisíveis ou mudam em um grande corpo de dados. Ele migra automaticamente objetos entre as camadas de acesso frequente, infrequente, de arquivamento instantâneo, de arquivamento e de arquivamento profundo com base no acesso observado, cobrando uma pequena taxa de monitoramento por objeto. Como não há cobranças de recuperação entre as camadas de acesso frequente e infrequente e nenhuma duração mínima, é o padrão mais seguro para data lakes e cargas de trabalho mistas com objetos ≥128 KB. É a escolha errada quando você já sabe que os objetos são permanentemente de acesso frequente (custo extra de monitoramento) ou permanentemente de acesso esporádico por uma década (o Deep Archive é muito mais barato).

Glacier Instant Retrieval fornece acesso em milissegundos a preços de arquivamento para dados acessados trimestralmente ou menos — imagens médicas, PDFs de conformidade que devem ser produzidos imediatamente quando solicitados. Glacier Flexible Retrieval oferece recuperação de minutos a horas. Glacier Deep Archive é a camada mais barata da AWS, custando aproximadamente $1/TB/mês, com recuperação padrão de 12 horas (ou em massa de 48 horas) e um mínimo de 180 dias — a resposta correta para retenção regulatória de 7 a 10 anos e substituição de fitas.

As duas armadilhas de custo dominantes são erros opostos. Selecionar o Standard para dados de longo prazo raramente lidos desperdiça dinheiro porque o Standard não tem redução de preço para armazenamento frio — um conjunto de dados de 5 TB mantido por anos no Standard custa várias vezes mais do que os mesmos dados no Deep Archive. Por outro lado, mover objetos novos diretamente para o Standard-IA ou Glacier é uma armadilha, porque as cobranças mínimas de 30/90/180 dias mais as taxas de recuperação excedem a economia quando os objetos ainda são de acesso frequente. O Glacier Flexible ou o Deep Archive também são totalmente incompatíveis com qualquer carga de trabalho que espere uma leitura síncrona — um usuário esperando por um GET HTTP não pode tolerar um SLA de recuperação de minutos a 12 horas. O Glacier Instant Retrieval é a única camada do Glacier compatível com acesso imediato.

Políticas de Ciclo de Vida e Gerenciamento de Versões

A configuração de ciclo de vida (Lifecycle) é um JSON/YAML declarativo anexado a um bucket que transiciona ou expira objetos com base na idade, tag ou prefixo. As transições são avaliadas uma vez por dia e só são acionadas depois que a idade especificada é atingida — uma transição Days: 30 significa que as taxas do Standard se aplicam durante os primeiros 30 dias. As transições devem mover os objetos para camadas progressivamente mais frias, e objetos menores que 128 KB não são transicionados do Standard para o IA porque a sobrecarga por objeto supera a economia; consolide objetos pequenos via tar/zip ou S3 Batch Operations primeiro.

Uma política canônica para uma carga de trabalho que é de acesso frequente por 30 dias, de acesso esporádico depois disso, necessitando de acesso imediato o tempo todo, retida por quatro anos, com uma higiene adequada:

Rules:
  - ID: archive-and-clean
    Status: Enabled
    Transitions:
      - Days: 30
        StorageClass: STANDARD_IA
      - Days: 180
        StorageClass: DEEP_ARCHIVE
    NoncurrentVersionTransitions:
      - NoncurrentDays: 30
        StorageClass: GLACIER
    NoncurrentVersionExpiration:
      NoncurrentDays: 365
    Expiration:
      Days: 1460
    AbortIncompleteMultipartUpload:
      DaysAfterInitiation: 7

Uma armadilha comum no gerenciamento de versões: em um bucket versionado, uma regra de ciclo de vida que expira objetos atuais apenas insere marcadores de exclusão; as versões anteriores se acumulam silenciosamente e continuam a ser faturadas. Versões não atuais exigem suas próprias regras explícitas NoncurrentVersionTransitions e NoncurrentVersionExpiration. Da mesma forma, sempre inclua AbortIncompleteMultipartUpload — partes de multipart uploads órfãs são invisíveis na listagem do console e acumulam custos de armazenamento indefinidamente.

Para padrões mistos — por exemplo, telemetria de IoT que é de acesso frequente para treinamento de ML no primeiro mês, depois consultada trimestralmente por um ano e, em seguida, arquivada — a resposta certa é o Intelligent-Tiering para o primeiro ano (permitindo que a classe otimize automaticamente entre picos de treinamento e dias ociosos), seguido por uma transição agendada para o Deep Archive no dia 365.

Versionamento, MFA Delete e Object Lock

Uma vez ativado, o versionamento só pode ser suspenso; ele não pode ser desativado. Cada PUT cria um novo ID de versão; um DELETE insere um marcador de exclusão em vez de remover os dados. O versionamento protege contra sobrescritas acidentais, mas não é imutabilidade: qualquer principal com a permissão s3:DeleteObjectVersion pode remover permanentemente uma versão específica. O MFA Delete adiciona a exigência de que a conta root apresente um token MFA para remover permanentemente versões ou alterar o estado do versionamento — fechando a brecha de exclusão acidental para buckets de alto valor, mas ainda não impedindo que um ator autorizado destrua os dados.

A verdadeira imutabilidade exige o S3 Object Lock, que requer versionamento e geralmente deve ser ativado na criação do bucket. Ele tem dois modos que são frequentemente confundidos:

A retenção pode ser aplicada por objeto (Retain-Until-Date) ou por meio de uma Legal Hold (retenção legal), que não tem data de expiração. Para registros contábeis que exigem um ano em armazenamento “hot” (acesso frequente), nove anos arquivados e nenhuma exclusão por dez anos, o padrão correto é o Object Lock no modo Compliance com uma retenção de dez anos, combinado com uma transição de ciclo de vida para o Deep Archive no dia 365. O modo Governance não é um substituto aceitável para uma exigência legal — um órgão regulador não aceitará “alguém com permissões poderia ter excluído isso” como imutabilidade.

Para aplicar a retenção a um corpo de PDFs existente em uma única tarefa (job), use o S3 Batch Operations orientado por um manifesto do S3 Inventory. O Batch Operations é a resposta gerenciada para mutações em grande escala — retenção, etiquetagem (tagging), recriptografia com PUT-copy, invocação de Lambda — em bilhões de chaves; scripts de iteração manuais não são o padrão correto.

Criptografia: SSE-S3, SSE-KMS e Bucket Keys

Todo bucket tem criptografia padrão. O SSE-S3 (AES-256, chaves gerenciadas pelo S3) é gratuito e não requer administração de chaves. O SSE-KMS usa uma chave mestra de cliente (CMK) do KMS, permitindo trilhas de auditoria por chave no CloudTrail, políticas de acesso à chave baseadas no IAM e controle de rotação de chaves — ao custo de cobranças da API do KMS e, mais criticamente, do throttling de requisições do KMS, que pode gargalar cargas de trabalho de leitura de alta vazão (high-throughput). Escolha o SSE-KMS quando você realmente precisar desses controles (atestado regulatório, separação de funções, compartilhamento de chaves entre contas). Adotar o SSE-KMS como padrão “por segurança” adiciona custo e complexidade desnecessários quando o SSE-S3 já atende ao requisito.

As S3 Bucket Keys resolvem o custo das requisições do SSE-KMS. O S3 gera uma chave de curta duração no nível do bucket a partir da CMK e deriva localmente as chaves de dados por objeto, evitando uma chamada GenerateDataKey/Decrypt ao KMS por objeto e reduzindo os custos de requisição do KMS em até 99%:

"ServerSideEncryptionConfiguration": {
  "Rules": [{
    "ApplyServerSideEncryptionByDefault": {
      "SSEAlgorithm": "aws:kms",
      "KMSMasterKeyID": "arn:aws:kms:..."
    },
    "BucketKeyEnabled": true
  }]
}

Mudar para SSE-S3 para “evitar custos do KMS” é a solução paliativa errada quando o requisito exige o KMS — as Bucket Keys satisfazem tanto os objetivos de conformidade quanto de custo sem abandonar o KMS.

Ativar a criptografia padrão do bucket garante que todos os uploads futuros sejam criptografados (PUTs não criptografados são criptografados de forma transparente). Para rejeitar completamente PUTs não criptografados, negue escritas que não possuam o cabeçalho:

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringNotEquals": {
      "s3:x-amz-server-side-encryption": "AES256"
    }
  }
}

A criptografia padrão não afeta objetos não criptografados já existentes. Recriptografe-os via S3 Inventory + Batch Operations executando uma tarefa (job) de Copy que sobrescreve cada chave no mesmo local — o padrão para recriptografia em massa.

A criptografia do lado do cliente (client-side) ad-hoc é inferior à criptografia padrão mais o KMS: ela espalha o gerenciamento de chaves entre as equipes de aplicação, não pode ser auditada centralmente através de eventos do KMS no CloudTrail e não pode usar Bucket Keys.

Cross-Region Replication e Chaves Multi-Region do KMS

A Cross-Region Replication (CRR) copia objetos de forma assíncrona para um bucket em uma Região diferente para fins de conformidade, recuperação de desastres (DR) ou latência. A Same-Region Replication (SRR) serve para separação de conformidade, agregação de logs e cópias entre contas. Ambos exigem versionamento nos buckets de origem e destino e uma IAM role que o bucket de origem assume. O CRR é a resposta de baixo esforço sempre que um bucket precisa ser espelhado para outra Região — criar scripts com aws s3 sync, conectar Lambdas em eventos ObjectCreated ou executar cópias em lote agendadas introduz sobrecarga operacional, condições de corrida (race conditions) e falhas silenciosas. Nem o CRR nem o SRR replicam objetos existentes por padrão; use o S3 Batch Replication para preencher os dados antigos (backfills).

As interações com a criptografia são onde os projetos comumente falham:

• SSE-S3: objetos replicam de forma transparente.
• SSE-KMS: objetos não são replicados por padrão — você deve optar explicitamente por isso, especificar uma chave KMS de destino na Região de destino e conceder à replication role as permissões kms:Decrypt na chave de origem e kms:Encrypt na chave de destino. Uma chave de Região única (single-Region) não pode criptografar objetos em outra Região.
• Objetos com criptografia do lado do cliente (client-side) replicam como texto cifrado opaco; a Região de destino não ganha nada a menos que o material da chave do cliente esteja disponível lá.

O atrito histórico de gerenciar duas CMKs independentes é resolvido pelas chaves multi-Region do AWS KMS, que apresentam o mesmo material de chave e ID de chave (com um prefixo de Região) em múltiplas Regiões. Um objeto replicado pode então ser descriptografado na Região de destino sem chamadas ao KMS entre Regiões e sem re-empacotar (re-wrapping) a chave de dados. Este é o padrão canônico para buckets criptografados e replicados que devem permanecer utilizáveis em um failover Regional.

O compartilhamento de snapshots e objetos entre contas sob uma chave KMS gerenciada pelo cliente (customer-managed) exige que os principais da conta de destino tenham as permissões kms:Decrypt, kms:CreateGrant, kms:DescribeKey e kms:ReEncrypt* na chave de origem por meio da política de chave (key policy), além de permissões IAM correspondentes. Chaves gerenciadas pela AWS (por exemplo, aws/ebs, aws/s3) não podem ser compartilhadas entre contas, portanto, chaves gerenciadas pelo cliente são obrigatórias para fluxos de trabalho entre contas.

Block Public Access e Restrição de Acesso ao CloudFront

O S3 Block Public Access (BPA) tem quatro configurações — bloquear novas ACLs públicas, ignorar ACLs públicas existentes, bloquear novas políticas de bucket públicas, restringir políticas de bucket públicas — configuráveis por bucket e, mais importante, no nível da conta. O BPA no nível da conta substitui qualquer política de bucket que concederia acesso público e é o controle correto para garantir que “nenhum objeto nesta conta pode ser público”. Políticas no nível do bucket sozinhas são frágeis: um novo bucket pode ser lançado sem uma; o BPA no nível da conta opera em modo “fail-closed” (falha fechada).

Para impedir que um administrador em uma conta-membro desabilite o BPA, aplique uma Service Control Policy na OU do Organizations ou na raiz:

{
  "Effect": "Deny",
  "Action": "s3:PutAccountPublicAccessBlock",
  "Resource": "*",
  "Condition": {
    "Bool": { "aws:PrincipalIsAWSService": "false" }
  }
}

Para servir conteúdo do S3 apenas através do CloudFront, anexe um Origin Access Control (OAC) — o substituto moderno para o antigo OAI — à distribuição e restrinja a política do bucket com base no ARN da distribuição:

{
  "Effect": "Allow",
  "Principal": { "Service": "cloudfront.amazonaws.com" },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringEquals": {
      "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E123"
    }
  }
}

O BPA permanece ativado no bucket. Para acesso por tempo limitado a objetos privados por um usuário específico (expiração de upload/download), gere uma presigned URL cuja assinatura embutida herda as permissões do principal que a assinou.

Caminhos de Rede Privada: Gateway Endpoints

O tráfego do EC2 para o S3 dentro de uma VPC não utiliza automaticamente o backbone privado da AWS. Sem configuração, as chamadas de API do S3 são resolvidas para endpoints públicos e atravessam o internet gateway ou o NAT gateway, incorrendo em cobranças de processamento de dados do NAT e expondo o tráfego à internet. Um gateway VPC endpoint para o S3 (e DynamoDB) é gratuito, é adicionado como uma rota de lista de prefixos (prefix-list) nas tabelas de rotas especificadas e mantém o tráfego na rede da AWS. Interface endpoints (PrivateLink) para o S3 também existem e são faturáveis, úteis quando o acesso se origina do ambiente on-premises via Direct Connect. Combine o endpoint com uma condição aws:SourceVpce na política do bucket para garantir que o bucket seja acessível apenas a partir de VPC endpoints aprovados — o padrão para cargas de trabalho regulamentadas.

Object Lambda para Transformação Dinâmica

O S3 Object Lambda insere uma função Lambda no caminho de uma requisição GET/HEAD/LIST para que o objeto retornado ao solicitante seja transformado em tempo de leitura. Isso evita a duplicação de dados para cada variante (redigida, redimensionada, reformatada) e mantém uma única fonte da verdade (source of truth) no bucket subjacente. Usos típicos: redação de PII para analistas versus dados completos para auditores, marca d’água em imagens por usuário, conversão de XML para JSON para clientes legados. As políticas do IAM e do bucket ainda controlam o acesso ao objeto subjacente; a função Lambda vê apenas o que sua execution role permite.

Notificações de Eventos

O S3 emite eventos (s3:ObjectCreated:*, s3:ObjectRemoved:*, eventos de replicação e de ciclo de vida) para o Lambda, SQS, SNS ou EventBridge. O EventBridge é preferível quando você precisa de múltiplos alvos (targets), filtragem com base em metadados de objetos ou roteamento entre contas; as notificações diretas são mais simples e baratas para pipelines de alvo único, como a geração de miniaturas (thumbnails) no momento do upload. As notificações têm garantia de entrega de “pelo menos uma vez” (at-least-once), portanto, os consumidores devem ser idempotentes.

Otimização de Taxa de Transferência: Multipart Upload e Transfer Acceleration

Para objetos com mais de 100 MB, o multipart upload é a melhor prática; para objetos com mais de 5 GB, é obrigatório. As partes são enviadas em paralelo, partes que falham são reenviadas de forma independente e a taxa de transferência (throughput) escala com a simultaneidade. Requisições GET com “byte-range” fornecem um paralelismo equivalente nos downloads. Conforme observado, sempre anexe uma regra de ciclo de vida AbortIncompleteMultipartUpload para evitar a cobrança por partes órfãs.

O S3 Transfer Acceleration roteia os uploads através do ponto de presença (edge) mais próximo do CloudFront pelo backbone da AWS — use para clientes distribuídos globalmente que fazem upload para um único bucket. Para downloads, coloque o CloudFront na frente do S3 para fazer cache no ponto de presença (edge). O Transfer Acceleration é orientado para uploads; o CloudFront é orientado para downloads; eles resolvem problemas relacionados, mas distintos.

EBS: Tipos de Volume, Criptografia e Snapshots

Volumes EBS são dispositivos de bloco no escopo de uma AZ, anexados a uma única instância EC2. O gp3 é o SSD de uso geral padrão; sua vantagem crucial sobre o gp2 é que o IOPS (até 16.000) e o throughput (vazão, até 1.000 MiB/s) são provisionados independentemente da capacidade, eliminando o antipadrão do gp2 de superprovisionar armazenamento apenas para atingir metas de desempenho. O io2 Block Express entrega até 256.000 IOPS com latência de submilisegundo para bancos de dados sensíveis à latência. O st1 e o sc1 são baseados em HDD para cargas de trabalho sequenciais e frias orientadas a throughput. O Multi-Attach em io1/io2 existe, mas é limitado a 16 instâncias na mesma AZ executando um filesystem com reconhecimento de cluster — uma exceção restrita, não um padrão geral de “EBS compartilhado”. Tentar anexar um EBS amplamente entre instâncias (por exemplo, atrás de um load balancer) é um erro de categoria que produz exatamente o sintoma de “alguns documentos visíveis ao atualizar, outros não”, porque cada volume é um dispositivo de bloco privado.

Os volumes EBS são criptografados em repouso com AES-256 usando chaves de dados encapsuladas (wrapped) pelo KMS. A criptografia é transparente — sem penalidade de desempenho, sem alterações na aplicação. Uma vez que um volume é criptografado, os snapshots e volumes derivados também são criptografados; você não pode descriptografar o volume existente (in-place). Habilite a criptografia de EBS por padrão por Região para que cada novo volume e snapshot seja criptografado, independentemente de o desenvolvedor se lembrar de ativá-la:

aws ec2 enable-ebs-encryption-by-default --region us-east-1
aws ec2 modify-ebs-default-kms-key-id \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...

Volumes não criptografados existentes não são criptografados retroativamente — a remediação exige a criação de um snapshot, a cópia com criptografia e a criação de um volume a partir do snapshot criptografado.

Snapshots são backups incrementais em nível de bloco armazenados em uma infraestrutura gerenciada pelo S3 — mas eles não são gratuitos (você paga pelos blocos alterados retidos), não desaparecem quando o volume de origem é excluído e não são removidos quando uma AMI que os referencia é desregistrada. Faça a transição deles para a camada EBS Snapshots Archive (75% mais barata, com restauração em 24 a 72 horas) via aws ec2 modify-snapshot-tier, Amazon Data Lifecycle Manager (DLM) ou AWS Backup. O Fast Snapshot Restore (FSR) pré-aquece um snapshot em AZs específicas para que as instâncias iniciadas a partir dele entreguem desempenho total imediatamente — habilite-o para AMIs atrás de grupos de auto scaling que precisam lidar com um scale-out rápido.

A Recycle Bin (Lixeira) captura snapshots de EBS e AMIs excluídos, mantendo-os em uma janela de restauração (de 1 dia a 1 ano). Sem ela, a exclusão de um snapshot é imediata e permanente:

aws rbin create-rule \
  --retention-period RetentionPeriodValue=30,RetentionPeriodUnit=DAYS \
  --resource-type EBS_SNAPSHOT \
  --description "30-day snapshot recovery"

Confiar apenas em snapshots diários do EBS para retenção de longo prazo para fins de conformidade (compliance) é um erro de arquitetura comum — os snapshots têm um preço mais próximo do armazenamento morno (warm storage) e exigem transições explícitas para arquivamento.

Amazon EFS: POSIX Compartilhado para Frotas Linux

O EFS é um sistema de arquivos NFSv4.1 totalmente gerenciado, elástico e compatível com POSIX, que pode ser montado simultaneamente a partir de milhares de clientes EC2, ECS, EKS ou Lambda em várias AZs em uma Região, e de hosts on-premises via Direct Connect ou VPN. A propriedade que o define é que o mesmo sistema de arquivos, com identificadores de arquivo (file handles) e semântica em nível de byte idênticos, é visível para todos os clientes ao mesmo tempo. Portanto, o EFS é a resposta correta sempre que uma frota de instâncias Linux atrás de um load balancer precisa compartilhar um conjunto comum de arquivos — uploads de usuários, configurações, diretórios home compartilhados.

Os mount targets (alvos de montagem) residem em cada sub-rede de AZ que você configura. O utilitário amazon-efs-utils habilita TLS em trânsito e autorização de montagem via IAM:

sudo mount -t efs -o tls,iam fs-0123456789abcdef0:/ /mnt/shared

As classes de armazenamento do EFS abrangem duas dimensões. O gerenciamento do ciclo de vida (Lifecycle management) move arquivos não acessados por 7 a 90 dias da camada Standard para a Infrequent Access e, opcionalmente, para a Archive, reduzindo o custo de armazenamento em até 92%; o Intelligent-Tiering os move de volta quando acessados. As classes One Zone armazenam os dados em uma única AZ por um custo ~47% menor — apropriado para dev/test ou dados reproduzíveis, nunca para dados cuja perda durante uma falha de AZ seja inaceitável. Uma medida de otimização de custos para uma carga de trabalho que já está no EFS Standard-IA é mudar para o EFS One Zone-IA sem qualquer alteração na aplicação.

O desempenho tem dois controles (knobs) independentes. Modo de desempenho (Performance mode) (definido na criação): o modo General Purpose tem a menor latência e é o correto para web serving com uso intensivo de metadados; o modo Max I/O é uma opção legada, substituída pelo modo Elastic. Modo de throughput (vazão): o modo Bursting escala com o tamanho (linha de base de 50 KB/s por GB, com créditos de burst quando abaixo da linha de base), o modo Provisioned paga por uma taxa fixa de MB/s, independentemente do tamanho, e o modo Elastic — o padrão atual — escala automaticamente para mais de 10 GB/s sem necessidade de planejamento de capacidade. Um sistema de arquivos pequeno sob carga sustentada pode esgotar os créditos de burst e sofrer throttling para uma linha de base baixa, portanto, cargas de trabalho com I/O intenso e pouco volume de dados (small footprints) devem usar o modo Elastic ou Provisioned.

O EFS não é um substituto para armazenamento em bloco de alto IOPS. Cada operação de I/O no EFS é uma chamada RPC do NFS pela rede, então cargas de trabalho do tipo log de transações, com um único gravador (single-writer) e latência de submilisegundo, pertencem ao EBS io2 Block Express — um único volume entrega 256.000 IOPS com latência de submilisegundo, algo que o EFS não consegue igualar por operação. O EFS também tem um preço excessivamente alto para dados frios em comparação com o Deep Archive; manter dados de conformidade (compliance) no EFS “porque é fácil” é indefensável.

FSx: Windows, Lustre, ONTAP, OpenZFS

O FSx é uma família de sistemas de arquivos gerenciados selecionados por protocolo e carga de trabalho:

O FSx for Windows File Server entrega SMB 2.0/3.1.1 nativo com NTFS ACLs, DFS Namespaces, shadow copies e Kerberos sobre o Active Directory. A implantação Multi-AZ implanta um servidor de arquivos ativo em uma AZ com um standby replicado de forma síncrona em outra e um único nome DNS de failover. A integração com o AD não é opcional: o FSx deve se juntar a um AWS Managed Microsoft AD ou a um AD autogerenciado alcançável, e os clientes se autenticam como usuários de domínio em relação aos SIDs do domínio. Pular a integração com o AD, ou apontar clientes para um sistema de arquivos em uma floresta não confiável sem uma relação de confiança entre florestas, produz o sintoma clássico de acesso negado apesar do compartilhamento estar visível. O FSx for Windows é o alvo ideal (drop-in) para a migração lift-and-shift de compartilhamentos de arquivos do Windows.

O FSx for Lustre é um sistema de arquivos POSIX paralelo para HPC, treinamento de ML, EDA e genômica — milhares de clientes, centenas de GB/s de throughput, metadados abaixo de milissegundos. Sua característica crucial na AWS é a associação do repositório de dados com o S3: as chaves dos objetos aparecem como arquivos no namespace do Lustre e são carregadas de forma preguiçosa (lazy loading) no primeiro acesso (ou pré-carregadas via

"ServerSideEncryptionConfiguration": {
  "Rules": [{
    "ApplyServerSideEncryptionByDefault": {
      "SSEAlgorithm": "aws:kms",
      "KMSMasterKeyID": "arn:aws:kms:..."
    },
    "BucketKeyEnabled": true
  }]
}

); arquivos novos/modificados são exportados de volta para o S3 de forma agendada ou sob demanda. O padrão canônico de HPC é:

1. Copiar os conjuntos de dados on-premises para o S3 (via DataSync ou Storage Gateway).
2. Criar o Lustre vinculado a esse bucket.
3. Montar em todos os workers Spot; ler entradas e escrever saídas na velocidade máxima da rede (line rate).
4. Exportar os resultados para o S3, que permanece como o repositório durável de longo prazo.
5. Excluir o sistema de arquivos Lustre quando o trabalho terminar.

As implantações Scratch do Lustre não têm replicação e perdem dados em caso de falha de hardware — a opção mais barata e rápida, apropriada para dados de trabalhos transitórios. As implantações Persistent replicam dentro de uma AZ para maior durabilidade. O throughput é provisionado em MB/s por TiB (50/125/250/500/1000), desacoplando a capacidade do desempenho.

O FSx for NetApp ONTAP é a resposta multiprotocolo: NFS, SMB e iSCSI simultaneamente sobre os mesmos dados, com snapshots, replicação SnapMirror, FlexClones e desduplicação. Escolha o ONTAP ao consolidar compartilhamentos mistos de Linux (NFS) e Windows (SMB) que precisam de acesso multiprotocolo com redundância Multi-AZ, ou ao migrar de um NetApp on-premises. O FSx for OpenZFS preenche um nicho para cargas de trabalho Linux que precisam de recursos ZFS (snapshots, clones) sobre NFS. Não confunda a força multiprotocolo do ONTAP com as outras variantes.

Escolha errado e você falhará de forma clara: EBS para uma carga de trabalho compartilhada, EFS para um compartilhamento SMB do Windows, ou Lustre para um compartilhamento Windows integrado ao AD são todos inadequados — combine primeiro o protocolo e o padrão de acesso.

Storage Gateway: Acesso Híbrido

O Storage Gateway apresenta o armazenamento em nuvem como se fosse local. Isso é diferente do DataSync, que move os dados.

Para uma aplicação de renderização que moveu sua biblioteca de mídia para o S3, mas ainda precisa de leituras de baixa latência on-premises, o S3 File Gateway é a solução ideal — acesso NFS/SMB, cache local, objetos frios buscados do S3 sob demanda. O FSx File Gateway é a resposta para escritórios filiais: um cache SMB com velocidade de LAN de um compartilhamento FSx central na nuvem, não uma solução para acesso compartilhado entre instâncias EC2 (que devem montar o FSx diretamente). O Volume Gateway se aplica quando a carga de trabalho usa iSCSI de bloco em vez de semântica de arquivo. O Tape Gateway substitui bibliotecas de fitas físicas sob o software de backup existente.

Transferência e Migração de Dados

O AWS DataSync é uma migração online baseada em agente para NFS, SMB, HDFS e object stores para o S3, EFS ou FSx — até 10x mais rápido que ferramentas de código aberto, com criptografia, verificação de integridade, agendamento e preservação de metadados POSIX e ACLs NTFS. Para uma migração SMB em larga escala com milhões de arquivos pequenos e hierarquias profundas, a resposta com menor sobrecarga é o DataSync para o FSx for Windows: o SMB é preservado, ACLs/timestamps intactos, o throughput de arquivos pequenos é tratado por meio de transferências paralelas, sem alterações na aplicação. Migrar tal conjunto de dados diretamente para o S3 é uma armadilha — o object storage lida mal com a listagem de arquivos pequenos em prefixos profundos e os clientes SMB não podem montar buckets.

A AWS Snow Family envia dispositivos físicos para transferência offline: Snowcone (até 8 TB, robusto para a borda), Snowball Edge (até ~80 TB utilizáveis, com opções de computação) e Snowmobile (escala de exabytes). Regra geral: se a transferência pela rede levaria mais de uma semana, o Snowball é mais barato e mais rápido.

A AWS Transfer Family expõe SFTP, FTPS, FTP e AS2 com S3 ou EFS como backend — a resposta certa quando parceiros externos precisam continuar usando protocolos padrão de transferência de arquivos.

AWS Backup, Cópia entre Regiões e Vault Lock

O AWS Backup centraliza políticas entre EBS, EFS, FSx, RDS, DynamoDB, S3 e mais. Um plano de backup define a programação, a retenção warm (ativa), a transição para o armazenamento cold (frio) e as ações de cópia entre Regiões/contas:

BackupPlan:
  Rules:
    - RuleName: DailyWithDRCopy
      TargetBackupVault: prod-vault
      ScheduleExpression: "cron(0 5 * * ? *)"
      Lifecycle:
        MoveToColdStorageAfterDays: 30
        DeleteAfterDays: 2555        # 7 years
      CopyActions:
        - DestinationBackupVaultArn: arn:aws:backup:eu-west-1:...:backup-vault:dr-vault
          Lifecycle:
            MoveToColdStorageAfterDays: 30
            DeleteAfterDays: 2555

A transição para o armazenamento cold exige pelo menos 90 dias de retenção warm, mais pelo menos 90 dias no armazenamento cold; ciclos de vida configurados incorretamente são rejeitados. Para uma verdadeira retenção regulatória de vários anos, combine-o com o AWS Backup Vault Lock (WORM), que impede que até mesmo administradores reduzam a retenção — satisfazendo a norma SEC 17a-4 e mandatos semelhantes. A cópia entre Regiões atende a cenários de DR regional; a cópia entre contas atende a cenários de ransomware e ameaças internas, isolando os backups do raio de alcance (blast radius) da conta de produção.

Guia de Consulta Rápida para Seleção

← Arquiteturas Serverless e Orientadas a Eventos · Todos os domínios · Transferência e Migração de Dados →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Amazon →