Lab 60 — Well-Architected review da sua própria arquitetura

⏱ 40 min·⭐ 150 XP

O problema, e a empresa que o tem

A Cadência chegou a 900 lojas depois de cinquenta e nove laboratórios de decisão: instrumentação correlacionada (L51), orçamento de erro com alarme acionável (L52), pipeline sem chave estática (L54), estado remoto do Terraform (L55), um ambiente por conta (L56), caos controlado numa AZ (L57) e failover regional ensaiado (L58). Cada decisão foi boa isoladamente, e cada uma foi tomada, documentada e testada dentro do laboratório que a motivou.

O gatilho para este laboratório não foi um incidente. Foi um questionário de segurança: uma rede de varejo maior quer contratar a API de pedidos da Cadência como serviço white-label, e o time de compras deles pediu evidência de revisão formal de arquitetura — não uma lista de serviços usados, um documento que mostre PERGUNTA respondida, RISCO classificado e PLANO com prazo. Ninguém na Cadência tinha isso pronto, porque ninguém tinha comparado as decisões dos 59 laboratórios contra um framework, todas juntas, de uma vez.

A pergunta que a diretoria fez foi direta: "se um auditor perguntasse por que confiamos nessa arquitetura, o que responderíamos além de é assim que sempre funcionou?" Este laboratório é a resposta — não como desenho novo, mas como o processo que transforma 59 decisões dispersas num documento com risco classificado, dono e prazo.

NívelAvançado — depende do L52, L58 e L59, e pressupõe o resto da banda 6 no ar

Pré-requisitosL52, L58 e L59 lidos (ou no ar); acesso de administrador na conta de exemplo

Tempo estimadoEstudo 45 min · workshop de revisão 3 a 4 h · automação da cadência 1 h

Custo relativoZero de ferramenta — a AWS não cobra pelo Well-Architected Tool; o custo real é hora de pessoas na sala

ServiçosAWS Well-Architected Tool, IAM, EventBridge Scheduler, SNS, S3

Volume atual900 lojas, seis pessoas na plataforma, 59 laboratórios de decisão já tomada

Requisito declaradorevisão com evidência real, plano priorizado, comparável na próxima revisão

Hipótese declaradaas respostas avaliam a arquitetura tal como os laboratórios anteriores a deixaram; nenhuma decisão é refeita aqui, só avaliada

Ao final você temworkload registrado, seis pilares respondidos com evidência citada, milestone salvo e plano de melhoria com pelo menos 3 riscos altos e prazo

⚠️

O que este laboratório NÃO é

Não é uma reforma da arquitetura da Cadência. Nenhum recurso dos 59 laboratórios anteriores muda aqui — a AWS Well-Architected Tool lê decisão, não aplica infraestrutura. Também não é uma auditoria de conformidade formal (SOC 2, ISO 27001): o relatório que sai daqui é insumo para esse tipo de auditoria, não o substituto dela. E não é preencher até o relatório sair todo verde — um relatório sem nenhum risco alto depois de 59 laboratórios escritos por pessoas diferentes, em ritmos diferentes, é sinal de revisão malfeita, não de arquitetura perfeita.

O que você vai conseguir fazer

Objetivos verificáveis: cada um se prova com um comando ou uma resposta registrada, não com a sensação de ter revisado.

Registrar a Cadência como workload no AWS Well-Architected Tool, com o lens padrão do framework.
Responder pelo menos uma pergunta de cada um dos seis pilares citando a evidência real de um laboratório específico, não uma frase genérica.
Classificar cada resposta como risco alto, médio ou nenhum, e explicar a diferença entre as duas categorias de risco.
Registrar por escrito, com o motivo correto da API, pelo menos um risco que a Cadência aceita conscientemente em vez de mitigar agora.
Gerar um plano de melhoria com os riscos altos ordenados antes dos médios, cada um com dono e prazo.
Salvar um milestone que congele respostas e contagem de risco num ponto no tempo, para a próxima revisão comparar contra ele.
Automatizar o lembrete da próxima revisão, sem depender de alguém lembrar sozinho.
Justificar por que pelo menos um risco fica classificado como ALTO mesmo sem solução prevista nos laboratórios já escritos.

O que a certificação cobra disto

Conceito	Certificação	Como aparece aqui	O que dominar
Os seis pilares	SAP-C02	cada resposta classificada por pilar	nomear os seis de cor e o que cada um pergunta
Risco alto vs risco médio (HRI/MRI)	SAP-C02	cada resposta gera uma contagem de risco por pilar	a diferença entre prática fundacional (alto) e prática habilitadora (médio)
Lens e lens customizado	SAP-C02	lens padrão AWS Well-Architected Framework aplicado	quando um lens customizado se justifica — setor regulado, arquitetura própria
Milestone e comparação ao longo do tempo	SAP-C02, DOP-C02	milestone salvo depois da primeira revisão	milestone é imutável; a revisão seguinte gera um novo, não edita o antigo
Well-Architected Tool vs Trusted Advisor	SAP-C02	a ferramenta é citada, não substituída	Trusted Advisor checa configuração; o WA Tool avalia decisão e trade-off, com contexto humano
Prioridade do plano de melhoria	SAP-C02	risco alto ordenado antes de risco médio	por que tratar um risco médio antes de um alto é priorização invertida

ConceitoOs seis pilares

CertificaçãoSAP-C02

Como aparece aquicada resposta classificada por pilar

O que dominarnomear os seis de cor e o que cada um pergunta

ConceitoRisco alto vs risco médio (HRI/MRI)

CertificaçãoSAP-C02

Como aparece aquicada resposta gera uma contagem de risco por pilar

O que dominara diferença entre prática fundacional (alto) e prática habilitadora (médio)

ConceitoLens e lens customizado

CertificaçãoSAP-C02

Como aparece aquilens padrão AWS Well-Architected Framework aplicado

O que dominarquando um lens customizado se justifica — setor regulado, arquitetura própria

ConceitoMilestone e comparação ao longo do tempo

CertificaçãoSAP-C02, DOP-C02

Como aparece aquimilestone salvo depois da primeira revisão

O que dominarmilestone é imutável; a revisão seguinte gera um novo, não edita o antigo

ConceitoWell-Architected Tool vs Trusted Advisor

CertificaçãoSAP-C02

Como aparece aquia ferramenta é citada, não substituída

O que dominarTrusted Advisor checa configuração; o WA Tool avalia decisão e trade-off, com contexto humano

ConceitoPrioridade do plano de melhoria

CertificaçãoSAP-C02

Como aparece aquirisco alto ordenado antes de risco médio

O que dominarpor que tratar um risco médio antes de um alto é priorização invertida

💡

Onde isto costuma ser cobrado errado

A pergunta clássica descreve uma equipe que concluiu a revisão e pede o próximo passo correto. A resposta esperada não é "corrigir todos os riscos altos imediatamente" — é priorizar por dono e prazo dentro do plano de melhoria, porque a ferramenta existe para ORDENAR trabalho, não para exigir que ele seja feito de uma vez.

Requisitos, e como cada um muda a revisão

Requisito não funcional que não aparece em nenhum campo da revisão é intenção. A coluna da direita é onde cada um deixou marca — na revisão, não na infraestrutura, porque nenhuma peça dos 59 laboratórios muda aqui.

Requisito	Valor declarado	O que ele muda na revisão
Evidência real, não opinião	obrigatório em toda resposta aplicável	cada Notes cita o laboratório e o número medido, nunca uma frase genérica copiada do texto do lens
Cadência sem depender de lembrete	trimestral	EventBridge Scheduler dispara a task de revisão; SNS avisa o plantão do L52 em vez de confiar na memória de alguém
Sem orçamento para resolver tudo agora	só priorizar	o plano ordena risco alto antes de médio, com dono e prazo — não promete resolver os dois no mesmo trimestre
Risco aceito fica registrado por escrito	obrigatório quando aplicável	Reason = BUSINESS_PRIORITIES ou ARCHITECTURE_CONSTRAINTS entra na resposta, comparável na próxima revisão em vez de decidido de novo
Relatório exportável para o cliente	obrigatório	o milestone salvo vira arquivo no S3, entregável sem dar acesso à conta AWS da Cadência a quem pediu evidência
A revisão não muda infraestrutura em produção	obrigatório	nenhum recurso dos 59 laboratórios é tocado — a revisão é leitura e registro, nunca `terraform apply` sobre o que já existe

RequisitoEvidência real, não opinião

Valor declaradoobrigatório em toda resposta aplicável

O que ele muda na revisãocada Notes cita o laboratório e o número medido, nunca uma frase genérica copiada do texto do lens

RequisitoCadência sem depender de lembrete

Valor declaradotrimestral

O que ele muda na revisãoEventBridge Scheduler dispara a task de revisão; SNS avisa o plantão do L52 em vez de confiar na memória de alguém

RequisitoSem orçamento para resolver tudo agora

Valor declaradosó priorizar

O que ele muda na revisãoo plano ordena risco alto antes de médio, com dono e prazo — não promete resolver os dois no mesmo trimestre

RequisitoRisco aceito fica registrado por escrito

Valor declaradoobrigatório quando aplicável

O que ele muda na revisãoReason = BUSINESS_PRIORITIES ou ARCHITECTURE_CONSTRAINTS entra na resposta, comparável na próxima revisão em vez de decidido de novo

RequisitoRelatório exportável para o cliente

Valor declaradoobrigatório

O que ele muda na revisãoo milestone salvo vira arquivo no S3, entregável sem dar acesso à conta AWS da Cadência a quem pediu evidência

RequisitoA revisão não muda infraestrutura em produção

Valor declaradoobrigatório

O que ele muda na revisãonenhum recurso dos 59 laboratórios é tocado — a revisão é leitura e registro, nunca `terraform apply` sobre o que já existe

💡

PillarPriorities decide a ORDEM, não decide o risco

O campo `PillarPriorities` do workload muda em qual ordem os pilares aparecem no relatório e no plano de melhoria — não muda se uma resposta é risco alto ou médio. Colocar Confiabilidade e Segurança primeiro não reclassifica um risco de Sustentabilidade para baixo; só decide o que o leitor do relatório vê primeiro.

Arquitetura mínima: a Cadência sem nenhuma revisão formal

A arquitetura abaixo é, literalmente, o que já existe hoje — não uma simplificação didática. É por isso que o defeito é visível sem precisar exagerar nada: a decisão está boa, e ela só existe onde ninguém mais consegue lê-la.

A Cadência sem nenhuma revisão formal

O que está no ar, depois de 59 laboratóriosVPC

API da Cadência (ECS Fargate)roda em produção desde o L01; nenhuma peça de infraestrutura muda nesta revisão — ela lê decisão, não aplica configuração

Aurora Global, failover ensaiado (L58)a decisão de warm standby está no código Terraform do L58, não em nenhum documento que alguém compare contra os seis pilares

Onde cada decisão mora hoje

Head de plataformacarrega de cabeça por que 14,4x foi o limiar do burn rate do L52 — se essa pessoa sair da empresa, a decisão sai junto

"Plano de DR — Cadência.pdf", 2 anos sem revisãodescreve o roteiro manual que o failover gerenciado do L58 já substituiu; ninguém voltou para atualizar o arquivo depois do ensaio

Runbook de plantão informalmora fixado num canal de chat, não em lugar que sobrevive a alguém sair do time ou apagar a mensagem por engano

O que nunca aconteceu

Pergunta formal, pilar por pilarnenhuma das seis perguntas do framework foi feita explicitamente contra o Aurora Global, os 3 SLOs do L52 ou a disciplina de custo — decisão boa sem comparação escrita ainda é risco não classificado

→ por que está assim: só na memória de uma pessoa
→ a decisão real diverge do documento antigo
→ risco de plantão nunca classificado como alto ou médio
→ conhecimento tácito nunca virou resposta comparável

Compute
Banco de dados
Fora da AWS
Conceito de arquitetura

