Qualidade de Dados e Observabilidade: DQDL, Quarentena, Lineage e SLOs

As lições 01 to 14 construíram algo que funciona: um prefixo bronze, tabelas Iceberg, jobs do Glue, um catálogo, Athena e QuickSight, orquestração, grants do Lake Formation, controles de PII e um perímetro endurecido. Nada disso responde à pergunta que os seus consumidores realmente vão fazer; vocês conseguem provar que os números gold de hoje estão certos, e conseguem me dizer o que mudou quando não estão? Um lakehouse sem qualidade e observabilidade é um jeito muito rápido de mover dados errados.

Esta lição constrói a camada de prova na ordem em que a própria orientação da AWS organiza o assunto: engines → regras → runtimes → resultados e sinais → quarentena → SLOs → observabilidade por camada → auditoria → lineage → remediação. Duas ideias carregam tudo. Primeira, qualidade é um passo de pipeline com saída, não um dashboard: ela ou bloqueia uma gravação, ou separa linhas, ou levanta um sinal para alguém ser acionado. Segunda, observabilidade tem três planos distintos que os times confundem o tempo todo, o catálogo Glue guarda metadados técnicos e permissões, o DataZone guarda significado de negócio e lineage, o CloudTrail guarda quem chamou o quê. Todo número abaixo está datado de outubro de 2026.

Nesta lição você vai:

• escolher uma engine de qualidade no próprio mapeamento de Prescriptive Guidance da AWS, Glue Data Quality, DataBrew, Deequ ou código customizado, e defender o default;
• criar DQDL: rulesets presos a uma tabela, os quatro modificadores (expressões, where, regras dinâmicas, labels), os 32 tipos de regra, e quais deles podem gerar uma linha reprovada;
• rodar a avaliação nos dois runtimes, a tarefa do Data Catalog e o EvaluateDataQuality dentro de um job Glue, e saber exatamente o que cada um pode e não pode fazer;
• pousar resultados em três destinos: JSON no S3, o service store do Glue e tabelas Iceberg no Data Catalog, e depois lê-los no Athena;
• ligar os sinais: eventos do EventBridge, métricas do CloudWatch no namespace Glue Data Quality, alarmes, dashboards: incluindo o checkbox que mata os alertas em silêncio;
• construir o padrão de quarentena de ponta a ponta: separar as linhas, gravar o prefixo e a tabela de quarentena, emitir a métrica, o alerta, e rodar um backfill que permanece idempotente;
• calcular um SLO de frescor em três relógios e defender um número P95 com aritmética de verdade;
• escopar os data events do CloudTrail por prefixo sensível para que a trilha de auditoria não vire a maior linha da fatura;
• separar os três planos, catálogo Glue, catálogo de negócios e lineage do DataZone, auditoria do CloudTrail, e nomear apenas as fontes de lineage que a AWS de fato documenta;
• ligar um caminho de remediação EventBridge → SNS → Lambda que funcione, com o IAM que cabe;
• estudar dois casos de clientes da AWS, uma caixa de atualização de outubro de 2026 com fontes, onze questões de prova e quatro verificações interativas.

---

1. Quatro engines de qualidade, uma decisão

1.1 O mapeamento da própria AWS

O Prescriptive Guidance da AWS publica uma tabela de mapeamento de soluções para checks de qualidade de dados. É a resposta correta mais rápida para "qual ferramenta":

(AWS Prescriptive Guidance: Data quality checks, acesso em 2026-10-11.)

Para o lakehouse deste curso a resposta é Glue Data Quality por default, com o DataBrew reservado ao profiling de analistas de negócio sobre conjuntos CSV/JSON, e PyDeequ apenas onde a customização no nível do Deequ é de fato necessária. Isso não é uma disputa de popularidade: o Glue DQ avalia "tabelas e views do Amazon Athena suportadas que estão armazenadas no AWS Glue Data Catalog" sobre o "Amazon S3, Amazon Redshift, fontes JDBC compatíveis com o Data Catalog e formatos de data lake transacionais como Apache Iceberg, Apache Hudi e Delta Lake": esse é exatamente o substrato que você construiu nas Lições 02 to 08 (Glue Developer Guide, acesso em 2026-10-11).

