Monitoramento e Observabilidade para Pipelines de Dados

Duas tarefas do exame se encontram nesta lição. Tarefa 3.3, manter e monitorar pipelines de dados, pede que você extraia logs para auditorias, implemente soluções de logging e monitoramento que permitam auditoria e rastreabilidade, envie notificações de alerta, depure problemas de desempenho, rastreie chamadas de API com o AWS CloudTrail, mantenha pipelines do Glue e do EMR, registre dados de aplicação com o Amazon CloudWatch Logs e analise logs com Athena, EMR, OpenSearch e CloudWatch Logs Insights. Tarefa 4.4, preparar logs para auditoria, pede o mesmo material pelo lado da conformidade: CloudWatch, armazenamento de CloudWatch Logs, CloudTrail Lake, análise de logs e integração de serviços como o EMR para grandes volumes de log. O exame trata as duas como uma disciplina com duas perguntas: o que aconteceu (evidência de auditoria) e o que está acontecendo agora (sinal operacional).

Nesta lição você vai:

• separar o plano de auditoria do plano operacional e posicionar corretamente eventos de gerenciamento, eventos de dados e eventos de Insights;
• escolher entre métricas de serviço, métricas customizadas e Embedded Metric Format, com as armadilhas de cardinalidade e de permissão;
• desenhar alarmes: estados, ações de mudança de estado, dados ausentes, alarmes compostos e de log, dashboards e métricas matemáticas;
• usar os três mecanismos do CloudWatch Logs, metric filter, subscription filter, Logs Insights, sem misturá-los;
• escrever consultas de Logs Insights (linguagem de consulta, índices de campo, cobrança por bytes escaneados);
• monitorar cada estágio do pipeline nativamente: Glue, Kinesis, Redshift, EMR, Lambda, DMS, Step Functions, S3, EventBridge;
• aplicar melhores práticas de logging: JSON estruturado, correlation IDs, políticas de proteção de dados para PII, retenção e roteamento entre contas;
• trabalhar nove exemplos resolvidos: seis configurações de alarme e três consultas de Logs Insights;
• ler a caixa de atualização de outubro de 2026, quatro estudos de caso de clientes da AWS e terminar com catorze questões no estilo do exame mais três verificações interativas.

---

1. Dois planos de evidência: auditoria versus operações

1.1 A divisão que o exame cobra

1.2 CloudTrail: gerenciamento, dados, Insights

• Eventos de gerenciamento (padrão): leituras Describe*, Get* e chamadas de escrita como RunInstances, além de eventos fora de API como ConsoleLogin.
• Eventos de dados (opt-in, cobrados): operações de alto volume no nível do recurso, AWS:S3:Object, AWS:Lambda:Function (Invoke), AWS:DynamoDB:Table, AWS:Kinesis:Stream, AWS:SQS:Queue, AWS:StepFunctions:StateMachine, AWS:Glue:Table. Uma questão sobre s3:GetObject é insolvível a menos que os eventos de dados estejam habilitados, eles estão desligados por padrão.
• Eventos de Insights: detecção de anomalia em eventos de gerenciamento, cobrados e desligados por padrão.
• Integridade: hash SHA-256 mais assinatura digital SHA-256 com RSA produz um arquivo de resumo a cada hora, e a validação não é retroativa.
• Trilhas de organização (conta de gestão ou admin delegado): um bucket para cada conta, contas membros podem ver mas não modificar ou excluir, propagação ≤24 horas, arquivos de log entregues aproximadamente a cada 5 minutos.
• As ações do plano de controle do Glue são todas registradas com eventSource: glue.amazonaws.com; muitas respostas Get*/BatchGet* são registradas como null.

1.3 Exemplo trabalhado E1: “quem excluiu as partições?” em quatro movimentos

• 📚 Você sabia? O histórico de eventos do CloudTrail te dá 90 dias de eventos de gerenciamento para a conta conectada apenas: sem configuração, sem trilha. É a resposta rápida para “quem fez isso nos últimos 90 dias?”, mas ele não consegue responder uma questão entre contas ou sobre eventos de dados; isso exige uma trilha de organização ou o CloudTrail Lake (documentação do AWS CloudTrail, acesso em outubro de 2026).

---

2. Métricas do CloudWatch: de serviço, customizadas e embutidas

