Serviços de Computação e Armazenamento

O Domínio 3 (Tecnologia e Serviços de Nuvem) carrega 34% da pontuação do CLF-C02, e duas de suas tarefas fazem a maior parte do trabalho: Tarefa 3.3 "Identificar serviços de computação da AWS" e Tarefa 3.6 "Identificar serviços de armazenamento da AWS". A tarefa 3.3 pede que você reconheça tipos de instância, contêineres, opções serverless, que "o auto scaling proporciona elasticidade" e os propósitos dos load balancers; a tarefa 3.6 pede que você identifique serviços de objeto, bloco e arquivo, as diferenças entre as classes de armazenamento do S3, políticas de ciclo de vida e o AWS Backup. Acrescente a metade de computação da Tarefa 4.1 do Domínio 4, as sete opções de compra, e esta única lição cobre material que aparece em dois domínios.

Nesta lição você vai:

• decifrar um nome de instância EC2 em série, geração, silício e tamanho;
• mapear as famílias de instância (M/T, C, R, I/D, P/G/F) aos seus enunciados de exame;
• percorrer a lista de verificação de inicialização: AMI, tipo de instância, par de chaves, grupo de segurança, template de inicialização;
• escolher entre as sete opções de compra com percentuais de desconto com fonte;
• fazer aritmética de Auto Scaling com min / desejado / máx e explicar por que multi-AZ é a resposta padrão de alta disponibilidade;
• precificar uma invocação de Lambda em requisições e GB-segundos e saber quando o Lambda é a resposta errada;
• definir ECS, EKS, Fargate, ECR, Batch em uma linha e depois posicionar Elastic Beanstalk e Lightsail;
• percorrer o lineup de classes de armazenamento do S3, versionamento, ciclo de vida, criptografia e hospedagem estática;
• escolher um tipo de volume EBS, explicar snapshots e separar EBS de instance store;
• comparar EFS vs FSx, posicionar Storage Gateway, conhecer o status da Snow Family e usar o AWS Backup;
• decidir S3 vs EBS vs EFS em uma tabela;
• estudar cinco estudos de caso publicados pela AWS;
• praticar com 12 questões no estilo do exame mais quatro verificações interativas.

Revisão de outubro de 2026. Além do esquema acima, esta lição agora também carrega cinco estudos de caso publicados pela AWS, uma caixa de Atualizações de 2026 com fonte, 12 questões de prática, quatro verificações interativas e oito caixas Você sabia?.

---

1. Amazon EC2: o servidor virtual que você realmente escolhe

1.1 O que é uma instância

A AWS define o bloco de construção em uma frase: "Uma instância EC2 é um servidor virtual na AWS Cloud." A Amazon EC2 "fornece capacidade de computação sob demanda e escalável", e a escolha mais consequencial que você faz na inicialização é esta: "Quando você lança uma instância, o tipo de instância que você especifica determina o hardware do computador host usado para sua instância." O tipo de instância não é, portanto, um alternador de preços: é uma decisão de hardware (geração de CPU, proporção de memória, disco local, GPU, rede) que então determina o preço.

EC2 é o exemplo clássico de IaaS no modelo de responsabilidade compartilhada: a AWS possui o host, você possui tudo a partir do sistema operacional convidado.

1.2 Decifrar um nome de instância: a habilidade de EC2 mais cobrada

A AWS publica uma gramática de nomenclatura: [série][geração][opções].[tamanho]. A primeira posição é a série (por exemplo c), a segunda é a geração (por exemplo 7), as letras depois dela são opções e tudo após o ponto é o tamanho da instância.

Letras de opção:

• a = AMD
• g = Graviton
• i = Intel
• d = volumes de instance store anexados
• n = otimizado para rede e EBS
• e = armazenamento ou memória extras
• z = alta frequência de CPU

Depois do ponto: small, large, xlarge, 2xlarge … 4xlarge, e metal significa bare metal. Duas regras de decifração que o exame adora: geração mais alta = hardware mais novo, e m7i ≠ m7g, o sufixo muda o silício e o suporte do sistema operacional, então uma opção Graviton não é um renome cosmético.

