Solução de Problemas, Desempenho e Otimização de Custo

O Domínio 3 do DEA-C01 é Operações e Suporte de Dados, 22% do exame, e suas declarações de tarefa dizem a mesma coisa de quatro formas diferentes: troubleshoot performance issues (3.3.4), troubleshoot and maintain pipelines such as AWS Glue and Amazon EMR (3.3.6), analyze logs with AWS services (3.3.8) e implement data skew mechanisms (3.4.5). O custo fica ao lado delas na 2.1.1, escolha serviços de armazenamento para requisitos específicos de custo e desempenho, e na 3.2.5, descreva trade-offs entre serviços provisionados e serverless. Esta lição é a união dessas habilidades: um loop de triagem repetível, um mapa sintoma→causa→correção por serviço, e a aritmética que transforma "torne isso mais barato" em uma resposta defensável.

Nesta lição você vai:

• rodar um loop de triagem de quatro etapas e uma taxonomia de falhas cobrindo drift de esquema, arquivos corrompidos, OOM, timeout, IAM, throttling, small files e encoding com sintoma→causa→correção por serviço;
• dimensionar o AWS Glue: tipos de DPU e worker, aritmética de partições, auto scaling, flexible execution, modos de falha de bookmark, repartition versus coalesce e fusão de small files;
• diagnosticar o Amazon Redshift: erros de distribution e sort key, triagem de skew com SVV_TABLE_INFO, VACUUM/ANALYZE automáticos e ATO, WLM e query monitoring rules, pruning do Spectrum e leitura de um plano EXPLAIN;
• dimensionar corretamente o Amazon EMR: papéis de nó primário/core/task, aritmética de contagem de nós, nós de tarefa Spot, HDFS versus S3 e quando o EMR Serverless é a resposta;
• consertar o Amazon Kinesis Data Streams: hot shard versus hot key, redesenho da partition key, alarmes de idade do iterador e os três modos de capacidade;
• operar o AWS Lambda: pools de concorrência, reserved versus provisioned concurrency, timeouts, reprocessamentos assíncronos e dead-letter queues;
• aplicar uma tabela de alavancas de custo por serviço, uma tabela de trade-offs entre custo e desempenho e as heurísticas de enunciado MAIS eficiente operacionalmente / MENOS custoso;
• resolver sete exemplos trabalhados: aritmética de partição e custo do Glue, triagem de skew do Redshift, um exercício de EXPLAIN, dimensionamento de nós do EMR, custo de shard do Kinesis, concorrência do Lambda e custo de provisioned concurrency, e custo de requisições do S3;
• ler a caixa de atualizações de outubro de 2026, quatro estudos de caso de clientes da AWS e terminar com quatro questões estilo exame mais três verificações interativas.

---

1. O loop de triagem e a taxonomia de falhas

1.1 Quatro etapas, em ordem

A própria orientação de troubleshooting da AWS é direta: comece no Error log da execução do job e depois vá para a aba Executors / UI do Spark para ver qual executor morreu e quando (orientação de troubleshooting e Builder do AWS Glue, acesso em outubro de 2026).

1.2 Sintoma → causa → correção, por serviço

Esta tabela é o núcleo examinável da Habilidade 3.3.4. Cada linha é um modo de falha da AWS documentado com a correção que a AWS documenta para ele (documentação de troubleshooting do AWS Glue, diagnóstico do Redshift e troubleshooting de EMR/Kinesis/Lambda, acesso em outubro de 2026).

1.3 A árvore de decisão das falhas

1.4 Verificação interativa: combine o sintoma com a correção

• 📚 Você sabia? Um job do Glue pode reportar SUCCEEDED sem gravar nada: um bookmark que já registrou os arquivos de origem os pulará na próxima execução, e um prefixo errado ou um caminho morto do catálogo parecem idênticos a uma partição vazia saudável. A própria lista de troubleshooting da AWS portanto coloca "sucesso sem dados" ao lado de erros reais: a correção é uma verificação de timestamp, não um stack trace (guia de troubleshooting do AWS Glue, acesso em outubro de 2026).

---

2. Falhas de formato dos dados: drift, arquivos corrompidos, encoding

2.1 Drift de esquema é um problema de versão, não de parse

