A conta AWS mais cara nem sempre é a que processa a maior carga, mas a que nasceu sem responsável, limites de acesso ou atribuição de custos. Uma boa fundação torna o comportamento seguro o padrão e dá a cada recurso um dono, ambiente, trilha de auditoria e orçamento antes de a produção começar.
Landing zone: separe controle, evidência e workloads
SCP define a permissão máxima disponível. As policies IAM ainda concedem a permissão efetiva dentro de cada conta.
Adote uma landing zone com múltiplas contas
Crie uma AWS Organization e mantenha a management account sem workloads. No mínimo, separe segurança, arquivo de logs, serviços compartilhados, produção e não produção. Empresas maiores podem dividir por unidade e produto, mas devem evitar proliferação sem automação de ciclo de vida. A AWS recomenda limitar o acesso à management account porque SCPs não restringem as identidades dela; consulte as boas práticas da conta de gerenciamento.
O AWS Control Tower pode montar a landing zone, matricular contas e aplicar controles. Ele não substitui decisões arquiteturais: defina antes as organizational units, o processo de criação, Regions permitidas, residência de dados, exceções e administradores delegados.
Desenhe OUs pela política, não pelo organograma
Uma organizational unit existe para receber um conjunto coerente de controles. Produção pode negar RDS público e Regions não aprovadas; sandbox pode permitir experimentação mais ampla, mas limitar gasto e bloquear dados corporativos. Se duas contas exigem políticas materialmente diferentes, colocá-las na mesma OU gera exceções que enfraquecem o modelo. Mantenha SCPs pequenas e teste a permissão efetiva: SCP nunca concede acesso, apenas limita o que IAM poderia conceder.
Defina o ciclo de vida da conta: solicitação, aprovação, provisionamento automático, verificação do baseline, revisão de dono, quarentena e encerramento. Use aliases de e-mail e nomes que não dependam de uma pessoa. A quarentena importa porque fechar imediatamente uma conta desconhecida pode destruir evidência.
Proteja identidades antes de criar recursos
- Proteja o root, habilite MFA, remova access keys do root e documente um acesso de emergência monitorado.
- Use IAM Identity Center integrado ao provedor corporativo para pessoas; workloads devem assumir roles temporárias.
- Crie permission sets por função, exija MFA e separe leitura, operação e administração.
- Aplique menor privilégio e permission boundaries para times delegados. Evite usuários compartilhados e chaves permanentes.
O guia de segurança de login da AWS recomenda MFA no root e um administrador no IAM Identity Center, em vez do uso cotidiano do root.
Separe identidade humana, workload e emergência
Acesso humano deve nascer no provedor corporativo, ser baseado em grupos e gerar sessões curtas. Workloads assumem roles pela identidade do runtime ou CI/CD; access key em código ou segredo compartilhado não tem rotação aceitável. Emergência é um terceiro caminho: credencial restrita, MFA, monitoramento imediato e teste periódico. Se o procedimento nunca foi ensaiado durante indisponibilidade do IdP, ele é documentação, não resiliência.
Torne a auditoria difícil de adulterar
Habilite CloudTrail organizacional em todas as Regions e envie os eventos para a conta dedicada de log archive, com criptografia, retenção e exclusão restrita. Use AWS Config quando precisar de histórico de configuração e evidência de conformidade. Centralize achados do GuardDuty, Security Hub e IAM Access Analyzer na conta de segurança. Alerte sobre uso do root, falhas de login, alterações no CloudTrail e KMS, storage público e exposição em security groups.
Separe coleta, detecção e resposta. CloudTrail responde quem chamou uma API AWS; VPC Flow Logs mostra aceite e rejeição de rede; logs do RDS/PostgreSQL mostram autenticação e eventos SQL; AWS Config registra estado dos recursos. Um não substitui o outro. Normalize timestamps, defina retenção pela evidência necessária e confirme que uma conta de workload comprometida não apaga a cópia central.
Defina o padrão de rede e proteção de dados
Padronize endereçamento de VPC, camadas de sub-rede, saída, DNS e conectividade. Bancos ficam em sub-redes privadas e aceitam tráfego apenas de security groups explícitos de aplicação ou administração. Criptografe em repouso com uma estratégia consciente de KMS, exija TLS, guarde credenciais no Secrets Manager e teste rotação. Decida como backups atravessam contas e Regions e prove a restauração.
Deixe os limites de disponibilidade explícitos
Uma sub-rede na segunda AZ só ajuda se aplicação, rotas, dependência de NAT/egress e failover do banco também sobreviverem à primeira. Segunda Region é projeto de recuperação, não checkbox: defina dados copiados, presença de chaves e secrets, mudança de DNS, infraestrutura pré-provisionada e qual inconsistência cabe no RPO.
Instale controles de custo no primeiro dia
- Crie budgets por conta e produto, com alertas para responsáveis e finanças.
- Habilite Cost Explorer, Cost and Usage Reports, Cost Anomaly Detection e Cost Optimization Hub.
- Defina tags obrigatórias como
Owner,Application,Environment,CostCenter,DataClassificationeManagedBy; ative as tags de alocação relevantes. - Crie políticas para Regions e famílias de instâncias permitidas, retenção de snapshots e deletion protection.
Tags alimentam sistemas diferentes: finanças precisa alocação, operação precisa ownership, segurança precisa classificação e automação precisa intenção de ciclo de vida. Defina valores permitidos e herança. Tag policy padroniza chaves/valores, mas um controle de deploy ou remediação é necessário quando a ausência deve bloquear ou corrigir criação. Combine budgets e anomalias: budget acompanha acúmulo esperado; anomaly detection encontra mudança inesperada de formato.
Codifique e verifique continuamente
Construa contas, redes, roles, logging e alertas em Terraform, CloudFormation ou CDK. Revise mudanças por pull request e faça deploy com roles temporárias no CI/CD. O teste de “dia zero” deve provar que uma conta nova recebe identidade, logs, controles, budgets e rede automaticamente. Revalide essas evidências: governança também sofre drift.
Checklist para produção: dono definido, root protegido, acesso federado, workload isolado, CloudTrail centralizado, segurança delegada, budgets ativos, tags exigidas, banco em rede privada, restore testado e código da fundação versionado.
Como o PG Monitoring ajuda depois da fundação AWS
A governança prova que o RDS está criptografado, privado e com tags; ela não prova que autovacuum acompanha a carga, um plano está estável, a replicação cumpre SLA ou a capacidade sobrevive ao próximo pico. O PG Monitoring fecha essa lacuna operacional com role PostgreSQL de menor privilégio, visão isolada por organização e histórico entre instâncias. A equipe correlaciona incidentes, queries, locks, bloat, replicação e crescimento sem dar acesso AWS amplo ou privilégio de DBA a todo operador.
Resultado prático: a landing zone governa onde o banco pode rodar; o PG Monitoring mostra se ele está saudável e se seu comportamento é explicável. Fale com nossa equipe para incluir um baseline de observabilidade PostgreSQL na sua fábrica de contas AWS.