1.3 Famílias → workloads

Exemplo trabalhado E1, a família a partir do enunciado (redação com fonte, em outubro de 2026). Leia a exigência, escolha a letra e depois a opção: "um cache em memória que deve manter um conjunto de trabalho residente" → R (otimizada para memória) → acrescente g se o workload roda em Linux/Arm → r7g.xlarge. "Um transcodificador de vídeo com CPU no limite" → C → c6g.large. "Uma máquina de desenvolvimento intermitente que deve ser barata quando ociosa" → T → t3.micro. O exame nunca pede que você nomeie uma lista real de famílias de instância, ele pede que você leia o mapeamento enunciado → categoria.

1.4 Dimensionamento: quatro decisões antes de clicar em Launch

1. Formato do workload → família (equilibrado / CPU / memória / armazenamento / GPU).
2. Tamanho dentro da família → o número após o ponto; famílias otimizadas para memória também carregam um sufixo de tamanho em memória.
3. AMI: "fornece o software necessário para configurar e inicializar uma instância da Amazon EC2" e "você deve especificar uma AMI quando lança uma instância". Uma AMI é fixada a uma Região, sistema operacional, arquitetura, tipo de volume raiz e tipo de virtualização, e é por isso que você não pode lançar uma AMI de Windows em um tipo de instância Graviton.
4. Opção de compra e rede: coberto na Seção 2, mais par de chaves e grupo de segurança abaixo.

• 📚 Você sabia? O Free Tier do EC2 mudou de era em 15 de julho de 2025. Contas criadas antes dessa data mantiveram o crédito clássico, 750 horas por mês de t2.micro/t3.micro por 12 meses mais 30 GB de EBS. Contas criadas naquele dia ou depois recebem um Free plan baseado em créditos: $100 na inscrição mais até $100 extras, por 6 meses ou até os créditos acabarem, em tamanhos elegíveis como t3/t4g.micro, t3/t4g.small, c7i-flex.large e m7i-flex.large. Um enunciado que cita "750 horas de t2.micro" depende da era, leia a data (em outubro de 2026; verifique os valores atuais antes de usar).

1.5 A lista de verificação de inicialização: AMI, tipo, par de chaves, grupo de segurança

Dois fatos sobre security groups carregam peso desproporcional: eles são com estado (o tráfego de retorno é permitido automaticamente) e não podem expressar uma negação: se uma questão precisa de "bloquear este IP", a resposta é uma network ACL (nível de subnet, permite e nega, sem estado), não um security group.

Exemplo trabalhado E2, da exigência às entradas de inicialização. "Uma camada web precisa de Linux, recursos equilibrados e deve escalar em três AZs." Entradas: AMI = imagem Linux/x86 ou Arm fixada à Região; família = M (propósitos gerais) ou T (estourável, se o tráfego tem picos e a máquina deve ser barata quando ociosa); tamanho = o que o modelo de tráfego precisar; grupo de segurança permite entrada na porta 443 a partir do grupo de segurança do load balancer (não 0.0.0.0/0 diretamente), permite toda saída; mais um template de inicialização para que um grupo do Auto Scaling possa reproduzi-lo. Nada naquela lista é opcional, um grupo do Auto Scaling sem template de inicialização não pode lançar nada.

---

2. As sete opções de compra do EC2

A Tarefa 4.1 do Domínio 4 as nomeia explicitamente: "On-Demand Instances, Reserved Instances, Spot Instances, AWS Savings Plans, Dedicated Hosts, Dedicated Instances, Capacity Reservations", mais "Descrever a flexibilidade de Reserved Instances" e o comportamento de Reserved Instances em AWS Organizations. Esta tabela é a habilidade inteira.

2.1 A tabela de compra

⚠️ Reserved Instances não são servidores reservados. A própria redação da AWS é um desconto de cobrança, não uma caixa em um rack. Duas consequências que o exame testa: uma RI com escopo de AZ também reserva capacidade, uma RI com escopo de Região é apenas um desconto, e Savings Plans não reservam capacidade alguma. Se o enunciado diz "capacidade garantida na AZ X", a resposta é uma RI com escopo de AZ ou uma Capacity Reservation: nunca um Savings Plan.