Quando um time upstream adiciona, remove ou troca o tipo de uma coluna, três coisas acontecem em sequência: a fonte muda, a tabela do Glue ganha uma nova versão no Data Catalog, e todo consumidor a jusante (crawler, query do Athena, schema externo do Redshift, dataset do QuickSight) herda a mudança em silêncio. O padrão da AWS para isso é: difar as versões da tabela → publicar num tópico SNS → evoluir o consumidor antes que os dados cheguem (AWS Big Data Blog, "Identify source schema changes using AWS Glue", 14-09-2022).

Dentro do próprio job, um DynamicFrame representa "algumas linhas têm esta coluna, outras não" como um tipo de escolha. O reparo documentado é resolveChoice, que ou faz cast (você nomeia o tipo: valores não conversíveis viram NULL) ou make_cols (acrescenta uma coluna anulável). Estreitamente relacionado: o crawler reporta "Partitions were not updated" quando o esquema do DynamicFrame de entrada não é idêntico a, ou um subconjunto de, o esquema do catálogo e updateBehavior não é UPDATE_IN_DATABASE.

2.2 Registros corrompidos: rejeite alto ou ponha em quarentena

Linhas CSV malformadas que "cabem" no esquema inferido são descartadas em silêncio. O remédio documentado é errorsAsDynamicFrame(), que divide o frame em um frame bom e um frame de rejeição, mais as contagens stageThreshold / totalThreshold que falham o job quando as rejeições excedem um orçamento. O padrão operacional da Lição 11 completa isso: grave as rejeições num prefixo de quarentena com _dq_rule, _dq_reason e _run_id, e alerte sobre a contagem. O leitor CSV vetorizado é uma armadilha específica: ele não lida com multiLine nem conteúdo multibyte, então "erros de parse que só aparecem em algumas linhas" geralmente significa "use o leitor baseado em linhas".

2.3 Encoding

Divergências de charset aparecem como caracteres corrompidos, campos truncados ou linhas que quebram na vírgula errada. Defina encoding nas opções de formato do Glue, evite o leitor vetorizado para dados multibyte e coloque uma regra de encoding do DataBrew antes do load em vez de limpar mojibake no warehouse. Encoding é um contrato origem-destino e, assim como o drift de esquema, é invisível nas contagens de linhas: que é exatamente por que os dois pertencem à taxonomia e não a um capítulo lateral de "qualidade de dados".

---

3. Desempenho do AWS Glue: DPU, workers, bookmarks, small files

3.1 O que você realmente está pagando

Um DPU = 4 vCPUs de capacidade de computação e 16 GB de memória (documentação de tipos de worker do AWS Glue, acesso em outubro de 2026). Jobs do Glue 2.0+ são dimensionados com WorkerType + NumberOfWorkers, não existe MaxCapacity em versões modernas, e um executor do Spark roda por nó worker, em todos os tipos G e R.

Regra de dimensionamento do guia de tuning do Prescriptive Guidance: escale horizontalmente (mais workers) apenas "até observar workers ociosos: além disso, acrescentar mais workers aumenta custos sem melhorar resultados", e escale verticalmente (tipo maior) para transformações pesadas de memória, agregações com skew e planos grandes de driver.

3.2 Aritmética de partições: a conta que o exame pode pedir você refazer

Para Glue 3.0+:

Partições iniciais a partir do S3: para objetos ≤ 64 MB, conte os objetos; para > 64 MB, use size / 64 MB; gzip não dividível conta como uma task por objeto: um único .csv.gz de 10 GB é 1 task, não importa quantos workers você compre. Partições demais explodem o driver e o agendador de tasks, então conserte-as com groupFiles, coalesce(N) (sem shuffle completo, então mais barato que repartition) ou o coalescing do AQE do Spark 3.

3.3 Auto scaling, flexible execution e AQE

• Auto scaling (--enable-auto-scaling=true, Glue 3.0+, todos os tipos G/R): o Glue adiciona e remove workers por estágio até NumberOfWorkers como máximo, e também define spark.sql.shuffle.partitions e spark.default.parallelism a partir desse máximo: sobrescreva com --conf se sua carga for irregular.
• Flexible execution (Glue 3.0+, somente G.1X e G.2X, jobs não urgentes): uma DPU-hora com desconto em troca de um horário de início variável. Pré-produção e backfills noturnos são o caso de uso documentado.
• AQE está ligado por padrão no Glue 4.0; no 3.0 defina spark.sql.adaptive.enabled=true. Ele coalesca partições de shuffle, converte sort-merge join em broadcast e lida com skew com skewedPartitionFactor / skewedPartitionThresholdInBytes.
• Escalar horizontalmente não é linear. O próprio exemplo de métricas trabalhado da AWS (10 → 55 DPU corta o tempo pela metade, 55 → 100 DPU não acrescenta nada porque os executors ficam ociosos) vem de uma página aplicável apenas ao Glue 0.9/1.0: leve o método ("acrescente workers apenas até ficarem ociosos"), nunca os minutos absolutos.