Depois de 59 laboratórios cada decisão foi boa e testada isoladamente — mas nenhuma foi comparada, pilar por pilar, contra o framework nem contra as outras. O risco aqui não é decisão ruim: é decisão nunca classificada, e ela só existe na cabeça de quem a tomou.

🚨

A falha que o milestone não denuncia sozinho

Se ninguém atualiza uma resposta depois de mitigar o risco real na infraestrutura, o próximo milestone congela a MESMA classificação de risco de antes — e um relatório que mostra "risco alto" quando o risco já foi tratado é tão enganoso quanto um que mostra "risco baixo" quando não foi. A ferramenta não audita a conta: ela registra o que alguém digitou. É por isso que este laboratório trata "revisão" como processo contínuo, não como tarefa riscada uma vez.

Arquitetura para produção: o workload revisado, com plano priorizado

Cada peça nova aqui rastreia a um requisito da seção anterior: o workload existe porque a evidência precisa de um lugar formal; o milestone existe porque a cadência não pode depender de lembrete; o risco alto de sustentabilidade existe porque tratar honestamente o que ainda não foi avaliado é parte do requisito de evidência real.

O mesmo sistema, com a revisão Well-Architected completa

O workload registrado

AWS Well-Architected Tool (workload da Cadência)ícone mais próximo do catálogo desta plataforma — não existe chave 'wellarchitected' ainda; relatado como pendência ao final do módulo

Lens padrão: AWS Well-Architected Frameworkaplicado automaticamente a todo workload; carrega as perguntas dos seis pilares que a Cadência vai responder

As perguntas respondidas com evidência dos laboratórios anteriores

Confiabilidade: o failover foi testado?resposta cita o L58 — RTO e RPO medidos num ensaio real, não estimados num documento

Custo: há rightsizing antes de compromisso?resposta segue a disciplina que o L59 estabeleceu — medir com o Compute Optimizer antes de qualquer Savings Plan

Excelência operacional: o alarme aciona alguém?resposta cita o L52 — 3 SLOs com burn rate substituíram 40 alarmes que ninguém mais lia

O que a revisão expõe

Risco médio: duas regiões, não três (L58)dívida que o próprio L58 já declarou por escrito; a revisão transforma essa nota solta em risco registrado, com dono e prazo

Risco ALTO: sustentabilidade sem nenhuma respostanão é uma resposta ruim — é a ausência total de pergunta respondida nos 59 laboratórios anteriores, e é isso que o framework classifica como prática fundacional ausente

O plano que sobrevive à saída de alguém do time

Milestone: "Revisão 2026-Q3"congela respostas e contagem de risco num ponto no tempo; é contra ele que a revisão de janeiro compara, não contra a memória de quem participou

Plano de melhoria priorizadocada risco alto ganha dono e prazo antes de qualquer risco médio — ordem que a própria contagem de risco por pilar devolve

→ lens carrega as perguntas dos seis pilares
→ pergunta de confiabilidade instanciada
→ resposta aponta a dívida de rede já registrada no L58
→ pergunta de custo instanciada
→ resposta com evidência do L59 entra como risco baixo
→ pergunta de excelência operacional instanciada
→ resposta com evidência do L52 entra como risco baixo
→ pilar sem nenhuma resposta em 59 laboratórios entra como risco alto
→ risco médio da terceira região entra no plano com prazo
→ milestone vira cronograma de mitigação priorizado

Gestão e governança
Conceito de arquitetura

As seis perguntas foram respondidas com evidência real: duas saem risco médio, com plano e prazo; uma sai risco ALTO porque nenhum dos 59 laboratórios chegou a tratar aquele pilar. O milestone garante que a próxima revisão compara contra ESTE ponto, não do zero.

Como a revisão funciona ponta a ponta

🗺️ Da evidência dispersa ao milestone comparável

1. Reunir evidênciaAntes de abrir o console, o time de plataforma lista, laboratório por laboratório, qual decisão responde a qual pergunta previsível do framework. É trabalho de leitura, não de ferramenta — e é o que falta quando uma revisão sai rasa.

2. CreateWorkloadRegistra a Cadência como workload: Environment = PRODUCTION, o lens padrão, ReviewOwner e ao menos uma AWS Region declarada — a API rejeita a chamada se nem AwsRegions nem NonAwsRegions vier preenchido.

3. UpdateAnswer, pergunta por perguntaPara cada pergunta relevante, SelectedChoices marca a prática adotada e Notes cita o laboratório fonte — "RTO e RPO medidos no L58: 4h47 e 2.140 ms". Pergunta que não se aplica recebe IsApplicable = false com um Reason, nunca fica sem resposta nenhuma.

4. GetLensReview agrega o riscoRiskCounts soma por pilar dentro de PillarReviewSummaries. É esse número — não a sensação de "acho que está bem" — que decide o que entra primeiro no plano de melhoria.

5. Montar o plano de melhoriaOrdenar por classificação de risco (alto antes de médio), atribuir dono e prazo a cada item. Risco sem dono não é plano, é lista de desejos — a mesma falha que a tabela de requisitos da série já evita noutro lugar.

6. CreateMilestoneCongela respostas e contagem de risco com um nome único dentro do workload, como "Revisão 2026-Q3". É o que a próxima revisão vai comparar contra — sem ele, cada revisão recomeça do zero.

7. Exportar e compartilharO relatório sai do console e vai para quem pediu — o cliente enterprise, neste caso — sem que ele precise de acesso nenhum à conta AWS da Cadência.

8. Agendar a próximaO EventBridge Scheduler dispara um lembrete trimestral. Sem isso, a revisão que acabou de sair corre o mesmo risco do documento de DR do L58: existir uma vez e nunca mais ser olhada.

O corpo de uma chamada real de UpdateAnswer para a pergunta de confiabilidade sobre teste de recuperação regional, com a evidência do L58 citada na nota:

update-answer-confiabilidade.json

{
  "SelectedChoices": ["reliability_test_failover"],
  "Notes": "Failover regional ensaiado no L58 (Aurora Global, warm standby): RTO medido de 4h47 e RPO de 2.140 ms no ensaio de 07/ago/2026. Duas regioes, nao tres -- divida aceita por escrito no mesmo laboratorio, tratada aqui como risco medio com prazo de reavaliacao.",
  "IsApplicable": true
}
// Os IDs de escolha ('reliability_test_failover') sao ILUSTRATIVOS: o conjunto real
// de ChoiceId por pergunta pertence a versao do lens aplicada e se le com GetAnswer
// antes de enviar UpdateAnswer -- nunca se copia de outra pergunta ou de outro lens.
// A chamada completa tambem exige WorkloadId (32 caracteres hex) e LensAlias na URL,
// nao no corpo: PATCH /workloads/{WorkloadId}/lensReviews/{LensAlias}/answers/{QuestionId}

⚠️

GetLensReview sem número de milestone lê o estado ATUAL

Chamar `GetLensReview` sem `MilestoneNumber` devolve as respostas e o risco de AGORA, que podem já ter mudado desde o último milestone salvo. Para comparar com uma revisão passada, o número do milestone tem de ser explícito na chamada — omiti-lo não é "o milestone mais recente", é "sem milestone nenhum".

As decisões, e o que se perde em cada uma

📋 A Cadência tem 59 laboratórios de decisão já tomada, seis pessoas na plataforma, e um cliente enterprise pedindo evidência de revisão formal antes de assinar um contrato maior. Não há orçamento para contratar uma revisão paga conduzida por parceiro AWS, e a diretoria quer algo comparável na próxima revisão, não um documento estático.

✓ AWS Well-Architected Tool, com evidência citada por laboratório e cadência trimestral automatizada

É gratuito — não há cobrança pela ferramenta, só pelos recursos que ela avalia — e produz um artefato estruturado (workload, resposta por pergunta, risco classificado, milestone) que sobrevive à saída de qualquer pessoa do time. Substitui exatamente o que a Cadência tinha: nada formal, e o conhecimento na cabeça de quem escreveu cada laboratório. Contratar uma revisão paga faz sentido quando o objetivo é uma segunda opinião externa ou entrada em mercado que exige certificação de terceiro — não é o caso aqui, e pagar por isso agora seria comprar credibilidade externa para um processo que a própria equipe ainda não tinha internalizado.

Alt: Checklist próprio em planilha — não gera risco classificado nem comparação formal entre revisões; cada pessoa preenche diferente, e a planilha não sobrevive a quem a criou sair do time.

Alt: Revisão paga conduzida por AWS Partner — traz segunda opinião de fato, e existe apoio de crédito da AWS para parte do custo em alguns programas — mas cobra agendamento e não resolve o problema real, que é a Cadência nunca ter feito a PRIMEIRA revisão nem ter o hábito de repeti-la.

Alt: Não revisar formalmente, confiar na experiência do time — é o desenho mínimo deste laboratório, e é exatamente o que o cliente enterprise recusou aceitar como resposta.

Alt: Usar só o AWS Trusted Advisor — verifica configuração — bucket público, instância parada, certificado vencendo — mas não avalia decisão nem trade-off; não responde "você testou o failover", porque essa pergunta não tem resposta em nenhuma configuração isolada.

Construir: quem pode revisar, e quem pode aceitar um risco