2.2 Reserved Instances vs Savings Plans vs Spot, o desempate em três vias

2.3 Exemplos numéricos trabalhados: a aritmética por trás dos descontos

Exemplo trabalhado E3: economia do Spot (taxa ilustrativa; o desconto tem fonte). A AWS afirma que o Spot está disponível com "desconto de até 90% em comparação com os preços On-Demand" (em outubro de 2026). Os preços horários exatos de On-Demand do EC2 dependem da Região, do SO e do momento e não foram coletados para esta lição, então use uma taxa ilustrativa rotulada de $0.10 por hora:

Leia o teto corretamente: "até 90%" é um máximo, não uma cotação, e você paga por ele com risco de interrupção: um aviso de dois minutos, sem proteção contra terminação e sem cobertura de Savings Plan.

Exemplo trabalhado E4: economia de Savings Plan / RI (tetos com fonte, gasto ilustrativo). Pegue uma execução estável de $1.000 por mês On-Demand (base ilustrativa):

Exemplo trabalhado E5: aritmética do termo. Um termo de compromisso é muito tempo, e o exame pede que você sinta isso:

Antes de escolher um Savings Plan de 3 anos, responda uma pergunta: esta configuração exata de workload ainda estará certa em 26.280 horas? Se a resposta puder ser "vamos trocar de família ou de Região", Compute Savings Plans (qualquer família, qualquer Região) ou RIs Convertible são as respostas flexíveis; se puder ser "talvez nem precise disso", On-Demand é mais barato do que pagar por um compromisso não usado: porque uma Capacity Reservation é cobrada quer usada quer não, e um compromisso de Savings Plan simplesmente para de economizar.

• 📚 Você sabia? O percentual que você cita importa tanto quanto a opção. A AWS publica até 72% (Standard RI, EC2 Instance Savings Plan), até 66% (Compute Savings Plan, Convertible RI), até 35% (Database Savings Plans), até 64% (SageMaker AI Savings Plans) e até 90% (Spot): todos em outubro de 2026. Uma página separada de otimização de custos da AWS ainda mostra "até 75%" para Reserved Instances; esse número não é corroborado em nenhum outro lugar desta pesquisa, então não o memorize. Qualquer questão de desconto quer o nome da opção primeiro e um número com data depois.

---

3. Auto Scaling: elasticidade, min / desejado / máx, multi-AZ

A Tarefa 3.3 lista "Reconhecer que o auto scaling proporciona elasticidade", então a divisão de trabalho do exame é precisa: o Auto Scaling decide quantas instâncias existem (elasticidade), um load balancer decide para onde o tráfego vai. A AWS documenta que o Elastic Load Balancing "distribui automaticamente seu tráfego de entrada entre vários alvos … monitora a saúde de seus alvos registrados e roteia o tráfego apenas para os alvos saudáveis."

3.1 Os três números

A configuração documentada da AWS, mínimo quatro, desejado seis, máximo doze, vale a pena memorizar como um formato: min ≤ desejado ≤ máx é um invariante rígido, e qualquer opção que ponha desejado acima do máximo (ou min acima do desejado) é inválida na cara.

3.2 Por que multi-AZ é a resposta de alta disponibilidade

Um grupo do Auto Scaling abrange Zonas de Disponibilidade; quando uma AZ se degrada, o grupo lança substitutas nas AZs saudáveis e rebalanceia. Este é o padrão padrão do Domínio 3: multi-AZ = sobreviver a uma falha de AZ, multi-Região = sobreviver a uma falha de Região. A ordem do ciclo de vida também importa: uma instância vai lançamento → health check → InService, e a AWS observa que um grupo do Auto Scaling com um load balancer anexado registra a instância no load balancer antes de marcá-la InService, então o tráfego nunca alcança uma instância não pronta.