2.1 Três jeitos de um número chegar ao CloudWatch

As estatísticas são retidas por 15 meses. Depois que você publica uma métrica customizada nova, ela fica visível para GetMetricStatistics em até 2 minutos e para ListMetrics em até 15 minutos: uma armadilha de exame quando você “acabou de criá-la e não vê nada”.

2.2 Exemplo trabalhado E2: a fatura da cardinalidade

Uma linha de log EMF dimensiona uma métrica por job (50 nomes) × status (4 valores) × região (6 valores):

O EMF é atraente exatamente porque não precisa de permissão extra de IAM, mas existe uma métrica customizada por valor de dimensão único: campos de alta cardinalidade (request IDs, user IDs, strings de SQL) precisam ficar na mensagem de log, não nas dimensões.

• 📚 Você sabia? Como as métricas do EMF vêm de eventos de log, elas são entregues at-least-once: um PutLogEvents reprocessado pode produzir um ponto de dado de métrica duplicado. Desenhe alarmes sobre estatísticas que toleram isso (por exemplo Sum em um período em vez de um SampleCount exato) e nunca trate uma contagem derivada de EMF como um razão de dupla entrada (documentação do EMF da AWS, acesso em outubro de 2026).

---

3. Alarmes do CloudWatch: estados, ações e como combiná-los

3.1 A máquina de estados

Regras-chave (todas verificadas na AWS, acesso em outubro de 2026):

• Um alarme invoca ações somente quando o alarme muda de estado: a exceção são alarmes com ações de Auto Scaling. Um pipeline que continua quebrado não te página de novo a cada minuto.
• Os estados são OK / ALARM / INSUFFICIENT_DATA; recursos ociosos frequentemente param de publicar e ficam em INSUFFICIENT_DATA.
• Tipos de alarme: alarmes de métrica (incluindo expressões de métrica matemática sobre as quais você pode alarmar), alarmes compostos (Boolean AND/OR/NOT sobre outros alarmes), alarmes de log (uma consulta Logs Insights agendada com condição M-de-N: nenhum metric filter obrigatório) e alarmes PromQL. Não existe cota no número de alarmes.
• Alarmes compostos: só na mesma conta e Região, começam em INSUFFICIENT_DATA (a única vez que um alarme novo começa assim), não podem executar ações de EC2 ou de Auto Scaling, filhos não carregam ações então o composto página uma vez, e os limites são 100 filhos / 500 elementos / 150 compostos por filho.
• Janelas de avaliação: até 7 dias quando o período é ≥1 hora, ou 1 dia para períodos menores.

3.2 O comportamento com dados ausentes é uma decisão de desenho

TreatMissingData tem três configurações e a certa depende da métrica: breaching (ausente = ruim; correto para idade do iterador, onde silêncio significa que não há leitor), notBreaching (ausente = ok; correto para profundidade da DLQ, onde ausência de pontos de dado significa fila vazia) e ignore (manter o estado atual). Escolher o padrão (missing) é como equipes ganham alarmes INSUFFICIENT_DATA em que ninguém confia.

3.3 Detecção de anomalia em vez de limite estático

A detecção de anomalia do CloudWatch treina uma banda de ML por métrica e por estatística, então você alarma quando o valor sai da banda em vez de cruzar um número ajustado à mão. Ela substitui limites fixos onde a carga é sazonal (janelas de ETL diárias) e os complementa onde existe um limite de conformidade (uma latência CDC de 300 segundos).

---

4. Dashboards e métricas matemáticas

• Dashboards são ilimitados por conta e todos os dashboards são globais, não específicos de Região: um dashboard de monitoramento puxa métricas qualificadas por Região por widget.
• Cotas: ≤500 widgets por dashboard e ≤500 métricas no array metrics de um widget (em outubro de 2026).
• Widgets entre contas: a partir de uma conta de monitoramento, cada widget nomeia sua accountId e sua region.
• Uma métrica que ficou silenciosa por 14 dias some do seletor de métricas do dashboard: um pipeline quieto parece um pipeline excluído.
• Métrica matemática permite que um widget mostre 100 * (Errors / Invocations) como uma taxa de erro, e os alarmes podem observar a expressão, não só a métrica bruta.

---

5. CloudWatch Logs: grupos, retenção, metric filters, subscription filters