Diferente dos outros 59 laboratórios, este não tem Terraform para o objeto central. O provedor oficial da AWS para Terraform não tem recurso para AWS Well-Architected Tool — o pedido da comunidade (issue #34844 no repositório `hashicorp/terraform-provider-aws`) foi fechado como "not planned" pelo mantenedor em dezembro de 2023. O que TEM recurso, e entra em Terraform, é a IAM de quem pode operar a revisão.

iam-revisao.tf

# iam-revisao.tf -- menor privilegio para quem conduz e quem aceita risco

# CreateWorkload cria um recurso que ainda nao existe: nao ha ARN para restringir
# a chamada a um workload especifico, porque o workload nasce DESSA chamada. E o
# mesmo raciocinio do ecr:GetAuthorizationToken no L03 -- operacao sem alvo previo
# nao aceita Resource especifico, e a AWS Service Authorization Reference confirma
# isto para wellarchitected:CreateWorkload.
data "aws_iam_policy_document" "revisor" {
  statement {
    sid       = "CriarWorkload"
    effect    = "Allow"
    actions   = ["wellarchitected:CreateWorkload", "wellarchitected:ListWorkloads"]
    resources = ["*"]
  }

  # As acoes abaixo JA aceitam Resource especifico (arn do workload), diferente
  # da criacao. Restringir aqui e o que separa "pode revisar A CADENCIA" de
  # "pode revisar QUALQUER workload da conta".
  statement {
    sid    = "OperarWorkloadDaCadencia"
    effect = "Allow"
    actions = [
      "wellarchitected:GetWorkload",
      "wellarchitected:UpdateWorkload",
      "wellarchitected:GetLensReview",
      "wellarchitected:GetAnswer",
      "wellarchitected:ListAnswers",
      "wellarchitected:UpdateAnswer",
      "wellarchitected:CreateMilestone",
      "wellarchitected:ListMilestones",
      "wellarchitected:GetMilestone",
    ]
    resources = [aws_ssm_parameter.workload_arn.value]
  }
}

# Papel separado para quem tem autoridade de aceitar um risco alto sem mitigar --
# marcar IsApplicable=false com Reason=BUSINESS_PRIORITIES ou
# ARCHITECTURE_CONSTRAINTS e uma decisao de negocio, nao uma configuracao tecnica,
# e por isso e um papel a parte do revisor comum.
data "aws_iam_policy_document" "aprovador_de_risco_aceito" {
  statement {
    sid       = "AceitarRiscoComJustificativa"
    effect    = "Allow"
    actions    = ["wellarchitected:UpdateAnswer"]
    resources  = [aws_ssm_parameter.workload_arn.value]
    condition {
      test     = "StringEquals"
      variable = "aws:PrincipalTag/papel"
      values   = ["head-de-plataforma", "cto"]
    }
  }
}

resource "aws_iam_policy" "revisor" {
  name   = "${var.projeto}-wellarchitected-revisor"
  policy = data.aws_iam_policy_document.revisor.json
}

resource "aws_iam_policy" "aprovador_de_risco_aceito" {
  name   = "${var.projeto}-wellarchitected-aprovador-risco"
  policy = data.aws_iam_policy_document.aprovador_de_risco_aceito.json
}

# O ID do workload so existe DEPOIS do CreateWorkload (chamado pelo SDK, nao pelo
# Terraform -- ver a secao seguinte). Este parametro e escrito pela task de
# revisao na primeira execucao, e as policies acima leem dele a partir da segunda.
resource "aws_ssm_parameter" "workload_arn" {
  name  = "/${var.projeto}/wellarchitected/workload-arn"
  type  = "String"
  value = "arn:aws:wellarchitected:${var.regiao}:${data.aws_caller_identity.atual.account_id}:workload/PLACEHOLDER"

  lifecycle {
    ignore_changes = [value] # a task de revisao atualiza o valor real via SDK
  }
}

data "aws_caller_identity" "atual" {}

💡

Por que dois papéis, e não um só

Responder uma pergunta com evidência é trabalho técnico; aceitar um risco alto sem mitigar é decisão de negócio. Misturar os dois papéis deixaria qualquer pessoa com acesso de revisor livre para classificar um risco real como "fora de escopo" sem segunda opinião — é o mesmo raciocínio de menor privilégio que o L41 já aplicou a infraestrutura, agora aplicado a decisão.

Construir: o workload e as respostas, com evidência real dos 59 laboratórios

O registro do workload e cada resposta acontecem via SDK, chamando a API do AWS Well-Architected Tool diretamente — não há camada de IaC entre o código e a API, porque essa camada não existe.

RegistrarWorkload.cs

// RegistrarWorkload.cs -- o Terraform nao tem este recurso; o SDK fala com a API

using Amazon.WellArchitected;
using Amazon.WellArchitected.Model;

var cliente = new AmazonWellArchitectedClient();

// Environment so aceita PRODUCTION ou PREPRODUCTION -- nao existe valor
// intermediario. AwsRegions OU NonAwsRegions e obrigatorio; sem nenhum dos dois
// a chamada falha com ValidationException.
var criar = new CreateWorkloadRequest
{
    WorkloadName      = "cadencia-api-pedidos",
    Description       = "API de pedidos da Cadencia -- 59 laboratorios de decisao, "
                       + "revisada pela primeira vez em 2026-Q3",
    Environment        = WorkloadEnvironment.PRODUCTION,
    Lenses             = new List<string> { "wellarchitected" }, // lens padrao da AWS
    AwsRegions         = new List<string> { "us-east-1" },
    ReviewOwner        = "plataforma@cadencia.example",
    PillarPriorities   = new List<string> { "reliability", "security" }, // ordem do plano
    ClientRequestToken = Guid.NewGuid().ToString(), // idempotencia: reenvio nao duplica
};

var workload = await cliente.CreateWorkloadAsync(criar);
Console.WriteLine($"workload criado: {workload.WorkloadId}");

// Cada resposta cita o laboratorio fonte na Notes -- e o que distingue "resposta
// escrita rapido copiando o texto do lens" de "resposta com evidencia real". As
// tres abaixo usam achado JA MEDIDO nos laboratorios anteriores, nao opiniao.
var respostas = new[]
{
    new UpdateAnswerRequest
    {
        WorkloadId = workload.WorkloadId,
        LensAlias  = "wellarchitected",
        QuestionId = "REL_02", // "Como voce projeta a resiliencia da sua carga de trabalho?"
        SelectedChoices = new List<string> { "reliability_test_failover" },
        Notes = "Failover regional ensaiado no L58 (Aurora Global, warm standby): RTO "
              + "medido de 4h47 e RPO de 2.140 ms. Duas regioes, nao tres -- divida "
              + "aceita por escrito no mesmo laboratorio.",
        IsApplicable = true,
    },
    new UpdateAnswerRequest
    {
        WorkloadId = workload.WorkloadId,
        LensAlias  = "wellarchitected",
        QuestionId = "COST_02", // "Como voce governa o uso de recursos na nuvem?"
        SelectedChoices = new List<string> { "cost_rightsizing_before_commitment" },
        Notes = "A frota de EC2 da Rotamix (L59) demonstrou o padrao que a Cadencia "
              + "segue: Compute Optimizer antes de qualquer Savings Plan. A Cadencia "
              + "ainda nao comprou compromisso -- nada para verificar ainda, risco baixo.",
        IsApplicable = true,
    },
    new UpdateAnswerRequest
    {
        WorkloadId = workload.WorkloadId,
        LensAlias  = "wellarchitected",
        QuestionId = "OPS_06", // "Como voce monitora sua carga de trabalho para atingir os resultados de negocio?"
        SelectedChoices = new List<string> { "ops_actionable_alerts" },
        Notes = "3 SLOs com burn rate multi-janela (L52) substituiram 40 alarmes que "
              + "ninguem lia. Tempo ate confirmar incidente caiu de ate 6h para 65 min "
              + "medidos no proprio laboratorio.",
        IsApplicable = true,
    },
    new UpdateAnswerRequest
    {
        WorkloadId = workload.WorkloadId,
        LensAlias  = "wellarchitected",
        QuestionId = "SUS_01", // "Qual regiao voce escolhe para os seus recursos com base nos requisitos?"
        // Nenhum SelectedChoices: nenhuma das 59 decisoes anteriores considerou este
        // criterio, entao nao ha o que marcar como praticado -- IsApplicable continua
        // true (a pergunta se aplica) e a ausencia de escolha e o proprio dado.
        Notes = "Nenhum dos 59 laboratorios anteriores escolheu regiao, tipo de "
              + "instancia ou padrao de escala por criterio de sustentabilidade. Risco "
              + "alto nao por resposta ruim -- por pergunta nunca respondida.",
        IsApplicable = true,
    },
};

foreach (var req in respostas)
    await cliente.UpdateAnswerAsync(req);

Console.WriteLine($"{respostas.Length} respostas registradas, com evidencia citada em cada Notes");

⚠️

Os IDs de pergunta e de escolha são ilustrativos

Os valores como `REL_02` e `reliability_test_failover` neste laboratório seguem o padrão observado em ferramentas de automação de terceiros sobre a API, mas o conjunto exato de `QuestionId` e `ChoiceId` pertence à versão do lens aplicada e muda entre versões. Antes de rodar isto na sua conta, liste as perguntas reais com `ListAnswers` e confirme cada `ChoiceId` com `GetAnswer` — não copie os literais deste código.

Construir: o milestone, a contagem de risco e o relatório exportado

FecharRevisao.cs

// FecharRevisao.cs -- agrega risco, monta o plano, congela o milestone

using Amazon.WellArchitected;
using Amazon.WellArchitected.Model;
using Amazon.S3;
using Amazon.S3.Model;
using System.Text.Json;

var wa = new AmazonWellArchitectedClient();
var s3 = new AmazonS3Client();

var workloadId = Environment.GetEnvironmentVariable("WORKLOAD_ID")
    ?? throw new InvalidOperationException("defina WORKLOAD_ID");

var revisao = await wa.GetLensReviewAsync(new GetLensReviewRequest
{
    WorkloadId = workloadId,
    LensAlias  = "wellarchitected",
});

// RiskCounts e um mapa por nivel de risco (HIGH, MEDIUM, NONE, NOT_APPLICABLE,
// UNANSWERED). E este numero -- nao a sensacao de "acho que esta bem" -- que
// decide o que entra primeiro no plano.
var altos  = revisao.LensReview.RiskCounts.GetValueOrDefault("HIGH", 0);
var medios = revisao.LensReview.RiskCounts.GetValueOrDefault("MEDIUM", 0);

Console.WriteLine($"risco antes do milestone: {altos} alto(s), {medios} medio(s)");

if (altos < 1)
    Console.WriteLine("AVISO: zero risco alto depois de 59 laboratorios e sinal de "
        + "revisao rasa, nao de arquitetura perfeita -- confira se todas as perguntas "
        + "foram respondidas com evidencia real antes de prosseguir.");

// O plano prioriza por pilar: cada PillarReviewSummary carrega a contagem de risco
// DAQUELE pilar, e e essa ordenacao que vira o cronograma.
var plano = revisao.LensReview.PillarReviewSummaries
    .OrderByDescending(pilar => pilar.RiskCounts.GetValueOrDefault("HIGH", 0))
    .ThenByDescending(pilar => pilar.RiskCounts.GetValueOrDefault("MEDIUM", 0))
    .Select(pilar => new
    {
        pilar.PillarId,
        pilar.PillarName,
        Altos  = pilar.RiskCounts.GetValueOrDefault("HIGH", 0),
        Medios = pilar.RiskCounts.GetValueOrDefault("MEDIUM", 0),
    })
    .ToList();

// MilestoneName precisa ser unico DENTRO do workload -- um nome repetido falha
// com ConflictException, e e por isso que o nome carrega o trimestre.
var milestone = await wa.CreateMilestoneAsync(new CreateMilestoneRequest
{
    WorkloadId          = workloadId,
    MilestoneName       = $"Revisao {DateTime.UtcNow:yyyy}-Q{(DateTime.UtcNow.Month - 1) / 3 + 1}",
    ClientRequestToken  = Guid.NewGuid().ToString(),
});

Console.WriteLine($"milestone {milestone.MilestoneNumber} salvo para o workload {workloadId}");

// O relatorio sai do console e vai para quem pediu evidencia -- sem exigir acesso
// nenhum a conta AWS da Cadencia.
var relatorio = JsonSerializer.Serialize(new { milestone.MilestoneNumber, altos, medios, plano });
await s3.PutObjectAsync(new PutObjectRequest
{
    BucketName  = Environment.GetEnvironmentVariable("BUCKET_RELATORIO"),
    Key         = $"revisoes/{DateTime.UtcNow:yyyy-MM-dd}-milestone-{milestone.MilestoneNumber}.json",
    ContentBody = relatorio,
});

💡

Cem milestones por workload, e depois?

Um workload aceita no máximo 100 milestones. Numa cadência trimestral isso dá 25 anos antes de esbarrar no limite — não é urgente, mas é o tipo de cota que vale checar em `Service Quotas` antes de automatizar uma cadência mais curta que trimestral, porque `CreateMilestone` além do limite falha com `ServiceQuotaExceededException`.

Construir: a cadência que não depende de lembrete

Esta é a parte que volta a ser Terraform, porque EventBridge Scheduler, SNS e S3 são recursos reais, e reaproveita o cluster ECS do L01 em vez de criar computação nova só para rodar um script trimestral.

cadencia.tf

# cadencia.tf -- o Terraform nao cria o workload, mas cria o que faz a
# revisao se repetir sem depender de alguem lembrar.

resource "aws_s3_bucket" "relatorios_revisao" {
  bucket = "${var.projeto}-wellarchitected-relatorios"
}

resource "aws_s3_bucket_versioning" "relatorios_revisao" {
  bucket = aws_s3_bucket.relatorios_revisao.id
  versioning_configuration { status = "Enabled" }
}

# Retencao de 3 anos: e o historico auditavel que sobrevive mesmo se alguem
# apagar o workload no console sem querer -- ver o callout de limpeza.
resource "aws_s3_bucket_lifecycle_configuration" "relatorios_revisao" {
  bucket = aws_s3_bucket.relatorios_revisao.id
  rule {
    id     = "retencao-3-anos"
    status = "Enabled"
    expiration { days = 1095 }
  }
}

resource "aws_sns_topic" "lembrete_revisao" {
  name = "${var.projeto}-wellarchitected-lembrete"
}

# O plantao do L52 e quem recebe o lembrete -- reaproveita o topico e a rotacao
# ja existentes em vez de criar um segundo caminho de notificacao paralelo.
resource "aws_sns_topic_subscription" "plantao" {
  topic_arn = aws_sns_topic.lembrete_revisao.arn
  protocol  = "email"
  endpoint  = var.email_plantao
}

# EventBridge Scheduler dispara a task ECS que roda RegistrarWorkload.cs e
# FecharRevisao.cs -- reaproveita o cluster do L01 em vez de criar computacao nova.
resource "aws_scheduler_schedule" "revisao_trimestral" {
  name                         = "${var.projeto}-wellarchitected-trimestral"
  schedule_expression          = "rate(90 days)"
  schedule_expression_timezone = "America/Sao_Paulo"

  flexible_time_window { mode = "OFF" }

  target {
    arn      = aws_ecs_cluster.principal.arn
    role_arn = aws_iam_role.scheduler_revisao.arn

    ecs_parameters {
      task_definition_arn = aws_ecs_task_definition.revisao_wa.arn
      launch_type          = "FARGATE"
      network_configuration {
        subnets         = aws_subnet.privada[*].id
        security_groups = [aws_security_group.task.id]
      }
    }

    sns_target { message_group_id = null } # nao aplicavel a FIFO; mantido por clareza
    retry_policy {
      maximum_retry_attempts       = 2
      maximum_event_age_in_seconds = 3600
    }
    dead_letter_config { arn = aws_sns_topic.lembrete_revisao.arn }
  }
}

resource "aws_iam_role" "scheduler_revisao" {
  name               = "${var.projeto}-scheduler-revisao"
  assume_role_policy = data.aws_iam_policy_document.confianca_scheduler.json
}

data "aws_iam_policy_document" "confianca_scheduler" {
  statement {
    effect  = "Allow"
    actions = ["sts:AssumeRole"]
    principals {
      type        = "Service"
      identifiers = ["scheduler.amazonaws.com"]
    }
  }
}

⚠️

`rate(90 days)` não é "todo início de trimestre"

A expressão `rate(90 days)` conta a partir do momento em que o agendamento foi criado, e desliza ao longo do ano — não alinha com janeiro, abril, julho e outubro. Se o requisito real é "no início de cada trimestre civil", a expressão certa é `cron()` com dia e mês fixos, não `rate()`. Este laboratório usa `rate()` por simplicidade; confira qual dos dois o seu calendário de negócio realmente exige.

Implantar, e provar com número

Cinco medições. Nenhuma conclusão vem de "o relatório parece completo".

provas.sh

# -- Prova 1: o workload existe -------------------------------------------------
aws wellarchitected list-workloads \
  --query "WorkloadSummaries[?WorkloadName=='cadencia-api-pedidos']" --output table
# Esperado: exatamente 1 linha. Zero significa que o CreateWorkload nao rodou ou
# falhou silenciosamente; duas ou mais significa workload duplicado (ver Antipadroes).

# -- Prova 2: existe PELO MENOS 3 risco alto, conforme o objetivo declarado -----
WORKLOAD_ID=$(aws wellarchitected list-workloads \
  --query "WorkloadSummaries[?WorkloadName=='cadencia-api-pedidos'].WorkloadId" \
  --output text)
aws wellarchitected get-lens-review --workload-id "$WORKLOAD_ID" \
  --lens-alias wellarchitected --query "LensReview.RiskCounts"
# Esperado: {"HIGH": 3, "MEDIUM": N, ...} ou mais. Menos que 3 depois de responder
# os seis pilares com honestidade e sinal de resposta forcada para "baixo".

# -- Prova 3: o milestone foi salvo com nome unico do trimestre -----------------
aws wellarchitected list-milestones --workload-id "$WORKLOAD_ID" \
  --query "MilestoneSummaries[].MilestoneName" --output table
# Esperado: "Revisao 2026-Q3" (ou o trimestre corrente) na lista.

# -- Prova 4: mitigar um risco muda o NUMERO no milestone seguinte --------------
# Corrija de proposito a resposta de um risco medio (ex.: SUS_01, adicionando uma
# escolha real), rode FecharRevisao.cs de novo, e compare:
aws wellarchitected get-lens-review --workload-id "$WORKLOAD_ID" \
  --lens-alias wellarchitected --milestone-number 1 \
  --query "LensReview.RiskCounts.MEDIUM"
aws wellarchitected get-lens-review --workload-id "$WORKLOAD_ID" \
  --lens-alias wellarchitected --milestone-number 2 \
  --query "LensReview.RiskCounts.MEDIUM"
# Esperado: o segundo numero e MENOR que o primeiro. Numeros iguais depois de uma
# mitigacao real e a Falha 2 da secao "Quebrar de proposito".

# -- Prova 5: a cadencia esta ativa, sem depender de lembrete humano ------------
aws scheduler get-schedule --name cadencia-wellarchitected-trimestral \
  --query "State" --output text
# Esperado: ENABLED.

Quebrar de propósito: três falhas e o diagnóstico

As três acontecem de verdade, e nenhuma é erro de digitação — são erros de entender o que a ferramenta faz e o que ela não faz.

Falha	Como provocar	Sintoma	Onde olhar	Correção
ChoiceId copiado de outra pergunta	chamar UpdateAnswer com um ChoiceId que pertence a outra pergunta do mesmo lens	ValidationException, sem alterar a resposta	campo `Fields` da exceção lista o ChoiceId rejeitado	ler o ChoiceId real via GetAnswer antes de enviar; nunca copiar entre perguntas
Milestone com risco desatualizado	mitigar o problema real na infraestrutura, mas esquecer de chamar UpdateAnswer antes de CreateMilestone	RiskCounts do novo milestone é idêntico ao anterior, mesmo depois da correção	comparar SelectedChoices e Notes do GetAnswer antes e depois — eles não mudaram sozinhos	milestone é fotografia, não recálculo; atualizar a resposta é sempre o primeiro passo, nunca o depois
Workload duplicado, revisão fragmentada	dois squads rodam CreateWorkload sem checar se já existe, cada um responde metade das perguntas	ListWorkloads mostra dois workloads quase iguais, nenhum com o quadro completo	WorkloadName só falha em duplicidade EXATA de nome — nomes parecidos passam	nomeação padronizada e ListWorkloads antes de criar, ou lens/review template compartilhado entre squads

FalhaChoiceId copiado de outra pergunta

Como provocarchamar UpdateAnswer com um ChoiceId que pertence a outra pergunta do mesmo lens

SintomaValidationException, sem alterar a resposta

Onde olharcampo `Fields` da exceção lista o ChoiceId rejeitado

Correçãoler o ChoiceId real via GetAnswer antes de enviar; nunca copiar entre perguntas

FalhaMilestone com risco desatualizado

Como provocarmitigar o problema real na infraestrutura, mas esquecer de chamar UpdateAnswer antes de CreateMilestone

SintomaRiskCounts do novo milestone é idêntico ao anterior, mesmo depois da correção

Onde olharcomparar SelectedChoices e Notes do GetAnswer antes e depois — eles não mudaram sozinhos

Correçãomilestone é fotografia, não recálculo; atualizar a resposta é sempre o primeiro passo, nunca o depois

FalhaWorkload duplicado, revisão fragmentada

Como provocardois squads rodam CreateWorkload sem checar se já existe, cada um responde metade das perguntas

SintomaListWorkloads mostra dois workloads quase iguais, nenhum com o quadro completo

Onde olharWorkloadName só falha em duplicidade EXATA de nome — nomes parecidos passam

Correçãonomeação padronizada e ListWorkloads antes de criar, ou lens/review template compartilhado entre squads

Quiz rápido

Depois da revisão, a Cadência classifica "nunca testamos failover regional" como risco baixo, porque o L58 já implementou Aurora Global com failover gerenciado. O que está errado nessa classificação?

Segurança: quem pode ver e mudar a revisão

Uma revisão que existe para ser mostrada a um cliente também é, ela mesma, informação sensível — descreve exatamente onde a arquitetura é frágil.

Risco	Probabilidade	Impacto	Prevenção	Detecção	Resposta
Nota de resposta expõe detalhe sensível para quem não devia ver	média	alto	compartilhamento explícito do workload, nunca acesso amplo de conta	CloudTrail em GetLensReview/ExportLens fora do time	revogar compartilhamento, revisar quem tinha acesso
Workload "fantasma" criado e nunca revisado, dando falsa cobertura	baixa	médio	convenção de nome e auditoria trimestral da lista de workloads	ListWorkloads comparado à lista esperada	apagar o workload órfão e documentar por que existiu
Apagar o workload apaga o histórico auditável sem segunda confirmação	baixa	alto	só o dono do workload tem permissão de DeleteWorkload; fora da rotina do revisor comum	CloudTrail em DeleteWorkload	reconstituir a partir do relatório exportado no S3 — é para isso que ele existe
Reason = OUT_OF_SCOPE usado para esconder risco real do cliente que pediu o relatório	média	alto	revisão por pares antes de marcar IsApplicable = false	nota do Reason revisada na apresentação do relatório	reabrir a pergunta e responder de verdade
Credencial da task ECS trimestral com permissão além do necessário	média	médio	papel de execução restrito às ações `wellarchitected:` da IAM section e `s3:PutObject` só no bucket do relatório	IAM Access Analyzer sobre uso real	derivar a política do uso medido, como o L41 já ensinou

RiscoNota de resposta expõe detalhe sensível para quem não devia ver

Probabilidademédia

Impactoalto

Prevençãocompartilhamento explícito do workload, nunca acesso amplo de conta

DetecçãoCloudTrail em GetLensReview/ExportLens fora do time

Respostarevogar compartilhamento, revisar quem tinha acesso

RiscoWorkload "fantasma" criado e nunca revisado, dando falsa cobertura

Probabilidadebaixa

Impactomédio

Prevençãoconvenção de nome e auditoria trimestral da lista de workloads

DetecçãoListWorkloads comparado à lista esperada

Respostaapagar o workload órfão e documentar por que existiu

RiscoApagar o workload apaga o histórico auditável sem segunda confirmação

Probabilidadebaixa

Impactoalto

Prevençãosó o dono do workload tem permissão de DeleteWorkload; fora da rotina do revisor comum

DetecçãoCloudTrail em DeleteWorkload

Respostareconstituir a partir do relatório exportado no S3 — é para isso que ele existe

RiscoReason = OUT_OF_SCOPE usado para esconder risco real do cliente que pediu o relatório

Probabilidademédia

Impactoalto

Prevençãorevisão por pares antes de marcar IsApplicable = false

Detecçãonota do Reason revisada na apresentação do relatório

Respostareabrir a pergunta e responder de verdade

RiscoCredencial da task ECS trimestral com permissão além do necessário

Probabilidademédia

Impactomédio

Prevençãopapel de execução restrito às ações `wellarchitected:` da IAM section e `s3:PutObject` só no bucket do relatório

DetecçãoIAM Access Analyzer sobre uso real

Respostaderivar a política do uso medido, como o L41 já ensinou

💡

O `*` que aparece na política, e por que ele se justifica

`wellarchitected:CreateWorkload` é uma operação que cria um recurso ainda inexistente: não há ARN para restringir a chamada a um workload específico, porque o workload nasce dela. As outras ações operacionais da mesma política — UpdateAnswer, CreateMilestone, GetLensReview — são restritas ao ARN do workload da Cadência. A regra não é "nunca use `*`" — é "todo `*` tem de ter uma frase explicando por que não pode ser mais estreito".

Observabilidade: as perguntas que o painel de revisão tem de responder

Um painel de revisão tem função estreita: dizer se o plano de melhoria está sendo seguido, não repetir a lista de riscos que já está no relatório.

Pergunta	Métrica ou consulta	O que significa mudar	Limiar inicial
Quantos HRI e MRI existem agora, por pilar?	GetLensReview → PillarReviewSummaries[].RiskCounts	queda é progresso real; aumento pode ser arquitetura nova ou revisão mais honesta	reportar em toda apresentação trimestral
Quantos risco alto diminuíram desde o milestone anterior?	comparar RiskCounts entre dois números de milestone	zero mudança depois de um trimestre inteiro é sinal de plano sem execução	meta: pelo menos 1 risco alto tratado por trimestre
Quantas perguntas ainda não foram respondidas?	ListAnswers com filtro de resposta ausente	pergunta sem resposta nem "não aplicável" é lacuna, não decisão	zero perguntas pendentes antes de fechar o milestone
Qual risco está aberto há mais de um trimestre sem dono?	cruzar Notes do plano de melhoria com a data do milestone anterior	risco sem dono não progride sozinho	qualquer risco alto sem dono nomeado dispara alerta
O plano de melhoria tem prazo, ou é só lista?	leitura humana do plano exportado	prazo ausente é o sintoma mais comum de revisão que virou ritual	todo item de risco alto com data, não só descrição

PerguntaQuantos HRI e MRI existem agora, por pilar?

Métrica ou consultaGetLensReview → PillarReviewSummaries[].RiskCounts

O que significa mudarqueda é progresso real; aumento pode ser arquitetura nova ou revisão mais honesta

Limiar inicialreportar em toda apresentação trimestral

PerguntaQuantos risco alto diminuíram desde o milestone anterior?

Métrica ou consultacomparar RiskCounts entre dois números de milestone

O que significa mudarzero mudança depois de um trimestre inteiro é sinal de plano sem execução

Limiar inicialmeta: pelo menos 1 risco alto tratado por trimestre

PerguntaQuantas perguntas ainda não foram respondidas?

Métrica ou consultaListAnswers com filtro de resposta ausente

O que significa mudarpergunta sem resposta nem "não aplicável" é lacuna, não decisão

Limiar inicialzero perguntas pendentes antes de fechar o milestone

PerguntaQual risco está aberto há mais de um trimestre sem dono?

Métrica ou consultacruzar Notes do plano de melhoria com a data do milestone anterior

O que significa mudarrisco sem dono não progride sozinho

Limiar inicialqualquer risco alto sem dono nomeado dispara alerta

PerguntaO plano de melhoria tem prazo, ou é só lista?

Métrica ou consultaleitura humana do plano exportado

O que significa mudarprazo ausente é o sintoma mais comum de revisão que virou ritual

Limiar inicialtodo item de risco alto com data, não só descrição

⚠️

A métrica que engana quem olha só o relatório final

Um relatório com "3 risco alto" no primeiro milestone e "3 risco alto" no segundo PARECE estagnação, mas pode ser progresso real: dois riscos antigos foram mitigados, e um risco novo apareceu porque a arquitetura cresceu. Comparar o NÚMERO sem comparar QUAIS riscos são, item por item, esconde exatamente o progresso que a revisão deveria mostrar.

Escala: de um workload a toda a organização

Aqui "escala" não é volume de requisição — é quantos workloads a revisão precisa cobrir conforme a Cadência cresce, e o que passa a doer em cada ordem de grandeza.

Volume	O que acontece com a revisão	O que passa a doer	O que fazer
1 workload (hoje)	um squad, uma revisão trimestral, seis pessoas na sala	nada; é o cenário deste laboratório	nada
10 workloads (por serviço, quando o monólito se separar)	cada serviço ganha workload próprio; lens compartilhado entre squads	inconsistência — squads diferentes respondendo a mesma pergunta de formas diferentes	lens customizado com critério comum (nível 5 da evolução)
100 workloads (todas as contas, via Organizations — L56)	revisão vira processo de plataforma, não de time isolado	ninguém consegue ler 100 relatórios trimestrais linha por linha	painel agregado por RiskCounts somado, não leitura manual de cada um
Fusão ou aquisição de outra empresa	workload novo herda arquitetura desconhecida, sem histórico de milestone	primeira revisão do workload adquirido nasce sem baseline para comparar	tratar como o L01 desta série: primeira revisão é sempre a mínima, sem vergonha de risco alto
A região que hospeda o workload no WA Tool sai do ar	não é possível atualizar resposta nem ver o console durante a interrupção	nada — a revisão é artefato de planejamento, não runtime; o relatório já exportado no S3 continua correto	é exatamente por isso que o relatório é exportado, e não só lido no console

Volume1 workload (hoje)

O que acontece com a revisãoum squad, uma revisão trimestral, seis pessoas na sala

O que passa a doernada; é o cenário deste laboratório

O que fazernada

Volume10 workloads (por serviço, quando o monólito se separar)

O que acontece com a revisãocada serviço ganha workload próprio; lens compartilhado entre squads

O que passa a doerinconsistência — squads diferentes respondendo a mesma pergunta de formas diferentes

O que fazerlens customizado com critério comum (nível 5 da evolução)

Volume100 workloads (todas as contas, via Organizations — L56)

O que acontece com a revisãorevisão vira processo de plataforma, não de time isolado

O que passa a doerninguém consegue ler 100 relatórios trimestrais linha por linha

O que fazerpainel agregado por RiskCounts somado, não leitura manual de cada um

VolumeFusão ou aquisição de outra empresa

O que acontece com a revisãoworkload novo herda arquitetura desconhecida, sem histórico de milestone

O que passa a doerprimeira revisão do workload adquirido nasce sem baseline para comparar

O que fazertratar como o L01 desta série: primeira revisão é sempre a mínima, sem vergonha de risco alto

VolumeA região que hospeda o workload no WA Tool sai do ar

O que acontece com a revisãonão é possível atualizar resposta nem ver o console durante a interrupção

O que passa a doernada — a revisão é artefato de planejamento, não runtime; o relatório já exportado no S3 continua correto

O que fazeré exatamente por isso que o relatório é exportado, e não só lido no console

💡

O gargalo que só aparece com muitos workloads

Ler 100 relatórios de revisão manualmente não escala do mesmo jeito que ler um. O painel que importa em escala de organização não é o relatório individual — é a soma de RiskCounts por pilar entre todos os workloads, para saber ONDE concentrar atenção antes de abrir workload por workload.

Custo: o que uma revisão gratuita ainda custa

A ferramenta não cobra nada. O que este laboratório acrescenta à fatura é a infraestrutura da cadência — e ela é pequena de propósito.

Cenário	Volume	O que acrescenta	Tendência	Otimização
Revisão única (workshop de 4h)	1 workload, ~20 perguntas respondidas	zero custo de ferramenta; custo real é hora de seis pessoas por uma tarde	não recorrente	nenhuma — é o mínimo que já vale a pena
Cadência trimestral automatizada	4 revisões/ano, 1 workload	segundos de task ECS por trimestre, S3 para o relatório, EventBridge Scheduler	centavos por trimestre	reusar o cluster ECS existente, não criar um novo
Múltiplos workloads (banda 7 em diante)	10+ workloads, revisão por squad	mais tempo humano que infraestrutura	cresce com número de squads, não de requisições	lens customizado compartilhado evita repetir julgamento em cada workload

CenárioRevisão única (workshop de 4h)

Volume1 workload, ~20 perguntas respondidas

O que acrescentazero custo de ferramenta; custo real é hora de seis pessoas por uma tarde

Tendêncianão recorrente

Otimizaçãonenhuma — é o mínimo que já vale a pena

CenárioCadência trimestral automatizada

Volume4 revisões/ano, 1 workload

O que acrescentasegundos de task ECS por trimestre, S3 para o relatório, EventBridge Scheduler

Tendênciacentavos por trimestre

Otimizaçãoreusar o cluster ECS existente, não criar um novo

CenárioMúltiplos workloads (banda 7 em diante)

Volume10+ workloads, revisão por squad

O que acrescentamais tempo humano que infraestrutura

Tendênciacresce com número de squads, não de requisições

Otimizaçãolens customizado compartilhado evita repetir julgamento em cada workload

Dimensão	Cobra por	Cuidado
AWS Well-Architected Tool	nada — gratuito	a citação oficial da AWS é literal: "não há cobrança adicional pela ferramenta"
Task ECS trimestral	vCPU-segundo e GB-segundo de uma execução de minutos	desprezível; a task roda, grava o relatório e para
Armazenamento do relatório no S3	GB-mês	pequeno mesmo com retenção de 3 anos, porque cada relatório é um JSON, não um vídeo
EventBridge Scheduler	por invocação	centavos por trimestre; não é onde se economiza
Tempo humano na revisão	não aparece em nenhuma fatura da AWS	é o maior custo real, e é também o que o cliente enterprise está pagando para ver documentado

DimensãoAWS Well-Architected Tool

Cobra pornada — gratuito

Cuidadoa citação oficial da AWS é literal: "não há cobrança adicional pela ferramenta"

DimensãoTask ECS trimestral

Cobra porvCPU-segundo e GB-segundo de uma execução de minutos

Cuidadodesprezível; a task roda, grava o relatório e para

DimensãoArmazenamento do relatório no S3

Cobra porGB-mês

Cuidadopequeno mesmo com retenção de 3 anos, porque cada relatório é um JSON, não um vídeo

DimensãoEventBridge Scheduler

Cobra porpor invocação

Cuidadocentavos por trimestre; não é onde se economiza

DimensãoTempo humano na revisão

Cobra pornão aparece em nenhuma fatura da AWS

Cuidadoé o maior custo real, e é também o que o cliente enterprise está pagando para ver documentado

✅

O ganho de custo que não está em nenhuma linha da AWS

O valor real não é a fatura de infraestrutura, que continua desprezível — é o cliente enterprise assinando contrato depois de receber um relatório que dizia exatamente qual risco existia e quando seria tratado, em vez de um "confiamos na nossa arquitetura" sem nada atrás.

Well-Architected nos seis pilares

Esta tabela não é hipotética: é a saída real da revisão conduzida neste laboratório, pilar por pilar, com a evidência que cada resposta cita.

Pilar	Situação, com evidência	Risco	Melhoria	Prioridade
Excelência operacional	3 SLOs com burn rate multi-janela substituíram 40 alarmes mudos (L52); tempo até confirmar incidente medido em até 65 min	médio — limiar de 14,4x não calibrado no tráfego real da Cadência	coletar 90 dias de burn rate real e recalibrar o limiar	média
Segurança	menor privilégio auditado no L41; papéis de revisor e aprovador de risco separados neste laboratório	médio — ninguém audita quem pode compartilhar o workload da revisão	revisão por pares antes de qualquer IsApplicable=false	média
Confiabilidade	failover regional gerenciado e ensaiado (L58): RTO de 4h47, RPO de 2.140 ms medidos	médio — duas regiões, não três; dívida aceita por escrito no próprio L58	reavaliar terceira região quando o requisito de RTO apertar (L99)	média
Eficiência de performance	gargalo nomeado por teste de carga (L40), mas o achado nunca virou resposta formal comparável	médio — conhecimento existe, mas não está registrado contra o framework	transformar o achado do L40 em resposta formal, com nota citando o teste	média
Otimização de custos	disciplina de rightsizing antes de compromisso demonstrada no ecossistema da série (L59); a Cadência ainda não comprou nenhum Savings Plan	baixo — nada para verificar ainda, mas sem revisão trimestral formal do gasto próprio	aplicar o mesmo critério do L59 à própria frota da Cadência antes de qualquer compromisso	média
Sustentabilidade	nenhuma pergunta deste pilar foi respondida nos 59 laboratórios anteriores	ALTO — não porque a resposta seja ruim, mas porque não existe resposta	primeira resposta formal: critério de escolha de região, avaliação de Graviton, medição de capacidade ociosa — mesmo sem dado ainda	alta

PilarExcelência operacional

Situação, com evidência3 SLOs com burn rate multi-janela substituíram 40 alarmes mudos (L52); tempo até confirmar incidente medido em até 65 min

Riscomédio — limiar de 14,4x não calibrado no tráfego real da Cadência

Melhoriacoletar 90 dias de burn rate real e recalibrar o limiar

Prioridademédia

PilarSegurança

Situação, com evidênciamenor privilégio auditado no L41; papéis de revisor e aprovador de risco separados neste laboratório

Riscomédio — ninguém audita quem pode compartilhar o workload da revisão

Melhoriarevisão por pares antes de qualquer IsApplicable=false

Prioridademédia

PilarConfiabilidade

Situação, com evidênciafailover regional gerenciado e ensaiado (L58): RTO de 4h47, RPO de 2.140 ms medidos

Riscomédio — duas regiões, não três; dívida aceita por escrito no próprio L58

Melhoriareavaliar terceira região quando o requisito de RTO apertar (L99)

Prioridademédia

PilarEficiência de performance

Situação, com evidênciagargalo nomeado por teste de carga (L40), mas o achado nunca virou resposta formal comparável

Riscomédio — conhecimento existe, mas não está registrado contra o framework

Melhoriatransformar o achado do L40 em resposta formal, com nota citando o teste

Prioridademédia

PilarOtimização de custos

Situação, com evidênciadisciplina de rightsizing antes de compromisso demonstrada no ecossistema da série (L59); a Cadência ainda não comprou nenhum Savings Plan

Riscobaixo — nada para verificar ainda, mas sem revisão trimestral formal do gasto próprio

Melhoriaaplicar o mesmo critério do L59 à própria frota da Cadência antes de qualquer compromisso

Prioridademédia

PilarSustentabilidade

Situação, com evidêncianenhuma pergunta deste pilar foi respondida nos 59 laboratórios anteriores

RiscoALTO — não porque a resposta seja ruim, mas porque não existe resposta

Melhoriaprimeira resposta formal: critério de escolha de região, avaliação de Graviton, medição de capacidade ociosa — mesmo sem dado ainda

Prioridadealta

💡

Por que Sustentabilidade ficou com a única prioridade "alta" da tabela

Todos os outros riscos têm decisão real por trás — algo foi medido, testado ou pelo menos considerado, mesmo que o resultado não seja perfeito. Sustentabilidade é o único pilar em que a Cadência não tem NENHUMA decisão para citar, boa ou ruim. Entre "decisão imperfeita, registrada" e "nenhuma decisão", a segunda é a que o framework trata como mais urgente — porque a primeira já tem por onde melhorar, e a segunda ainda nem começou.

Evolução em níveis: da revisão informal ao dado que prevê risco

A terceira arquitetura não é um desenho: é a resposta a QUANDO a revisão precisa mudar de forma. Cada nível resolve um risco e compra outro.

🗺️ Da ausência de revisão ao histórico que vira sinal preditivo

Nível 1 — ProtótipoRisco resolvido: nenhum. Novo risco: dívida invisível — ninguém sabe quantos riscos altos existem até um cliente perguntar. Custo: zero, e é exatamente por isso que ele se acumula sem ninguém perceber.

→

Nenhuma revisão formal — decisão fica só na cabeça de quem escreveu o laboratório, e comparação com o framework nunca acontece. É onde a Cadência estava até este laboratório.

Nível 2 — Este laboratórioRisco resolvido: dívida invisível vira lista com dono e prazo. Novo risco: uma revisão única falsifica sensação de segurança se não se repetir. Custo: hora de pessoas na sala; a infraestrutura da ferramenta é gratuita.

→

Workload registrado, seis pilares respondidos com evidência real, plano priorizado, milestone salvo.

Nível 3 — Cadência automatizadaRisco resolvido: revisão que dependia de alguém lembrar, o mesmo defeito do plano de DR do L58. Novo risco: cadência automática sem dono humano vira ritual — a reunião acontece, ninguém muda nada de verdade. Custo: centavos de execução trimestral.

→

EventBridge Scheduler dispara lembrete trimestral, SNS avisa o plantão do L52, relatório versionado no S3.

Nível 4 — Múltiplos workloadsRisco resolvido: risco de componente pequeno escondido dentro da média de um workload gigante. Novo risco: squads respondendo à mesma pergunta de formas diferentes, sem critério comum. Custo: cresce com número de workloads, não com tráfego.

→

Cada serviço, quando a Cadência quebrar o monólito, ganha workload próprio; lens compartilhado entre squads.

Nível 5 — Plataforma e governançaRisco resolvido: serviço novo nascendo sem passar pelo crivo do framework. Novo risco: lens customizado desatualizado vira falso critério — pior que nenhum critério, porque parece rigor. Custo: manutenção do lens como se fosse código, com dono e revisão própria.

→

Lens customizado com regras internas da empresa; review template obrigatório antes de lançar serviço novo, aplicado via Organizations (L56).

Nível 6 — Dados e IA: o histórico vira sinal preditivoRisco resolvido: revisão que trata cada trimestre como se fosse o primeiro, sem aprender com os anteriores. Novo risco: um modelo treinado em poucos trimestres de histórico é estatística fraca com aparência de IA — o mesmo erro que a série já nomeou para modelo de risco de deploy no L03. Custo: baixo, porque o dado já existe no próprio Well-Architected Tool e no CloudWatch do L52; o que falta é tempo acumulado, não infraestrutura nova.

→

O histórico de milestones — contagem de risco por trimestre, tempo até mitigar, qual pergunta muda de resposta com mais frequência — vira dado que um modelo de IA cruza com os alarmes reais do L52 para apontar qual risco tem maior chance de virar incidente antes de acontecer. A decisão de aceitar ou mitigar continua humana e de negócio.

💡

A ordem não é negociável, e o motivo é concreto

Um modelo preditivo no nível 6 depende de ter histórico comparável entre trimestres, que depende de milestone regular — que é o nível 3. Quem tenta IA sobre o histórico de revisão antes de ter cadência automatizada treina um modelo sobre uma amostra de um ponto só, que não é histórico nenhum.

Onde IA entra nesta arquitetura, e onde não entra

A decisão central deste laboratório — classificar um risco como alto ou médio, e aceitar ou mitigar — é julgamento humano sobre impacto de negócio. Um modelo não tem contexto sobre o contrato com o cliente enterprise, o orçamento do próximo trimestre ou a prioridade estratégica da diretoria. Forçar IA nessa decisão seria o antipadrão que a própria série critica.

Há um lugar onde IA acrescentaria valor real, e ele é modesto: detectar quando uma resposta registrada divergiu do que a infraestrutura realmente faz hoje. É o mesmo problema de drift que o L55 já nomeou para Terraform — só que aqui o "estado" é texto numa nota, não um arquivo `.tf`.

Pergunta	Resposta honesta para este módulo
Qual problema a IA resolveria?	apontar quando uma Notes registrada parece desatualizada frente à configuração real (ex.: nota cita RTO de 4h47, mas o Aurora Global foi reconfigurado depois)
Por que uma regra não bastaria?	uma regra simples bastaria para o caso estrutural — comparar campo por campo entre Terraform state e uma nota estruturada. IA só ajudaria a ler nota em PROSA LIVRE e comparar contra configuração, que é o caso real aqui
De onde viriam os dados?	o texto das Notes de cada resposta, e o estado do Terraform já versionado desde o L55
Qual o risco?	falso positivo constante vira o mesmo problema de fadiga de alarme que o L52 já resolveu para métrica — se o alerta de "nota desatualizada" dispara toda semana sem ser real, a equipe passa a ignorá-lo
Por que não agora?	a Cadência tem um trimestre de histórico depois deste laboratório. Modelo sobre um ponto de dado é superstição com aparência de estatística — o mesmo limite que o L03 já registrou para histórico de deploy

PerguntaQual problema a IA resolveria?

Resposta honesta para este móduloapontar quando uma Notes registrada parece desatualizada frente à configuração real (ex.: nota cita RTO de 4h47, mas o Aurora Global foi reconfigurado depois)

PerguntaPor que uma regra não bastaria?

Resposta honesta para este módulouma regra simples bastaria para o caso estrutural — comparar campo por campo entre Terraform state e uma nota estruturada. IA só ajudaria a ler nota em PROSA LIVRE e comparar contra configuração, que é o caso real aqui

PerguntaDe onde viriam os dados?

Resposta honesta para este móduloo texto das Notes de cada resposta, e o estado do Terraform já versionado desde o L55

PerguntaQual o risco?

Resposta honesta para este módulofalso positivo constante vira o mesmo problema de fadiga de alarme que o L52 já resolveu para métrica — se o alerta de "nota desatualizada" dispara toda semana sem ser real, a equipe passa a ignorá-lo

PerguntaPor que não agora?

Resposta honesta para este móduloa Cadência tem um trimestre de histórico depois deste laboratório. Modelo sobre um ponto de dado é superstição com aparência de estatística — o mesmo limite que o L03 já registrou para histórico de deploy

⚠️

O uso de IA que parece atraente e é armadilha aqui

Pedir a um modelo para "decidir se o risco é alto ou médio" troca uma classificação que depende de contexto de negócio — orçamento, contrato, prioridade da diretoria — por uma inferência estatística sem acesso a nada disso. A ferramenta já separa claramente o que é mensurável (RiskCounts, derivado de resposta objetiva) do que é julgamento (a prioridade do plano); IA sobre a segunda parte decide por quem tem menos informação, não mais.

Anti-padrões deste laboratório

Anti-padrão	Por que alguém faz	Por que é problema	Sintoma	Forma correta
Revisão sozinho, sem os donos de cada pilar na sala	convocar todo mundo parece caro em tempo, numa equipe de seis pessoas	quem responde não é quem decide orçamento nem quem sofre o risco de segurança	plano de melhoria não sai do papel, porque ninguém com autoridade sobre o item participou	pelo menos uma pessoa por área crítica — plataforma, segurança, produto — na sessão
Marcar tudo como risco baixo para "passar" na revisão	ninguém quer ser o motivo do relatório vermelho na frente do cliente	esconde exatamente o que a revisão existe para revelar	a próxima revisão encontra o mesmo risco, sem nenhum progresso registrado	risco alto real fica alto; o que muda com o tempo é o plano, não a classificação forçada
Revisão de uma vez só, sem repetir	parece tarefa concluída depois da primeira vez, como um checklist riscado	sem milestone comparável, não há como provar que um risco melhorou	a arquitetura muda, a revisão não acompanha, e a próxima "primeira revisão" recomeça do zero	cadência automatizada — nível 3 da evolução —, sem depender de lembrete
Copiar a resposta sugerida pelo lens sem citar evidência real	o texto do lens já parece uma resposta pronta, e preencher rápido é tentador	nota genérica não ajuda ninguém a entender a decisão da Cadência daqui a seis meses	quem lê o relatório não sabe se a prática foi realmente adotada ou só citada	toda nota cita o laboratório ou a medição que sustenta a resposta
Tratar risco alto e risco médio com a mesma prioridade no plano	parece mais justo tratar tudo igual, sem favorecer nada	gasta o tempo escasso da equipe no que é mais fácil de resolver, não no mais perigoso	risco médio fácil sai da lista rápido; risco alto difícil segue aberto revisão após revisão	plano ordena por classificação de risco primeiro, facilidade depois
Usar a revisão só para justificar decisão já tomada	a revisão foi pedida por auditoria ou cliente, e confirmar o que já existe é o caminho de menor resistência	nenhum risco alto aparece nunca, mesmo com dívida conhecida — como a terceira região do L58	relatório sempre verde, mas o incidente que a revisão deveria ter previsto acontece do mesmo jeito	entrar na revisão disposto a encontrar risco, não a confirmar que está tudo bem

Anti-padrãoRevisão sozinho, sem os donos de cada pilar na sala

Por que alguém fazconvocar todo mundo parece caro em tempo, numa equipe de seis pessoas

Por que é problemaquem responde não é quem decide orçamento nem quem sofre o risco de segurança

Sintomaplano de melhoria não sai do papel, porque ninguém com autoridade sobre o item participou

Forma corretapelo menos uma pessoa por área crítica — plataforma, segurança, produto — na sessão

Anti-padrãoMarcar tudo como risco baixo para "passar" na revisão

Por que alguém fazninguém quer ser o motivo do relatório vermelho na frente do cliente

Por que é problemaesconde exatamente o que a revisão existe para revelar

Sintomaa próxima revisão encontra o mesmo risco, sem nenhum progresso registrado

Forma corretarisco alto real fica alto; o que muda com o tempo é o plano, não a classificação forçada

Anti-padrãoRevisão de uma vez só, sem repetir

Por que alguém fazparece tarefa concluída depois da primeira vez, como um checklist riscado

Por que é problemasem milestone comparável, não há como provar que um risco melhorou

Sintomaa arquitetura muda, a revisão não acompanha, e a próxima "primeira revisão" recomeça do zero

Forma corretacadência automatizada — nível 3 da evolução —, sem depender de lembrete

Anti-padrãoCopiar a resposta sugerida pelo lens sem citar evidência real

Por que alguém fazo texto do lens já parece uma resposta pronta, e preencher rápido é tentador

Por que é problemanota genérica não ajuda ninguém a entender a decisão da Cadência daqui a seis meses

Sintomaquem lê o relatório não sabe se a prática foi realmente adotada ou só citada

Forma corretatoda nota cita o laboratório ou a medição que sustenta a resposta

Anti-padrãoTratar risco alto e risco médio com a mesma prioridade no plano

Por que alguém fazparece mais justo tratar tudo igual, sem favorecer nada

Por que é problemagasta o tempo escasso da equipe no que é mais fácil de resolver, não no mais perigoso

Sintomarisco médio fácil sai da lista rápido; risco alto difícil segue aberto revisão após revisão

Forma corretaplano ordena por classificação de risco primeiro, facilidade depois

Anti-padrãoUsar a revisão só para justificar decisão já tomada

Por que alguém faza revisão foi pedida por auditoria ou cliente, e confirmar o que já existe é o caminho de menor resistência

Por que é problemanenhum risco alto aparece nunca, mesmo com dívida conhecida — como a terceira região do L58

Sintomarelatório sempre verde, mas o incidente que a revisão deveria ter previsto acontece do mesmo jeito

Forma corretaentrar na revisão disposto a encontrar risco, não a confirmar que está tudo bem

⚠️

O anti-padrão que este próprio laboratório poderia virar

Nada impede alguém de rodar `RegistrarWorkload.cs` uma vez, tirar um print do relatório para o cliente, e nunca mais tocar no workload — o que é exatamente o "revisão de uma vez só" da tabela acima, só que com uma ferramenta melhor por trás. A ferramenta certa não protege de processo errado; só o torna mais fácil de fazer direito, se alguém decidir fazer.

Quando algo não funciona

Antes de suspeitar de bug na API, pergunte: isto é um erro de CHAMADA (o que enviei está errado) ou de PROCESSO (o que eu esperava que a ferramenta fizesse sozinha, ela não faz)? A maioria das falhas desta seção é do segundo tipo.

Sintoma	Causa provável	Como investigar	Correção
Workload não aparece para outro membro do time	não foi compartilhado — o dono de um workload precisa convidar explicitamente outras contas, usuários ou a organização	ListWorkloads na conta do outro membro retorna vazio, mesmo sabendo que existe	usar o recurso de compartilhamento de workload, não copiar credencial nem dar acesso amplo à conta
UpdateAnswer falha com ValidationException	SelectedChoices referencia um ChoiceId que não existe naquela pergunta ou naquele lens	o campo `Fields` da exceção nomeia qual valor foi rejeitado	ler o ChoiceId exato via GetAnswer antes de enviar
CreateMilestone falha com ConflictException	nome de milestone repetido dentro do mesmo workload	ListMilestones mostra o nome já usado	nomear com o trimestre ("Revisão 2026-Q3"), nunca um nome genérico reaproveitado
Risco não muda entre milestones mesmo depois de mitigar	a resposta correspondente não foi atualizada antes do novo milestone	GetAnswer mostra SelectedChoices/Notes idênticos aos do milestone anterior	chamar UpdateAnswer sempre ANTES de CreateMilestone, nunca depois
Pergunta continua aparecendo mesmo sabendo que "não se aplica"	IsApplicable nunca foi definido como false com um Reason	GetAnswer mostra IsApplicable = true sem Reason preenchido	UpdateAnswer com IsApplicable = false e um Reason do conjunto válido da API

SintomaWorkload não aparece para outro membro do time

Causa provávelnão foi compartilhado — o dono de um workload precisa convidar explicitamente outras contas, usuários ou a organização

Como investigarListWorkloads na conta do outro membro retorna vazio, mesmo sabendo que existe

Correçãousar o recurso de compartilhamento de workload, não copiar credencial nem dar acesso amplo à conta

SintomaUpdateAnswer falha com ValidationException

Causa provávelSelectedChoices referencia um ChoiceId que não existe naquela pergunta ou naquele lens

Como investigaro campo `Fields` da exceção nomeia qual valor foi rejeitado

Correçãoler o ChoiceId exato via GetAnswer antes de enviar

SintomaCreateMilestone falha com ConflictException

Causa provávelnome de milestone repetido dentro do mesmo workload

Como investigarListMilestones mostra o nome já usado

Correçãonomear com o trimestre ("Revisão 2026-Q3"), nunca um nome genérico reaproveitado

SintomaRisco não muda entre milestones mesmo depois de mitigar

Causa provávela resposta correspondente não foi atualizada antes do novo milestone

Como investigarGetAnswer mostra SelectedChoices/Notes idênticos aos do milestone anterior

Correçãochamar UpdateAnswer sempre ANTES de CreateMilestone, nunca depois

SintomaPergunta continua aparecendo mesmo sabendo que "não se aplica"

Causa provávelIsApplicable nunca foi definido como false com um Reason

Como investigarGetAnswer mostra IsApplicable = true sem Reason preenchido

CorreçãoUpdateAnswer com IsApplicable = false e um Reason do conjunto válido da API

💡

A pergunta que resolve metade destes casos

Antes de suspeitar de bug: isto é erro de CHAMADA (o que enviei está formalmente errado, e a API recusa com uma exceção nomeada) ou de PROCESSO (a API aceitou tudo, mas o comportamento não é o que eu esperava que acontecesse sozinho)? As duas primeiras linhas da tabela são erro de chamada; as três últimas são processo — e é aí que mais gente se perde, porque não há exceção nenhuma para ler.

Limpeza: o que o destroy não leva, e o que nunca teve destroy

A maior parte deste laboratório não é Terraform, então terraform destroy só alcança a cadência automatizada — o workload, as respostas e os milestones precisam de limpeza explícita pela API, se algum dia forem descontinuados.

limpar.sh

# 1. Derrube o que o Terraform administra: scheduler, SNS, bucket de relatorio, IAM.
terraform destroy -auto-approve

# 2. O WORKLOAD, AS RESPOSTAS E OS MILESTONES NAO SAEM DAQUI. Nao sao geridos por
#    Terraform -- foram criados via SDK/CLI, e so saem do mesmo jeito.
WORKLOAD_ID=$(aws wellarchitected list-workloads \
  --query "WorkloadSummaries[?WorkloadName=='cadencia-api-pedidos'].WorkloadId" \
  --output text)

# 3. Confirme antes de apagar: DeleteWorkload remove TODOS os milestones e
#    respostas junto -- e irreversivel, e nao existe segunda confirmacao na API.
#    So faca isto se realmente quer perder o historico auditavel.
# aws wellarchitected delete-workload --workload-id "$WORKLOAD_ID"

# 4. O bucket de relatorios so esvazia com objeto removido explicitamente (sem
#    force_destroy no Terraform, de proposito -- e o historico que sobrevive
#    mesmo se o workload for apagado no passo 3).
aws s3 ls "s3://cadencia-wellarchitected-relatorios/" --recursive

# 5. Prova final: nenhum recurso do Terraform de pe.
aws resourcegroupstaggingapi get-resources \
  --tag-filters Key=Projeto,Values=cadencia-wellarchitected \
  --query "ResourceTagMappingList[].ResourceARN" --output table

Recurso	Sai no destroy?	Cobra parado?	Por que fica
Workload, respostas e milestones	não — não é Terraform	não	precisam de `DeleteWorkload` explícito pela API ou console
Bucket S3 do relatório	só sem objeto, ou com `force_destroy`	sim, GB-mês	o relatório histórico é exatamente o que não queremos apagar sem querer
EventBridge Scheduler	sim	não	mas para de lembrar a próxima revisão — cancelar sem substituto é voltar ao defeito do plano de DR antigo do L58: existir uma vez e nunca mais ser revisto
Tópico SNS e IAM	sim	centavos	nada de especial

RecursoWorkload, respostas e milestones

Sai no destroy?não — não é Terraform

Cobra parado?não

Por que ficaprecisam de `DeleteWorkload` explícito pela API ou console

RecursoBucket S3 do relatório

Sai no destroy?só sem objeto, ou com `force_destroy`

Cobra parado?sim, GB-mês

Por que ficao relatório histórico é exatamente o que não queremos apagar sem querer

RecursoEventBridge Scheduler

Sai no destroy?sim

Cobra parado?não

Por que ficamas para de lembrar a próxima revisão — cancelar sem substituto é voltar ao defeito do plano de DR antigo do L58: existir uma vez e nunca mais ser revisto

RecursoTópico SNS e IAM

Sai no destroy?sim

Cobra parado?centavos

Por que ficanada de especial

🚨

Apagar o workload apaga o histórico de decisão auditável

`DeleteWorkload` remove o workload e TUDO dentro dele — respostas, notas com evidência citada, e todos os milestones salvos — de uma vez, sem confirmação dupla na API. Não há como recuperar um milestone apagado dessa forma. Se o objetivo é só arquivar um workload que não é mais revisado, o relatório já exportado no S3 é a cópia que sobrevive; o workload em si só deve ser apagado com certeza absoluta de que ninguém precisará do histórico.

Resumo: problema, peça e motivo

Problema	Peça	Por que ela, e não outra
Decisão boa só existe na cabeça de quem a tomou	workload no AWS Well-Architected Tool	transforma conhecimento tácito em resposta registrada, comparável entre revisões
Nenhuma decisão foi comparada contra um framework	lens padrão AWS Well-Architected Framework	carrega as perguntas dos seis pilares, sem precisar inventar um checklist próprio
Resposta genérica não ajuda ninguém a entender a decisão	Notes citando o laboratório fonte	evidência real em vez de frase copiada do texto do lens
Ninguém sabe o que é mais urgente resolver primeiro	RiskCounts por pilar (HIGH/MEDIUM)	ordena o plano de melhoria por classificação de risco, não por facilidade
Revisão sem repetição vira documento estático	milestone com nome único por trimestre	fotografia comparável contra a próxima revisão
Cadência que depende de lembrete não se sustenta	EventBridge Scheduler + SNS ao plantão do L52	automatiza o que o plano de DR do L58 fez de errado: existir uma vez
Cliente pede evidência sem querer acesso à conta	relatório exportado ao S3	entregável que sai do console sem compartilhar credencial nenhuma
Terraform não tem recurso para o objeto central	C#/.NET 8 com AWSSDK.WellArchitected	a API existe e é estável; a ausência é só na camada de IaC

ProblemaDecisão boa só existe na cabeça de quem a tomou

Peçaworkload no AWS Well-Architected Tool

Por que ela, e não outratransforma conhecimento tácito em resposta registrada, comparável entre revisões

ProblemaNenhuma decisão foi comparada contra um framework

Peçalens padrão AWS Well-Architected Framework

Por que ela, e não outracarrega as perguntas dos seis pilares, sem precisar inventar um checklist próprio

ProblemaResposta genérica não ajuda ninguém a entender a decisão

PeçaNotes citando o laboratório fonte

Por que ela, e não outraevidência real em vez de frase copiada do texto do lens

ProblemaNinguém sabe o que é mais urgente resolver primeiro

PeçaRiskCounts por pilar (HIGH/MEDIUM)

Por que ela, e não outraordena o plano de melhoria por classificação de risco, não por facilidade

ProblemaRevisão sem repetição vira documento estático

Peçamilestone com nome único por trimestre

Por que ela, e não outrafotografia comparável contra a próxima revisão

ProblemaCadência que depende de lembrete não se sustenta

PeçaEventBridge Scheduler + SNS ao plantão do L52

Por que ela, e não outraautomatiza o que o plano de DR do L58 fez de errado: existir uma vez

ProblemaCliente pede evidência sem querer acesso à conta

Peçarelatório exportado ao S3

Por que ela, e não outraentregável que sai do console sem compartilhar credencial nenhuma

ProblemaTerraform não tem recurso para o objeto central

PeçaC#/.NET 8 com AWSSDK.WellArchitected

Por que ela, e não outraa API existe e é estável; a ausência é só na camada de IaC

Risco	O que o registra	O que ele NÃO resolve
Failover regional não testado	resposta de Confiabilidade citando o L58	a terceira região que o L58 conscientemente não construiu
Alarme que ninguém olha	resposta de Excelência Operacional citando o L52	a calibração real do limiar de burn rate sobre tráfego medido
Compromisso comprado sem medir antes	resposta de Otimização de Custos citando o L59	a revisão trimestral formal do gasto da própria Cadência, ainda por criar
Arquitetura sem critério de sustentabilidade	resposta de Sustentabilidade, marcada risco alto	nenhuma prática ainda — a revisão documenta a ausência, não a resolve

RiscoFailover regional não testado

O que o registraresposta de Confiabilidade citando o L58

O que ele NÃO resolvea terceira região que o L58 conscientemente não construiu

RiscoAlarme que ninguém olha

O que o registraresposta de Excelência Operacional citando o L52

O que ele NÃO resolvea calibração real do limiar de burn rate sobre tráfego medido

RiscoCompromisso comprado sem medir antes

O que o registraresposta de Otimização de Custos citando o L59

O que ele NÃO resolvea revisão trimestral formal do gasto da própria Cadência, ainda por criar

RiscoArquitetura sem critério de sustentabilidade

O que o registraresposta de Sustentabilidade, marcada risco alto

O que ele NÃO resolvenenhuma prática ainda — a revisão documenta a ausência, não a resolve

O time reúne, laboratório por laboratório, a evidência de cada decisão já tomada.
CreateWorkload registra a Cadência, com o lens padrão do framework.
UpdateAnswer marca cada resposta relevante, citando o laboratório fonte na nota.
Pergunta sem prática correspondente recebe IsApplicable e Reason, nunca fica muda.
GetLensReview soma o risco por pilar — é esse número que ordena o plano.
O plano de melhoria trata risco alto antes de médio, com dono e prazo em cada item.
CreateMilestone congela respostas e contagem de risco com nome único do trimestre.
O relatório sai para o S3 e vai para quem pediu evidência, sem acesso à conta.
EventBridge Scheduler agenda a próxima revisão, sem depender de lembrete humano.
A revisão seguinte compara contra ESTE milestone, não recomeça do zero.

Perguntas frequentes

❓ A AWS Well-Architected Tool é paga?

Não — não há cobrança pela ferramenta em si, só pelos recursos AWS que ela avalia. É possível registrar workload, responder as perguntas dos seis pilares, gerar plano de melhoria e salvar milestones sem custo adicional algum. O que pode ter custo é contratar uma revisão conduzida por um AWS Partner, que é um serviço diferente e opcional — este laboratório usa exclusivamente a ferramenta gratuita.

❓ Qual a diferença entre risco alto e risco médio no Well-Architected Tool?

Risco alto (HRI) marca uma prática fundacional que, se ausente, pode causar impacto significativo ao negócio — como não proteger a conta AWS. Risco médio (MRI) marca uma prática que melhora substancialmente o workload, mas cujo impacto é menor se ausente — como não rotacionar credenciais periodicamente. A diferença não é urgência absoluta: é quanto a AUSÊNCIA daquela prática específica pesa, e é por isso que o plano de melhoria trata risco alto antes de médio.

❓ Preciso resolver todos os riscos altos antes de terminar a revisão?

Não — a revisão termina quando cada risco está classificado, com dono e prazo, não quando cada um está resolvido. Um risco alto que a empresa aceita conscientemente, por prioridade de negócio ou restrição de arquitetura, continua sendo um risco alto registrado — a diferença é que ele carrega uma justificativa por escrito em vez de ficar invisível. É isso que transforma revisão em documento auditável, e não em lista de tarefas concluídas.

❓ O que é um milestone na AWS Well-Architected Tool?

É uma fotografia congelada das respostas e da contagem de risco de um workload num ponto específico no tempo, com um nome único dentro daquele workload. Depois de salvo, um milestone não muda mesmo que as respostas do workload continuem sendo atualizadas — é contra ele que a próxima revisão compara, para provar se um risco alto realmente diminuiu ou só mudou de descrição.

❓ Um workload no Well-Architected Tool precisa ficar restrito a uma única aplicação?

Não há essa obrigação técnica, mas a prática recomendada é um workload por unidade que se decide e se opera junto — um serviço, uma equipe dona, um conjunto de decisões coerente. Colocar toda a Cadência num workload só fazia sentido enquanto a arquitetura era um monólito; a partir do momento em que serviços se separam, um workload por serviço evita que o risco de um componente pequeno se esconda dentro da média de um workload gigante.

❓ Terraform consegue criar o workload da revisão automaticamente?

Não hoje: o provedor oficial da AWS para Terraform não tem recurso para AWS Well-Architected Tool — o pedido da comunidade para adicioná-lo foi fechado como "não planejado" pelo mantenedor em dezembro de 2023. Isso significa registrar o workload, responder perguntas e salvar milestone via SDK (C#, Python, o que for) ou AWS CLI, e reservar o Terraform para a infraestrutura ao redor da revisão — a cadência automatizada, o armazenamento do relatório, o alarme.

❓ Uma pergunta que não se aplica à minha arquitetura precisa de resposta mesmo assim?

Precisa de uma decisão registrada, não de uma escolha entre as práticas listadas. Marcar IsApplicable como falso, com um motivo do conjunto que a API aceita — fora do escopo, prioridade de negócio, restrição de arquitetura ou outro —, é uma resposta legítima e entra no relatório como tal. O erro comum é pular a pergunta sem marcar nada: aí ela aparece como pendente na próxima revisão, e ninguém lembra por que foi ignorada da primeira vez.

❓ Com que frequência a revisão Well-Architected deve se repetir?

A prática recomendada pela própria AWS é revisar em marcos relevantes do ciclo de desenvolvimento — um lançamento grande, uma mudança de escala, ou pelo menos uma vez por trimestre quando não há marco natural. Uma revisão única resolve o problema de nunca ter revisado nada; uma cadência automatizada, como o agendamento trimestral deste laboratório, evita que a segunda revisão dependa de alguém lembrar — que era exatamente o defeito do plano de DR do L58, escrito uma vez e nunca revisto em dois anos.

Fixando

Quiz rápido

O time acabou de mitigar um risco alto: aplicou a correção na arquitetura, mas esqueceu de chamar UpdateAnswer na pergunta correspondente antes de rodar CreateMilestone para fechar o trimestre. O que o relatório do novo milestone vai mostrar?

Quiz rápido

Depois de responder as perguntas dos seis pilares para a Cadência, o pilar de Sustentabilidade fica com risco ALTO — mesmo sem nenhum incidente relacionado a ele nos 59 laboratórios anteriores. Por que essa classificação é coerente, e não um exagero da revisão?

Conhecimentos, próximo módulo e documentação

Item	Conteúdo
Conhecimentos anteriores necessários	L52 (SLO/error budget), L58 (DR multi-região) e L59 (FinOps/rightsizing) lidos ou no ar; acesso de administrador na conta de exemplo
Conhecimentos adquiridos	os seis pilares e a diferença entre risco alto e médio; o ciclo CreateWorkload → UpdateAnswer → GetLensReview → CreateMilestone; por que risco aceito por escrito é diferente de risco ignorado; por que a Well-Architected Tool não audita infraestrutura, só registra resposta
Limitação que fica	a revisão cobre um workload; a Cadência ainda não tem lens customizado nem revisão obrigatória automatizada antes de lançar serviço novo — isso é o nível 5 da evolução, ainda não construído
Próximo exemplo recomendado	L100 — o projeto final da série, que integra os 99 laboratórios anteriores num sistema completo com revisão Well-Architected e DR ensaiado. Este laboratório é o que ensina a fazer essa revisão
Também habilitado por este módulo	L99 (multi-região para IA, quando a residência de dado entrar em jogo) e L89/L98 (custo e governança em maior escala) partem do mesmo ciclo de revisão formal construído aqui
Data da última validação técnica	8 de agosto de 2026

ItemConhecimentos anteriores necessários

ConteúdoL52 (SLO/error budget), L58 (DR multi-região) e L59 (FinOps/rightsizing) lidos ou no ar; acesso de administrador na conta de exemplo

ItemConhecimentos adquiridos

Conteúdoos seis pilares e a diferença entre risco alto e médio; o ciclo CreateWorkload → UpdateAnswer → GetLensReview → CreateMilestone; por que risco aceito por escrito é diferente de risco ignorado; por que a Well-Architected Tool não audita infraestrutura, só registra resposta

ItemLimitação que fica

Conteúdoa revisão cobre um workload; a Cadência ainda não tem lens customizado nem revisão obrigatória automatizada antes de lançar serviço novo — isso é o nível 5 da evolução, ainda não construído

ItemPróximo exemplo recomendado

ConteúdoL100 — o projeto final da série, que integra os 99 laboratórios anteriores num sistema completo com revisão Well-Architected e DR ensaiado. Este laboratório é o que ensina a fazer essa revisão

ItemTambém habilitado por este módulo

ConteúdoL99 (multi-região para IA, quando a residência de dado entrar em jogo) e L89/L98 (custo e governança em maior escala) partem do mesmo ciclo de revisão formal construído aqui

ItemData da última validação técnica

Conteúdo8 de agosto de 2026

Documentação oficial consultada: AWS Well-Architected Tool User Guide — introdução, os seis pilares e a definição de risco alto e médio com matriz de probabilidade × impacto; AWS Well-Architected Tool FAQs — gratuidade da ferramenta e recomendação de cadência por marco do ciclo de desenvolvimento; e a AWS Well-Architected Tool API Reference — CreateWorkload, UpdateAnswer, CreateMilestone e GetLensReview, para os campos, tipos e valores válidos usados no código deste módulo. A ausência de suporte no provedor oficial da AWS para Terraform está registrada na issue #34844 do repositório `hashicorp/terraform-provider-aws`, fechada como "not planned" — não é documentação oficial da AWS, mas confirma o estado do provedor na data desta escrita. Os valores de preço não aparecem neste módulo por decisão: a ferramenta em si é gratuita, e o restante varia por região e uso.

⚠️

O que não foi verificado, e você deve conferir antes de aplicar

Os IDs de pergunta e de escolha usados no código (`REL_02`, `reliability_test_failover`, e os demais) são ilustrativos: a AWS não publica um dicionário estável de `QuestionId`/`ChoiceId` por documentação de referência — eles pertencem à versão do lens aplicada e se leem em tempo de execução com `GetAnswer`. Da mesma forma, os nomes exatos das chaves em `RiskCounts` (aqui tratadas como `"HIGH"`/`"MEDIUM"`) seguem o padrão observado em exemplos de terceiros sobre a API; confirme a grafia exata na resposta real de `GetLensReview` na sua conta antes de constar num script de produção. A permissão de `wellarchitected:CreateWorkload` sem recurso restrito também não foi confirmada por leitura completa da AWS Service Authorization Reference — siga o padrão geral (toda ação de criação sem recurso prévio pede `"*"`, como o próprio L03 já mostrou para o ECR) e confirme testando `iam:SimulatePrincipalPolicy` na sua conta.

Terminou de ler?

Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.

Próximos passos sugeridos

🔀

Lab 61 — Do operacional ao analítico: por que não consultar a produção

100 Laboratórios de Arquitetura AWS · 37 min · +135 XP

→

Temas deste módulo

Serviços AWS

Discussão

Carregando comentários…