Exemplo trabalhado E6: min / desejado / máx sob pressão. Usando o grupo documentado da AWS (min 4, desejado 6, máx 12) distribuído em três AZs (2 + 2 + 2):

Dois pontos de exame caem dessa aritmética: o máximo é um teto rígido que protege seu orçamento, e o mínimo é um piso rígido que protege sua disponibilidade: nenhum substitui o outro.

---

4. AWS Lambda: serverless e orientado a eventos

A AWS define-o secamente: "AWS Lambda é um serviço de computação serverless. Com o Lambda, você pode executar código sem provisionar ou gerenciar servidores." A AWS é responsável pela "manutenção do servidor, provisionamento de capacidade, scaling e aplicação de patches": você fornece código mais configuração. Ele é orientado a eventos: "Eventos podem acionar uma função Lambda de duas maneiras: por invocação direta (push) e por event source mappings (pull)."

4.1 O que o Lambda realmente cobra

A orientação da AWS sobre aderência é direta: o Lambda é "mais adequado para invocações curtas que duram um segundo ou menos." Processos com estado, longevos ou sempre ativos são a resposta errada clássica.

Exemplo trabalhado E7: uma micro-fatura de Lambda (taxas com fonte, em outubro de 2026). 2.000.000 de requisições por mês, cada uma executando 100 ms em 1.024 MB (1 GB):

Exemplo trabalhado E8, o teto Always Free (com fonte). Quanto tempo contínuo de execução os 400.000 GB-segundos realmente compram?

A lição que o exame quer: ocioso custa nada, rodar custa GB-segundos. Uma função que roda uma vez por dia por 50 ms é quase de graça; a mesma lógica que torna o Lambda barato o torna a casa errada para um processo que precisa manter estado por horas.

• 📚 Você sabia? O estudo de caso da Capital One sobre Lambda e ECS relata que uma aplicação cortou seu custo em 90% após migrar para o Lambda, com verificações 80% mais rápidas usando AWS Step Functions, e descreve mais de um terço das aplicações da Capital One como serverless (aws.amazon.com/solutions/case-studies/capital-one-lambda-ecs-case-study, acesso em outubro de 2026; alegação do cliente, não auditado). A leitura no formato do exame é arquitetural: orientado a eventos mais ocioso-custa-nada é por que um workload pertence ao Lambda, e um número como 90% é o resultado daquele cliente, nunca uma garantia da AWS.

---

5. Contêineres: ECS, EKS, Fargate e ECR

A Tarefa 3.3 espera quatro definições de uma linha, e o exame as recombina constantemente:

Duas distinções de responsabilidade carregam a maior parte das notas. Fargate vs launch type EC2 é sobre quem gerencia os nós, não sobre velocidade: com Fargate não há instâncias para aplicar patches (cobrança por tarefa, mínimo de 1 minuto); com o launch type EC2 você aplica patches, escala e escolhe instâncias, e descontos de RI/Savings Plan/Spot se aplicam àquelas instâncias. ECS vs EKS é sobre portabilidade vs uma taxa de clúster: ECS é nativo da AWS sem taxa de orquestração; EKS te dá o Kubernetes padrão por uma taxa horária por clúster.

Exemplo trabalhado E9: aritmética de Fargate e EKS (taxas com fonte, us-east-1, em outubro de 2026).

Aquela comparação é a questão de contêiner favorita do exame: EKS custa extra pelo plano de controle gerenciado; ECS não, e nenhum dos dois inclui o custo dos seus nós.

• 📚 Você sabia? A startup de IA de Toronto WOMBO contou à AWS que gerenciava 12.000 GPUs enquanto seus aplicativos tinham 74 milhões de downloads em 10 meses em mais de 180 países, citando: "Nossa infraestrutura tem estado em grande parte no piloto automático. Usar a Amazon ECS economiza definitivamente muito tempo para nós." (aws.amazon.com/ecs/customers e aws.amazon.com/fargate/customers, acesso em outubro de 2026; voz do cliente). O detalhe no formato do exame é a dupla por trás dessa citação, ECS como o orquestrador nativo da AWS com Fargate como o mecanismo serverless, mais o lembrete de que escala viral chega primeiro como um problema de tráfego, que a elasticidade (Seção 3) absorve muito antes de virar um problema de compra (Seção 2).