3.4 Exemplo trabalhado E1: aritmética de partição e custo do Glue

3.5 Bookmarks: o modo de falha mais errado deste exame

A AWS documenta sete maneiras de um job com bookmark reprocessar dados: MaxConcurrency > 1, job.init() / job.commit() ausentes, transformation_ctx ausente ou renomeado, chave primária JDBC não sequencial, hora da última modificação alterada, entrada Spark DataFrame em vez de DynamicFrame e caminho de origem alterado sob o mesmo contexto. Duas frases cobrem a maioria dos itens de exame:

• "Atualmente os bookmarks do AWS Glue não suportam execuções concorrentes de job e os commits falharão.": mantenha Max concurrent runs = 1.
• "Se você não passar o parâmetro transformation_ctx, então os job bookmarks não são habilitados para um dynamic frame ou uma tabela usada no método.": bookmarks rastreiam operações de DynamicFrame, e rastreiam origens, não destinos: um rewind ou reset nunca apaga o que já foi gravado, então reproduza num novo prefixo de destino.

3.6 repartition versus coalesce, e fusão de small files

4. Amazon Redshift: distribution, skew, manutenção, planos

4.1 Três doenças, três tratamentos

Questões de desempenho do Redshift quase sempre se resolvem em um de três problemas no nível da coluna, e cada um tem uma cura diferente (AWS Redshift Identifying tables with data skew or unsorted rows, acesso em outubro de 2026).

A manutenção automática está ligada por padrão: o analyze automático roda em janelas de carga leve com analyze_threshold_percent = 10 %, o auto vacuum de sort/delete pausa sob carga alta ou locks DDL exclusivos, e a otimização automática de tabelas (ATO) aplica sort e distribution keys em tabelas AUTO em poucas horas de ver suficientes queries. Audite com SVV_ALTER_TABLE_RECOMMENDATIONS e SVL_AUTO_WORKER_ACTION. Fatos-chave que o exame reutiliza: chaves explícitas de sort/distribution tiram a tabela da automação, e o VACUUM pula a fase de sort por padrão quando mais de 95 % das linhas já estão ordenadas.

4.2 Exemplo trabalhado E2: triagem de skew em quatro queries

Depois refaça o EXPLAIN e procure a tag de redistribuição que você quer: DS_DIST_NONE / DS_DIST_ALL_NONE.

4.3 Fundamentos do EXPLAIN: leia o plano antes de redimensionar o cluster

Tags de redistribuição: DS_DIST_NONE e DS_DIST_ALL_NONE são boas; DS_BCAST_INNER é bom para uma dimensão pequena e não é automaticamente ruim; DS_DIST_INNER / DS_DIST_OUTER são custosos; DS_DIST_ALL_INNER serializa a execução num único slice; DS_DIST_BOTH é o pior. Se o planner escolher uma direção de join que parece errada, a causa documentada é estatística velha: rode ANALYZE.

4.4 Exemplo trabalhado E3, o plano que a própria AWS usa no treinamento

Duas lições examináveis: o nome do operador diz a estratégia, a estimativa de custo diz se importou, e nenhum dos dois exige um cluster maior (AWS Prescriptive Guidance, "Evaluating the query plan", acesso em outubro de 2026).

4.5 Gestão de carga de trabalho, concurrency scaling e Spectrum

• WLM: o padrão é 1 fila com 5 queries concorrentes. O WLM automático cria até 8 filas (service classes 100 to 107) cada uma com uma priority (NORMAL padrão; CRITICAL é só para superusuário). O WLM manual permite concorrência 1 to 50 por fila, 50 slots no total, com uma porcentagem de memória por fila.

• Query monitoring rules rodam a cada 10 s. Severidade da ação: log < hop (somente WLM manual, e apenas para queries CTAS/somente leitura) < abort (nunca para COPY, ALTER, ANALYZE ou VACUUM) < change priority (somente WLM automático). Templates para decorar: spill query_temp_blocks_to_disk > 100000 blocos (100 GB) e I/O skew io_skew > 1.30.