5.1 O modelo de contêiner e suas cotas

Um log group guarda log streams que compartilham retenção e controle de acesso; não há limite no número de streams por grupo. Em outubro de 2026: 1.000.000 de log groups por Região, 100 metric filters por grupo, 5 subscription filters por grupo, evento de log de 1.024 KB, lotes de PutLogEvents de 1 MB / 5.000 por segundo, StartQuery 10/s e limites de regex de ≤5 padrões de regex por grupo e ≤2 regexes por padrão.

5.2 Um padrão, três trabalhos

5.3 Exemplo trabalhado E3: metric filter mais alarme sobre logs de job em JSON

Como os filtros não são retroativos, este alarme só vê erros do momento em que o filtro existe: questões retrospectivas (“deu erro na terça passada?”) são questões de Logs Insights.

5.4 Exemplo trabalhado E4: saúde da entrega do subscription filter

Entregáveis com throttling são reprocessados por até 24 horas, depois as entregas com falha são descartadas, então um alarme DeliveryThrottling é um alarme de perda de dados fantasiado de desempenho.

6. CloudWatch Logs Insights: consultando as evidências

6.1 Três linguagens, um modelo de cobrança

O Insights oferece a linguagem de consulta (fields, filter, parse, stats, sort, limit, join, lookup, filterIndex, estimate), o OpenSearch PPL e o OpenSearch SQL: SQL é a única que consegue fazer JOIN entre log groups. Você é cobrado pelos dados de log não comprimidos escaneados, as consultas expiram após 60 minutos, os resultados vivem por 7 dias, e os índices de campo (mais o comando filterIndex) cortam dramaticamente o volume escaneado. Os logs de serviços da AWS são descobertos automaticamente como campos com prefixo @; seus próprios campos de JSON estruturado aparecem pelo nome.

Barreiras de proteção: estreite o intervalo de tempo primeiro, cancele as consultas antes de fechar o console e prefira metric filters ou EMF a um widget de dashboard que reexecuta o Insights.

6.2 Exemplo trabalhado E5: triagem de um job noturno com falha (janela de 30 segundos)

6.3 Exemplo trabalhado E6: taxa de erro por job a partir de JSON estruturado

As duas consultas são investigações. Para alertar sobre o mesmo sinal você acrescentaria um metric filter (Exemplo E3) ou publicaria via EMF, e, como metric filters não são retroativos, você também manteria a consulta do Insights para a metade retrospectiva da questão.

• 📚 Você sabia? O Logs Insights descobre automaticamente os campos @ dos logs de serviços da AWS (por exemplo @message, @timestamp, @logStream), mas são os índices de campo que você define que tornam o filter barato: sem índice, toda linha candidata é escaneada, então a fatura acompanha bytes escaneados, não linhas retornadas. Indexe os campos pelos quais você filtra e deixe varreduras amplas de @message LIKE apenas para intervalos curtos de tempo (documentação do CloudWatch Logs Insights da AWS, acesso em outubro de 2026).

---

7. Streaming: Amazon Kinesis Data Streams

7.1 A métrica que define a saúde do stream

Namespace AWS/Kinesis. As métricas de nível de stream são gratuitas e publicadas a cada minuto; as métricas aprimoradas (de nível de shard) são uma feature opt-in com custo adicional (EnableEnhancedMonitoring).

7.2 Exemplo trabalhado E7, o alarme de idade do iterador

A orientação da própria AWS: se a idade de um iterador passa de 50% do período de retenção, você corre o risco de os registros expirarem antes de serem lidos, e você deve usar alarmes do CloudWatch na estatística Maximum. A aritmética de limiar sobre uma retenção padrão de 24 horas é exatamente o tipo de cálculo que o DEA-C01 espera que você realize, não que memorize.

---

8. AWS Glue: DPU, bookmarks, observabilidade e job insights

8.1 Como as métricas do Glue se comportam

O AWS Glue reporta métricas ao CloudWatch a cada 30 segundos, como valores delta em relação aos reportados anteriormente, então um gráfico de dashboard em granularidade de 1 minuto é uma agregação, e a estatística certa por minuto é Sum, não Average. O namespace de métrica da CLI/API é Glue.

8.2 Alerta de falha geralmente é EventBridge, não CloudWatch

