Well-Architected Agent: a revisão de arquitetura vira processo semanal

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.

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.

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.

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.