---

6. Elastic Beanstalk e Lightsail: PaaS e VPS

O arco esperado no exame é começar simples e depois crescer: um blog pessoal ou uma pequena ferramenta interna começa no Lightsail ou no Elastic Beanstalk; quando você precisa de Auto Scaling, rede em nível de VPC, Spot ou Savings Plans, você migra para EC2 com um template de inicialização e um grupo do Auto Scaling. O AWS Batch é a quarta opção nesta família: trabalhos conteinerizados enfileirados que a AWS escala para você em capacidade Spot ou On-Demand.

---

7. Amazon S3: armazenamento de objetos, classes, versionamento, ciclo de vida

A Tarefa 3.6 abre com "Identificar os usos do armazenamento de objetos" e "Reconhecer as diferenças entre as classes de armazenamento do Amazon S3". A AWS define a anatomia: "Um objeto é um arquivo e quaisquer metadados que descrevem o arquivo. Um bucket é um contentor de objetos." Os objetos são endereçados por chave (mais um ID de versão opcional) dentro de um bucket cujo nome é globalmente único e cuja Região é fixada na criação. Um bucket é privado por padrão, com Block Public Access ligado e ACLs desligadas; o teto da bucket policy é 20 KB. O tamanho máximo do objeto é 50 TB (elevado de 5 TB em 2 de dezembro de 2025); um único PUT é 5 GB.

Durabilidade é o número a citar: 99,999999999% (11 nonos) em um mínimo de três Zonas de Disponibilidade por padrão: durabilidade e disponibilidade são coisas diferentes, e o One Zone-IA prova isso.

7.1 O lineup de classes de armazenamento

Intelligent-Tiering é a única classe que move objetos para você: 30 dias sem acesso → camada Infrequent Access, 90 dias → Archive Instant Access (ainda em milissegundos), mais camadas Archive opt-in (≥90 dias) e Deep (≥180 dias). Ela cobra uma taxa de monitoramento de $0.0000025 por objeto por mês e sem taxas de recuperação, então é perfeita para padrões desconhecidos e errada para milhões de objetos minúsculos.

Velocidades de recuperação do Glacier (em outubro de 2026): Instant = milissegundos; Flexible = Expedited 1 to 5 minutos, Standard 3 to 5 horas, Bulk 5 to 12 horas e grátis; Deep Archive ≈ 12 horas / 48 horas. Note que a AWS diz "Não recomendamos usar o serviço Amazon Glacier": a resposta examinável é as classes de armazenamento S3 Glacier, não um serviço legado separado.

7.2 Versionamento, ciclo de vida e replicação

• Versionamento tem três estados (desabilitado, habilitado, suspenso) e "nunca pode voltar a um estado sem versionamento". Excluir um objeto cria um marcador de exclusão; sobrescrever cria uma nova versão; cada versão é cobrada integralmente, e é por isso que regras de ciclo de vida precisam de uma ação NoncurrentVersionExpiration.
• Regras de ciclo de vida têm ações de transição (mover para outra classe) e ações de expiração: "o Amazon S3 exclui objetos expirados em seu nome". O modelo é uma cachoeira de sentido único: Standard → IA / Intelligent-Tiering / One Zone-IA → qualquer classe Glacier; One Zone-IA → apenas Glacier; Instant → Flexible → Deep; Deep Archive só pode ir em um caminho.
• Replicação (CRR/SRR) exige versionamento habilitado em ambos os buckets, pula objetos pré-existentes a menos que você use Batch Replication, e o S3 Replication Time Control garante 99,99% dos novos objetos em 15 minutos (SLA). Exclusões são replicadas, então replicação não é backup.

7.3 Criptografia e sites estáticos