• 📚 Você sabia? O Glue Data Quality não é uma reimplementação: a AWS afirma que ele é "construído sobre o framework open-source DeeQu" e que não há "Sem lock-in… permitindo que você mantenha as regras que está escrevendo em uma linguagem aberta" (Glue Developer Guide, acesso em 2026-10-11). É por isso que uma regra DQDL se parece com o vocabulário de restrições do Deequ, e por que a biblioteca open source continua sendo um escape hatch legítimo para analyzers que o produto não expõe.

1.2 O que o "gerenciado" compra, em uma tabela

A última linha importa. O Great Expectations aparece nesta lição apenas como um framework traga-o-você-mesmo: a AWS não publica nenhuma oferta gerenciada de GX, a documentação legada do próprio GX fixa a integração com o AWS Glue em "a versão mais recente do GX que suporta esta integração é o GX 0.15.50", e o walkthrough do conector do Glue Catalog é um post de parceiro. Trate o GX como o seu runner, para você versionar, aplicar patches e suportar.

---

2. DQDL: a linguagem, os modificadores, o contrato do ruleset

2.1 O contrato: Rules = [ ... ] preso a uma tabela

Um ruleset é uma lista entre colchetes e separada por vírgulas, presa a exatamente uma tabela de catálogo:

Essa é a forma de create_data_quality_ruleset (Glue Developer Guide: Using APIs to measure and manage data quality, acesso em 2026-10-11). Dois limites definem o tamanho de um ruleset: 2.000 regras por ruleset ("Se seus rulesets forem maiores, recomendamos dividir em vários rulesets") e um tamanho de ruleset de 65 KB. Estatísticas são um orçamento separado: 100.000 estatísticas por conta, armazenadas gratuitamente por 2 anos (Glue pricing, acesso em 2026-10-11).

Uma exclusão de nível de linguagem para decorar: "O DQDL não suporta atualmente dados de coluna aninhados ou de tipo lista." Structs aninhados e arrays estão fora do escopo de alvos diretos de regra: aplane ou use CustomSql contra uma view pré-processada.

2.2 Os quatro modificadores que mudam a semântica

