Revisão Well-Architected da AWS

Este fluxo de trabalho realiza uma revisão estruturada do AWS Well-Architected Framework (WAF) nos arquivos de IaC e na infraestrutura implantada da sua carga de trabalho. Ele identifica riscos em todos os 6 pilares do WAF e cria issues no GitHub para rastrear a remediação.

Pré-requisitos

• AWS CLI configurado e autenticado
• Arquivos de IaC presentes no repositório (Terraform, CloudFormation, CDK ou SAM)
• Servidor GitHub MCP configurado e autenticado

Etapas do Fluxo de Trabalho

Etapa 1: Carregar Referência do Well-Architected Framework

Busque as melhores práticas atuais do AWS WAF:

• https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html
• Lentes específicas de pilar relevantes para o tipo de carga de trabalho (Serverless, SaaS, etc.)

Etapa 2: Descobrir IaC e Arquitetura

Escaneie o repositório em busca de arquivos de IaC:

• Terraform: **/*.tf
• CloudFormation/SAM: **/*.yaml, **/*.json (templates CFn)
• CDK: lib/**/*.ts, bin/**/*.ts, cdk.json

Identifique os principais serviços da AWS em uso (computação, dados, rede, segurança, observabilidade) e gere um diagrama de arquitetura Mermaid.

Etapa 3: Revisão Pilar por Pilar

Pilar 1: Excelência Operacional

• Toda a infraestrutura definida como IaC (sem alterações manuais no console)
• Estratégia de marcação consistente aplicada em todos os recursos
• Alarmes do CloudWatch definidos para métricas chave
• Pipeline de implantação automatizado presente (sem implantações manuais)
• CloudTrail habilitado para registro de auditoria
• Runbooks ou documentação operacional presente

Pilar 2: Segurança

• Funções IAM usam políticas de privilégio mínimo (sem ações * sem justificativa)
• Credenciais não codificadas em IaC ou código
• Segredos gerenciados via Secrets Manager ou SSM Parameter Store
• Buckets S3 têm acesso público bloqueado e criptografia do lado do servidor habilitada
• Recursos sensíveis colocados em sub-redes privadas
• Grupos de segurança restringem o tráfego de entrada às portas/CIDRs mínimos necessários
• Criptografia KMS habilitada para armazenamentos de dados sensíveis (RDS, EBS, S3, SQS, DynamoDB)
• SSL/TLS imposto em todos os endpoints (enforceSSL: true)
• GuardDuty habilitado (aws guardduty list-detectors)
• AWS WAF configurado em APIs voltadas para o público e distribuições CloudFront
• Exclusão MFA habilitada em buckets S3 críticos

Pilar 3: Confiabilidade

• Implantações Multi-AZ para bancos de dados de produção (RDS Multi-AZ, Tabelas Globais DynamoDB)
• Auto Scaling configurado com políticas apropriadas para EC2/ECS
• Versionamento S3 e políticas de ciclo de vida configurados
• Backups automáticos do RDS habilitados com período de retenção apropriado
• Recuperação de Ponto no Tempo (PITR) do DynamoDB habilitada
• Filas de Mensagens Mortas (DLQ) configuradas para Lambda, SQS, SNS
• Verificações de integridade do Route 53 configuradas para failover de DNS
• Concorrência reservada do Lambda definida para evitar throttling de vizinho barulhento

Pilar 4: Eficiência de Desempenho

• Tipos de instância com dimensionamento correto (memória Lambda, tipo EC2, classe RDS)
• Instâncias Graviton/ARM usadas onde disponíveis (Lambda arm64, EC2 Graviton)
• Cache implementado (ElastiCache, DAX, CloudFront, cache API Gateway)
• CloudFront usado para entrega de conteúdo estático global
• Aurora Serverless ou DynamoDB On-Demand para padrões de carga variável
• Concorrência Provisionada do Lambda para caminhos síncronos críticos de latência

Pilar 5: Otimização de Custo

• Instâncias Reservadas EC2 ou Planos de Economia para cargas de trabalho em estado estável
• Políticas de ciclo de vida S3 movendo dados para camadas de armazenamento mais baratas
• Arquitetura Lambda arm64 adotada (redução de 20% no custo)
• Endpoints VPC para S3/DynamoDB para evitar cobranças do NAT Gateway
• Volumes EBS gp2 migrados para gp3 (mesmo desempenho, 20% mais barato)
• Ambientes de desenvolvimento/teste com agendamentos de desligamento automático
• Orçamentos AWS e Detecção de Anomalias de Custo configurados
• Volumes EBS não anexados e instâncias EC2 ociosas identificadas

Pilar 6: Sustentabilidade

• Instâncias Graviton/ARM selecionadas onde disponíveis
• Serviços Serverless/gerenciados preferidos em vez de EC2 sempre ativo
• Políticas de ciclo de vida S3 reduzem o armazenamento de dados desnecessário a longo prazo
• Auto Scaling configurado para evitar provisionamento excessivo
• Seleção de região considera os compromissos de energia renovável da AWS

Etapa 4: Classificação de Risco

Para cada descoberta, classifique:

• Alto Risco: Vulnerabilidade de segurança, ponto único de falha, sem backup/recuperação
• Médio Risco: Confiabilidade subótima, ineficiência de custo, preocupação de desempenho
• Baixo Risco: Desvio de melhores práticas, oportunidade de otimização menor

Etapa 5: Confirmação do Usuário