Boas práticas

Estas são as lições que normalmente você só aprende depois de levar uns tombos em produção. Tente economizar a queda.

Segurança

• Princípio do menor privilégio: a IAM Role da sua EC2 que só precisa LER de um bucket não deve ter s3:* nem s3:DeleteObject.
• MFA na conta root: ative autenticação em 2 fatores no usuário root e nunca mais use ele para nada. Crie usuários IAM.
• Secrets Manager / Parameter Store: nunca, jamais, em hipótese alguma, deixe senhas, tokens ou access keys no código ou no .env commitado.
• Security Groups apertados: não libere 0.0.0.0/0 nas portas 22 (SSH) e 3306/5432 (banco). SSH só do seu IP, banco só do SG da aplicação.
• Criptografia em repouso e em trânsito: ative encryption no S3, RDS e EBS. Use HTTPS sempre (gratuito com ACM).
• VPC Flow Logs e CloudTrail: logs de quem fez o quê e qual pacote trafegou. Auditoria.

Custos

• AWS Budgets: crie um orçamento e seja alertado por email quando atingir 50%, 80%, 100%.
• Tags em tudo: Environment=prod, Project=loja-joao, Owner=time-pagamentos. Sem tags, você não consegue saber para onde foi a fatura.
• Desligue o que não usa: ambiente de dev parado de noite e fim de semana? Use Instance Scheduler.
• Reserved Instances / Savings Plans: se você sabe que vai rodar uma carga 24/7 por 1 ano, comprometa-se. Economia de 30-70%.
• Right-sizing: aquela t3.large que está com 5% de CPU pode virar t3.small. Use o Compute Optimizer da AWS, ele recomenda automaticamente.
• Cuidado com NAT Gateway: ele cobra por GB processado. Tráfego pesado para internet via NAT pode estourar o orçamento.

Arquitetura

• Stateless sempre que possível: não guarde sessão de usuário na memória do servidor. Use Redis (ElastiCache) ou JWT.
• Idempotência: a mesma requisição executada 2x deve dar o mesmo resultado. Crucial para retries seguros.
• Multi-AZ desde o dia 1: não adianta tornar Multi-AZ depois de cair. Comece distribuído.
• Health checks de verdade: o /health da sua aplicação deve checar conexão com banco e dependências críticas, não só retornar 200.
• Filas para tarefas longas: não deixe o cliente esperando enquanto você processa um PDF de 50MB. Mande para SQS e processe em background.
• Cache agressivo: ElastiCache (Redis) na frente do banco salva dinheiro e latência. CloudFront na frente da API para conteúdo cacheável.

Operação

• Infraestrutura como código (IaC): Terraform ou AWS CDK. Esqueça o ClickOps em produção.
• Ambientes separados: dev, staging e prod em CONTAS AWS DIFERENTES (use AWS Organizations). Reduz blast radius.
• Backups testados: backup que você nunca restaurou não existe. Faça drill periódico.
• Runbooks: documente o que fazer quando o alerta X dispara. Às 3h da manhã, você sonolento agradece.
• Postmortem sem blame: quando algo der errado (e vai dar), foque em "como o sistema permitiu isso" e não em "quem errou".

Os 6 pilares do Well-Architected Framework

A AWS publica o Well-Architected Framework, um guia oficial com 6 pilares:

1. Excelência operacional
2. Segurança
3. Confiabilidade
4. Eficiência de performance
5. Otimização de custo
6. Sustentabilidade

Vale uma leitura quando você quiser ir mais fundo. A AWS oferece a Well-Architected Tool gratuita que faz uma auditoria da sua arquitetura.