Não existe métrica padrão de “job com falha”. O alerta canônico (habilidade 3.3.3) é uma regra do EventBridge sobre o evento Glue Job State Change.

8.3 Exemplo trabalhado E8: alerta quando o job noturno falha

Os bookmarks são o modo de falha silencioso: um job pode ter sucesso lendo nada porque o watermark do bookmark diz que ele já leu. Alarme sobre glue.driver.aggregate.recordsRead caindo para 0 contra um volume esperado e pareie com a regra de mudança de estado para que silêncio e sucesso sejam distinguíveis.

---

9. Amazon Redshift: três planos de evidência

Spectrum e limites de uso: UsageLimitConsumed carrega a dimensão FeatureType, incluindo SPECTRUM: os bytes escaneados por consultas externas contra o S3, que é como você alarma uma consulta Spectrum desgovernada antes que a fatura chegue.

Exemplo trabalhado (congestionamento de WLM): alarme WLMQueueLength com dimensão QueueName=etl > 5 por 3 períodos, depois confirme com QueryRuntimeBreakdown em stage=QueryWaiting: se QueryWaiting estiver alto, as consultas estão na fila (acrescente filas ou concorrência do WLM); se estiver baixo mas QueryDuration estiver alto, o SQL em si está lento. A conclusão errada a partir do plano errado é a armadilha.

---

10. Amazon EMR: YARN e o padrão de 5 minutos

• As métricas padrão chegam a cada 5 minutos e são grátis; no EMR 7.0 e superior o agente do CloudWatch acrescenta 34 métricas extras em granularidade de 1 minuto (cobradas), e o 7.1 acrescenta classificações do YARN e do HBase.
• IsIdle é amostrado a cada 5 minutos: a orientação de alarme da própria AWS é alarmar “quando IsIdle for 1 por mais de uma checagem consecutiva de 5 minutos”.
• Capacidade e scaling: AppsRunning, AppsPending, ContainerPendingRatio (o sinal de scaling), HDFSUtilization e YARNMemoryAvailablePercentage: a métrica-chave do managed scaling.
• O managed scaling também emite YarnContainersUsedMemoryGBSeconds, que a AWS descreve como crítica para o managed scaling.
• Logs: o agente envia /mnt/var/log/hadoop-yarn/... para log groups do CloudWatch, e é isso que torna as Habilidades 3.3.6/4.4.5 (analisar logs do EMR, usar o EMR para grandes volumes de log) respondíveis com Logs Insights ou um subscription filter para o S3.

Leitura de exame: uma questão do EMR que exige métricas de 1 minuto está na verdade perguntando qual componente as publica: a resposta é o agente do CloudWatch no EMR 7.0+, não uma configuração de console.

---

11. AWS Lambda: throttles, duração e erros

As métricas chegam em granularidade de 1 minuto.

As métricas de mapeamento de origem de eventos são opt-in: PolledEventCount, InvokedEventCount, FailedInvokeEventCount, DroppedEventCount, MaxOffsetLag. A entrega do ESM é at-least-once, então as contagens podem dobrar: nunca leia como uma contagem de eventos de negócio exatamente-uma-vez.

Desenho do alarme: Errors / (Invocations + Throttles) como métrica matemática é enganoso porque os throttles são excluídos dos dois; alarme Throttles > 0 e Errors > 0 separadamente, depois investigue limites de concorrência versus código.

12. AWS DMS: a latência CDC são dois números, não um

As métricas vivem em AWS/DMS, são expressas em segundos e são dimensionadas por instância e tarefa.

• CDCLatencySource, o último evento capturado na origem versus o relógio da replication instance: o lado de leitura da origem.
• CDCLatencyTarget, o evento mais antigo sem confirmação esperando para confirmar no destino versus o relógio: o lado de aplicação no destino.
• CDCLatencyTarget é sempre maior ou igual a CDCLatencySource.

Exemplo trabalhado E9: leia as duas latências antes de tocar em qualquer coisa

Essa ordem, a origem primeiro quando os dois estão altos, é o fato de monitoramento do DMS mais testável de todos, e ele decorre da desigualdade: a latência do destino inclui tudo o que a latência da origem inclui.

---

13. AWS Step Functions: histórico de execução e backlog

Namespace AWS/States, dimensão StateMachineArn; sem dimensão, as métricas são no nível da conta.