SSE-S3 é a configuração de criptografia padrão de todos os buckets (desde 5 de janeiro de 2023) e não custa nada extra; SSE-KMS acrescenta custo e controle por chave, SSE-C traz sua própria chave, e DSSE-KMS é criptografia dupla. Para EBS você não pode criptografar no lugar um volume ou snapshot não criptografado existente. Para hospedagem: um site estático no S3 precisa de um index document, Block Public Access desligado e uma permissão pública de leitura s3:GetObject, e "sites estáticos suportam apenas endpoints HTTP", então HTTPS requer CloudFront.

Exemplo trabalhado E10: um terabyte-mês entre classes (us-east-1, em outubro de 2026). Só armazenamento, 1.000 GB, ignorando requisições:

Preços de requisição do S3 (mesma Região e data): PUT/COPY/POST/LIST $0.005 por 1.000, GET $0.0004 por 1.000, DELETE grátis.

• 📚 Você sabia? A regra dos 30 dias tem duas metades que mudaram independentemente. As orientações de armazenamento da AWS (atualizadas em 5 de outubro de 2026) dizem que o S3 "não se aplica mais a um armazenamento mínimo de 30 dias para transições" para Standard-IA e One Zone-IA: você pode transicionar no dia 0. Mas a regra de faturamento de duração mínima de armazenamento de 30 dias para classes IA ainda é publicada nas páginas de preços. Mover no dia 10 e excluir no dia 20 ainda te cobra os 30 dias inteiros (em outubro de 2026; verifique os valores atuais antes de usar).

---

8. Amazon EBS e instance store: armazenamento de bloco

A Tarefa 3.6 nomeia o par: "Identificar soluções de armazenamento de bloco (por exemplo, Amazon EBS, instance store)". Armazenamento de bloco é armazenamento de sistema de arquivos do SO, de baixa latência e de anexação única, o disco que sua instância vê como /dev/xvda.

Amazon EBS é um "volume de bloco durável" para o EC2. Dois fatos estruturais: um volume tem escopo de uma Zona de Disponibilidade (ele é "replicado automaticamente dentro de sua Zona de Disponibilidade") e pode ser anexado a até 16 instâncias apenas se forem io1/io2 na mesma AZ (Multi-Attach, e o aplicativo precisa fazer fencing de escritas). A durabilidade não é a dos 11 nonos do S3: io2 Block Express oferece 99,999%, outros tipos de volume 99,8% a 99,9%.

8.1 Tipos de volume

Preços de tabela publicados: gp3 $0.08/GB-mês, gp2 $0.10, io1/io2 $0.125 (mais cobranças de IOPS), st1 $0.045, sc1 $0.015: publicados em outubro de 2026; a página não declara Região, então verifique os valores atuais antes de usar em sua Região.

8.2 Snapshots

Um snapshot é um "backup incremental" armazenado no S3, mas invisível às ferramentas do S3: você não pode ver snapshots como objetos do S3, listá-los em um bucket, nem pagar tarifas de requisição do S3 por eles. Eles são replicados em toda a Região (diferente dos volumes, que são limitados à AZ). Criticamente, "a AWS não faz backup automático de seus volumes EBS", você deve usar o Amazon Data Lifecycle Manager, o AWS Backup ou um script manual. Preços de snapshot (em outubro de 2026): $0.05 por GB-mês padrão, $0.0125 por GB-mês arquivado (mínimo de 90 dias), restauração do arquivo $0.03 por GB.

8.3 Instance store vs EBS

Exemplo trabalhado E11: gp3 vs gp2 e arquivo de snapshot (preços publicados, verifique a Região).

• 📚 Você sabia? A linha de base do gp3 é independente do tamanho: 3.000 IOPS e 125 MiB/s "em qualquer tamanho de volume". No modelo mais antigo do gp2 você precisava de um volume de 3.000 GB para conseguir 3.000 IOPS, porque os IOPS escalavam a 3 por GB, e é por isso que a AWS descreve o gp3 como "preços até 20% menores por GB em comparação com o gp2 existente" sendo também mais rápido fora da caixa (em outubro de 2026).

---

9. Arquivo, híbrido e backup: EFS, FSx, Storage Gateway, Snow Family, AWS Backup

9.1 EFS versus FSx: a resposta de arquivo