(Notas de versão do Glue DQ e AWS What's New, 2025-11-25, acesso em 2026-10-11.)

Três recursos de apoio completam o pacote: constantes (2025-11-21) permitem definir um valor uma vez e referenciá-lo no script inteiro, "evitando problemas relacionados aos limites de tamanho de consulta"; consultas de pré-processamento (GA 2025-11-25) rodam SparkSQL sobre a tabela antes da avaliação, pelo campo PreProcessingQuery de DataQualityGlueTable, para você derivar colunas, filtrar ou validar relações entre colunas; e regras compostas complexas (2024-11-22) permitem aninhar grupos AND/OR em vez de empilhar regras planas.

Repare na armadilha da coluna with threshold: essa cláusula só funciona com ColumnValues, ColumnDataType e CustomSql. Coloque-a em Completeness e você está escrevendo uma regra que o DQDL não vai avaliar do jeito que você imagina.

2.3 Os 32 tipos de regra, e os que podem nomear uma linha

A referência de tipos de regra do DQDL lista exatamente 32 tipos em outubro de 2026: AggregateMatch, AllStatistics, ColumnCorrelation, ColumnCount, ColumnDataType, ColumnExists, ColumnLength, ColumnNamesMatchPattern, ColumnValues, Completeness, CustomSql, DataFreshness, DatasetMatch, DistinctValuesCount, Distribution, Entropy, IsComplete, IsPrimaryKey, IsUnique, Mean, ReferentialIntegrity, RowCount, RowCountMatch, SchemaMatch, StandardDeviation, Sum, Uniqueness, UniqueValueRatio, DetectAnomalies, FileFreshness, FileMatch, FileUniqueness e FileSize.

Elas se dividem em quatro famílias:

A própria documentação do Studio é franca sobre a divisão: regras de nível de conjunto "não conseguem identificar registros de erro porque são aplicadas no nível do conjunto de dados" (Glue Developer Guide: Evaluating data quality with AWS Glue Studio, acesso em 2026-10-11). Construa uma quarentena em cima de RowCount e você não vai colocar nada em quarentena.

2.4 Exemplo resolvido E1, o ruleset orders da camada silver

Alvo: lakehouse_silver.orders, uma tabela Iceberg particionada por dt, avaliada dentro do job bronze→silver e reavaliada diariamente como tarefa de catálogo.

Por que cada linha merece estar ali: IsPrimaryKey colapsa duas regras em uma; as formas com limiar em ColumnValues toleram menos de 1% de sujeira sem reprovar a execução inteira; RowCount <= avg(last(10)) * 1.5 é uma guarda de pico dinâmica que não precisa de constante ajustada à mão; o CustomSql de nível de linha é a única regra aqui que pode te entregar uma lista de IDs de pedido para colocar em quarentena; e DataFreshness … where "dt = current_date - 1" limita o aviso de frescor à partição que deveria estar fresca em vez de gritar sobre a história inteira.

O walkthrough de getting-started da AWS mostra a mesma forma na tabela de tickets de exemplo, IsComplete "SET_FINE_AMOUNT", Uniqueness "TICKET_NUMBER" > 0.95, ColumnValues "PROVINCE" in [...], ColumnLength "INFRACTION_DESCRIPTION" between 15 and 31, com a ressalva importante da documentação: as recomendações "facilitam o início… sem escrever código", mas as regras são geradas a partir de estatísticas atuais, então trate-as como um rascunho a apertar (acesso em 2026-10-11).

2.5 Recomendações de regra: BASIC e ADVANCED via Bedrock

start_data_quality_rule_recommendation_run(DataSource={'GlueTable': {...}}, Role=role_arn) devolve um RunId; busque ResultIds em get_data_quality_ruleset_evaluation_run e depois cada get_data_quality_result(ResultId=…). As execuções de recomendação são apagadas automaticamente depois de 90 dias. Desde 2026-09-18 / 2026-09-25, um modo ADVANCED usa o Amazon Bedrock com metadados da tabela e linhas amostradas para gerar DQDL: um assistente de rascunho, não uma aprovação.

---

3. Dois runtimes: a tarefa do Data Catalog e o EvaluateDataQuality no job

Eles compartilham DQDL, EventBridge, métricas do CloudWatch, resultados no S3 e ações de IAM. Eles não são intercambiáveis.

(Glue Developer Guide: matriz de capacidades, acesso em 2026-10-11.)

3.1 Dentro do job

A opção de saída do transform é a decisão que importa: "Dados originais" versus "Adicionar novas colunas para indicar erros de qualidade dos dados". A segunda acrescenta quatro colunas: DataQualityRulesPass, DataQualityRulesFail, DataQualityRulesSkip (arrays de string) e DataQualityEvaluationResult ("Passed" ou "Failed" no nível da linha). A nota da própria AWS é a que vale decorar: "seus resultados gerais podem ser FAIL, mas um registro específico pode passar." As regras no Studio ficam "dentro dos colchetes e… separadas por vírgulas": Rules = [ Completeness "year" > 0.8, Completeness "month" > 0.8 ].

Qualidade incremental vem dos job bookmarks: para entradas no S3, a marca d'água é o tempo de última modificação do objeto, com um maxBand padrão de 900.000 ms (15 minutos), durante o qual a listagem "provavelmente estará consistente". Bookmarks exigem job.init no início e job.commit no final, e dependem de um transformation_ctx único: omita-o e o operador não é rastreado de modo algum (que é exatamente como você relê uma dimensão de propósito a cada execução).

3.2 Três destinos de resultado, e desde julho de 2026 o catálogo é um deles

1. Resultados JSON no S3 (opt-in via resultsS3Prefix ou o local de resultados da tarefa) → registre com um crawler, CREATE EXTERNAL TABLE com um SerDe JSON, MSCK REPAIR TABLE, e depois Athena. A AWS entrega o DDL completo, particionado por year/month/day.
2. O service store do Glue → legível por GetDataQualityResult / ListDataQualityResults e renderizado na aba Data quality do console; o Data quality snapshot mostra as últimas 10 execuções entre rulesets por default.
3. Tabelas Iceberg no Data Catalog (GA 2026-07-27) → quatro tipos de resultado em opt-in, resultados de regra, de profiling, de nível de linha e de observação, configurados via --additional-run-options em StartDataQualityRulesetEvaluationRun ou additional_options em um job ETL. Nada é gravado por default: "Você precisa habilitar explicitamente cada tipo de resultado."

Esta é a maior mudança de 2026 no assunto desta lição: seu histórico de qualidade vira uma tabela Iceberg comum, com as mesmas ferramentas de Athena, Lake Formation, time travel e QuickSight do resto do lakehouse.

3.3 O contrato de alertas tem um checkbox escondido

Toda avaliação concluída emite um evento do EventBridge:

A variante de ETL usa contextType: "GLUE_JOB" com jobId, jobName e evaluationContext. O caminho paralelo do CloudWatch é igualmente simples: "Cada avaliação do AWS Glue Data Quality emite um par de métricas chamadas glue.data.quality.rules.passed… e glue.data.quality.rules.failed" sob o namespace Glue Data Quality, publicado por tabela e por ruleset.

A preferência declarada da AWS: "Nossa abordagem recomendada é configurar alertas de qualidade de dados usando o Amazon EventBridge, porque o Amazon EventBridge requer uma configuração única para alertar os clientes." A alternativa com CloudWatch é um alarme padrão: glue.data.quality.rules.failed, estatística Sum, período de 1 minuto, limiar ≥ 1, ação = tópico SNS.

• 📚 Você sabia? O score não é uma nota de qualidade que você passa adiante: a AWS o define como "a porcentagem de regras de qualidade de dados que passaram para a entrada". Um ruleset com uma regra fraca pontua 1.0 enquanto 40% das linhas são lixo. É por isso que existem as colunas de nível de linha e as tabelas de resultado: score para o alerta, linhas para a correção (Glue Developer Guide, acesso em 2026-10-11).

---

4. Deequ, PyDeequ e DataBrew: os caminhos laterais verificados

4.1 Deequ: a engine, e onde ele ainda compensa

O anúncio do PyDeequ da AWS descreve o original: o Deequ "é usado internamente na Amazon para verificar a qualidade de muitos grandes conjuntos de dados de produção… O sistema calcula métricas de qualidade de dados regularmente (com cada nova versão de um conjunto de dados), verifica restrições definidas pelos produtores de dados e publica os conjuntos de dados para os consumidores em caso de sucesso. Em casos de erro, a publicação do conjunto de dados pode ser interrompida e os produtores são notificados para agir." Calcular → verificar → publicar-ou-parar é o loop que o Glue DQ colocou como produto em 2023 (AWS Big Data Blog, 2020-12-30, atualizado em junho de 2024).

Motivos legítimos restantes para rodar você mesmo o Deequ, segundo os próprios posts da AWS:

O PyDeequ "suporta Spark até a versão 3.3.0" segundo as notas do PyDeequ 1.1.x que a AWS vincula, e "pode funcionar dentro do Amazon EMR e do SageMaker". O resumo honesto de 2026: a maior parte do valor do Deequ já está dentro do Glue Data Quality; recorra à biblioteca quando o runtime for exótico ou a restrição não for expressível.

4.2 DataBrew: regras, mas não DQDL

A história de qualidade do DataBrew é um ruleset de CheckExpressions avaliado dentro de um profile job: "Se qualquer um dos critérios de uma regra não for atendido, o ruleset como um todo reprova na validação", e a execução "produz um relatório de validação além do perfil de dados" no mesmo local. Forma da API: CheckExpression, ColumnSelectors (Name ou Regex), Disabled, SubstitutionMap, Threshold (Type/Unit/Value). Restrições a respeitar: apenas colunas de tipos simples (string, números, boolean) participam, e as regras ficam na aba Recommendations da tela de ruleset.

Ao concluir, "o DataBrew envia um evento do Amazon CloudWatch com os detalhes dessa execução de job… para cada ruleset validado… e o evento contém o resultado (SUCCEEDED, FAILED ou ERROR)" mais um link para o relatório. Esse evento é o seu padrão do EventBridge para checks de propriedade dos analistas. As métricas ficam no namespace AWS/DataBrew, o exemplo documentado é SessionCount.

4.3 Exemplo resolvido E2: quanto custa um gate de qualidade, e onde colocá-lo

O benchmark da própria AWS: 104 colunas, 1 milhão de linhas, 10 DPUs (AWS Big Data Blog, 2024-03-12):

Duas conclusões sobrevivem à ambiguidade de preço: orçe pelo tamanho da tabela × frequência, não pela contagem de regras, e para um desenho de quarentena a avaliação dentro do job domina porque é mais barata e é o único caminho que pode nomear as linhas.

---

5. Quarentena: um padrão, não um produto

5.1 Três ações, dois checkpoints

A InsuranceLake, sample da AWS Solutions Library, formaliza o que todo pipeline de produção precisa: três ações em dois checkpoints de pipeline:

Checkpoints: before_transform ("imediatamente após o mapeamento de schema… antes de qualquer transformação ser executada") e after_transform ("logo antes de salvar os dados no bucket Cleanse"). A regra que importa para o desenho do seu ruleset: "a expressão de qualidade de dados precisa ser escrita usando resultados de nível de linha para avaliar e colocar linhas individuais em quarentena" e "regras que dependem de razões ou limiares não são suportadas como regras de quarentena."

A InsuranceLake também mostra como fica um halt por frescor quando você quer que o pipeline pare em vez de separar:

5.2 A separação, em código

A orientação do Studio da AWS também oferece uma variante de primeira parte: em Data quality actions, escolha Fail job after loading target data, que aparece como AssertionError: The job failed due to failing DQ rules for node: …: halt sem quarentena.

5.3 Exemplo resolvido E3, o loop de quarentena com números reais

As duas últimas linhas são o ponto: quarentena sem um caminho de backfill é só perda de dados com etapas extras. E como agora os resultados são tabelas Iceberg, a pergunta "como o gold estava antes da partição ruim" se responde com time travel em vez de um restore.

5.4 Write-Audit-Publish: a forma nativa do Iceberg

O padrão WAP da AWS substitui a cópia física de quarentena por branches: grave tudo em uma branch stg → rode o Glue DQ contra ela → filtre as linhas aprovadas em uma branch audit → fast_forward para main com o procedimento fast_forward do Spark. O conjunto de regras de demonstração do blog verificava a temperatura do sensor "entre −10 e 50 °C", e nomeia o trade-off com honestidade: "O principal desafio do padrão WAP é a latência adicional que ele introduz." A abordagem de dead-letter-queue (o prefixo de quarentena no S3) é a outra opção documentada: escolha pela latência que você pode pagar ou pelo armazenamento duplicado que você pode tolerar.

• 📚 Você sabia? Bookmarks rastreiam origens, não destinos. A documentação da AWS diz de forma direta que "quando você rebobina ou redefin um bookmark, o AWS Glue não limpa os arquivos de destino porque pode haver vários destinos e os destinos não são rastreados com job bookmarks." É por isso que o passo de backfill acima grava em um prefixo novo ou faz MERGE, reexecutar no mesmo caminho anexa duplicatas que a sua regra IsPrimaryKey depois vai cumpridamente colocar em quarentena na próxima execução (Glue Developer Guide, job bookmarks, acesso em 2026-10-11).

---

6. SLOs de frescor: três relógios e a aritmética

6.1 Separe os relógios antes de definir uma meta

SLO de frescor = P95(disponibilidade − evento) ≤ meta. O pipeline contribui com dois intervalos: chegada − evento (atraso de ingestão) e disponibilidade − chegada (atraso de processamento + DQ + backfill). O DQDL dá duas codificações: DataFreshness contra uma coluna de timestamp da tabela ("Verifica se os dados estão frescos", métrica Column.[Column].DataFreshness.Compliance, resultados de nível de linha: Sim) e FileFreshness contra os timestamps de arquivo do S3 (caminho de arquivo/pasta + limiar, nível de linha: Não).

6.2 Exemplo resolvido E4: um SLO de 3 horas, aritmética P95

Some os P95 dos componentes em vez de fazer a média das médias, o P95 de uma soma é limitado pela soma dos P95, então 162 minutos é o número defensável para colocar na frente de um stakeholder, e os 18 minutos de folga dizem qual alavancagem puxar antes de estourar. A escada de falhas é deliberadamente redundante: uma regra de frescor pega dado velho, um alarme de RowCount zero pega um pipeline morto, e um evento de job FAILED pega o crash, três problemas diferentes que todos parecem com "o dashboard está velho".

6.3 Codificando volume e schema drift como alarmes

O DetectAnomalies merece menção especial: ele "verifica anomalias nas métricas relatadas por outro tipo de regra", o que transforma as regras de limiar de ontem em um baseline auto-ajustável: a 1 DPU por estatística, por execução, e é por isso que a AWS recomenda habilitá-lo de forma seletiva.

---

7. Observabilidade operacional: um dashboard por camada

7.1 Logs por camada

Configurações multi-conta centralizam com filtros de assinatura cross-account, um destino de logs Firehose/Kinesis, ou CloudWatch Logs data centralization no nível de Organizations (os nomes de log group de destino aceitam ${source.accountId}, ${source.region}, ${source.logGroup}, ${source.org.id}).

7.2 O mapa de dashboards

A recomendação do Prescriptive Guidance da AWS é um dashboard por preocupação: "um dashboard do CloudWatch pode mostrar aos usuários o status das cargas… ou que porcentagem dos dados deles foi descartada por baixa qualidade ou quais fontes têm o máximo de falhas." Para este lakehouse isso vira um dashboard por camada de medalhão mais um painel de operações de dados no nível da conta:

Free tier em outubro de 2026: 10 métricas custom, 3 dashboards referenciando até 50 métricas cada, 10 métricas de alarme, 1 milhão de requisições de API e 5 GB de ingestão de logs por mês; métricas custom custam $0,30 por métrica-mês nos primeiros 10.000, depois as faixas de $0,10 e $0,05. Dashboards e alarmes são rateados por hora a partir da criação: um alarme sem uso não é grátis, e alarmes de anomaly detection "incurrem custos por cada métrica que você listar na expressão de métrica do alarme, mais dois custos adicionais de métrica de alarme."

---

8. Data events do CloudTrail: prefixos escopados e a fatura

O CloudTrail é a trilha de auditoria do plano de dados, e, sem escopo, a fatura surpresa. "Por padrão, trails e event data stores não registram data events. Cobranças adicionais se aplicam aos data events." Habilitá-los exige advanced event selectors com eventCategory Equals Data e resources.type Equals AWS:S3:Object, escopados com resources.ARN StartsWith, repare que a barra final faz parte do ARN: arn:aws:s3:lakehouse-bronze/.

Regras da estrada:

• "Seletores não suportam o uso de curingas como *": você enumera prefixos, não faz glob.
• Seletores básicos: até 5 event selectors e 250 data resources por trail; seletores avançados permitem até 500 valores especificados entre condições, e os dois estilos não podem ser misturados.
• Exclusões são filtros gratuitos: {"Field": "eventSource", "NotEquals": ["s3lifecycle.amazonaws.com"]} derruba o ruído de lifecycle; readOnly = false dá auditoria somente de escrita para uma landing zone.
• Preços: data events $0.10 por 100.000 entregues ao S3 (agregações $0.03 por 100.000 analisados); management events primeira cópia grátis, cópias adicionais $2.00 por 100.000. Management events respondem quem executou StartJobRun / GrantPermissions / StartQueryExecution; data events respondem quem tocou em qual objeto.

8.1 Exemplo resolvido E5: três seletores, uma fatura

---

9. Três planos: DataZone, o catálogo Glue, CloudTrail

9.1 Para que serve cada plano

O registro no Lake Formation autoriza o acesso a um local, é um escopo de permissão, não uma aresta de lineage. O CloudTrail registra atividade, não é um grafo de derivação. Apresentar qualquer um dos dois como "lineage" é a confusão mais comum deste espaço.

9.2 Lineage: as fontes que você consegue nomear de fato

O DataZone fica em cima do catálogo de negócios: você cria data sources para Glue e Redshift, importa metadados técnicos para o inventário de um projeto, cura com nomes de negócio/termos de glossário/metadata forms, e publica: "Apenas a versão mais recente do ativo do inventário pode ser publicada no catálogo." Um consumidor então vê "uma visualização do lineage desse ativo com 1 nível upstream e downstream." É uma camada de governança e descoberta, não um substituto do AWS Glue Data Catalog que o Athena e o Redshift Spectrum consultam.

• 📚 Você sabia? O lineage do DataZone chegou ao geral em 2024-12-03, e o anúncio é explícito de que a captura é automática para Glue e Redshift e programática para todo o resto: os produtores "hidratam as informações de lineage programaticamente criando nós de lineage customizados por meio de APIs que aceitam eventos compatíveis com OpenLineage de componentes de pipeline existentes, como schedulers, warehouses, ferramentas de análise e engines SQL." Então o teste de integração do seu lakehouse é simples: publique um ativo do Glue, execute o seu data source, e veja se o nó upstream aparece, antes de prometer lineage ponta a ponta para alguém (AWS News Blog, 2024-12-03).

Legenda para decorar: catálogo = metadados técnicos e permissões (Glue + Lake Formation); DataZone = catálogo de negócios e lineage; CloudTrail = auditoria de acesso. Três planos, três ferramentas.

---

10. Exemplo resolvido E6: EventBridge → SNS → Lambda de remediação, ligado

10.1 A regra

10.2 Os alvos, em ordem

Alvo 1, tópico SNS dq-alerts (email / Chatbot para o canal humano). A entrega do SNS para Lambda e SQS é isenta de cobrança de entrega do SNS, "Sem cobrança por entregas para SQS Queues. Aplica-se a precificação padrão do SQS", e idem para o Lambda.

Alvo 2: Lambda dq-remediate:

10.3 O IAM que cabe, e quanto custa

A conclusão é econômica: o caminho de alerta é quase grátis; o caminho de dados é o que custa dinheiro. E essa é a forma correta: um lakehouse que aciona alguém por $1,80 por mês e gasta $21,90 por mês de fato medindo os próprios dados.

---

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

---

Casos Reais

A AWS publica como isso fica em escala. Todo número abaixo é afirmação de cliente ou da AWS e não auditada, com fonte e data nomeadas, o ponto examinável é o padrão.

Caso A, Siemens: logs centralizados que transformaram dias em 10 minutos

A lição para este curso é a forma da resposta: o 10-minutos-versus-vários-dias da Siemens é o que log groups por camada, seletores escopados e um dashboard por camada compram para você: você não diagnostica mais rápido porque a ferramenta é mais esperto, você diagnostica mais rápido porque a evidência já estava indexada e escopada. Repare no que o caso não afirma: o Security Lake é um serviço de agregação de logs de segurança, não o AWS Lake Formation, e ele produz evidência de auditoria, não lineage de coluna.

Caso B, Vanguard: um "data swamp" transformado em produtos de dados com dono

Leia os 600 jobs e as 500.000 consultas mensais como uma declaração de orçamento de qualidade: nesse volume, uma partição ruim silenciosa não é um incômodo, é um mês de decisões erradas. A frase "data swamp" é o próprio atalho da indústria para o que acontece quando um lake acumula arquivos sem curadoria, dono e checks: que é exatamente o modo de falha que as regras, a quarentena e os SLOs desta lição existem para prevenir. (Os números de escala são reportados pela Vanguard/AWS no post de março de 2026; são instantâneos, não garantias.)

---

Perguntas de Prática (Practice Questions)