Well-Architected Framework aplicado em review
- ⬜💰 Cost allocation tags em escala + Cost Categories(AWS Solutions Architect Professional (SAP-C03))
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
Os 6 pilares
Operational Excellence:
Executar workloads com eficiência e melhorar continuamente.
Práticas: IaC, runbooks, game days, post-mortems, deploy frequente
e pequeno, rollback automático.
Security:
Proteger sistemas e dados, habilitar delivery segura.
Práticas: least privilege, defense in depth, encryption
at-rest/in-transit, automated response (GuardDuty + Lambda).
Reliability:
Workloads performam corretamente mesmo em falhas.
Práticas: multi-AZ, auto-recovery, throttling, circuit breakers,
chaos engineering, RPO/RTO definidos por tier.
Performance Efficiency:
Usar recursos computacionais de forma eficiente.
Práticas: escolha informada de instance types, managed
services onde cabem, caching, async onde possível.
Cost Optimization:
Evitar gasto desnecessário, pagar pelo que entrega valor.
Práticas: rightsizing contínuo, commitments, Spot onde tolera,
storage tiering, automation pra desligar dev à noite.
Sustainability:
Minimizar impacto ambiental de workloads cloud.
Práticas: região limpa, Graviton/ARM, managed efficient,
data lifecycle, código eficiente (menos ciclos CPU = menos CO2).- → aplica lente
- → entra primeiro
- → evidência
- → evidência
- → próximo ciclo
- Gestão e governança
- Segurança e identidade
- Fora da AWS
Well-Architected não é checklist para passar: é um processo com carga definida, risco classificado e plano com dono. A questão do SAP costuma testar exatamente isso — o que fazer com o resultado do review.
- Review é por carga, não por conta. Uma aplicação com fronteira clara e um dono. Tentar revisar "a AWS da empresa" gera resposta genérica que não vira ação — e é o erro mais comum de quem faz o primeiro review.
- Lens especializa as perguntas. A lente Serverless pergunta sobre cold start e idempotência; a de GenAI sobre custo de token e alucinação. Usar só a lente padrão em carga especializada deixa risco de fora.
- HRI é o que muda a prioridade. A ferramenta classifica em risco alto e médio. HRI vai para o topo do backlog independente de quanto custa arrumar — é assim que review deixa de ser relatório e passa a ser plano.
- Sem dono e prazo, não é plano. Cada item precisa de responsável, esforço estimado e data. Lista de recomendação sem dono é o que faz o segundo review encontrar os mesmos riscos do primeiro.
- Trusted Advisor e Config dão a evidência. Eles automatizam parte das respostas: instância ociosa, bucket público, sem Multi-AZ. Isso encurta o review e o torna verificável em vez de opinativo.
Onde isso entra no exame
O exame usa os pilares como critério de decisão, não como teoria. Dada uma arquitetura existente e um problema, a resposta correta é a que resolve o pilar citado sem violar outro — e reconhecer o trade-off explícito (pagar mais por resiliência, aceitar latência por custo) é exatamente o que se cobra.
Review estruturada em ciclo
WA review não é evento único. Cadence realista: workload novo → review inicial pré-prod; workloads em operação → review trimestral leve; pós-incidente grande → review focada no pilar afetado. Cada review gera backlog concreto, com owner, deadline e follow-up na próxima.
Output típico de WA review (workload "checkout-api"):
High-Risk Items (HRI):
- [Security] Secrets ainda em env vars (não Secrets Manager)
- [Reliability] Single-AZ RDS em prod
- [CostOpt] No commitments em workload stable de 18 meses
Medium-Risk Items (MRI):
- [OpEx] Runbook de rollback não testado em 2024
- [PerfEff] EC2 m5.2xlarge em workload que usa 15% CPU
- [Sustain] Logs retention 7 anos em bucket sem lifecycle
Improvement plan (Q2):
- Migrate secrets to SM (owner: security, due: M+30d)
- Enable RDS Multi-AZ (owner: checkout-team, due: M+14d)
- Purchase 1-year Compute Savings Plan (owner: finops)Um Well-Architected Review deve ser feito sobre o quê?
Lenses e integrações
Lenses adicionam perguntas específicas por domínio sem duplicar os 6 pilares: Serverless Lens, Machine Learning Lens, SaaS Lens, IoT Lens, Hybrid Networking Lens. Você ativa lens por workload. WA Tool também puxa findings automáticos de Trusted Advisor (com Business Support) e Config — reduz trabalho manual.
Regra prática: cada workload tem entry no WA Tool + lens relevante ativada + review agendada no calendário. Sem isso, "fazemos Well-Architected" é folclore corporativo.
Perguntas frequentes
❓ Como conduzir uma revisão de Well-Architected de verdade?
❓ Os pilares entram em conflito?
❓ Qual pilar priorizar quando não há tempo para tudo?
Fixando
O que fazer com um High Risk Issue (HRI) identificado no review?
Para que servem as Lenses do Well-Architected?
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
Temas deste módulo
Discussão
Carregando comentários…