Ambientes na nuvem costumam crescer aos poucos. Um servidor para um projeto, um banco para outro, uma regra de rede aberta para resolver um problema urgente. Depois de alguns anos, o ambiente funciona, mas ninguém sabe dizer com segurança se ele está bem construído. O AWS Well-Architected Framework existe para responder a essa pergunta de forma estruturada. Neste artigo, explicamos o que ele é, como funciona uma revisão e o que fazer com o resultado.
O que é o Well-Architected Framework
É o conjunto de boas práticas que a AWS publica para avaliar arquiteturas na nuvem. Ele é organizado em seis pilares:
- Excelência operacional: como o ambiente é operado, monitorado e melhorado.
- Segurança: identidades, permissões, proteção de dados e resposta a incidentes.
- Confiabilidade: capacidade de se recuperar de falhas e atender à demanda.
- Eficiência de desempenho: uso adequado dos recursos à medida que a carga muda.
- Otimização de custos: pagar apenas pelo que gera valor.
- Sustentabilidade: reduzir o impacto ambiental da carga de trabalho.
Cada pilar traz perguntas e boas práticas. A AWS Well-Architected Tool, disponível no console sem custo, registra as respostas e gera um relatório com os riscos classificados em alto e médio. Para cargas específicas também existem as lentes (lenses), como serverless, análise de dados e IA generativa.
Como funciona uma revisão na prática
Uma revisão bem feita começa pelo escopo. Em vez de avaliar a conta inteira, escolhemos uma carga de trabalho importante para o negócio, como o ERP, o e-commerce ou a plataforma de dados.
Depois vem a coleta. Com uma role IAM somente leitura, cruzamos as informações de serviços que a própria AWS oferece: AWS Config para a configuração dos recursos, AWS Security Hub e AWS Trusted Advisor para alertas de segurança e boas práticas, AWS Cost Explorer e AWS Compute Optimizer para custo e dimensionamento.
A terceira etapa é a conversa com o time. Boa parte das perguntas do framework é sobre processo, e não sobre configuração: como as mudanças chegam à produção, quem é avisado quando algo falha, quando a restauração do backup foi testada pela última vez. Essas respostas não aparecem no console.
Por fim, tudo é registrado na Well-Architected Tool, que gera o relatório de riscos.
Os achados mais comuns
Alguns pontos aparecem com frequência em ambientes que cresceram sem uma revisão:
- Conta root sem MFA, ou usuários IAM com chaves de acesso antigas e permissões amplas.
- AWS CloudTrail sem cobrir todas as regiões e Amazon GuardDuty desligado.
- Banco de dados de produção sem Multi-AZ, e backup que existe mas nunca foi restaurado em teste.
- Instâncias superdimensionadas, volumes EBS sem uso e snapshots esquecidos.
- Recursos sem tags e nenhum alerta de orçamento configurado no AWS Budgets.
- Deploy manual, sem infraestrutura como código.
Nenhum desses itens é raro. E quase todos têm correção simples quando alguém para e olha.
Do relatório ao plano
O relatório só tem valor se virar ação. A ordem que costuma funcionar:
- Riscos altos de segurança e confiabilidade primeiro. São os que podem parar a empresa ou expor dados.
- Ganhos rápidos de custo. Desligar o que não é usado e ajustar o tamanho das instâncias costuma pagar parte do esforço.
- O restante vira roadmap, com responsável e prazo.
A Well-Architected Tool permite salvar marcos (milestones) e comparar a evolução entre uma revisão e outra. Repetir o exercício a cada seis ou doze meses, ou depois de uma mudança grande, evita que o ambiente volte a crescer sem controle.
Conclusão
Uma revisão Well-Architected não serve para dar nota ao ambiente. Ela mostra, com critério, onde estão os riscos que importam e o que fazer primeiro. Para quem já está na AWS, é a forma mais objetiva de transformar a sensação de que "tem coisa para arrumar" em um plano concreto.