• Os timeouts do WLM cobrem apenas a fase em execução: esperas de fila, lock, compilação e hop ficam fora deles.

• Concurrency scaling roteia queries excedentes para clusters transitórios em vez de enfileirar, por fila (auto/off), com 1 hora grátis a cada 24 horas e max_concurrency_scaling_clusters de 1 to 10. Ele alivia enfileiramento, não a pressão de memória por query.

• Spectrum cobra US$ 5,00 por TB varrido (mínimo de 10 MB por query, em outubro de 2026), então o pruning é uma alavanca de custo tanto quanto de velocidade: particione pelos predicados que você realmente filtra, use Parquet/ORC para eliminação de colunas, mantenha arquivos ≥ 64 MB e defina TABLE PROPERTIES (numRows = n) porque o Redshift nunca analisa tabelas externas e caso contrário assume que a tabela externa é a maior tabela do plano. Verifique com SVL_S3PARTITION (assigned_partitions versus qualified_partitions), SVL_S3QUERY_SUMMARY (s3_scanned_*) e marcadores do EXPLAIN (S3 Seq Scan, Partition Loop). DISTINCT e ORDER BY nunca são empurrados para baixo.

• 📚 Você sabia? Uma tabela do Redshift pode estar 86 % não ordenada e apenas 5 % melhorável: vacuum_sort_benefit existe justamente para que você não pague por um VACUUM que não muda nada, e por padrão o VACUUM pula a fase de sort completamente acima de 95 % de linhas ordenadas. É por isso que "rode VACUUM após cada load" é um distractor, não uma melhor prática (documentação de vacuuming do AWS Redshift, acesso em outubro de 2026).

---

5. Amazon EMR: dimensionamento, nós de tarefa Spot, HDFS versus S3

5.1 Três papéis de nó, três decisões de compra

A própria regra da AWS: "Use instâncias Spot em nós de tarefa. Os nós de tarefa processam dados mas não guardam dados persistentes no Hadoop Distributed File System (HDFS). Se os nós de tarefa forem desligados… nenhum dado é perdido." All-Spot é apenas para jobs transitórios e tolerantes a perdas. Repare no comportamento assimétrico do Spot: instâncias de task-Spot lançam conforme a capacidade fica disponível, enquanto core-Spot espera todas as instâncias solicitadas antes de lançar, e o reclaim do Spot permite cerca de 20 s de desligamento gracioso (spark.decommissioning.timeout.threshold, EMR ≥ 5.11.0).

5.2 Exemplo trabalhado E4: contagem de nós e capacidade de HDFS

HDFS versus S3 para fins de exame: S3/EMRFS é durável, desacoplado, sobrevive à terminação do cluster e custa menos por GB → é o padrão do pipeline; HDFS é mais rápido para shuffle intermediário mas consome o orçamento de replicação e morre com o cluster. No EMR, adaptive query execution está ligado por padrão (5.30+) com coalescing de partições de shuffle (tamanho advisory 64 MB, minPartitionNum 25, initialPartitionNum 1000), dynamic partition pruning (5.26+) e spark.default.parallelism = 2 × YARN cores.

5.3 EMR Serverless: a opção sem dimensionamento

O EMR Serverless cobra por vCPU-hora e GB-hora mais GB-hora de armazenamento, US$ 0,052624 / vCPU-hora, US$ 0,0057785 / GB-hora, US$ 0,000111 / GB-hora de armazenamento (em outubro de 2026), e os workers fazem auto scaling entre o mínimo e o máximo do job, então a decisão de dimensionamento desaparece. É a escolha natural para jobs intermitentes de Spark/Hive onde um cluster ficaria ocioso.

---

6. Amazon Kinesis Data Streams: hot shards, idade do iterador, modos de capacidade

6.1 Hot shard versus hot key: a distinção mais testada de todas

Limites por shard são 1 MB/s de escrita e 1.000 records/s, 2 MB/s e 2.000 records/s de leitura e 5 TPS de leitura; um único registro pode ter 10 MiB e o PutRecords aceita até 500 records / 10 MiB por chamada (limites do AWS Kinesis, acesso em outubro de 2026).