• Métricas de execução: ExecutionsStarted, ExecutionsSucceeded, ExecutionsFailed, ExecutionsTimedOut, ExecutionThrottled, ExecutionTime (milissegundos). Use Sum para contar execuções e Average para caracterizar durações.
• Armadilha: o Step Functions emite duas métricas ExecutionsStarted para cada execução de state machine, então SampleCount é 2: nunca leia SampleCount como contagem de execuções.
• As métricas são emitidas melhor esforço; um nome de state machine não-ASCII impede o logging do CloudWatch.
• Métricas de atividade (dimensão ActivityArn): ActivitiesSucceeded, ActivitiesFailed, ActivitiesTimedOut, ActivitiesHeartbeatTimedOut.
• Backlog: OpenExecutionCount contra o limite (padrão 1.000.000): a AWS recomenda um alarme Maximum em 100.000+; para Distributed Map, ApproximateOpenMapRunCount contra um limite de 1.000, alarmado em 900+.
• O histórico de execução no console (e a API GetExecutionHistory) é a evidência por execução, o CloudWatch te dá o agregado, o histórico de execução dá a história estado a estado.

---

14. Amazon S3: métricas de requisição versus métricas de armazenamento

Além disso: a entrega de métricas do S3 pelo CloudWatch é melhor esforço, então trate um ponto de dado ausente como ambiguidade, não como tráfego zero.

Exemplo trabalhado (taxa de erro por prefixo): para alarmar 4xx em s3://curated/, primeiro crie uma configuração de métricas filtrada por aquele prefixo, depois alarme 4xxErrors na dimensão FilterId=curated. Não existe jeito de obter uma taxa de erro por prefixo a partir das métricas diárias gratuitas de armazenamento, o exame reutiliza esse padrão constantemente.

---

15. Amazon EventBridge: invocações, falhas e a dead-letter queue

Namespace AWS/Events.

• Invocations: primeiras tentativas bem-sucedidas mais as com falha; ele exclui reprocessamentos até que se tornem falhas permanentes, e é emitido somente quando diferente de zero.
• FailedInvocations: somente falhas permanentes, também só quando diferente de zero.
• Detalhe da entrega: InvocationAttempts, SuccessfulInvocationAttempts, RetryInvocationAttempts; um alarme útil de métrica matemática é SuccessfulInvocationRate = SuccessfulInvocationAttempts / InvocationAttempts.
• Ordem de solução de problemas: TriggeredRules = 0 ⇒ seu padrão nunca casou; Invocations = 0 mas a regra disparou ⇒ configuração do target (permissões, ARN); falhas com invocações ⇒ o problema está no target.
• Os reprocessamentos rodam por até 24 horas / 185 tentativas, depois o evento pode ser enviado para uma dead-letter queue opcional: nesse ponto a profundidade da DLQ é uma métrica do SQS, não do EventBridge.

Exemplo trabalhado E10: profundidade da DLQ mais falhas permanentes

O pareamento importa: FailedInvocations diz “desistiu”, a profundidade diz “quantos estão esperando”, e as tentativas de reprocessamento dizem “ainda tentando”: três urgências diferentes a partir de três métricas diferentes.

---

16. Melhores práticas de logging para pipelines

16.1 Seis regras que valem pontos (Habilidades 3.3.2, 3.3.7, 4.4.2)

1. Logs em JSON estruturado. Índices de campo, parse, filter e metric filters todos assumem estrutura; linhas de texto livre forçam varreduras de @message LIKE cobradas por bytes.
2. Correlation IDs em todo lugar. Step Functions $$.Execution.Id, Glue JobName + JobRunId, request ID do Lambda, task ID do DMS. Um único ID permite que uma consulta do Insights faça join entre log groups e estágios.
3. Nunca registre PII quando puder evitar; se precisar, anexe uma política de proteção de dados do Logs: a detecção e o mascaramento acontecem quando os dados são ingeridos, então eventos escritos antes da política existir não são mascarados, ler dados mascarados exige logs:Unmask, e as detecções publicam a métrica gratuita (vendida) LogEventsWithFindings.
4. Defina a retenção por log group, o padrão é indefinido, a exclusão leva até 72 horas.
5. Centralize entre contas: uma conta de monitoramento do CloudWatch, Logs Centralization, um CloudTrail de organização em um único bucket, ou um subscription filter para o Firehose aterrissando em um bucket S3 central.
6. Mantenha os dois planos separados: evidência de auditoria vai para o CloudTrail (depois CloudTrail Lake / Athena), logs operacionais vão para o CloudWatch Logs.