A Tarefa 3.6 diz "Identificar serviços de arquivo (por exemplo, Amazon EFS, Amazon FSx)".

A durabilidade do EFS é de 11 nonos com disponibilidade de 99,99% na classe Regional em ≥3 AZs; suas classes de ciclo de vida Standard → IA → Archive aplicam automaticamente após 90 dias ociosos, com duração mínima de armazenamento de 90 dias para o Archive.

Exemplo trabalhado E12: dimensionamento de EFS (us-east-1, em outubro de 2026).

9.2 Storage Gateway: a resposta híbrida, em cache

A AWS descreve-o como um serviço que "conecta um appliance de software on-premises com armazenamento baseado em nuvem", e a tarefa 3.6 nomeia explicitamente "sistemas de arquivos em cache (por exemplo, AWS Storage Gateway)".

9.3 Snow Family, o status importa mais que as especificações

O AWS Snowball Edge não está mais disponível para novos clientes, fechou para novos clientes em 7 de novembro de 2025, e a AWS afirma: "Em 31 de dezembro de 2026, a AWS encerrará o suporte aos dispositivos AWS Snowball em todas as Regiões comerciais da AWS." O próprio dispositivo oferecia cerca de 210 TB em uma unidade Storage Optimized, com trabalhos de transferência concluídos em até 360 dias. Criticamente, a Snow Family não aparece nem na lista no escopo nem na lista fora do escopo no guia atual do CLF-C02, então ela é contexto, nunca uma resposta correta. As alternativas direcionadas da AWS para grandes transferências offline são AWS DataSync, Data Transfer Terminal e AWS Outposts.

9.4 AWS Backup: um mecanismo de políticas para tudo

A Tarefa 3.6 nomeia "Compreender casos de uso do AWS Backup". É um serviço de backup central, orientado a políticas: planos selecionam recursos (tipicamente por tag), cofres (vaults) guardam as cópias (criptografadas com KMS), e o AWS Backup Vault Lock fornece proteção write-once-read-many (WORM). Os backups são incrementais e podem mover warm → cold, rodar entre Regiões e entre contas, e relatar pelo AWS Backup Audit Manager. Ele cobre EC2/EBS, S3, EFS, FSx, RDS, DynamoDB e volumes do Storage Gateway, mas ele "não governa backups que você faça … fora do AWS Backup", e é aditivo: ele duplica mecanismos nativos de snapshot, então custa dinheiro além deles.

Números de retenção (em outubro de 2026): 1 dia a 100 anos para snapshots; 1 a 35 dias para PITR contínuo; mínimo de 90 dias no cold tier; um recurso deve ficar no warm por pelo menos 8 dias antes de ir para o cold. Serviço companheiro: o AWS Elastic Disaster Recovery faz "replicação contínua em nível de bloco" com um RPO de segundos e um RTO tipicamente de 5 to 20 minutos: a resposta de piloto leve para servidores inteiros.

Exemplo trabalhado E13: aritmética de retenção de backup (regra com fonte). Backups no cold tier devem ser retidos pelo menos 90 dias após a transição para o cold, e a retenção no warm deve ser ≥8 dias:

• 📚 Você sabia? AWS Backup e snapshots nativos resolvem problemas diferentes. Um snapshot é um mecanismo (incremental, em toda a Região, $0.05/GB-mês em outubro de 2026); o AWS Backup é governança: seleção baseada em tag entre contas, um cronograma de retenção único, Vault Lock para conformidade WORM e cópias entre Regiões. Uma pergunta pedindo "como aplicar uma política de backup em 40 contas" está pedindo AWS Backup, não um script que chama CreateSnapshot 40 vezes.

---

10. S3 vs EBS vs EFS: a tabela de decisão

Os três modelos de dados da Tarefa 3.6 são o caminho mais rápido para pontuar aqui: bloco = baixa latência, uma instância/contêiner; arquivo = hierárquico, compartilhado, NFS/SMB; objeto = endereçado por API, chave + metadados, o mais barato em escala.