• Hot shard = muitas keys caindo desigualmente → divida o shard (no provisionado UpdateShardCount / SplitShard) ou deixe o on-demand dividir.
• Hot key = uma key excedendo o limite de um shard → redesenhe a partition key (sufixo UUID ou composto) ou, se você precisa de ordenação/localidade por key, mantenha a key e aceite o teto.
• Acrescentar shards não conserta uma hot key: todo registro de uma key cai no mesmo shard, para sempre. E o modo on-demand "não detecta nem isola hash keys que estão dirigindo uma porção maior do tráfego de entrada para um shard em particular": documentado explicitamente, é por isso que é uma resposta errada favorita.

6.2 A idade do iterador é um aviso de perda de dados, não só de atraso

GetRecords.IteratorAgeMilliseconds (stream) / IteratorAgeMilliseconds (shard) mede o atraso do consumidor; 0 significa totalmente em dia. O aviso da AWS: "Se a idade de um iterador passar de 50% do período de retenção (por padrão, 24 horas, configurável até 7 dias), há risco de perda de dados por expiração de registros." Então alarme em Maximum em 50 % da retenção e conserte com: mais shards, ParallelizationFactor do Lambda (1 to 10 por shard; a ordenação ainda é preservada por partition key), uma janela de batching de até 5 min / 6 MB, enhanced fan-out (uma dedicada 2 MB/s por consumidor por shard), ou simplesmente um consumidor mais rápido.

6.3 Três modos de capacidade, não dois

As trocas de modo são limitadas a 2 por 24 horas móveis. O EFO custa US$ 0,015 por consumidor-shard-hora mais por GB, e suporta 20 consumidores registrados por stream (Standard) ou 50 (Advantage); com menos de cerca de 3 consumidores, leituras compartilhadas são a escolha mais barata.

• 📚 Você sabia? A idade do iterador é uma das poucas métricas da AWS em que "maior" pode significar perda permanente de dados em vez de "mais lento": uma vez que um registro passa da janela de retenção ele sumiu, e nenhum scaling traz de volta. É por isso que a recomendação da AWS é um alarme em metade do período de retenção, e não em 100 % (documentação de monitoramento do AWS Kinesis, acesso em outubro de 2026).

6.4 Exemplo trabalhado E5: custo de shard e a conta de unidades de payload

---

7. AWS Lambda: concorrência, timeouts, cold starts, reprocessamentos

7.1 O pool de concorrência

O padrão da conta é 1.000 execuções concorrentes por Região; uma função escala até 1.000 ambientes por 10 segundos, e o teto de invocações por segundo é cerca de 10 × a cota de concorrência. Acima da cota, as invocações são limitadas com 429.

Reserved e provisioned concurrency contam ambas contra o pool da conta, e provisioned ≤ reserved para a mesma função. O Application Auto Scaling mira 70 % de utilização (escala para fora acima de 70, para dentro abaixo de 63), e a orientação da própria AWS é que pipelines assíncronos de processamento de dados geralmente não precisam de provisioned concurrency.

7.2 Timeouts e reprocessamentos

Suba memória e timeout juntos: a CPU é proporcional à memória, então um "timeout" frequentemente é uma função subdimensionada. Reprocessamentos assíncronos não consertam subdimensionamento: eles só o escondem até a DLQ encher:

• Síncrono: quem chama vê o erro; os retries seguem a política de quem chama.
• Assíncrono: o Lambda enfileira e depois reprocessa 2 vezes (após 1 minuto, depois 2 minutos) para erros de função; para throttling (429) e erros de sistema (série 500) o evento volta à fila e é reprocessado por até 6 horas, com backoff de 1 s até 5 min. Então a dead-letter queue (somente SQS standard ou SNS standard: nunca FIFO) ou o on-failure destination o recebe; um on-failure destination carrega adicionalmente o payload de resposta.
• Stream (event source mapping): reprocessa até bisect_batch_on_error, maximum_record_age ou retry_attempts disparar, depois o on-failure destination. Para Kinesis, ParallelizationFactor 1 to 10 aumenta o paralelismo por shard mantendo a ordem por partition key.

7.3 Exemplo trabalhado E6: concorrência, reserved versus provisioned

8. Alavancas de custo por serviço

8.1 A dimensão cobrável, depois a alavanca

Nunca nomeie uma alavanca sem nomear a dimensão que ela reduz (páginas de preços do AWS Glue, Redshift, EMR, Kinesis, Lambda e S3, em outubro de 2026).

8.2 Exemplo trabalhado E7: small files custam duas vezes