16.2 Exemplo trabalhado E11: alarme de barreira de proteção de PII

16.3 A cadeia de alerta, ponta a ponta

A Habilidade 3.3.3 (“usar notificações durante o monitoramento para enviar alertas”) só é satisfeita quando um sinal se torna uma notificação: métrica (serviço, customizada ou EMF) ou alarme de log → mudança de estado do alarme → tópico Amazon SNS (e-mail, SMS, Lambda, Chatbot) ou um target do EventBridge. Os alarmes do CloudWatch não enviam e-mail por si mesmos e, como as ações disparam somente em mudança de estado, as políticas de escalonamento precisam viver a jusante da primeira notificação.

• 📚 Você sabia? Os três padrões de log entre contas são ferramentas genuinamente diferentes: uma conta de monitoramento (observabilidade entre contas do CloudWatch) permite que uma consulta do Logs Insights abranja log groups vinculados: /aws/glue/* em seis contas em uma única consulta; Logs Centralization move a entrega dos log groups para uma conta central; um CloudTrail de organização coloca arquivos de auditoria de cada conta em um único bucket do S3. Escolher entre eles é uma questão de Habilidades 3.3.1/4.4.5, e a alternativa errada geralmente mistura dois dos três (documentação do CloudWatch e do CloudTrail da AWS, acesso em outubro de 2026).

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

---

Casos Reais

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 examinavel é o padrão, quais sinais precisaram ser alarmados e por que a operação sobreviveu, não o marketing.

Caso A, AGCO: uma pessoa operando um pipeline de telemetria

Leia como uma história de monitoramento: um pipeline que uma pessoa opera só pode funcionar se os alarmes forem automáticos. Os dois sinais que importam aqui são exatamente os da Seção 7, GetRecords.IteratorAgeMilliseconds em Maximum para leitores ficando para trás, e WriteProvisionedThroughputExceeded para produtores com throttling, mais a saúde da entrega do Firehose a jusante. −78% é uma afirmação de cliente (acesso em outubro de 2026), não uma garantia.

Caso B, FINRA: escala regulada e o plano de auditoria

Aritmética derivada (rotule assim): 37.000.000.000 ÷ 86.400 s ≈ 428.000 registros/segundo; um dia movimentado de 75 bilhões ≈ 868.000 registros/segundo. Nessa taxa a trilha de auditoria não pode ser um subproduto: eventos de gerenciamento do CloudTrail mais uma trilha de organização para um único bucket, e métricas do EMR/YARN na granularidade da Seção 10, são o que torna “prove o que aconteceu” respondível.

• 📚 Você sabia? As duas histórias publicadas da FINRA se dividem pelos dois planos desta lição: a arquitetura de vigilância é uma história de operações (EMR, HBase, YARNMemoryAvailablePercentage, uso de HDFS), enquanto o Consolidated Audit Trail é uma história de auditoria (CloudTrail, KMS, GuardDuty, Redshift). Ambas são publicadas pela AWS e não auditadas (acesso em outubro de 2026), o padrão examinável é qual plano uma questão nomeia, não qual cliente alcançou qual porcentagem.

Caso C, Nasdaq: dois caminhos, dois conjuntos de alarmes

Leia como uma história de monitoramento: como armazenamento e computação estão desacoplados, uma consulta lenta não consegue bloquear a ingestão, e os dois caminhos por isso alarmam em namespaces diferentes. O caminho de escrita é AWS/S3, 4xxErrors, 5xxErrors, FirstByteLatency em uma configuração de métricas (Seção 14), enquanto o caminho de leitura é AWS/Redshift, HealthStatus, WLMQueueLength, QueryRuntimeBreakdown em stage=QueryWaiting (Seção 9). O Object Lock transforma a camada de arquivo em evidência WORM, que é a metade do Domínio 4 da mesma arquitetura. Derivado (rotule): 70.000.000.000 ÷ 86.400 s ≈ 810.000 registros/segundo sustentados, uma taxa com a qual nenhuma revisão humana noturna consegue acompanhar.

• 📚 Você sabia? O estudo de caso da Nasdaq da AWS cita Robert Hunt, VP de Engenharia de Software: “Conseguimos suportar com facilidade o salto de 30 bilhões para 70 bilhões de registros por dia por causa da flexibilidade e da escalabilidade do Amazon S3 e do Amazon Redshift.” A folga de escala veio da arquitetura, não de uma feature de monitoramento, e é por isso que o exame te recompensa por separar alarmes do caminho de escrita (métricas de requisição do S3, opt-in e cobradas) de alarmes do caminho de leitura (métricas de cluster e WLM do Redshift, gratuitas) em vez de por conhecer qualquer limiar isolado (estudo de caso Nasdaq da AWS, acesso em outubro de 2026).

Caso D, Oportun: descobrindo PII que ninguém indexou

Leia como uma história de monitoramento: o Macie é inventário + classificação + score, então os sinais sobre os quais você alarma são o inventário de buckets, a tendência do sensitivity score e achados roteados pelo Amazon EventBridge para um SNS ou uma remediação em Step Functions: a mesma cadeia de mudança-de-estado-para-notificação da Seção 16.3. Mantenha o limite nítido: o Macie descobre PII no Amazon S3; ele não varre nativamente o Amazon RDS ou o Amazon Redshift, e PII dentro de linhas de log é trabalho de uma política de proteção de dados do CloudWatch Logs (LogEventsWithFindings, Seção 16.2), não do Macie. Os números +95% / −80% são afirmações de cliente publicadas pela AWS (acesso em outubro de 2026), não um benchmark que você possa generalizar.

• 📚 Você sabia? Os próprios limites do Amazon Macie são fatos de monitoramento: o inventário de buckets de uma conta cobre até 10.000 buckets, identificadores customizados precisam ter 1 to 300 caracteres (padrão 50), e as detecções têm severidade padrão MEDIUM, então “nós varremos tudo” é uma afirmação sobre um limite de inventário, não sobre a ausência de PII, e um sensitivity score que para de se mover merece a mesma investigação que uma métrica que para de publicar (documentação e histórico de documentos do Amazon Macie, 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 guia DEA-C01 testa apenas serviços da AWS: CloudWatch, CloudWatch Logs, CloudTrail, CloudTrail Lake e as métricas nativas do Glue, Kinesis, Redshift, EMR, Lambda, DMS, Step Functions, S3 e EventBridge. Qualquer alternativa que pivote para a pilha de observabilidade de um concorrente, ou para uma estatística de APM de terceiros, está fora de escopo por construção; responda com um serviço da AWS no escopo ou com um nome de métrica publicado pela AWS.
• Verso autogerenciado / on-premises (Prometheus, ELK, syslog que você roda): você pode construir o mesmo pipeline você mesmo, mas aí você é dono dos coletores, do armazenamento de retenção, da capacidade de consulta e do roteamento entre contas. A preferência do exame é o caminho gerenciado e integrado, métricas de serviço → alarme → SNS, logs → CloudWatch Logs → Insights, com as ferramentas autoexecutadas aparecendo como o conceito que a AWS implementa. Note que o AWS X-Ray está explicitamente fora do escopo, então “é só acrescentar distributed tracing” é uma distractor mesmo onde seria engenharia correta.
• Verso outro serviço da AWS na mesma camada: o CloudTrail é o plano de auditoria (chamadas de API), o CloudWatch Logs é o plano operacional (saída da aplicação), métricas/alarmes do CloudWatch são a camada de alertas, o AWS Health é o sinal “nós ou a AWS?”, e CloudTrail Lake / Athena / Logs Insights são a camada de análise. Uma questão perguntando “quem chamou a API” nunca responde “CloudWatch Logs”, e uma perguntando “taxa de erro do job” nunca responde “CloudTrail”.
• Verso um processo manual e humano: o pipeline de um operador da AGCO e a escala regulada da FINRA (afirmações de clientes, acesso em outubro de 2026) são resultados de mecanismos, alarmes de idade do iterador, regras de mudança de estado, métricas do YARN, trilhas de organização, não de alguém olhando uma tela. No exame, prefira a alternativa que produz uma notificação ou um registro consultável sobre a alternativa que exige que alguém lembre de olhar.