Regra prática reutilizável: uma instância e um sistema de arquivos do SO → EBS; muitas instâncias precisam dos mesmos arquivos → EFS/FSx; qualquer coisa que você enviaria por e-mail, hospederia estaticamente ou arquivaria → S3; on-premises sem re-arquitetura → Storage Gateway; uma política única entre serviços, baseada em tag e com capacidade WORM → AWS Backup.

Atualizações de 2026 (em outubro de 2026)

---

Casos Reais

A AWS publica como esses padrões parecem em produção. Todo valor abaixo é alegação do cliente ou da AWS, não auditado, citado com sua fonte para que você possa verificar, o ponto examinável é o padrão (qual opção de compra foi escolhida, qual camada de armazenamento foi movida, qual número), não o marketing.

Caso A, NASA JPL: Auto Scaling com Spot, On-Demand e Capacity Reservations

Lição de exame: a resposta para "qual opção de compra" frequentemente é uma mistura, não uma opção só. Os 90% do Spot são um teto, e ele só funciona onde o trabalho é tolerante a falhas e tem checkpoints: que é exatamente por que o processamento estilo HPC da NASA é elegível e um banco de dados transacional com estado não é.

Caso B, Box: otimização de custos do Well-Architected, majoritariamente no armazenamento

Lição de exame: este é o pilar de custo do Domínio 4 expresso em serviços do Domínio 3. "Movemos objetos infrequentes para uma classe mais fria e arrumamos snapshots do EBS" é a mesma decisão das nossas tabelas das Seções 7 e 8, e note que a alavanca gratuita (melhor prática de arquitetura, revisão do Well-Architected) produziu a maior parte da economia.

O que os dois casos têm em comum

• 📚 Você sabia? O próprio Amazon S3 é um estudo de caso de 20 anos: a AWS o lançou em 14 de março de 2006 com cerca de 1 PB de capacidade em cerca de 400 nós de armazenamento em 15 racks, um tamanho máximo de objeto de 5 GB e um preço de 15 centavos por gigabyte; a AWS relatou em 13 de março de 2026 que o preço de hoje é "um pouco mais de 2 centavos por gigabyte", cerca de uma redução de 85%, enquanto "o código que você escreveu para o S3 em 2006 ainda funciona hoje, inalterado" (aws.amazon.com/blogs/aws, acesso em outubro de 2026). O tamanho máximo de objeto atual é 50 TB, um aumento de 10× feito em 2 de dezembro de 2025.

Três histórias adicionais publicadas pela AWS seguem, e a cautela acima governa todos os números delas.

Caso C, Canva: um workload, três opções de compra

Lição de exame: este é o desempate da Seção 2 executado como modelo operacional, e note que a Canva manteve Reserved Instances como fallback em vez de primeira escolha, o que espelha a orientação atual da AWS de preferir Savings Plans sobre Reserved Instances. Os 46% são o resultado medido da Canva; a AWS nunca os garante.

Caso D, Shutterfly Business Solutions: 400 TB de objetos mais um lift-and-shift de serviço de arquivo

Lição de exame: o FSx aparece em uma migração real exatamente como o enunciado que a Seção 9.1 ensina, "lift-and-shift de um serviço de arquivos existente", enquanto o corte de ~25% de opex vindo de right-sizing e evitação de licenças é o pilar de custo do Domínio 4 aparecendo dentro de uma migração do Domínio 3. A ponte VMware foi um passo, não o destino: o estado final era AWS nativa.

Caso E, FarEye: três alavancas de computação empilhadas em uma história

Lição de exame: −65% é o resultado da FarEye, nunca uma garantia da AWS, e as economias do Graviton não são de graça, o g em c7g significa imagens e código compatíveis com Arm (Seção 1.2), então "só mover tudo para o Graviton" ignora completamente a armadilha de compatibilidade.

Onde as cinco histórias se encaixam nesta lição

Todos os valores acima são alegações de clientes ou publicações da AWS, não auditados (acesso em outubro de 2026): atribua-os ao estudo de caso, nunca a uma garantia da AWS.

---

Perguntas de Prática (Practice Questions)