• 📚 Você sabia? A metade de armazenamento da conta está caindo há vinte anos enquanto a metade de requisições não: o retrospectivo de S3 da AWS (13-03-2026) coloca a redução de preço desde o lançamento em 2006 em cerca de 85 % e afirma que os clientes economizaram mais de US$ 6 bilhões usando S3 Intelligent-Tiering em vez de S3 Standard. É por isso que esta lição continua separando as alavancas de S3 em classe de armazenamento e requisições: automatizar a classe move um número grande, fundir objetos move o outro (post "Twenty years of Amazon S3" da AWS, acesso em outubro de 2026).

---

9. Custo versus desempenho: a tabela de trade-offs e as heurísticas de enunciado

9.1 O trade-off que o exame realmente pergunta

9.2 Onde cada serviço se encaixa

9.3 As duas heurísticas de enunciado (derivadas do comportamento documentado da AWS, não de um documento da AWS)

• "MAIS eficiente operacionalmente" ⇒ escolha a alternativa sem planejamento de capacidade e sem cluster para dimensionar: AWS Glue (workers gerenciados, auto scaling), EMR Serverless, Redshift Serverless, Kinesis on-demand, Lambda: depois releia o enunciado procurando uma restrição que sobrescreva isso (HDFS, controle de hot key, ciclo de duty estável 24/7).
• "MENOS custoso" (estável 24/7) ⇒ escolha a alternativa provisionada ou comprometida: shards provisionados, um cluster do Redshift em vez de Serverless, computação On-Demand/comprometida, menos DPU-horas, S3 em níveis de lifecycle. Uma opção serverless que fica ociosa 20 horas por dia raramente é a mais barata.
• "MAIS RÁPIDO de implementar" ⇒ uma mudança de configuração gerenciada (WLM, auto scaling, um alarme, uma sort key) vence um refactor de código: a menos que a causa raiz do enunciado seja código (um predicado de join ausente, um transformation_ctx ausente).
• Leia sempre as restrições primeiro: estável versus espicoso, SLA versus throughput, isolamento versus latência. A heurística é o desempate, não a premissa.

9.4 Verificação interativa: preencha os números que o exame reutiliza

9.5 Verificação interativa: ordene a decisão de custo

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

• 📚 Você sabia? Reduções de preço mudam respostas de exame: Glue 6.0 (−30 %), S3 Express One Zone (armazenamento −31 %, PUT −55 %, GET −85 %, 10-04-2025) e o Kinesis on-demand Advantage todos mudaram a coluna "mais barato", mas as dimensões (DPU-hora, shard-hour, GB-s, bytes varridos) não mudaram. Aprenda a dimensão e reverifique a taxa (páginas de preços da AWS, acesso em outubro de 2026).

---

Casos Reais

A AWS publica como esta lição fica em produção. Todos os números abaixo são afirmações de clientes ou da AWS, não auditadas, com a fonte nomeada para você conferir, o ponto examinável é o padrão (qual alavanca moveu, e em qual direção), não a porcentagem de marketing.

Caso A, Amazon Customer Service: dimensionar certo um warehouse

Leia como Habilidade 3.3.4 mais 2.1.1 numa história só: desempenho e custo se moveram juntos, porque o RA3 separa o armazenamento gerenciado da computação, então você para de pagar por disco local que só enchia de dados frios. A versão distractor dessa história diz que o custo caiu porque um desconto foi comprado: nenhum desconto aparece no estudo de caso.

Caso B, Paytm: uma alavanca de custo faseada no EMR

"Migrar para instâncias baseadas em AWS Graviton é um investimento de longo prazo e será benéfico em termos de custo total de propriedade.": Parakh Aggarwal, Diretor de Cloud Excellence e FinOps (estudo de caso da AWS, acesso em outubro de 2026)

O padrão examinável é a lacuna entre o preço de lista e a economia realizada: uma alavanca só vale seus pontos depois que você mediu a carga, e a linha do tempo (2022 → 2024) mostra por que "troque tudo esta noite" nunca é a resposta neste exame.

Caso C, GE Aerospace: um ODS legado reconstruído no Redshift

"Estávamos vendo consultas que costumavam rodar uma hora e meia rodando em 7 minutos usando o Amazon Redshift.": Bejoy John, Diretor Sênior de Data Analytics (estudo de caso da AWS, acesso em outubro de 2026)

