# Custom Lens para Plataformas de Dados: Anatomia de um Padrão O AWS Well-Architected Custom Lens é frequentemente tratado como um artefato de documentação — mas quando aplicado a plataformas de dados corporativas, ele se torna um mecanismo de governança operacional com dentes reais. Neste artigo, desmonto a anatomia do padrão, exponho suas falhas de adoção mais comuns e proponho um design de referência que conecta revisões de lens a pipelines de remediação automatizados. - URL: https://fernando.moretes.com/blog/well-architected-lens-para-plataformas-de-dados-enterprise - Markdown: https://fernando.moretes.com/blog/well-architected-lens-para-plataformas-de-dados-enterprise/article.md?lang=pt - Published: 2026-06-10T12:00:00.000Z - Category: Dados & Plataformas - Tags: well-architected, custom-lens, data-platform, governance, data-mesh, glue, msk, finops - Reading time: 8 min - Source: [Custom Lens and enterprise data platforms](https://aws.amazon.com/blogs/architecture/) --- Toda plataforma de dados corporativa acumula dívida de governança mais rápido do que dívida técnica. O AWS Well-Architected Custom Lens é o único mecanismo nativo da AWS que permite codificar os critérios de qualidade específicos do seu domínio — latência de ingestão, linhagem de dados, isolamento de tenants, custo por dataset — e transformá-los em revisões estruturadas e repetíveis. Mas o padrão tem um problema de adoção grave: a maioria das equipes o trata como checklist de auditoria anual, e não como loop de feedback contínuo integrado ao ciclo de entrega. Este artigo desmonta o padrão de ponta a ponta, com foco em plataformas de dados financeiras onde o custo de uma revisão superficial é medido em incidentes de compliance. ## O Problema que o Custom Lens Realmente Resolve O Well-Architected Framework padrão foi projetado para ser universal. Isso é sua força e sua limitação. Quando você avalia uma plataforma de dados com os pilares genéricos, as perguntas sobre confiabilidade perguntam se você tem multi-AZ — mas não perguntam se seu pipeline de ingestão do Kafka/MSK tem idempotência de consumidor configurada, se o schema registry está versionado com compatibilidade BACKWARD, ou se o seu Glue Job tem bookmark habilitado para reprocessamento seguro. Essas lacunas não são bugs do framework; são o espaço exato que o Custom Lens foi projetado para preencher. Em ambientes financeiros, a consequência dessas lacunas é concreta. Um pipeline de dados sem controle de linhagem auditável pode resultar em falha de reconciliação regulatória. Um dataset particionado incorretamente no S3 — digamos, por `event_date` em vez de `processing_date` — cria janelas de atraso que invalidam relatórios de risco intraday. Um DynamoDB com partition key mal escolhida para uma tabela de posições de portfólio gera hot partitions que degradam latência de leitura justamente no momento de maior carga: o fechamento de mercado. O Custom Lens resolve isso ao permitir que você codifique **perguntas com contexto de domínio** — não apenas boas práticas genéricas. Cada pergunta tem choices com níveis de risco (HIGH, MEDIUM, NONE), e o framework agrega esses riscos em um score de workload. A diferença entre um lens bem construído e um mal construído está na granularidade das choices: choices vagas geram scores inúteis; choices com critérios objetivos e mensuráveis geram ações. ## Anatomia do Padrão: Custom Lens como Loop de Governança Fluxo completo desde a definição do lens até a remediação automatizada, passando pela revisão do workload e geração de plano de melhoria integrado ao pipeline de dados. ### 📐 Lens Authoring — Governance Team - Lens JSON Pillar + Questions + Choices (ci) - WA Tool Publish & Version Lens (security) ### 🗂️ Workload Review — Data Platform Team - WA Workload Data Platform ARN (compute) - Review Session Risk Scores per Pillar (compute) - Milestones Point-in-time snapshots (storage) ### 🔁 Automated Remediation — DevSecOps Pipeline - EventBridge WA Risk Change Event (messaging) - Step Functions Remediation Orchestrator (compute) - Lambda Config Drift Detector (compute) - AWS Config Compliance Rules (security) ### 📊 Observability — Data Platform Health - CloudWatch Custom Metrics + Alarms (data) - Jira / Backlog Improvement Plan Items (external) ### Fluxos - lens-json -> lens-publish: upload via CLI/API - lens-publish -> workload: associar ao workload - workload -> review: iniciar revisão - review -> milestones: salvar milestone - review -> eventbridge: HIGH risk detectado - eventbridge -> stepfn: trigger remediação - stepfn -> lambda-check: verificar drift - stepfn -> config: avaliar conformidade - stepfn -> cloudwatch: publicar métricas - stepfn -> jira: criar ticket de melhoria ## Anatomia do Lens: Estrutura JSON e Decisões de Design Um Custom Lens é um documento JSON com uma hierarquia bem definida: `pillars` → `questions` → `choices`. Cada choice tem um `id`, um `title`, um `description` e um `helpfulResource`. O risco do workload é calculado pelo WA Tool com base nas choices **não selecionadas** que têm `riskRules` associadas — ou seja, você define o que é seguro, e a ausência do comportamento seguro gera o risco. Para uma plataforma de dados, eu organizo os pillars em torno de cinco domínios que o framework padrão não cobre adequadamente: 1. **Ingestão e Confiabilidade de Stream** — idempotência, dead-letter queues no MSK, consumer group lag monitoring 2. **Qualidade e Linhagem de Dados** — integração com AWS Glue Data Catalog, tags de linhagem em S3 object metadata, validação de schema com AWS Glue Schema Registry 3. **Isolamento e Segmentação de Tenants** — Lake Formation row-level e column-level security, KMS CMK por tenant, S3 bucket policies com `aws:PrincipalTag` conditions 4. **Custo e Eficiência de Processamento** — Glue DPU sizing, S3 Intelligent-Tiering habilitado, Athena workgroup com data scanned limits 5. **Observabilidade de Pipeline** — OpenTelemetry spans em Glue Jobs, métricas customizadas de latência de ingestão no CloudWatch, SLOs definidos por dataset Uma decisão crítica de design: **não misture perguntas operacionais com perguntas de arquitetura no mesmo pillar**. Perguntas operacionais ("o monitoramento está configurado?") têm respostas binárias e mudam frequentemente. Perguntas de arquitetura ("o design suporta replay de eventos?") são mais estáveis. Misturá-las cria um score volátil que perde significado ao longo do tempo. ## Quando Usar Este Padrão — e Quando Ele É Overkill O Custom Lens faz sentido quando você tem **múltiplos workloads do mesmo domínio** que precisam ser avaliados com critérios consistentes ao longo do tempo. Em uma plataforma de dados financeira com 15 pipelines de ingestão, 8 data products e 3 zonas de landing, o lens se torna o único mecanismo que garante que todos os times respondam às mesmas perguntas com o mesmo vocabulário de risco. O padrão também é justificado quando você tem **requisitos regulatórios que precisam ser rastreados** — BACEN, LGPD, SOX. Nesse caso, o milestone do WA Tool funciona como evidência auditável de que a revisão aconteceu em uma data específica com um conjunto específico de riscos identificados e aceitos. Isso tem valor direto em auditorias externas. Por outro lado, **não use Custom Lens** quando: - Você tem apenas um ou dois workloads e a revisão pode ser feita com o framework padrão + notas adicionais - Sua equipe não tem capacidade de manter o lens atualizado — um lens desatualizado é pior que nenhum lens, porque cria falsa sensação de cobertura - Você está em fase de prova de conceito — o overhead de criar e publicar um lens não se justifica antes de ter workloads em produção - O objetivo é apenas documentação: para isso, um ADR bem escrito é mais eficiente A regra prática que uso: **Custom Lens se justifica quando o custo de uma revisão inconsistente entre times é maior que o custo de manter o lens**. Em plataformas com mais de 5 workloads do mesmo domínio e revisões trimestrais, esse break-even é atingido rapidamente. ## Anti-Padrões: Como o Custom Lens Falha na Prática - **Lens como artefato estático**: criar o JSON uma vez, publicar, e nunca revisar. Após 6 meses, as perguntas não refletem mais o estado real da plataforma. O score se torna ruído. - **Perguntas sem choices objetivas**: "Você monitora seus pipelines?" sem definir o que constitui monitoramento adequado. Isso permite que qualquer resposta seja justificada, esvaziando o valor da revisão. - **Revisão sem milestone**: conduzir a revisão sem salvar um milestone significa perder o histórico de evolução do risco. O WA Tool não persiste automaticamente — você precisa criar o milestone explicitamente via API ou console. - **Scope de workload mal definido**: associar um único workload a toda a plataforma de dados em vez de criar workloads por domínio (ingestão, transformação, serving). Isso dilui o score e torna impossível priorizar remediação. - **Ignorar o improvement plan**: o WA Tool gera um plano de melhoria automático baseado nos riscos identificados. Não integrar esse plano ao backlog do time é o anti-padrão mais comum e mais caro — os riscos são identificados, documentados, e ignorados. - **Lens com mais de 30 perguntas**: lenses excessivamente longos geram fadiga de revisão. Times começam a marcar choices sem ler, invalidando o processo. Mantenha entre 15 e 25 perguntas por lens. ## Integração com Pipeline de Remediação: Fechando o Loop O valor real do Custom Lens emerge quando você fecha o loop entre revisão e remediação. A API do WA Tool expõe eventos via EventBridge — especificamente, o evento `AWS Well-Architected Tool:UpdateAnswer` é emitido sempre que uma resposta muda de risco. Você pode usar isso como trigger para um pipeline de remediação. O design que implementei em produção usa Step Functions com o seguinte fluxo: 1. **EventBridge Rule** captura eventos de risco HIGH do WA Tool e invoca uma Step Function 2. **Lambda de triagem** consulta a API do WA Tool para obter o contexto completo da pergunta e da choice não selecionada 3. **AWS Config Rule** verifica se o drift de configuração correspondente existe no ambiente (por exemplo, se a pergunta é sobre Glue Job bookmarking, a Config Rule verifica se `--job-bookmark-option` está habilitado nos Glue Jobs do workload) 4. **Decisão condicional**: se o drift existe, cria automaticamente um ticket no Jira com o contexto completo e o link para a documentação da choice; se não existe, marca o risco como "accepted" via API com justificativa automática 5. **CloudWatch Custom Metric** `WATool/HighRiskCount` é publicada após cada execução, permitindo alarmes e dashboards de tendência Essa integração transforma o WA Tool de um mecanismo de auditoria passivo em um componente ativo do ciclo de governança. O custo operacional é baixo: Step Functions Express Workflows cobram por execução e duração — para revisões trimestrais com ~20 perguntas, o custo mensal é inferior a $1. O valor, por outro lado, é a eliminação do gap entre identificação e ação que mata a maioria dos programas de governança. ## Segurança e IAM: Quem Pode Fazer o Quê no WA Tool O WA Tool tem um modelo de permissões que a maioria das equipes ignora até ter um incidente. Por padrão, qualquer principal com `wellarchitected:*` pode criar workloads, conduzir revisões e — criticamente — **deletar milestones**. Em um contexto de auditoria, um milestone deletado é evidência destruída. O controle que implemento usa três IAM roles separadas com o princípio de least privilege: - **`WATool-Reviewer`**: `wellarchitected:CreateWorkload`, `wellarchitected:UpdateAnswer`, `wellarchitected:GetWorkload`, `wellarchitected:ListAnswers`. Sem permissão para criar ou deletar milestones. - **`WATool-Auditor`**: `wellarchitected:CreateMilestone`, `wellarchitected:GetMilestone`, `wellarchitected:ListMilestones`. Sem permissão para atualizar respostas. Essa role é assumida apenas pelo pipeline de CI/CD após a revisão ser concluída. - **`WATool-Admin`**: permissões completas, incluindo `wellarchitected:DeleteWorkload` e `wellarchitected:DisassociateLenses`. Restrita a um grupo de administradores com MFA obrigatório e session duration máxima de 1 hora via `aws:MultiFactorAuthAge` condition. Um detalhe importante: o WA Tool **não suporta resource-based policies** — todo controle é via IAM identity policies. Isso significa que você não pode usar `aws:ResourceTag` conditions diretamente nos recursos do WA Tool. A alternativa é usar SCPs no AWS Organizations para restringir ações do WA Tool a roles específicas em contas de produção. Para lenses publicados, use `wellarchitected:ShareInvitationAction` com cuidado — compartilhar um lens entre contas expõe a estrutura de perguntas e choices, que pode revelar gaps de controle que você prefere manter internos. ## Pontos-Chave do Padrão - Custom Lens codifica critérios de qualidade específicos do domínio que o framework padrão não cobre — para plataformas de dados, isso inclui linhagem, isolamento de tenants e SLOs por dataset. - Milestones são o único mecanismo de evidência auditável no WA Tool — proteja-os com IAM roles separadas e nunca delegue permissão de deleção a roles de reviewer. - Integrar EventBridge + Step Functions ao WA Tool transforma revisões passivas em loops de remediação ativos, com custo operacional inferior a $1/mês para revisões trimestrais. - Mantenha entre 15 e 25 perguntas por lens. Acima disso, a fadiga de revisão invalida o processo — times marcam choices sem ler. - Crie workloads separados por domínio funcional (ingestão, transformação, serving), não um único workload para toda a plataforma. Scores diluídos não geram priorização. - O improvement plan gerado pelo WA Tool deve ser integrado ao backlog do time via automação — sem essa integração, o padrão gera documentação de risco sem ação correspondente. > **Versione seu Lens como Código:** Trate o JSON do Custom Lens como infraestrutura: armazene no Git com semver, use pull requests para mudanças em perguntas e choices, e automatize o upload via `aws wellarchitected upload-lens-review` na pipeline de CI. Isso garante rastreabilidade de mudanças — quando uma pergunta é removida ou um critério de risco é relaxado, você tem um commit com autor, data e justificativa. Em auditorias regulatórias, essa rastreabilidade vale tanto quanto o conteúdo do lens em si. ## Pilares Well-Architected Aplicados ao Padrão - **security**: IAM roles separadas para Reviewer, Auditor e Admin com MFA obrigatório para Admin. SCPs bloqueando deleção de milestones em contas de produção. Lens JSON armazenado em S3 com versioning e KMS CMK. - **reliability**: Milestones como snapshots point-in-time garantem que o histórico de risco seja preservado mesmo se workloads forem recriados. Pipeline de remediação com retry exponencial no Step Functions para falhas de API do WA Tool. ## Custom Lens vs. Alternativas de Governança de Plataforma de Dados | Critério | Mecanismo | Rastreabilidade Temporal | Integração AWS-Nativa | Custo de Manutenção | Valor em Auditoria | | --- | --- | --- | --- | --- | --- | | Custom Lens (WA Tool) | Alta — milestones por data | Alta — EventBridge, API nativa | Médio — requer curadoria contínua | Alto — evidência estruturada | — | | AWS Config + Conformance Packs | Alta — histórico de compliance | Alta — nativo | Baixo — regras declarativas | Médio — técnico, não narrativo | — | | ADRs + Runbooks (Confluence/Git) | Baixa — sem versionamento de risco | Nenhuma | Baixo — texto livre | Baixo — não estruturado | — | | Security Hub + Standards | Alta — findings históricos | Alta — nativo | Baixo — gerenciado pela AWS | Alto — foco em segurança | — | > **Minha Perspectiva Prática:** Em plataformas de dados financeiras que operei, o Custom Lens se provou útil não pela qualidade do score em si, mas pela **conversa que ele força** entre times de engenharia e times de risco. A lição mais dura que aprendi: um lens sem sponsor executivo morre na segunda revisão. O time de engenharia preenche as respostas, o plano de melhoria vai para o backlog, ninguém prioriza, e na terceira revisão os mesmos riscos HIGH aparecem novamente. A automação do pipeline de remediação que descrevi aqui resolve parte do problema — mas a outra parte é política: o lens precisa estar conectado a um OKR de plataforma com dono nomeado. Sem isso, é documentação cara. ## Veredicto: Vale a Pena, Mas Apenas com o Loop Fechado O Custom Lens para plataformas de dados é um padrão maduro e subvalorizado. Quando implementado corretamente — com workloads por domínio, milestones protegidos por IAM, pipeline de remediação automatizado e sponsor executivo — ele entrega o que nenhuma outra ferramenta AWS entrega: uma visão estruturada, temporal e auditável da dívida de governança específica do seu domínio de dados. O custo de implementação é baixo (o WA Tool é gratuito; o pipeline de automação custa centavos), mas o custo de manutenção é real e proporcional à qualidade das perguntas que você escreve. Minha recomendação: comece com um lens de 20 perguntas cobrindo os cinco domínios que descrevi, automatize o improvement plan para o backlog no primeiro sprint, e revise o lens a cada 6 meses com o mesmo rigor que você revisa sua arquitetura. Se você não tem capacidade para isso, use o framework padrão com notas adicionais — um lens mal mantido é pior que nenhum lens. **Rating:** Recommended with conditions ## Referências - [AWS Well-Architected Custom Lens — Official Documentation](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html) - [AWS Well-Architected Tool API Reference](https://docs.aws.amazon.com/wellarchitected/latest/APIReference/Welcome.html) - [AWS Glue Schema Registry — Developer Guide](https://docs.aws.amazon.com/glue/latest/dg/schema-registry.html) - [AWS Lake Formation — Data Filtering and Cell-Level Security](https://docs.aws.amazon.com/lake-formation/latest/dg/data-filtering.html) - [AWS Architecture Blog — Well-Architected for Data Analytics](https://aws.amazon.com/blogs/architecture/category/analytics/) - [Data Mesh — Delivering Data-Driven Value at Scale (Zhamak Dehghani)](https://www.oreilly.com/library/view/data-mesh/9781492092384/) - [AWS Step Functions — Express Workflows Pricing](https://aws.amazon.com/step-functions/pricing/) - [AWS Config — Conformance Packs](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html)