# Well-Architected Agent: a revisão de arquitetura vira processo semanal A AWS colocou em preview um agente que analisa contas, cruza sinais de Trusted Advisor, Compute Optimizer, Security Hub CSPM e Resilience Hub e devolve recomendações priorizadas por metas de negócio em texto livre. O que muda para o arquiteto não é o volume de achados, é que a meta escrita vira função de ranqueamento, e a lista de tipos de recurso não suportados vira ponto cego de auditoria. - URL: https://fernando.moretes.com/blog/well-architected-agent-a-revisao-de-arquitetura-vira-processo-semanal - Markdown: https://fernando.moretes.com/blog/well-architected-agent-a-revisao-de-arquitetura-vira-processo-semanal/article.md?lang=pt - Published: 2026-10-13T10:13:32.828Z - Category: AWS & Cloud - Tags: well-architected, ai-agents, finops, iam, governance, aws - Reading time: 6 min - Source: [Announcing AWS Well-Architected Agent, an AI-powered intelligence to optimize your cloud environment (preview)](https://aws.amazon.com/blogs/aws/announcing-aws-well-architected-agent-an-ai-powered-intelligence-to-optimize-your-cloud-environment-preview/) --- Durante anos, a revisão Well-Architected foi um evento: uma semana de workshop, uma planilha de riscos altos e médios, e depois seis meses sem ninguém abrir o relatório. Em 01/10/2026 a AWS colocou em preview o AWS Well-Architected Agent, que troca o evento por um ciclo: varredura agendada, até 30 recomendações por execução, renovação semanal. A pergunta que me interessa não é "o agente acerta?", é "quem triagem 30 achados por semana, e o que acontece com o que ele não consegue ver?". Depois de 16 anos operando plataformas financeiras na AWS, aprendi que ferramenta de achado sem dono de triagem vira só mais um painel vermelho que todo mundo aprende a ignorar. ## Os números que definem o desenho - **100**: contas por profile. varrendo todas as regiões comerciais a partir de us-east-1, us-east-2 ou us-west-2 - **30**: recomendações por execução. com cooldown de 7 dias entre execuções agendadas do mesmo profile - **5/dia**: revisões de IaC por profile. zip até 25 MB; pasta S3 até 100 MB, arquivo até 1 MB ## O sinal: um agregador com opinião Tirando a camada de IA, o que a AWS entregou é um agregador com opinião. A documentação de serviços relacionados é explícita: o agente ingere achados do **Trusted Advisor** como sinal de base, usa os sinais de rightsizing do **Compute Optimizer** para EC2, Lambda e RDS, consome **Security Hub CSPM**, dados de avaliação do **Resilience Hub** (com seus RTO/RPO) e o **Cost Optimization Hub**. Sobre isso ele acrescenta três coisas: priorização contra metas que você escreve, análise de trade-off entre pilares e remediação pronta (console, IaC atualizado, comandos `aws` CLI e runbooks do Systems Manager). As recomendações saem em três níveis. **Recurso:** uma instância, uma função, um banco, com impacto em dólar quando aplicável. **Aplicação:** achados consolidados sobre recursos relacionados, formato que a própria documentação marca como beta. **Arquitetura:** gerada a partir de templates CloudFormation, Terraform ou CDK enviados por zip ou URI de S3, antes do deploy. Dois detalhes operacionais mudam a qualidade do resultado. Sem o **Cost Explorer** habilitado, o agente estima custo pelo preço público, o que ignora Savings Plans, Reserved Instances e desconto contratual; em conta com EDP, o "impacto em dólar" pode sair inflado o bastante para inverter a priorização. E o acesso exige plano de suporte **Business+** ou superior: Business+ dá 2 profiles e 7 aplicações por profile; Enterprise On-Ramp, Enterprise e Unified Operations dão 10 e 30. Developer e Business ficam de fora. ## O que muda para quem desenha - **Meta virou configuração:** até 10 metas por profile, em texto livre, uma por pilar, e são elas que ordenam a fila. Meta mal escrita prioriza errado sem dar erro nenhum. - **Revisão contínua tem vazão fixa:** 30 recomendações por execução e cooldown de 7 dias significam um teto de triagem por profile. O gargalo passa a ser o time, não a ferramenta. - **Shift-left com cota:** 5 revisões de IaC por dia por profile não sustentam gate em todo pull request. Cabem no merge para a branch de release. - **Criticidade é declarada, não inferida:** o contexto da aplicação aceita `MISSION_CRITICAL`, `BUSINESS_CRITICAL`, `NON_CRITICAL` e `TEST_DEVELOPMENT`. Quem não declara recebe recomendação calibrada para o caso médio. - **Silêncio não é conformidade:** a lista de tipos não suportados inclui `AWS::WAFv2::WebACL`, `AWS::Organizations::Policy` e `AWS::IAM::RolePolicy`. Ausência de achado ali não prova nada. ## O ponto cego que importa num banco A página de cotas traz uma tabela longa de tipos de recurso CloudFormation que o agente não analisa. A maior parte é periférica (IoT Analytics, DeviceFarm, Evidently). Mas alguns itens são exatamente os controles que um auditor olha primeiro num ambiente sob BACEN 4.893 ou PCI-DSS: - `AWS::WAFv2::WebACL`, `WebACLAssociation`, `IPSet` e `RuleGroup`: a borda inteira do WAF. - `AWS::Organizations::Policy`: as SCPs, ou seja, o perímetro de dados da organização. - `AWS::IAM::RolePolicy`, `UserPolicy` e `GroupPolicy`: políticas inline, onde costuma morar o `"Action": "*"` que ninguém lembra de ter escrito. - `AWS::OpenSearchService::Domain`, `AWS::Shield::Protection` e as configurações do próprio Security Hub. O modo de falha aqui é silencioso. O relatório chega limpo no pilar de segurança, alguém leva o print para o comitê de risco, e a ausência de achado sobre WAF é lida como WAF bem configurado. Não é: é WAF não analisado. A mitigação é barata e precisa ser explícita. Mantenha esses controles cobertos por AWS Config com conformance packs e pelo Security Hub CSPM direto, fora do agente, e escreva no documento de governança quais tipos o agente não cobre e qual ferramenta cobre cada um. A lista está marcada como preview e deve encolher, então revise a cada trimestre em vez de assumir que ela é estável. ## Onde o agente lê, de onde ele escreve Cadeia de roles em conta dedicada, sinais de entrada e caminhos de remediação. Só o caminho por IaC volta para o pipeline. ### 🔐 AWS: Conta de tooling dedicada - Agent profile us-east-1 · 10 metas (ai) - Execution role trust wellarchitected.amazonaws.com (security) - CloudTrail API wellarchitected:* (security) ### 🟧 AWS: Contas de workload (até 100) - Access role WellArchitectedAgentResourceScanning (security) - Recursos todas as regiões comerciais (compute) ### 📡 AWS: Sinais de entrada - Trusted Advisor Security Hub CSPM (data) - Compute Optimizer Cost Optimization Hub (data) - Cost Explorer sem ele: preço público (data) ### 📤 Saída: Remediação - IaC atualizado PR no repositório (ci) - AWS CLI / SSM runbook só em sandbox (external) ### Fluxos - profile -> exec: assume - exec -> access: sts:AssumeRole, ExternalId = ARN do profile - access -> res: leitura de configuração - ta -> profile: achados de base - co -> profile: rightsizing e custo - ce -> profile: custo real por recurso - profile -> ct: auditoria - profile -> owner: 30 recomendações/semana - owner -> iac: aceita e versiona - owner -> cli: testa fora de prod ## IAM: o desenho é bom, o default nem tanto O modelo de acesso merece crédito. Em vez de service-linked role, o agente usa roles gerenciadas pelo cliente em cadeia: uma **execution role** na conta do profile, com trust para `wellarchitected.amazonaws.com` e permissão só de `sts:AssumeRole`, e uma **access role** em cada conta de workload, com a managed policy `WellArchitectedAgentResourceScanning`, somente leitura. O ARN do profile entra como external ID, o que fecha o confused deputy, e há checagem de `iam:PassRole` na criação. A documentação afirma que nenhuma das duas roles permite modificar recurso. O onboarding é opt-in por conta. Dito isso, três ajustes que eu faria antes de ligar em produção: **Conta dedicada:** a própria AWS recomenda hospedar o profile numa conta sem workload. Num ambiente com Control Tower, isso é a conta de tooling ou de auditoria, nunca a management account. **Trust pelo ARN exato:** use o ARN da execution role, com o path `service-role/` que o console cria, e não o root da conta. Distribua as access roles por StackSets com o mesmo nome em todas as contas (o padrão de nome comum que o profile aceita) para que revogar seja uma operação, não cem. **Residência do processamento:** o profile só pode morar em `us-east-1`, `us-east-2` ou `us-west-2`, embora varra `sa-east-1`. Metadado de configuração e tag saem da região para análise. Se sua política de tags carrega nome de cliente ou CPF em tag (já vi), isso vira conversa com o DPO sob a LGPD antes de virar conversa com o auditor. ## Quatro caminhos de remediação, quatro custos de manutenção | Critério | Console | IaC atualizado | AWS CLI | SSM runbook | | --- | --- | --- | --- | --- | | Gera drift | Sim | Não | Sim | Sim, salvo se o runbook atualizar o código | | Trilha de revisão | Só CloudTrail | Pull request com aprovação | Só CloudTrail | Histórico de execução do SSM | | Onde eu uso | Entender o achado | Produção | Sandbox | Ação repetível sem estado em IaC, ex. snapshot órfão | ## Como eu posicionaria isso hoje O agente não substitui a revisão Well-Architected feita por gente, ele muda o que a revisão humana precisa cobrir. O trabalho mecânico (instância superdimensionada, bucket sem versionamento, RDS single-AZ marcado como `MISSION_CRITICAL`) sai da pauta do workshop. Sobra para as pessoas o que o agente declaradamente não vê: SCPs, WAF, políticas inline, e as decisões de arquitetura que não aparecem em configuração nenhuma, como o motivo de um fluxo de liquidação ser síncrono. Na prática, três decisões de desenho: **Um profile por domínio regulatório, não por time:** com 10 profiles no Enterprise, separe o que tem SLO e regime distintos (meios de pagamento, dados, plataforma interna). No Business+, com 2 profiles e 7 aplicações, a escolha é mais dura: produção regulada num, todo o resto no outro. **Metas versionadas em repositório:** as metas em texto livre são parâmetro de ranqueamento. Trate como código: arquivo no repositório de plataforma, aplicado via API do namespace `wellarchitected`, com revisão. Meta como "reduzir custo" é fraca; "reduzir custo de compute não produtivo em 20% sem tocar RTO de 15 minutos do core" dá ao agente um trade-off para respeitar. **Fila com dono e SLA:** 30 recomendações por semana são cerca de 120 por mês por profile. Sem um dono que marque concluído ou suprima com motivo, o backlog cresce linear e a ferramenta perde crédito em dois meses. Eu ligaria primeiro só cost e resilience, onde o custo de erro é baixo, e só depois security, com a lista de não suportados ao lado. ## Anti-padrões que já dá para prever - **Aplicar o comando de CLI em produção:** resolve o achado e cria drift; o próximo `terraform apply` desfaz a correção e ninguém percebe até a próxima varredura. - **Ler pilar de segurança limpo como atestado:** com WAF, SCP e política inline fora do escopo, relatório limpo é cobertura parcial, não conformidade. - **Priorizar por dólar sem Cost Explorer:** o agente usa preço público e ignora Savings Plans e EDP; a fila de custo sai ordenada por um número que não é o seu. - **Profile na management account:** concentra a role que assume acesso em 100 contas no lugar de maior blast radius da organização. - **Gate de IaC em todo PR:** 5 revisões por dia por profile esgotam antes do almoço; o gate falha aberto ou trava o time. > **A meta é o novo prompt:** O texto das metas define a ordem da fila de remediação de 100 contas. Isso é configuração de produção com efeito em dinheiro e risco, escrita em linguagem natural e sem validação. Quem edita meta precisa do mesmo controle de mudança de quem edita SCP. > **Nota do curador:** Eu ligaria o agente nesta semana numa conta de tooling dedicada, com cost e resilience apenas, e com o Cost Explorer habilitado antes da primeira execução. A access role sai por StackSets, trust no ARN exato da execution role, e as metas ficam num arquivo versionado. A lição que eu trago de anos de Trusted Advisor e Security Hub: o custo de uma ferramenta de achados não é a licença, é a triagem semanal que alguém precisa sustentar por anos. Se não houver um nome dono da fila, prefiro não ligar. ## Veredito Adote agora se você já tem plano Business+ ou superior, Control Tower com conta de tooling e um time de plataforma com capacidade de triar cerca de 120 itens por mês por profile: o agente tira o trabalho mecânico da revisão e entrega remediação em IaC que cabe no seu pipeline. Espere se a sua necessidade principal for evidência de segurança para auditoria regulatória: enquanto WAF, SCPs e políticas inline estiverem fora do escopo, ele complementa AWS Config e Security Hub CSPM, não os substitui. Em qualquer caso, remediação em produção só pelo caminho de IaC. **Rating:** Adotar com escopo / Adopt with scope ## Referências - [AWS News Blog: Announcing AWS Well-Architected Agent (preview)](https://aws.amazon.com/blogs/aws/announcing-aws-well-architected-agent-an-ai-powered-intelligence-to-optimize-your-cloud-environment-preview/) - [What is AWS Well-Architected Agent (preview)?](https://docs.aws.amazon.com/wellarchitected/latest/userguide/agent.html) - [AWS Well-Architected Agent access model (IAM)](https://docs.aws.amazon.com/wellarchitected/latest/userguide/security-iam-agent.html) - [AWS Well-Architected Agent quotas and limits](https://docs.aws.amazon.com/wellarchitected/latest/userguide/agent-quotas.html) - [AWS Well-Architected Agent related services](https://docs.aws.amazon.com/wellarchitected/latest/userguide/agent-related-services.html) - [AWS Well-Architected Agent concepts and terminology](https://docs.aws.amazon.com/wellarchitected/latest/userguide/agent-concepts.html) - [SDxCentral: AWS unveils Well-Architected AI agent](https://www.sdxcentral.com/news/aws-unveils-well-architected-ai-agent-that-acts-like-a-cloud-architect/)