Leia como Habilidade 3.3.4 (troubleshoot de desempenho) mais 2.1.1 (dimensionamento de custo/desempenho): a vitória veio de layout, plano e geração de nó, não de um desconto comprado. Dois hábitos de exame para treinar aqui: o mais de US$ 500.000 é a estimativa da própria GE, então nunca generalize para a sua carga; e uma migração de 9 meses com PoC antes é o oposto do distractor "conserte esta noite".

Caso D, Edmunds.com: três alavancas, uma conta

"A motivação principal é que eu não estou mais preso a um tipo de instância ou Região em particular.": Emil Ndreu, Diretor Executivo de Cloud and Security Operations (estudo de caso da AWS, acesso em outubro de 2026)

Faça a aritmética que a AWS não publica: US$ 100.000 em 11 meses ≈ US$ 9.091 por mês, mas a AWS nunca divide esse número entre Spot, Savings Plans e Fargate Spot, então qualquer alternativa que afirme "os Savings Plans sozinhos economizaram X %" não tem apoio na fonte. A distinção examinável é o tipo de alavanca: um Savings Plans é um desconto por compromisso (Compute SPs não ficam presos a um tipo de instância ou Região), Spot é capacidade interrompível para trabalho tolerante a falhas (a AWS lista até 90 % de desconto sobre On-Demand), e nenhum dos dois é a troca de silício Graviton do Caso B.

• 📚 Você sabia? As quatro histórias evitam a armadilha que esta lição repete: nenhum desses clientes "tornou isso mais barato" comprando um compromisso sobre um sistema superdimensionado. Um redimensionou, um re-platformou, um reconstruiu o plano e o layout primeiro, um empilhou duas alavancas de capacidade, e todos mediram antes. A porcentagem publicada da AWS é sempre a carga deles, nunca uma garantia para a sua (estudos de caso da AWS e Big Data Blog, acesso em outubro de 2026).
• 📚 Você sabia? Três alavancas parecem iguais numa conta e são respostas diferentes no exame: Savings Plans = desconto por compromisso (Compute SPs não estão ligados a um tipo de instância ou Região), Spot = capacidade interrompível que você precisa poder perder (a AWS cita até 90 % de desconto sobre On-Demand), e Graviton = silício diferente com preço de lista menor. Distractors no DEA-C01 rotineiramente trocam dois dos três: nomeie a dimensão que cada um muda antes de escolher (AWS Pricing e estudos de caso, acesso em outubro de 2026).

Perguntas de Prática (Practice Questions)

Veredito Comparativo: como este tópico se compara no dia do exame

• Verso outras nuvens: o DEA-C01 testa apenas serviços da AWS: nada pergunta que você compare DPU-horas do Glue com precificação de cluster de um concorrente. Responda com um serviço da AWS, um limiar publicado pela AWS (skew 4,00, 95 % de pulo do VACUUM, 1 MB/s por shard, 1.000 concorrentes do Lambda) ou uma taxa publicada pela AWS em outubro de 2026; qualquer alternativa que pivote para um benchmark de terceiros não verificado está fora de escopo por construção.
• Verso autogerenciado / on-premises: a resposta da AWS é sempre gerenciado e medido sobre feito-a-mão e manual: VACUUM/ANALYZE automáticos e ATO vencem um VACUUM em cron-job, o auto scaling do Glue vence um cluster ajustado à mão, cotas de concorrência do Lambda vencem um worker de fila auto-hospedado. Uma alternativa descrevendo você mantendo a maquinaria é o distractor, não o bônus.
• Verso outro serviço da AWS: escolha pela dimensão cobrável, não por prestígio: Glue para Spark ETL gerenciado (DPU-hora), Redshift para SQL em escala (node/RPU-hora + bytes varridos), EMR quando você precisa de controle no nível do cluster (EC2 + taxa do EMR), EMR Serverless/Glue quando o dimensionamento é o risco, Kinesis para streaming (shard-hour ou GB), Lambda para cola de eventos (requisições + GB-s). "Serverless" vence o enunciado operacional; "provisionado" vence o enunciado de custo em regime estável.
• Verso um processo manual e humano: os ~55 % de redução de custo do Amazon Customer Service com dashboards 47 % mais rápidos e a economia faseada de 30 to 35 % no EMR da Paytm (ambos afirmados por clientes, acesso em outubro de 2026) mostram por que o exame prefere uma alavanca automatizada e medida: humanos não encontram o skew, o plano ou o worker ocioso: um limiar, uma métrica ou um alarme encontra. Trate toda porcentagem publicada como "o cliente alcançou", nunca como "a AWS garante".